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

acahalan at gmail dot com gcc-bugzilla@gcc.gnu.org
Tue Sep 26 14:17:00 GMT 2006



------- Comment #35 from acahalan at gmail dot com  2006-09-26 14:16 -------
(In reply to comment #34)
> Subject: Re:  [4.0/4.1/4.2 Regression] alias
>         bug with cast and call clobbered
> 
> On Tue, 2006-09-26 at 04:44 +0000, acahalan at gmail dot com wrote:
> > 
> > Although it wouldn't work for the example code, extending the aliasing behavior
> > of (char*) to (void*) would fix the problem for LOTS of code out in the wild.
> > People normally use a (void*) when they want a generic pointer type to play
> > casting games with. This is a case where the C standard is very far from the
> > reality of how people write code. The example code is fairly unusual.
> 
> But C aliasing is not based on pointers but on accesses so it is wrong
> to it that way.

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

Most real-world code doesn't use unions and definitely doesn't do like the
example above. Typically (void*) is used for passing things around, and there
are also the trivial aliasing cases which gcc can warn about. (if you can warn
about it, you can instead do what the programmer wanted)

Evidence: this bug has existed for ages, meanwhile aliasing violations keep
getting reported as compiler bugs.

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.

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.

BTW, in the testcase, the following line should generate a warning:

glChoosePixelFormat((GLint*)blist);

I don't get any warning at all, even with -Wstrict-aliasing=2.


-- 


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



More information about the Gcc-bugs mailing list