Re: Wrong RTL instruction deleted

[espie at quatramaran dot ens dot fr (Marc Espie)]

In article <41D02F2D.5050503@adacore.com> you write:
>If -O2 -fstrict-aliasing has got a lot better, then that's
>good news, but it does not necessarily say what the default
>should be.
>
>We are seeing an increasing number of users who with pre-
>tree-ssa GNAT Pro 5 versions are seeing regressions in
>large programs.
>
>It is not at all clear that a performance increase is
>worth these regressions. What we are seeing is that more
>and more of our users fall into using -fno-strict-aliasing
>by default, and indeed we are getting used to recommending
>this as the first thing to try if people are seeing mysteries
>in -O2. Other users just fall back to -O0, discouraged to
>find out that gcc optimization is "dangerous". Yes, yes
>I know all the language lawyer responses here :-)

Just as another data point, to back you up.
OpenBSD uses gcc versions where -fno-strict-aliasing is on, by default,
at -O2. 

We've been bitten by it at one or two points in the kernel. We've seen
it go wrong on one or two external programs.

Yes, I'm a language lawyer, I know what -fstrict-aliasing does. I've
argued for it at some point. I've since dived into the code that breaks.
-fstrict-aliasing is not worth it. There's some nasty old code out
there. It would be great to have it fixed, but no-one will touch it,
and we will have to live with -fno-strict-aliasing. Most of the code
that breaks is really code that no-one wants to touch, or no-one wants
to rewrite...