Messages in this thread | | | Subject | Re: WARNING: GCC 2.9.5 & Linux | Date | Mon, 02 Aug 1999 20:32:18 -0400 | From | Horst von Brand <> |
| |
Steve Dodd <dirk@loth.demon.co.uk> said:
[...]
> What /is/ the issue with the strict aliasing code? I was under the > impression that it "merely" screwed up code that did icky things with > pointers to members of unions. Comments made here about Linus' view on > the thing sounds like it is some horrendous problem that may never get > sorted. Which is the case?
The ANSI C standard prohibits accessing data through a pointer to a different type. I.e., this is wrong:
int *pi = ...; char *pc;
pc = (char *) pi;
*pi = 117; /* 1st */ *pc = 'a'; /* 2nd */ ... *pi ... /* 3rd: Illegal */
Note that 3rd is illegal because we stored there through pc, an char * and we are going to access it again at 3rd through a int *. It is fine (AFAIU) if you store a char though pc and access it as a char later. The point is that this is _hard_ (probably impossible in the general case) to detect for a compiler, so the compiler is allowed to assume that *pi does not change, since no accesses through an int * could have changed *pi. So it could reorder stuff so that the setting at 2nd is done _after_ the line marked 3rd above...
> Looking at the EGCS/GCC manual section for strict-aliasing, is this the sort > of `grunt work' that the unwashed multitude like myself could plow through > and fix? How big a job is it? Is it even worth it?
I'd say it is a _big_ job. Plus you have to make sure not one slips through. The main problem is that illegal accesses like above are used al over the place, e.g. in memcpy() and its ilk to speed them up (so they work with longs, not char by char). Mostly harmless, but the resulting kernels on i586 don't boot because of code reordering of a memset() and setting a struct member that tells the booting kernel to initialize IDE intefaces ;-)
In any case, I'd fix it where it can be done cleanly, and without loss of efficiency. Some kind of solution from the GCC folks has to be forthcoming, glibc has exactly the same kind of trouble with mem* functions. It might take the form of _only_ builtin mem* functions, or a way to inhibit the strict aliasing for a variable or function or file. -- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Viña del Mar, Chile +56 32 672616
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |