Linux and aliasing?

[mark@codesourcery.com]

>>>>> "Jason" == Jason Merrill <jason@cygnus.com> writes:

    Jason> My problem with this is that only people who read the
    Jason> release notes for *this release* will see the big letters.
    Jason> Meanwhile, people who start with a later version or aren't
    Jason> involved in deploying the tools or whatever won't see the
    Jason> warning. 

This is a valid point.

    Jason> Saying "garbage in, garbage out" is a cop-out.  If we're
    Jason> going to let code like this break, we need to emit a
    Jason> warning so that people know that they have a problem,
    Jason> rather than leaving them to debug obscure problems.

Any warning will yield many false positives.  For example, there are
places in GCC where we store a `foo *' in a `tree' slot in a data
structure.  We (hopefully) never access it as a tree; we just cast if
back and forth.  That's legal.  It's also perhaps worth warning about.

But, warning like mad over every object-oriented C program seems
annoying.  Of course, a warning that's part of -W or some such is
probably OK.  But, then it won't accomplish what you want.  The
warning has to be on by default to overcome the problem you describe.
It's a reasonable point of view to argue that this is a better QOI
than the current state, but it's reasonable to argue the opposite as
well: false positive warnings are pretty annoying, and obscure the
real warnings.

We've had -fstrict-aliasing on in the tree for a long time, and had
very few bugs that we tracked down to the kind of thing you are
talking about.  But, admittedly, we haven't yet had it on in a general
release, so it's a relatively small sample size.

It's reasonable to argue that -fstrict-aliasing should be off by
default.  Then, you have to turn it on to get the benefits; when you
do so, it's fair to expect that you figured out what it did before you
did it, and it's easy to realize that if something went wrong after
you turned it on that it had to do with -fstrict-aliasing.
Unfortunately, this alternative means that most code will never be
compiled with this optimization.  I'm not sure what to think; QOI also
involves generating code that goes as fast as possible when presented
with conformant code, and not requiring people to root around the
manual to find funny flags to write into their makefiles to make the
code go fast.  It's a trade-off; reasonable people can certainly
disagree on whether or not -fstrict-aliasing should be on by default.

Note that this choice would have absolutely no bearing on the
*original* discussion regarding the Linux kernel; they want
-fstrict-aliasing *on* and still to have their code work as they
expect.

    Jason> BTW, the union trick isn't part of C, either.  It's a GCC
    Jason> implementation choice.

True enough.  This is implementation-defined behavior.  (Not
"undefined", but still "implementation-defined".)  I believe the
"memcpy trick" is the only 100% portable solution.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com