public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "mmitchel at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/29286] [4.0/4.1/4.2 Regression] placement new does not change the dynamic type as it should Date: Sun, 01 Oct 2006 18:39:00 -0000 [thread overview] Message-ID: <20061001183938.31971.qmail@sourceware.org> (raw) In-Reply-To: <bug-29286-10053@http.gcc.gnu.org/bugzilla/> ------- 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 would prevent implementation of placement new without non-standard facilities, since the people that wrote the standard all certainly expected the implementation to be just: void *operator new(size_t, void *p) { return p; } Variations on that definition also occur in various user-defined new operators, including those for class-scoped operators. I don't think we can reasonably ask people to change this code, which works with every other C++ compiler. Therefore, the only possible conclusion is that either the compiler is buggy or that the examples are invalid. Unfortunately, I don't think Andrew's example is invalid. There are two possible approaches to fixing the compiler: either (a) the C++ front end should mark all new operators as special, in some way that the middle end then uses to avoid this over-optimization, or (b) relax the aliasing rules used by the middle end. I think the right solution is (b). Fundamentally, I'm not sure that the object models in C and C++ are sufficiently well-defined to permit the kind of optimization that we are discussing. I also think that people use functions not named "operator new" to do the kinds of things being discussed (i.e., to allocate blocks of memory) and that C and C++ are intended to support that usage. Certainly, in C, people can't use "operator new". So, I'd probably suggest that we relax the aliasing rules, at least for heap-allocated objects. As an example of the kind of problems the standard poses, [basic.life] says: "The lifetime of an object is a runtime property of the object. The lifetime of an object of type T begins when: --storage with the proper alignment and size for type T is obtained, and --if T is a class type with a non-trivial constructor (_class.ctor_), the constructor call has completed. The lifetime of an object of type T ends when: --if T is a class type with a non-trivial destructor (_class.dtor_), the destructor call starts, or --the storage which the object occupies is reused or released." So, by that definition, it might seem that: int i = 3; *((float *)(&i)) = 7.0; is valid; we're reusing the "int" memory, as a "float", and it has the right size and alignment (on most systems). But, that would effectively nullify the [basic.lval] language that suggests that you can't access an object through a type other than its dynamic type -- or, at least, it would limit such access to writes. I don't think anyone would expect the dynamic type of "i" to be "float" in this example, even if someone had written: new (&i) float; Surely, the dynamic type of something explicitly declared "int" must be "int". But, for something with dynamic storage duration, perhaps we should assume that any write to the storage, with a type other than the one that it already has, forces it to possibly alias things of both types. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
next prev parent reply other threads:[~2006-10-01 18:39 UTC|newest] Thread overview: 190+ messages / expand[flat|nested] mbox.gz Atom feed top 2006-09-29 14:14 [Bug libstdc++/29286] New: placement new does not provide required side-effects rguenth at gcc dot gnu dot org 2006-09-29 14:15 ` [Bug libstdc++/29286] " rguenth at gcc dot gnu dot org 2006-09-29 14:17 ` [Bug libstdc++/29286] [4.2 Regression] " rguenth at gcc dot gnu dot org 2006-09-29 14:30 ` pcarlini at suse dot de 2006-09-29 14:38 ` rguenth at gcc dot gnu dot org 2006-09-29 14:52 ` pcarlini at suse dot de 2006-09-29 15:49 ` pinskia at gcc dot gnu dot org 2006-09-29 15:51 ` [Bug libstdc++/29286] [4.2 Regression] placement new does not change the dynamic type as it should pinskia at gcc dot gnu dot org 2006-09-29 16:08 ` pcarlini at suse dot de 2006-09-29 16:19 ` pinskia at gcc dot gnu dot org 2006-09-29 16:23 ` pcarlini at suse dot de 2006-09-29 16:25 ` rguenth at gcc dot gnu dot org 2006-09-29 16:25 ` rguenth at gcc dot gnu dot org 2006-09-29 16:58 ` [Bug libstdc++/29286] [4.0/4.1/4.2 " pinskia at gcc dot gnu dot org 2006-09-29 17:01 ` pinskia at gcc dot gnu dot org 2006-10-01 18:39 ` mmitchel at gcc dot gnu dot org [this message] 2006-10-01 23:05 ` mmitchel at gcc dot gnu dot org 2006-10-02 9:32 ` mrs at apple dot com 2006-10-02 17:48 ` mmitchel at gcc dot gnu dot org 2006-10-02 19:28 ` mrs at apple dot com 2006-10-03 16:03 ` ian at airs dot com 2006-10-03 16:13 ` mark at codesourcery dot com 2006-10-03 23:44 ` ian at airs dot com 2006-10-04 5:39 ` mark at codesourcery dot com 2006-10-24 6:53 ` Gabriel Dos Reis 2006-10-09 8:22 ` rguenth at gcc dot gnu dot org 2006-10-24 6:53 ` [Bug libstdc++/29286] [4.0/4.1/4.2/4.3 " gdr at integrable-solutions dot net 2006-12-29 20:28 ` dberlin at gcc dot gnu dot org 2007-01-01 0:41 ` mark at codesourcery dot com 2007-01-02 3:01 ` Daniel Berlin 2007-01-02 3:01 ` dberlin at dberlin dot org 2007-01-02 3:24 ` mark at codesourcery dot com 2007-05-02 15:57 ` ian at airs dot com 2007-05-02 16:11 ` pinskia at gcc dot gnu dot org 2007-05-02 16:14 ` pinskia at gcc dot gnu dot org 2007-05-02 20:41 ` mark at codesourcery dot com 2007-05-03 19:33 ` ian at airs dot com 2007-05-03 20:45 ` pcarlini at suse dot de 2007-05-03 20:49 ` pinskia at gcc dot gnu dot org 2007-05-03 20:59 ` rguenth at gcc dot gnu dot org 2007-05-03 21:25 ` pcarlini at suse dot de 2007-05-04 2:47 ` mark at codesourcery dot com 2007-05-04 3:54 ` bangerth at dealii dot org 2007-05-04 6:37 ` ian at airs dot com 2007-05-04 8:41 ` pcarlini at suse dot de 2007-05-04 10:45 ` rguenth at gcc dot gnu dot org 2007-05-04 11:04 ` pcarlini at suse dot de 2007-05-04 11:08 ` pcarlini at suse dot de 2007-05-04 12:03 ` rguenth at gcc dot gnu dot org 2007-05-04 14:31 ` rguenth at gcc dot gnu dot org 2007-05-04 15:55 ` ian at airs dot com 2007-05-04 15:57 ` rguenth at gcc dot gnu dot org 2007-05-11 23:22 ` ian at airs dot com 2007-05-12 0:36 ` dberlin at dberlin dot org 2007-05-12 9:48 ` rguenth at gcc dot gnu dot org 2007-05-12 11:11 ` rguenth at gcc dot gnu dot org 2007-05-12 13:29 ` dberlin at dberlin dot org 2007-05-12 18:41 ` ian at airs dot com 2007-05-12 18:44 ` ian at airs dot com 2007-05-12 21:48 ` rguenth at gcc dot gnu dot org 2007-05-13 10:04 ` rguenth at gcc dot gnu dot org 2007-05-14 3:45 ` ian at airs dot com 2007-05-14 4:00 ` dberlin at dberlin dot org 2007-05-14 8:25 ` rguenth at gcc dot gnu dot org 2007-05-14 11:44 ` Daniel Berlin 2007-05-14 11:44 ` dberlin at dberlin dot org 2007-05-14 15:20 ` rguenth at gcc dot gnu dot org 2007-05-14 15:38 ` dberlin at dberlin dot org 2007-05-14 16:42 ` ian at airs dot com 2007-05-14 17:14 ` ian at airs dot com 2007-05-14 21:25 ` mmitchel at gcc dot gnu dot org 2007-05-14 21:36 ` ian at airs dot com 2007-05-14 21:37 ` pinskia at gcc dot gnu dot org 2007-05-14 21:40 ` dberlin at dberlin dot org 2007-05-16 5:33 ` ian at airs dot com 2007-05-16 9:57 ` rguenth at gcc dot gnu dot org 2007-05-16 12:06 ` rguenth at gcc dot gnu dot org 2007-05-16 13:49 ` rguenth at gcc dot gnu dot org 2007-05-16 14:02 ` rguenth at gcc dot gnu dot org 2007-05-16 14:37 ` rguenth at gcc dot gnu dot org 2007-05-16 16:08 ` rguenth at gcc dot gnu dot org 2007-05-16 17:02 ` ian at airs dot com 2007-05-16 23:42 ` mark at codesourcery dot com 2007-05-18 6:15 ` ian at airs dot com 2007-05-18 6:25 ` ian at airs dot com 2007-05-18 6:27 ` mark at codesourcery dot com 2007-05-18 8:46 ` rguenth at gcc dot gnu dot org 2007-05-18 8:47 ` rguenth at gcc dot gnu dot org 2007-05-18 13:26 ` gdr at cs dot tamu dot edu 2007-05-18 13:30 ` gdr at cs dot tamu dot edu 2007-05-18 13:46 ` rguenth at gcc dot gnu dot org 2007-05-18 16:25 ` ian at airs dot com 2007-05-18 16:28 ` ian at airs dot com 2007-05-18 21:04 ` Gabriel Dos Reis 2007-05-18 16:36 ` ian at airs dot com 2007-05-18 16:44 ` mark at codesourcery dot com 2007-05-18 17:38 ` ian at airs dot com 2007-05-18 21:12 ` Gabriel Dos Reis 2007-05-18 17:46 ` pcarlini at suse dot de 2007-05-18 17:55 ` pinskia at gcc dot gnu dot org 2007-05-18 18:01 ` mark at codesourcery dot com 2007-05-18 18:03 ` ian at airs dot com 2007-05-18 19:55 ` rguenth at gcc dot gnu dot org 2007-05-18 20:12 ` pcarlini at suse dot de 2007-05-18 20:17 ` mark at codesourcery dot com 2007-05-18 20:27 ` pcarlini at suse dot de 2007-05-18 20:38 ` pcarlini at suse dot de 2007-05-18 21:04 ` gdr at cs dot tamu dot edu 2007-05-18 21:12 ` gdr at cs dot tamu dot edu 2007-05-18 21:16 ` gdr at cs dot tamu dot edu 2007-05-18 21:17 ` gdr at cs dot tamu dot edu 2007-05-18 21:44 ` pcarlini at suse dot de 2007-05-22 9:50 ` rguenth at gcc dot gnu dot org 2007-05-22 15:05 ` mark at codesourcery dot com 2007-05-22 15:54 ` Gabriel Dos Reis 2007-05-22 15:20 ` rguenther at suse dot de 2007-05-22 15:55 ` gdr at cs dot tamu dot edu 2007-05-22 16:20 ` mark at codesourcery dot com 2007-05-22 16:25 ` Gabriel Dos Reis 2007-05-22 16:25 ` gdr at cs dot tamu dot edu 2007-05-22 16:38 ` mark at codesourcery dot com 2007-05-22 16:46 ` Gabriel Dos Reis 2007-05-22 16:47 ` gdr at cs dot tamu dot edu 2007-05-22 16:54 ` mark at codesourcery dot com 2007-05-22 17:02 ` gdr at cs dot tamu dot edu 2007-05-22 17:11 ` dberlin at dberlin dot org 2007-05-22 17:13 ` dberlin at dberlin dot org 2007-05-22 17:20 ` gdr at cs dot tamu dot edu 2007-05-22 17:34 ` mark at codesourcery dot com 2007-05-22 17:41 ` gdr at cs dot tamu dot edu 2007-05-22 17:55 ` mark at codesourcery dot com 2007-05-22 19:13 ` gdr at cs dot tamu dot edu 2007-05-22 19:42 ` mrs at apple dot com 2007-05-22 19:53 ` gdr at cs dot tamu dot edu 2007-05-23 8:35 ` rguenther at suse dot de 2007-05-23 13:23 ` gdr at cs dot tamu dot edu 2007-05-23 13:43 ` rguenther at suse dot de 2007-05-23 14:24 ` ian at airs dot com 2007-05-23 14:38 ` rguenther at suse dot de 2007-05-23 15:00 ` gdr at cs dot tamu dot edu 2007-05-23 15:43 ` ian at airs dot com 2007-05-23 15:55 ` rguenther at suse dot de 2007-05-23 18:03 ` dberlin at dberlin dot org 2007-05-23 18:44 ` mark at codesourcery dot com 2007-05-23 18:54 ` rguenth at gcc dot gnu dot org 2007-05-23 18:57 ` rguenth at gcc dot gnu dot org 2007-05-23 19:10 ` mark at codesourcery dot com 2007-05-23 19:46 ` rguenth at gcc dot gnu dot org 2007-05-23 19:57 ` rguenth at gcc dot gnu dot org 2007-05-23 20:01 ` joseph at codesourcery dot com 2007-05-23 20:07 ` mark at codesourcery dot com 2007-05-23 20:13 ` mark at codesourcery dot com 2007-05-23 20:16 ` rguenther at suse dot de 2007-05-23 20:27 ` mark at codesourcery dot com 2007-05-23 20:48 ` rguenther at suse dot de 2007-05-23 21:02 ` dberlin at dberlin dot org 2007-05-23 21:13 ` mark at codesourcery dot com 2007-05-23 22:42 ` gdr at cs dot tamu dot edu 2007-05-23 22:50 ` gdr at cs dot tamu dot edu 2007-05-23 22:56 ` gdr at cs dot tamu dot edu 2007-05-23 22:58 ` gdr at cs dot tamu dot edu 2007-05-23 23:58 ` gdr at cs dot tamu dot edu 2007-05-24 0:07 ` gdr at cs dot tamu dot edu 2007-05-24 8:04 ` rguenther at suse dot de 2007-05-24 9:08 ` rguenther at suse dot de 2007-05-24 9:11 ` rguenther at suse dot de 2007-05-24 9:29 ` gdr at cs dot tamu dot edu 2007-05-24 9:33 ` rguenther at suse dot de 2007-05-24 9:47 ` gdr at cs dot tamu dot edu 2007-05-25 23:22 ` ian at airs dot com 2007-05-27 14:57 ` rguenther at suse dot de 2007-05-28 11:14 ` rguenther at suse dot de 2007-05-28 11:24 ` dberlin at dberlin dot org 2007-05-28 17:30 ` ian at airs dot com 2007-05-30 23:19 ` ian at airs dot com 2007-06-04 14:02 ` rguenth at gcc dot gnu dot org 2007-06-05 16:20 ` rguenth at gcc dot gnu dot org 2007-06-05 20:48 ` ian at airs dot com 2007-06-05 21:17 ` rguenther at suse dot de 2007-06-06 5:33 ` ian at airs dot com 2007-06-06 8:41 ` rguenther at suse dot de 2007-06-08 7:50 ` ian at airs dot com 2007-06-08 13:47 ` rguenther at suse dot de 2007-06-09 9:48 ` rguenth at gcc dot gnu dot org 2007-06-09 9:55 ` pcarlini at suse dot de 2007-06-09 12:03 ` bkoz at gcc dot gnu dot org 2007-06-09 19:29 ` mark at codesourcery dot com 2007-06-12 17:48 ` ian at gcc dot gnu dot org 2007-06-12 18:11 ` ian at airs dot com 2010-06-20 0:01 ` schaub-johannes at web dot de
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20061001183938.31971.qmail@sourceware.org \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).