This is the mail archive of the gcc-bugs@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]

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should



------- Comment #136 from mark at codesourcery dot com  2007-05-23 20:10 -------
Subject: Re:  [4.0/4.1/4.2/4.3 Regression] placement
 new does not change the dynamic type as it should

rguenth at gcc dot gnu dot org wrote:
> ------- Comment #134 from rguenth at gcc dot gnu dot org  2007-05-23 19:54 -------
> But using a union for type-punning is a gcc extension (and of course the
> extension
> is only for access through the union), so with strict C99/C++ semantics we can
> avoid reloading d[i-1] even if a and d were in the same union because the code
> would then be invalid.  

Gaby's claim, as I understand it, is that writing to a union member,
even through a pointer, rather than directly through the union, is
valid, and activates that part of the union.  So, it is not a GCC
extension.  For code like:

  a[i] = i;
  d[i] = d[i-1] + a[i];

I guess you can argue that a[i] does not alias d[i-1], even in Gaby's
model, because a[i] is written to right before the access to d[i-1].
But, you don't know that a[m] doesn't alias d[n] for arbitrary m and n.
 So, it's easy to create variations on the case I posted that can't be
optimized, if you agree to Gaby's model.

> So the union case is a non-issue here (it was only used to
> make available enough properly aligned storage for the particular testcase).

I agree that union case *should* be a non-issue in this context, where
we were discussing how to fix placement new, but Gaby has made it one
because he is claiming that placement new is not the only way to change
the dynamic type of memory.  Gaby's claim is that given an arbitrary
pointer "p", saying:

 (int *)p = 3;

is the same as saying:

 *(new (p) int) = 3;

That makes life for the optimizers much, much harder.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286


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