Re: Strict aliasing affects glibc 2.1.1 as well as Linux

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Linus" == Linus Torvalds <torvalds@transmeta.com> writes:

    Linus> I bet the same is true of most other programs. In glibc,
    Linus> memcpy() reared its ugly head. But once that is fixed,
    Linus> there will almost certainly be others. Some of them can be
    Linus> just explained away.

I totally agree.  Compiler builtins cannot solve all problems.

But, we do have builtin_memcpy, so we should make as effective as
possible.  And, if that would solve many of the common cases, that
would be great.

You are right that there is high-performance code that will need to
violate the type-system.  I would guess that most such code is a
relatively small proportion of its applications; for example, in some
complex nuclear simulation, a few inner loops somewhere, or, in the
Linux kernel, on a few hot paths.

Your example of copying around floating-point values using integer
operations (perhaps while twiddling sign bits or some such) is a good
one.  But, that kind of code is not only application-specific, but
processor specific; the kind of thing that, even today, could
reasonably be written in assembly code.  After all, if cycles really
count, and you're talking about small loops, then it still makes sense
to right them by hand, if you really know what you're doing.  That
will probably always be true.

Backing up, we're down this dark alley in another effort to deal with
the (alleged) problem of -fstrict-aliasing.  So, let's not beat the
memcpy horse to death; I'm sure we all agree that a) making the
builtin version as fast as possible is good and b) that will not solve
the world's problems.  It might, however, make it's use in an
UNSAFE_COPY macro reasonable, e.g.:

  #define UNSAFE_COPY(TYPE, DEST, SRC) \
    __builtin_memcpy (DEST, (TYPE) SRC, sizeof (*DEST))

Then again, we've been down that road before, and, as I recall, you
didn't like this approach, which was why we headed towards the use of
GCC's type-puns-via-unions guarantee, so I'm not sure we'll win big by
rehashing the debate. :-)

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