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 #145 from dberlin at gcc dot gnu dot org  2007-05-23 22:02 -------
Subject: Re:  [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should

On 23 May 2007 18:57:03 -0000, rguenth at gcc dot gnu dot org
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #135 from rguenth at gcc dot gnu dot org  2007-05-23 19:56 -------
> Re comment #132 -- you cannot encode this into the IL :/  And I don't propose
> to
> do so.  And I say any working and optimal (from optimization perspective)
> variant
> of a fix for this PR has the same problem.
So instead you are going to change every single optimization to
preserve things like store ordering, even though the underlying
aliasing information says it's okay to reorder (because it's broken in
the presence of these restrictions)?
No thanks!
This would be a massive rathole to go down in the end, and completely
at odds with the idea that our middle end IL is language independent,
and like *C*.
C99 has a clear proposed resolution to DR 236, and it says you need to
visibly use a union (which takes care of the other issue mentioned
here)
If placement new needs to mean a memory barrier to get things right
for placement new/C++, it needs to mean a memory barrier to get things
right for now.
Changing language independent optimizations to preserve something
magical in the face of wrong aliasing information is not the way to
fix this PR.

I would support turning off TBAA over that solution, given the choice.


-- 


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]