> > On 11/28/06, Andrew Pinski <[EMAIL PROTECTED]> wrote: > > > I often need to convince people that gcc is not just > > > defective for doing random nonsense to code which > > > violates the C and C++ aliasing rules. Not that I'm > > > real sure myself actually, given that gcc is able to > > > generate warnings for all the normal cases, but anyway... > > > I'm up against the idea that Visual Studio is correct > > > and gcc is buggy crap. :-) Very few professional > > > software developers can handle the aliasing issue. > > > > The aliasing rules are not hard to understand. > > For a long-time gcc developer like you, certainly.
If you call 5 years long-time, ok, fine. > It doesn't help that the standards are only available > for $$$ or as contraband. Anyway, I've never seen a > book or course that teaches any of this stuff. And yes this one reason why GCC get punished because nobody writes about the aliasing rules. > > Simplified rules for C: > > Only access a variable by its own type, its signed or > > unsigned variant, or by the character types (char, unsigned char, > > and signed char). For structs/unions, accessing it via > > an inner struct/union is also ok. > > How about an outer struct? For example, Linux does that > all the time to recover driver-specific data from a generic > struct without needing an extra pointer. That is questionable and I always forget what the C standard says here because this case involves pointer arthemantic which makes the code harder to understand. > > > Realistic code matters. Contrived examples won't > > > convince anyone. > > > > Realistic code for aliasing questions are usually going > > to be big and hard to understand. > > Bummer. I'm trying to resist the normal fix, which is > to consider strict-aliasing as a benchmark cheat that > you have to disable for real-world code. Maybe something like a loop where: for(i = 0;i<*t;i++) *f += 1.0; Where *t is an int. This is more realist code. What type based aliasing anylasis allows for (note I did not say it does anything) is the load of *t to be moved out of the loop and only have one store of *f. > I think there are 3 aliasing possibilities here: > 1. known to alias > 2. known to not alias > 3. may alias Actually there is only 2, it may alias or not. > You could start with a base+offset pass that only distinguishes the > known-to-alias cases from the others. That deals with typical casts. > Then you follow that with type-based analysis and finally back to > base+offset to find a few remaining known-to-not-alias cases. base+offset really only helps in cases like: int t[100]; int t2[100]; t[20] =1; t2[30] = 2; if (t[20] != 1) abort (); > If you want performance, disallow aliasing in unions. :-) Almost nobody > was doing that until it got suggested as a way to make gcc cooperate. > Even today it is very rare. People use unions to save space; this should > not hurt performance. Unions are another beast all together and not related to aliasing. In fact what the C standard says about unions is that the behavior is unspecified which means it is not undefined or implementation defined (which means it has to be documented) but it cannot do anything. Actually most uses of unions I have seen are not to save space but do some OO in C. -- Pinski
