[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>]

------- Comment #37 from acahalan at gmail dot com  2006-09-26 15:33 -------
(In reply to comment #36)

> > 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.

IMHO that qualifies as "ages". If the bug has survived that long, it
can't be all that major. People have learned that -fno-strict-aliasing
is the cure-all for mystery 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.
> 
> And Aliasing rules in C have existed now for at least 17 years.

Your point?

Fact: strict aliasing horrifies most software developers.

The wording in a seriously expensive ISO document doesn't
change the simple fact that people don't write code that way.
Books intended to teach the language don't mention this
"feature" of the language. I don't just mean "Learn C in
5 days", but college textbooks as well.

> > 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.

I know. I'm perfectly clear on that. You don't need to remind me.

If the example code had used (char*), the bug would not have shown
itself. Great. Most real-world code would use (void*) for this.
That breaks. If (void*) is treated the same as (char*) though, the
bug goes away. That is, an access to "void" (which is pretty much
impossible except for computed goto) should be considered to be
something which could happen and which could alias with anything.
Probably this fixes 99% of the real-world occurances of this bug.

Given such a change, the remaining bug is an insignificant
violation of the C standard. For the next release it can be
either ignored or addressed by having both -std=c99 and -std=c89
disable strict 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.

It's not illegal, and thus not an error, but it damn well is questionable.
Normal people cast to/from (void*), because this comes free in C or because it
seems clean to use (void*) as the generic pointer type. People trying to avoid
aliasing problems cast to/form (char*), and use (char*) as the generic pointer
type. Other casts between pointers to types not allowed to alias are highly
suspect.


-- 


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