This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix C++ strict-aliasing issues with memcpy folding

On 03/02/2010 12:52, Michael Matz wrote:

>>> (incidentally it's interesting to think about what type the access '*p'
>>> has)
>> '*p' is lvalue of type 'X'.
> Although a part of it (the space in mem[0] at least) is a float?  And type 
> 'X' doesn't contain a float?  That's surprising to say the least :)

  Well, to me, the simple unsurprising reasoning goes like so:

"'p' is a value of type pointer-to-X, therefore '*p' is an lvalue of type X."

  I can't help asking myself, is it really a good idea to pretend that memory
carries metadata tagging the type of object it contains, without actually
switching to a fat representation for even workaday scalars like ints and
floats?  I'm not surprised if we start to tie ourselves up in logical knots
trying to reason about the number of non-existent dynamic type metadata that
can dance on the head of a pin!

  On the general subject of constructing a float on top of an int, I wouldn't
be surprised if the compiler didn't know after "*p = 3;" that the float had
changed.  I also wouldn't be surprised if it hoisted "*p = 3;" above any
stores to the float and really messed things up.  If we can do a bit to avoid
that by using the concept of dynamic type, all well and good, but maybe we
shouldn't go too far with it.

  This aspect of the language in the standard has always seemed disturbingly
metaphysical to me.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]