On Thu, 1 Nov 2007, Ralf Baechle wrote:
> > I'm not sure if this is always a compile-time constant so that you can adorn
> > it with a LL. However, note that this is not a cast, a cast is at runtime.
> No. The compiler can evaluate the cast of a constant value at compile
> time and that exactly is what the code is exploiting here.
Except that some versions of GCC "forget" to stop a warning here as
irrelevant after the cast, hence the need for the stupid "#ifdef", sigh...
> > > if (sp >= (long)CKSEG0 && sp < (long)CKSEG2)
> > > usp = CKSEG1ADDR(sp);
> > > #ifdef CONFIG_64BIT
> > > - else if ((long long)sp >= (long long)PHYS_TO_XKPHYS(0LL, 0) &&
> > > - (long long)sp < (long long)PHYS_TO_XKPHYS(8LL, 0))
> > > - usp = PHYS_TO_XKPHYS((long long)K_CALG_UNCACHED,
> > > + else if ((long long)sp >= (long long)PHYS_TO_XKPHYS(0, 0) &&
> > > + (long long)sp < (long long)PHYS_TO_XKPHYS(8, 0))
> > > + usp = PHYS_TO_XKPHYS(K_CALG_UNCACHED,
> > > XKPHYS_TO_PHYS((long long)sp));
> > I'd say this code is broken in way too many aspects:
> > 1. A plethora of casts. PHYS_TO_XKPHYS() should return a physical address
> > (i.e. 32 or 64 bits unsigned integer) already, so casting its result should
> > not be necessary.
> No argument about the beauty of the whole thing.
The casts were an attempt by myself to shut up GCC warning about
comparisons giving a predictable result because of a limited size of the
data type used. Of course this is no longer true with "long long", but
GCC does not care and warns regardless.
A possible workaround would be using auxiliary variables of the "long
long" type, but I recall it making GCC produce worse code for some cases.
I can check it again, since it has been a while, and if a recent version
of GCC produces reasonable code, then I can try to recheck this approach.
Please note this code changes quite wildly depending on the exact
configuration, so chances are GCC may warn with one, but not another.