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 Wed, Feb 3, 2010 at 7:41 AM, Dave Korn
<> wrote:
> 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!

The fact that memory (or objects) carries a 'tag' of what it contains goes
back the abstract semantics of C itself.  However, since more compilers
are interested in optimizing 'correct' codes, they don't bother too much
with people breaking rules ('they get what they deserve').  From that
it is not really important to have a "fat" representation of points --
they won't
aid much a correct program.  Hence, where we are today.
I do not see that changing soon :-)

-- Gaby

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