mark at codesourcery dot com [EMAIL PROTECTED] writes:
| --- Comment #22 from mark at codesourcery dot com 2006-10-04 05:39
---
| Subject: Re: [4.0/4.1/4.2 Regression] placement new
| does not change the dynamic type as it should
|
| ian at airs dot com wrote:
| --- Comment #21
--- Comment #23 from rguenth at gcc dot gnu dot org 2006-10-09 08:22
---
One point to remember is that C does not allow re-using of storage with a
different type (which is what PR29272 is about and why that testcase is
invalid).
The storage type is either the declared one or the one
--- Comment #19 from ian at airs dot com 2006-10-03 16:03 ---
Mike suggests: it would appear that it is unsafe to reorder writes of
otherwise non-conflicting types past each other as type based analysis alone
isn't enough to ensure they don't conflict.
That would be bad in the general
--- Comment #20 from mark at codesourcery dot com 2006-10-03 16:13 ---
Subject: Re: [4.0/4.1/4.2 Regression] placement new
does not change the dynamic type as it should
ian at airs dot com wrote:
Fortunately I believe that in a correct program we only have a problem when we
can
--- Comment #21 from ian at airs dot com 2006-10-03 23:44 ---
In C a general allocation function should work with a char array. A specific
allocation function should use a union. I don't think there are many existing
exceptions to these guidelines.
I think that code like that in PR
--- Comment #22 from mark at codesourcery dot com 2006-10-04 05:39 ---
Subject: Re: [4.0/4.1/4.2 Regression] placement new
does not change the dynamic type as it should
ian at airs dot com wrote:
--- Comment #21 from ian at airs dot com 2006-10-03 23:44 ---
In C a general
--- Comment #16 from mrs at apple dot com 2006-10-02 09:32 ---
The dynamic type of the object at i is indeed float and has the value 7.0 (iff
align and sizes work out). We permitted this so that can can do:
class C { ... };
char buf[1024];
new (buf[n]) C
and have the dynamic
--- Comment #17 from mmitchel at gcc dot gnu dot org 2006-10-02 17:48
---
I disagree with Mike's analysis. I certainly understand the goals of placement
new, but I don't think that anyone intended this code:
int i;
*(float *)i = 7.0;
to be valid. I don't even think people
--- Comment #18 from mrs at apple dot com 2006-10-02 19:28 ---
What is your position based upon? Mine is based upon having been in the room
when we decided what the C rules probably were, what the C++ rules could be and
the up side and down side of each choice and where we decided what
--- Comment #15 from mmitchel at gcc dot gnu dot org 2006-10-01 18:39
---
I cannot see any plausible way to argue that this is a library bug.
Implementation of placement new should not need barriers or other compiler
intrinsics. It's twisted to argue that the C++ standard itself
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-09-29 16:58
---
And here is a testcase that fails also for 4.0.0 and self contained also:
#include new
int foo(int n, int *f, long *f1)
{
long t = 0;
*f = 1;
long *fp = new(f) long;
*fp = 1;
for (int i=0; in; ++i)
{
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-09-29 17:01
---
(In reply to comment #13)
And here is a testcase that fails also for 4.0.0 and self contained also:
replace main with:
int main(void)
{
if (sizeof(int) != sizeof(long))
return 0;
int *a = new int;
long
13 matches
Mail list logo
