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, 3 Feb 2010, Dave Korn wrote:

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

Indeed it doesn't.  But it would be undefined behavior to inspect
the float value again - it's gone.

>  I also wouldn't be surprised if it hoisted "*p = 3;" above any
> stores to the float and really messed things up.

It won't do that.  output- and anti-dependence cannot use TBAA with
the middle-end memory model.

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

There wasn't anything wrong with this original example from the start
and GCC handles it just fine.

What remains undefined behavior is

 int i;
 *(float *)&i = 1.0;
 i = 0;
 float f = *(float *)&i;

thus, you can only use an lvalue of a type compatible with the
dynamic type of the object to access it.  Unless you change the
dynamic type with that access which you always do if it is a store.


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