From: "Marko Kreen" <markokr@gmail.com>
To: Pavel Roskin <proski@gnu.org>
Cc: linux-sparse@vger.kernel.org
Subject: Re: confusing shift warning
Date: Fri, 25 Apr 2008 20:26:07 +0300 [thread overview]
Message-ID: <e51f66da0804251026y4c6fbc25scedf04ab6c7dd6a0@mail.gmail.com> (raw)
In-Reply-To: <1209139485.11744.25.camel@dv>
On 4/25/08, Pavel Roskin <proski@gnu.org> wrote:
> On Fri, 2008-04-25 at 17:37 +0300, Marko Kreen wrote:
> > > I mean, they are both 0 unless -m32 or -m64 is specified.
> >
> > No, see other sections - they assume one of them is set unless overrided.
>
> If you are fixing a bug, you cannot rely on the code being correct. Try
> printing those variables:
>
> printf("m32=%d, m64=%d\n", $m32, $m64);
>
> It will be two zeroes.
I think you have misunderstood the point of the variables - they
only signify whether either argument was given on command line,
nothing more. Each arch defaults implicitly to either of them,
so it needs to check if the other one was given, overriding the default.
> > > > Or do you mean I cannot assume one of them as set, unless
> > > > overrided on command line? But other sections (spact, i86, ppc)
> > > > do exactly that?
> > >
> > > You cannot assume either of them to be 1 until cgcc is fixed.
> >
> > But how should the fix look like if you don't like mine?
>
> Well, it looks like cgcc is seriously broken. In particular, it would
> define x86_64 even if -m32 is specified, but it should define i386
> instead.
You may be right here. Seems like the x86_64 arch was tested only
with kernel compiles with -m64 always given.
> Also, cgcc looks at uname output to determine the target CPU. That
> would default to 64 bit if a 32-bit system runs on a 64-bit kernel. I
> think cgcc should be running gcc instead to dump the machine settings.
> I realize that it might be slower, but correctness is important here.
> On the other hand, I'm not sure if we can rely on having gcc installed.
>
> I would probably introduce a variable that would hold the memory model.
> It could be ILP32 or LP64, but we could eventually support LLP64 (win64)
> and even LP32 (win16). It could be determined based on -m32/-m64
> switches and uname output, but be could switch to "gcc -dumpmachine"
> later.
>
> The architecture would be adjusted based on the selected memory model.
> And then it would be passed to add_specs().
Ok, this is somewhat of out my league. But I think that having good
default and forcing user to use -mX for non-default case is good enough.
--
marko
prev parent reply other threads:[~2008-04-25 17:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-25 7:53 confusing shift warning Marko Kreen
2008-04-25 8:03 ` Marko Kreen
[not found] ` <33544769883882222@unknownmsgid>
2008-04-25 8:34 ` Marko Kreen
2008-04-25 8:58 ` Marko Kreen
[not found] ` <-3423297637585954490@unknownmsgid>
2008-04-25 13:37 ` Marko Kreen
[not found] ` <-8184754938437793631@unknownmsgid>
2008-04-25 14:37 ` Marko Kreen
2008-04-25 16:04 ` Pavel Roskin
2008-04-25 17:26 ` Marko Kreen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e51f66da0804251026y4c6fbc25scedf04ab6c7dd6a0@mail.gmail.com \
--to=markokr@gmail.com \
--cc=linux-sparse@vger.kernel.org \
--cc=proski@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).