This is the mail archive of the gcc-patches@gcc.gnu.org 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


Hi,

On Wed, 3 Feb 2010, Dave Korn 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."

Ah, sorry.  I mixed concepts without stating this cleary.  My side 
question should have been, "what type does the storage pointed to by p 
have".  Yes, quite clearly the source construct "*p" has type X.  But the 
answer to the question influences the fact if we may use "*p" to access 
that storage.

>   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?

Our memory model was designed precisely to deal with storage as if it were 
tagged.  It can deal with all situations (modulo bugs) I tried to 
construct in this or other recent threads, also with situations that now 
seem to be invalid C++ (if they turn out to be valid in three years, at 
least we can handle them :-) )


Ciao,
Michael.


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