[Bug c++/11376] [3.3/3.4 regression] mozilla-1.4 miscompiled

["bangerth at dealii dot org" <gcc-bugzilla at gcc dot gnu dot org>]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From bangerth at dealii dot org  2003-07-08 20:10 -------
> I am a big fan of obviousness and really love C compared to C++

It's not about C vs C++. C has the same aliasing rules, basically. In short,
they read: if you've got an object of some type, don't try to fool everybody
else (including the compiler) by pretending it has another type when you
access it. Type safety is not so hard to achieve, and there are big C++
projects out there that have banned the use of void* and reinterpret_cast.
I would certainly ask my collaborators to change their code if they tried
to introduce such concepts. There's no need to do this.

> So having a similar warning for aliasing
> violations really would help improve code in the wild.

This has been extensively discussed over and over again. I'd say for code
like the one in question here, there's little hope a compiler can track
what a certain pointer points to. (If it can, then just pack some accessor
functions into another translation unit, and things become an order of
magnitude harder). gcc has, between dot releases, switched off -fstrict-aliasing
when it was first introduced, to give developers more time to fix their code,
and because nobody could come up with a way to warn of invalid constructs.
But this was years ago. Besides, in most code, these problems are not so
hard to find -- as long as you avoid explicit casts, in particular
reinterpret_cast, there are not so many possibilities to introduce aliasing
violations. It is only if you try to outsmart C/C++'s type system that you
are in danger. But I don't see why people should do that, templates offer them
plenty of ways to always stay on the safe side, and the compiler will tell
you about illegal casts -- unless you use void* and reinterpret_cast.

So look out for these two constructs. Some perl-fu is more powerful than gcc
for this...

W.