Hi.
I ask because I've just built a kernel without using that flag -
linus-2.5 BK from this morning, probably missing the 2.5.60 release by
a few hours. I'm now running with the kernel, and things are working
normally. So, my success with my strictly aliased kernel has made me curious
if the continuing use of the flag has outlived its usefulness. I'm
running on i586, compiling with gcc-3.2.2 (CVS). Possibly the flag is
needed for other chipsets or older compilers, or particular bits of code
that I don't compile. Still, I thought I'd ask and see. Maybe other
people can try building without '-fno-strict-aliasing' and see what sort
of results they get.
I'm not including my config file to save space, but can send it if
asked.
Art Haas
--
They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety.
-- Benjamin Franklin, Historical Review of Pennsylvania, 1759
Art Haas <[email protected]> said:
> I ask because I've just built a kernel without using that flag -
> linus-2.5 BK from this morning, probably missing the 2.5.60 release by
> a few hours.
The problem with strict aliasing is that it allows the compiler to assume
that in:
void somefunc(int *foo, int *bar)
foo and bar will _*never*_ point to the same memory area (at the same
struct, or into the same array, etc). There is no way to check for this in
the compiler in general (the function and the call might be in different
files, many functions are being called via pointers, ...).
That it did not bite you (yet, or perhaps you haven't noticed) doesn't mean
anything. Perhaps the compiler didn't make use of it (as of this version),
perhaps you did not hit a problem with optimized code (yet). Or perhaps the
kernel is clean WRT this. Your bet.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Horst von Brand <[email protected]> writes:
|> Art Haas <[email protected]> said:
|> > I ask because I've just built a kernel without using that flag -
|> > linus-2.5 BK from this morning, probably missing the 2.5.60 release by
|> > a few hours.
|>
|> The problem with strict aliasing is that it allows the compiler to assume
|> that in:
|>
|> void somefunc(int *foo, int *bar)
|>
|> foo and bar will _*never*_ point to the same memory area
This is wrong. Only if they are declared restrict.
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 N?rnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Andreas Schwab <[email protected]> said:
> Horst von Brand <[email protected]> writes:
>
> |> Art Haas <[email protected]> said:
> |> > I ask because I've just built a kernel without using that flag -
> |> > linus-2.5 BK from this morning, probably missing the 2.5.60 release by
> |> > a few hours.
> |>
> |> The problem with strict aliasing is that it allows the compiler to assume
> |> that in:
> |>
> |> void somefunc(int *foo, int *bar)
> |>
> |> foo and bar will _*never*_ point to the same memory area
>
> This is wrong. Only if they are declared restrict.
... can they point to the same area. That is exactly the problem: If you do
nothing, the language definition assumes the programmer made sure (LOL!)
that they don't point the same way. That's why the flag is needed in the
first place, as nobody writes "restrict" all over the place. I got biten by
that when the optimizations (and the flag) were introduced into gcc (egcs
branch perhaps?).
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Horst von Brand <[email protected]> writes:
|> Andreas Schwab <[email protected]> said:
|> > Horst von Brand <[email protected]> writes:
|> >
|> > |> Art Haas <[email protected]> said:
|> > |> > I ask because I've just built a kernel without using that flag -
|> > |> > linus-2.5 BK from this morning, probably missing the 2.5.60 release by
|> > |> > a few hours.
|> > |>
|> > |> The problem with strict aliasing is that it allows the compiler to assume
|> > |> that in:
|> > |>
|> > |> void somefunc(int *foo, int *bar)
|> > |>
|> > |> foo and bar will _*never*_ point to the same memory area
|> >
|> > This is wrong. Only if they are declared restrict.
|>
|> ... can they point to the same area. That is exactly the problem: If you do
|> nothing, the language definition assumes the programmer made sure (LOL!)
|> that they don't point the same way.
Why are you insisting on spreading misinformation?
Pointers that are _not_ declared as restricted can alias _any_ other
non-restricted pointer of the same target type.
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 N?rnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Horst von Brand wrote:
>
> Art Haas <[email protected]> said:
> > I ask because I've just built a kernel without using that flag -
> > linus-2.5 BK from this morning, probably missing the 2.5.60 release by
> > a few hours.
>
> The problem with strict aliasing is that it allows the compiler to assume
> that in:
>
> void somefunc(int *foo, int *bar)
>
> foo and bar will _*never*_ point to the same memory area (at the same
> struct, or into the same array, etc). There is no way to check for this in
> the compiler in general (the function and the call might be in different
> files, many functions are being called via pointers, ...).
I though pointers to the same type, such as int *, could alias still.
But pointers to different types, such as int* and short* is assumed
to never clash with strict aliasing. And this bites linux
because it sometimes choose to see "two adjacent shorts as one int" for
performance reasons.
I remember the flag was introduced because some IP or TCP
code do exactly this, and converting it all to unions would
render that code unreadable.
Helge Hafting
Quoting various people:
> The problem with strict aliasing is that it allows
> the compiler to assume that in:
>
> void somefunc(int *foo, int *bar)
>
> foo and bar will _*never*_ point to the same memory area
Nope, because foo and bar are compatible types.
These are compatible:
int*, unsigned*, const signed int *, register int*, etc.
For a pointer to an integer type, it pretty much boils
down to "compatible ones are the same size on an Alpha".
There is a special exception for (char*) though, and
a poorly-documented "restrict" keyword to let the compiler
know when aliasing (pointing to the same memory) won't happen.
Here are some examples:
#define restrict __restrict__ // or do "gcc -std=c99"
int fn(int *foo, int *bar); // may alias
int fn(int *foo, int *restrict bar); // may NOT alias
int fn(int *foo, long *bar); // may NOT alias
int fn(int *foo, char *bar); // may alias (char exception)
int fn(int *foo, char *restrict bar); // restrict w/ (char*) ?
int fn(int *restrict foo, char *bar); // restrict w/ (char*) ?
// New gcc feature, due to Linus complaining:
typedef unsigned long __attribute__((__may_alias__)) ula;
int fn(int *foo, ula *bar); // may alias
The big problem is testing. Lots of people assume that,
as long as alignment is satisfied, it is safe to cast
from one pointer type to another for accessing data.
This is not true. The half-legit solution to put both
pointers into a union, but that can get ugly. So some
determined person must go add __may_alias__ all over the
kernel, not missing any spot where it may be needed.
>> This is wrong. Only if they are declared restrict.
>
> ... can they point to the same area.
You have that exactly backwards. With restrict, they
MAY NOT point to the same area. With (char*) they MAY.
Otherwise, it's a question of compatible types.
> That is exactly the problem: If you do nothing, the
> language definition assumes the programmer made sure
> (LOL!) that they don't point the same way. That's why
> the flag is needed in the first place, as nobody
> writes "restrict" all over the place.
I do. (http://procps.sf.net/) Ulrich Drepper does. (glibc)
You should see the description of how "restrict" can
interact with scope. Magic smoke may leak out of your brain.
IMHO the "restrict" keyword was really botched.
If you really want to get fancy, alter the language
to suit your desires:
-fargument-alias
-fargument-noalias
-fargument-noalias-global
> I got biten by that when the optimizations (and the flag)
> were introduced into gcc (egcs branch perhaps?).
Me too, casting (double*) to (short*) to examine bits.
Now I don't do that. It's not legal in the C language.
-------
Grrr... why isn't Evolution good for editing code?