> - Linux developers often do horribly stupid things, and use 64-bit
> division etc instead of using a simple shift. Again, not linking
> against libgcc finds those things early rather than late, because the
> horribly stupid things end up requireing libgcc support.
I would have thought that the compiler would generate a shift if it
could (I'm presuming you're talking about shifting by a constant
here -- or are you talking about code that always shifts by a
computed power of two).
> In the case of __ucmpdi2, it appears to be a combination of kernel and
> compiler stupidity - there's no reason why __ucmpdi2 should not be done
> inline by the compiler, but at the same time there is probably also
> little reason to use a slow "long long" comparison in the kernel.
Little reason or no reason? If there is a reason, and it doesn't
work, then the coder is forced to rewrite using 32 bit variables,
synthesizing the result. Then you have belabored C code as well
as belabored machine code, and it doesn't automatically clean up
when you move to a 64 bit machine.
> So again, not linking libgcc showed a problem. Good for us.
(Un)fortunately, it was only the switch that caused the problem.
Other expressions using 64 bit variables work fine. So you can
use:
if ((uint64_t) x == (uint64_t) y)
...
all you want.
So what we've said is: 64 bit is okay, except in a switch statement,
or other random expressions that might cause gcc to embed a call to
similar libgcc function. If you run into that, figure out what
caused it (presumably by disassembling and comparing with source),
and then use a different construction (that may be more obtuse).
If you can, change to 32 bits. And you may be forced to.
> But yes, it is often much more convenient to not know about problems
> like this. And some people don't think they are a big deal. I'd rather
> nip them in the bud early than be "convenient", myself.
>
> Linus
jeremy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
