--- Comment #179 from schaub-johannes at web dot de 2010-06-20 00:01
---
(In reply to comment #158)
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
rguenther at suse dot de gcc-bugzi...@gcc.gnu.org writes:
[...]
| Now,
--- Comment #177 from ian at gcc dot gnu dot org 2007-06-12 17:47 ---
Subject: Bug 29286
Author: ian
Date: Tue Jun 12 17:47:37 2007
New Revision: 125653
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125653
Log:
./:
PR libstdc++/29286
* tree.def: Add
--- Comment #178 from ian at airs dot com 2007-06-12 18:10 ---
Fixed on mainline. No plans to backport the patch to previous releases.
--
ian at airs dot com changed:
What|Removed |Added
--- Comment #173 from rguenth at gcc dot gnu dot org 2007-06-09 09:48
---
Full testing shows no (or at least 0.5%) performance regression on tramp3d
runtime. Compile time seems to go up by 0.5% (that looks consistent, about the
same with previous patches) for tramp3d. Testcases not
--- Comment #174 from pcarlini at suse dot de 2007-06-09 09:55 ---
Great!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
--- Comment #175 from bkoz at gcc dot gnu dot org 2007-06-09 12:03 ---
Nice, thanks Ian.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
--- Comment #176 from mark at codesourcery dot com 2007-06-09 19:29 ---
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:
So, from my point of view the patch is ready to be exposed to more
--- Comment #171 from ian at airs dot com 2007-06-08 07:49 ---
Created an attachment (id=13666)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13666action=view)
Patch
This variant of the previous patch does better on at least some of the tramp3d
functions. Here we eliminate the
--- Comment #172 from rguenther at suse dot de 2007-06-08 13:47 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
On Fri, 8 Jun 2007, ian at airs dot com wrote:
--- Comment #171 from ian at airs dot com 2007-06-08
--- Comment #170 from rguenther at suse dot de 2007-06-06 08:41 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
On Wed, 6 Jun 2007, ian at airs dot com wrote:
--- Comment #169 from ian at airs dot com 2007-06-06 05:33
--- Comment #166 from rguenth at gcc dot gnu dot org 2007-06-05 16:20
---
It causes a 10% performance regression for tramp3d. There appear to be no
significant changes in libstdc++ performance testing. Fixing tramp3d-v4
with the below patch cures the performance regression.
---
--- Comment #167 from ian at airs dot com 2007-06-05 20:48 ---
Can you give me a .ii file for the performance regression, and point me at the
relevant function?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
--- Comment #168 from rguenther at suse dot de 2007-06-05 21:17 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
On Tue, 5 Jun 2007, ian at airs dot com wrote:
--- Comment #167 from ian at airs dot com 2007-06-05 20:48
--- Comment #169 from ian at airs dot com 2007-06-06 05:33 ---
What options are you using when you compile?
I don't see the symbol you mention, although I do see
--- Comment #165 from rguenth at gcc dot gnu dot org 2007-06-04 14:02
---
The lates patch fixes the FreePOOMA testsuite regressions. I'll give it a
performance testing spin on vangelis tonight.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
--- Comment #164 from ian at airs dot com 2007-05-30 23:18 ---
Created an attachment (id=13637)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13637action=view)
Patch
This is a modification of the previous patch which correctly handles the test
case in comment #85.
--
ian at
--- Comment #161 from rguenther at suse dot de 2007-05-28 11:14 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
Btw, it could save us many bugs (or bug reports) if if PTA says must-alias
we'd trust it, instead of using TBAA to
--- Comment #162 from dberlin at gcc dot gnu dot org 2007-05-28 11:24
---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
On 28 May 2007 11:14:20 -, rguenther at suse dot de
[EMAIL PROTECTED] wrote:
--- Comment #161
--- Comment #163 from ian at airs dot com 2007-05-28 17:30 ---
Richi, I tested my patch on every test case I saved. Can you just point me at
the one I missed? Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
--- Comment #160 from rguenther at suse dot de 2007-05-27 14:57 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
On Sat, 25 May 2007, ian at airs dot com wrote:
--- Comment #159 from ian at airs dot com 2007-05-25 23:21
--- Comment #159 from ian at airs dot com 2007-05-25 23:21 ---
Created an attachment (id=13613)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13613action=view)
Patch
This version of the patch is based on some code from Daniel Berlin. Here we
determine which pointers can
--- Comment #153 from rguenther at suse dot de 2007-05-24 09:03 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
On Thu, 23 May 2007, gdr at cs dot tamu dot edu wrote:
--- Comment #151 from gdr at cs dot tamu dot edu
--- Comment #154 from rguenther at suse dot de 2007-05-24 10:07 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
On Wed, 23 May 2007, mark at codesourcery dot com wrote:
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
--- Comment #155 from rguenther at suse dot de 2007-05-24 10:11 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
On Thu, 24 May 2007, rguenther at suse dot de wrote:
So I did some benchmarking with my two proposed patches
--- Comment #156 from gdr at cs dot tamu dot edu 2007-05-24 10:29 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
rguenther at suse dot de [EMAIL PROTECTED] writes:
[...]
| I brought in the union example to point of a
--- Comment #157 from rguenther at suse dot de 2007-05-24 10:33 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
On Thu, 24 May 2007, gdr at cs dot tamu dot edu wrote:
--- Comment #156 from gdr at cs dot tamu dot edu
--- Comment #158 from gdr at cs dot tamu dot edu 2007-05-24 10:47 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
rguenther at suse dot de [EMAIL PROTECTED] writes:
[...]
| Now, if I understand your argument below correctly,
--- Comment #124 from rguenther at suse dot de 2007-05-23 09:35 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
On Tue, 22 May 2007, dberlin at dberlin dot org wrote:
--- Comment #116 from dberlin at gcc dot gnu dot org
--- Comment #125 from gdr at cs dot tamu dot edu 2007-05-23 14:22 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
rguenther at suse dot de [EMAIL PROTECTED] writes:
[...]
| But you can still perform hoisting loads of incoming
--- Comment #126 from rguenther at suse dot de 2007-05-23 14:43 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
On Wed, 23 May 2007, gdr at cs dot tamu dot edu wrote:
--- Comment #125 from gdr at cs dot tamu dot edu
--- Comment #127 from ian at airs dot com 2007-05-23 15:23 ---
Re comment #105.
The case where TBAA is most useful is on a deeply pipelined in-order processor
with multiple function units and a high latency memory cache. One example I've
worked on is an embedded VLIW processor with
--- Comment #128 from rguenther at suse dot de 2007-05-23 15:37 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
On Wed, 23 May 2007, ian at airs dot com wrote:
--- Comment #127 from ian at airs dot com 2007-05-23 15:23
--- Comment #129 from gdr at cs dot tamu dot edu 2007-05-23 15:59 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
rguenther at suse dot de [EMAIL PROTECTED] writes:
| Note that it is important to retain the capability to
--- Comment #130 from ian at airs dot com 2007-05-23 16:43 ---
In this example
void foo(int *p)
{
float *f = (float *)p;
new (p) float;
*f = 1.0;
}
the pointer is p. In fact the relevant pointer is always the argument to
placement new, and every pointer which PTA can associate
--- Comment #131 from rguenther at suse dot de 2007-05-23 16:54 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
On Wed, 23 May 2007, ian at airs dot com wrote:
--- Comment #130 from ian at airs dot com 2007-05-23 16:43
--- Comment #132 from dberlin at gcc dot gnu dot org 2007-05-23 19:03
---
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 08:35:12 -, rguenther at suse dot de
[EMAIL PROTECTED] wrote:
--- Comment #124
--- Comment #133 from mark at codesourcery dot com 2007-05-23 19:43 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
ian at airs dot com wrote:
The case where TBAA is most useful is on a deeply pipelined in-order processor
--- 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
--- 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.
--
--- 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
--- Comment #137 from rguenth at gcc dot gnu dot org 2007-05-23 20:46
---
Created an attachment (id=13607)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13607action=view)
patch to perserve store ordering in loop load/store motion
quote
Gaby's claim is that given an arbitrary
--- Comment #138 from rguenth at gcc dot gnu dot org 2007-05-23 20:57
---
Note the patch is not 100% correct as we need to preserve store ordering on the
path to all exit edges which may be different for each exit.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
--- Comment #139 from joseph at codesourcery dot com 2007-05-23 21:00
---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
On Wed, 23 May 2007, mark at codesourcery dot com wrote:
Of course, Gaby's memory model doesn't allow
--- Comment #140 from mark at codesourcery dot com 2007-05-23 21:07 ---
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:
quote
Gaby's claim is that given an arbitrary
pointer p, saying:
--- Comment #141 from mark at codesourcery dot com 2007-05-23 21:13 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
joseph at codesourcery dot com wrote:
DR#236 http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_236.htm was
--- Comment #142 from rguenther at suse dot de 2007-05-23 21:14 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
On Wed, 23 May 2007, mark at codesourcery dot com wrote:
--- Comment #140 from mark at codesourcery dot com
--- Comment #143 from mark at codesourcery dot com 2007-05-23 21:27 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
rguenther at suse dot de wrote:
void f(int *p) {
*p = 3;
}
under Gaby's interpretation, we
--- Comment #144 from rguenther at suse dot de 2007-05-23 21:48 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
On Wed, 23 May 2007, mark at codesourcery dot com wrote:
rguenther at suse dot de wrote:
void f(int *p) {
--- 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 -, rguenth at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment
--- Comment #146 from mark at codesourcery dot com 2007-05-23 22:13 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
rguenther at suse dot de wrote:
Only so much that we seem to agree on the semantics of placement new.
Gaby
--- Comment #147 from gdr at cs dot tamu dot edu 2007-05-23 23:42 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
mark at codesourcery dot com [EMAIL PROTECTED] writes:
| Of course, Gaby's memory model doesn't allow this
--- Comment #148 from gdr at cs dot tamu dot edu 2007-05-23 23:50 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
mark at codesourcery dot com [EMAIL PROTECTED] writes:
| Gaby's claim, as I understand it, is that writing to a
--- Comment #149 from gdr at cs dot tamu dot edu 2007-05-23 23:56 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
mark at codesourcery dot com [EMAIL PROTECTED] writes:
| --- Comment #140 from mark at codesourcery dot com
--- Comment #150 from gdr at cs dot tamu dot edu 2007-05-23 23:57 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
mark at codesourcery dot com [EMAIL PROTECTED] writes:
| Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
|
--- Comment #151 from gdr at cs dot tamu dot edu 2007-05-24 00:58 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
rguenther at suse dot de [EMAIL PROTECTED] writes:
[...]
| Gaby's model says that we know less about dynamic
--- Comment #152 from gdr at cs dot tamu dot edu 2007-05-24 01:06 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
mark at codesourcery dot com [EMAIL PROTECTED] writes:
[...]
| However, I don't like this approach because I
--- Comment #105 from rguenth at gcc dot gnu dot org 2007-05-22 10:50
---
Let me again do a step back and look at the problem from another view ;)
--
C++ aliasing imposes additional restrictions on transformations we
are allowed to do to memory references compared to C type-based
--- Comment #106 from mark at codesourcery dot com 2007-05-22 16:04 ---
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:
- we _cannot_ sink loads across stores.
x = *int;
--- Comment #107 from rguenther at suse dot de 2007-05-22 16:20 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
On Tue, 22 May 2007, mark at codesourcery dot com wrote:
rguenth at gcc dot gnu dot org wrote:
- we
mark at codesourcery dot com [EMAIL PROTECTED] writes:
| 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:
|
| - we _cannot_ sink loads across stores.
|
| x = *int;
| *double = 1.0;
--- Comment #108 from gdr at cs dot tamu dot edu 2007-05-22 16:55 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
mark at codesourcery dot com [EMAIL PROTECTED] writes:
| Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
|
--- Comment #109 from mark at codesourcery dot com 2007-05-22 17:19 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
gdr at cs dot tamu dot edu wrote:
Consider the following instead
// tu-1.C
void f(int* p) {
mark at codesourcery dot com [EMAIL PROTECTED] writes:
| Indeed, consider this:
|
| // tu-2.C
| void f(int*);
| void g() {
|union {
| int i;
| double d;
|} t;
|
| t.i = 42;
| f(t);
| cout t.d endl;
| }
|
| I believe we
--- Comment #110 from gdr at cs dot tamu dot edu 2007-05-22 17:25 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
mark at codesourcery dot com [EMAIL PROTECTED] writes:
| Indeed, consider this:
|
| // tu-2.C
| void
--- Comment #111 from mark at codesourcery dot com 2007-05-22 17:37 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
gdr at cs dot tamu dot edu wrote:
| No, I do not. And GCC historically has not; you are only allowed to use
mark at codesourcery dot com [EMAIL PROTECTED] writes:
| But, I don't think the standard contemplated
| these issues in sufficient detail to make it useful in this respect.
The issues has been raised on the -core reflector.
-- Gaby
--- Comment #112 from gdr at cs dot tamu dot edu 2007-05-22 17:46 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
mark at codesourcery dot com [EMAIL PROTECTED] writes:
| But, I don't think the standard
--- Comment #113 from mark at codesourcery dot com 2007-05-22 17:54 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
gdr at cs dot tamu dot edu wrote:
--- Comment #112 from gdr at cs dot tamu dot edu 2007-05-22 17:46
--- Comment #114 from gdr at cs dot tamu dot edu 2007-05-22 18:01 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
mark at codesourcery dot com [EMAIL PROTECTED] writes:
| Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
|
--- Comment #115 from dberlin at gcc dot gnu dot org 2007-05-22 18:10
---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
On 22 May 2007 16:54:24 -, mark at codesourcery dot com
[EMAIL PROTECTED] wrote:
--- Comment #113
--- Comment #116 from dberlin at gcc dot gnu dot org 2007-05-22 18:13
---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
On 22 May 2007 17:01:40 -, gdr at cs dot tamu dot edu
[EMAIL PROTECTED] wrote:
--- Comment #114
--- Comment #117 from gdr at cs dot tamu dot edu 2007-05-22 18:19 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
dberlin at dberlin dot org [EMAIL PROTECTED] writes:
[...]
| And if you've raised them now, can you please try
--- Comment #118 from mark at codesourcery dot com 2007-05-22 18:34 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
gdr at cs dot tamu dot edu wrote:
Thanks for reminding all those points. I'll ensure that I make those
--- Comment #119 from gdr at cs dot tamu dot edu 2007-05-22 18:40 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
mark at codesourcery dot com [EMAIL PROTECTED] writes:
| Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
|
--- Comment #120 from mark at codesourcery dot com 2007-05-22 18:55 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
gdr at cs dot tamu dot edu wrote:
| I would guess
| that we made this change around the year 2000. So,
--- Comment #121 from gdr at cs dot tamu dot edu 2007-05-22 20:12 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
mark at codesourcery dot com [EMAIL PROTECTED] writes:
[...]
| And, although I don't have the time/energy that
--- Comment #122 from mrs at apple dot com 2007-05-22 20:41 ---
When the standard was originally written, I do think we may have missed out on
some finer points of the C object model, mainly to do with restrictions on what
one is not permitted to do stemming from the declared type. The
--- Comment #123 from gdr at cs dot tamu dot edu 2007-05-22 20:53 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
mrs at apple dot com [EMAIL PROTECTED] writes:
| I think it is reasonable to push the tighening language into
--- Comment #78 from ian at airs dot com 2007-05-18 07:14 ---
The test case in comment #73 is just a standard aliasing violation. You are
casting a double* to an int* and writing to it both ways. As I argued in
comment #76, the only way this is going to work is if we eliminate TBAA in
--- Comment #79 from ian at airs dot com 2007-05-18 07:25 ---
The test case in comment #71 doesn't use placement new either.
This PR was originally about placement new. I think there is general agreement
thta placement new needs to avoid aliasing problem. I don't think there is
--- Comment #80 from mark at codesourcery dot com 2007-05-18 07:26 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
ian at airs dot com wrote:
--- Comment #78 from ian at airs dot com 2007-05-18 07:14 ---
The test
--- Comment #81 from rguenth at gcc dot gnu dot org 2007-05-18 09:45
---
Yes, both testcases are valid and are using placement new. Note the loop
is only to confuse the optimizers enough to re-order the stores and produce
a miscompilation. Note the loop runs exactly once, and in
--- Comment #82 from rguenth at gcc dot gnu dot org 2007-05-18 09:47
---
Oh, and the double-ness is to show that at RTL expansion we actually unify
alias
sets of long and double, not long and int, which is wrong again. See my
comment #51.
--
--- Comment #85 from rguenth at gcc dot gnu dot org 2007-05-18 14:46
---
To avoid confusion about what testcase we speak, let's talk about the one
I replicated below. I believe this one is valid as the storage is a union
instantiated in main() and a pointer to it is passed to foo().
--- Comment #83 from gdr at cs dot tamu dot edu 2007-05-18 14:26 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
ian at airs dot com [EMAIL PROTECTED] writes:
| The test case in comment #71 doesn't use placement new either.
|
--- Comment #84 from gdr at cs dot tamu dot edu 2007-05-18 14:30 ---
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 [EMAIL PROTECTED] writes:
| --- Comment #81 from rguenth at gcc dot gnu dot
--- Comment #86 from ian at airs dot com 2007-05-18 17:24 ---
Re comment #80, comment #81, comment #82. My patch handles the placement new
in comment #73 to indicate an alias between double and long. The mis-ordered
code is actually aliasing int and long. That aliasing is due to a
--- Comment #89 from mark at codesourcery dot com 2007-05-18 17:44 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
ian at airs dot com wrote:
--- Comment #86 from ian at airs dot com 2007-05-18 17:24 ---
Re comment
--- Comment #88 from ian at airs dot com 2007-05-18 17:35 ---
Regarding comment #85, this again relies on the notion of dynamic type of a
memory location such that the only possible end result is to eliminate TBAA
when compiling C++. The only thing I can say about this sort of test
--- Comment #87 from ian at airs dot com 2007-05-18 17:27 ---
I'm not sure what to make of comment #84. We don't determine aliasing by
alignment or size. We determine it by type. We don't currently treat int and
long as aliasing each other even if they happen to have the same
--- Comment #92 from pinskia at gcc dot gnu dot org 2007-05-18 18:55
---
So if that is not valid, and the placement new case is valid, then what is the
essential difference between the cases? The variable is being accessed via
two
different types. Why is that OK?
void f(double*
--- Comment #94 from ian at airs dot com 2007-05-18 19:03 ---
I tried the original test case with icc, and it gets the right result. The
assignment b-p = 0 is discarded.
Unfortunately I'm not sure what this actually tells us.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
--- Comment #93 from mark at codesourcery dot com 2007-05-18 19:01 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
ian at airs dot com wrote:
void f(double* p) { *(int*)p = 3; long *l = new (p) long; *l = 4; }
void g() {
--- Comment #90 from ian at airs dot com 2007-05-18 18:38 ---
I agree that this is valid:
void f(double *p) { *(int*)p = 3; }
void g() {
int i;
f((double *)i);
}
But I don't think that is the question at hand. The variable is always being
accessed in the same type, which is also
--- Comment #91 from pcarlini at suse dot de 2007-05-18 18:46 ---
(In reply to comment #90)
Can anybody see a way through this maze?
Humbly, I'd like to suggest again that we have a look to the assembly produced
by other compilers. I remember that some GCC contributors have access to
--- Comment #95 from rguenth at gcc dot gnu dot org 2007-05-18 20:55
---
But construction/initialization of uninitalized memory in memory happens with
placement new! So we're back to square one. What this PR initially was about
is a fixed type memory allocator in C++ which needs to
--- Comment #96 from pcarlini at suse dot de 2007-05-18 21:12 ---
(In reply to comment #95)
But construction/initialization of uninitalized memory in memory happens
with
placement new!
Placement new is used only for non-POD types, to be clear.
--
--- Comment #97 from mark at codesourcery dot com 2007-05-18 21:17 ---
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:
But construction/initialization of uninitalized memory in memory
--- Comment #98 from pcarlini at suse dot de 2007-05-18 21:27 ---
(In reply to comment #97)
First and foremeost, we have to generate correct code. If that means
the memory barrier solution, for now, then so be it.
Yes, but I'm a little worried myself not by memory but by containers
--- Comment #99 from pcarlini at suse dot de 2007-05-18 21:37 ---
To complete my reasoning: in case we end-up with some sort of very bad
pessimization of placement new, probably we'll have to adjust such containers
to not call allocator::contruct at all when the default allocator is
1 - 100 of 164 matches
Mail list logo
