public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/54740] New: Empty base optimization gets confused when a member variable derives from the same empty base.
@ 2012-09-28 23:50 avenikov at google dot com
2012-09-28 23:58 ` [Bug c++/54740] " redi at gcc dot gnu.org
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: avenikov at google dot com @ 2012-09-28 23:50 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54740
Bug #: 54740
Summary: Empty base optimization gets confused when a member
variable derives from the same empty base.
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: avenikov@google.com
struct empty_base {};
struct another_empty_base {};
struct inner : empty_base {};
struct outer : empty_base {
inner i_;
};
int main(int, char **)
{
return sizeof(outer);
}
This returns 2;
If you change outer to derive from another_empty_base, it returns 1 (which is
correct). Whatever the correct result should be, they at least should be the
same.
I tried it on 4.7.2 and on 4.4.3 - same problem is present.
The optimization flags don't seem to make any difference.
Setting it to major, as this seems like a very common idiom and people expect
empty base optimization to kick in in such cases.
Andy.
P.S. Just in case: partial output from my gcc -v:
Using built-in specs.
COLLECT_GCC=/<...>/stage-4.7.2/bin/gcc
COLLECT_LTO_WRAPPER=/<...>/stage-4.7.2/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.7.2/configure --prefix=/<...>/stage-4.7.2
--with-gmp=/<...>/gmp-4.3.2/ --with-mpfr=/<...>/mpfr-3.0.0/
--with-mpc=/<...>/mpc-0.9/ --enable-languages=c,c++
Thread model: posix
gcc version 4.7.2 (GCC)
It's a ubuntu-based system.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug c++/54740] Empty base optimization gets confused when a member variable derives from the same empty base.
2012-09-28 23:50 [Bug c++/54740] New: Empty base optimization gets confused when a member variable derives from the same empty base avenikov at google dot com
@ 2012-09-28 23:58 ` redi at gcc dot gnu.org
2012-09-29 0:01 ` redi at gcc dot gnu.org
2012-09-29 0:10 ` avenikov at google dot com
2 siblings, 0 replies; 4+ messages in thread
From: redi at gcc dot gnu.org @ 2012-09-28 23:58 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54740
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
Severity|major |normal
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-09-28 23:58:34 UTC ---
(In reply to comment #0)
> If you change outer to derive from another_empty_base, it returns 1 (which is
> correct). Whatever the correct result should be, they at least should be the
> same.
No they shouldn't. The standard requires this to pass:
outer o;
assert( static_cast<inner*>(&o) != &o.i_ );
[intro.object]/6 requires two separate objects of the same type to have
distinct addresses.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug c++/54740] Empty base optimization gets confused when a member variable derives from the same empty base.
2012-09-28 23:50 [Bug c++/54740] New: Empty base optimization gets confused when a member variable derives from the same empty base avenikov at google dot com
2012-09-28 23:58 ` [Bug c++/54740] " redi at gcc dot gnu.org
@ 2012-09-29 0:01 ` redi at gcc dot gnu.org
2012-09-29 0:10 ` avenikov at google dot com
2 siblings, 0 replies; 4+ messages in thread
From: redi at gcc dot gnu.org @ 2012-09-29 0:01 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54740
--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-09-29 00:01:31 UTC ---
(In reply to comment #1)
> No they shouldn't. The standard requires this to pass:
>
> outer o;
> assert( static_cast<inner*>(&o) != &o.i_ );
Oops, that should be:
assert( static_cast<empty_base*>(&o) != &o.i_ );
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug c++/54740] Empty base optimization gets confused when a member variable derives from the same empty base.
2012-09-28 23:50 [Bug c++/54740] New: Empty base optimization gets confused when a member variable derives from the same empty base avenikov at google dot com
2012-09-28 23:58 ` [Bug c++/54740] " redi at gcc dot gnu.org
2012-09-29 0:01 ` redi at gcc dot gnu.org
@ 2012-09-29 0:10 ` avenikov at google dot com
2 siblings, 0 replies; 4+ messages in thread
From: avenikov at google dot com @ 2012-09-29 0:10 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54740
--- Comment #3 from Andy Venikov <avenikov at google dot com> 2012-09-29 00:09:55 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > No they shouldn't. The standard requires this to pass:
> >
> > outer o;
> > assert( static_cast<inner*>(&o) != &o.i_ );
>
> Oops, that should be:
>
> assert( static_cast<empty_base*>(&o) != &o.i_ );
I see.
I was aware of the rule you mentioned, but it was hard to see how it could
apply here.
Sorry for the noise then.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-09-29 0:10 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-09-28 23:50 [Bug c++/54740] New: Empty base optimization gets confused when a member variable derives from the same empty base avenikov at google dot com
2012-09-28 23:58 ` [Bug c++/54740] " redi at gcc dot gnu.org
2012-09-29 0:01 ` redi at gcc dot gnu.org
2012-09-29 0:10 ` avenikov at google dot com
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).