[Bug tree-optimization/28778] [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered

["pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #36 from pinskia at gcc dot gnu dot org  2006-09-26 14:32 -------

> It's also wrong to assume that unions can be used for type punning, but so
> what? It is allowed by gcc.

No, it is less there as the behavior with unions is unspecified and not
undefined unlike type punning via an address/type cast.


> Evidence: this bug has existed for ages, meanwhile aliasing violations keep
> getting reported as compiler bugs.
This bug (PR28778) has only existed for the last two major releases which is
not ages.

> Since gcc introduced strict aliasing, I've worked at three places doing
> software development. All were embedded/OS related, so I would say the people
> are/were hard-core programmers with a clue. Everybody is shocked when I explain
> strict-aliasing, and all but one have been horrified.

And Aliasing rules in C have existed now for at least 17 years.  It is not like
it magically was added either.  Yes GCC is one of the few compiler that uses
the information produced by type based aliasing anyalsis but that does not mean
GCC is wrong.  Yes GCC turned on "strict" aliasing only 7 years ago but the
aliasing rules have been around for 10 years longer than that.


> So, to get back to this bug specifically: treating a (void*) arg the same as a
> (char*) arg will cover up the problem for nearly everyone. Sadly it won't fix
> the example given, which is legit to a language lawyer and a nonsense piece of
> shit to any normal programmer. Oh well. By treating (void*) the same as
> (char*), you can demote the bug severity greatly and move on.

Again, aliasing in C has to do with accesses and nothing to the type of
pointers.  In fact this is aliasing rules in all languages have to do with
accesses and not the type.  Look at Fortran (which have existed since at least
1977) aliasing rules wich basically say no two arguments alias which makes
people write undefined code easier than with C aliasing.
> 
> BTW, in the testcase, the following line should generate a warning:
> 
> glChoosePixelFormat((GLint*)blist);

Why there is nothing questionable about it until glChoosePixelFormat deferences
the agrument in the wrong type.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28778