> 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.
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.
For C++, it is the same except replace type with dynamic type.
so you can do, hopefully I have the syntax correct for placement news):
int *a = new int;
use (a)
float *b = new(a) float;
use (b)
> Realistic code matters. Contrived examples won't
> convince anyone.
Realistic code for aliasing questions are usually going
to be big and hard to understand.
> People care about 32-bit x86, not IA-64. AMD64 and
> PowerPC count for something, but not much.
Actually PowerPC code generation counts a lot for me, as I
work for Sony.
> The best examples would involve optimizations which
> could not be performed if gcc did what people normally
> expect from a simple pointer cast and wrong-type access.
> I doubt such examples exist, but I hope they do.
An easy quick example of what strict alias can do is the following:
int f(int *a, float *b)
{
*a = 1;
*b = 2.0;
return *a == 2;
}
Without the aliasing rules provided by the C/C++ standard,
you would not know if *a could alias *b, therefor not always return 0.
The reason why GCC gets the cast case "wrong" is because GCC does
not do that much base+offset based aliasing but instead it implements
type based aliasing.
What most other compilers do is first base+offset aliasing and then
type based aliasing if they cannot figure that out with the base+offset.
We have found that we currently get better results with our current IR,
with type based aliasing first.
Thanks,
Andrew Pinski
