[Bug c++/39981] zero-size base class optimization fails in certain scenarios
--- Comment #10 from navinkumar+bugs at gmail dot com 2009-11-09 18:08 --- After review, I agree it is not a bug. Because _0_emptyB and _2_emptyB both inherent from empty_t, the compiler is obligated to ensure that static_cast(static_cast<_0_emptyB*>(compositeB2)) != static_cast(static_cast<_2_emptyB*>(compositeB2)). The zero-size base class optimization doesn't apply when the grandparent empty class is repeated. -- navinkumar+bugs at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39981
[Bug c++/39981] zero-size base class optimization fails in certain scenarios
--- Comment #9 from paolo dot carlini at oracle dot com 2009-11-09 17:51 --- For the record, the Intel compiler, also implementing the IA64 C++ ABI, behaves exactly the same as GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39981
[Bug c++/39981] zero-size base class optimization fails in certain scenarios
--- Comment #8 from navinkumar+bugs at gmail dot com 2009-11-09 17:39 --- Created an attachment (id=19000) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19000&action=view) demonstrates scenarios when zero-size base class optimization fails, compile with flag: -std=c++0x -- navinkumar+bugs at gmail dot com changed: What|Removed |Added Attachment #18986|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39981
[Bug c++/39981] zero-size base class optimization fails in certain scenarios
--- Comment #7 from navinkumar+bugs at gmail dot com 2009-11-09 17:35
---
(From update of attachment 18986)
>#include
>#include
>#include
>#include
>
>struct empty_t {
> template
> explicit empty_t(Arg arg) { }
>};
>
>template
>struct EmptyWrapperA {
> template
> explicit EmptyWrapperA(Arg arg) { }
> static_assert(std::is_empty::value, "sanity check");
>};
>
>template
>struct EmptyWrapperB : T {
> template
> explicit EmptyWrapperB(Arg arg) : T(arg) { }
> static_assert(std::is_empty::value, "sanity check");
>};
>
>template
>struct Member {
> T m_value;
> template
> explicit Member(Arg arg) : m_value(arg) { }
>};
>
>typedef EmptyWrapperA<0,empty_t> _0_emptyA; typedef EmptyWrapperB<0,empty_t>
>_0_emptyB;
>typedef Member<1,int> _1_member;
>typedef EmptyWrapperA<2,empty_t> _2_emptyA; typedef EmptyWrapperB<2,empty_t>
>_2_emptyB;
>
>static_assert(std::is_empty<_0_emptyA>::value, "sanity check");
>static_assert(std::is_empty<_0_emptyB>::value, "sanity check");
>static_assert(std::is_empty<_2_emptyA>::value, "sanity check");
>static_assert(std::is_empty<_2_emptyB>::value, "sanity check");
>class compositeA1 : _0_emptyA, _1_member, _2_emptyA { };
>class compositeA2 : _0_emptyA, _1_member { };
>class compositeB1 : _0_emptyB, _1_member { };
>class compositeB2 : _0_emptyB, _1_member, _2_emptyB { };
>class compositeB3 : _1_member, _2_emptyB { };
>
>int main(int argc, char** argv) {
> // output *should* be 4 since "int" is the only data member
> // something is wrong with GCC's zero-size base class optimization for
> compositeB1
> std::cout << "sizeA1: " << sizeof(compositeA1) << std::endl; // outputs
> 4
> std::cout << "sizeA2: " << sizeof(compositeA2) << std::endl; // outputs
> 4
> std::cout << "sizeB1: " << sizeof(compositeB1) << std::endl; // outputs
> 4
> std::cout << "sizeB2: " << sizeof(compositeB2) << std::endl; // outputs
> 8
> std::cout << "sizeB3: " << sizeof(compositeB3) << std::endl; // outputs
> 4
> return 0;
>}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39981
[Bug c++/39981] zero-size base class optimization fails in certain scenarios
--- Comment #4 from navinkumar+bugs at gmail dot com 2009-04-30 19:22 --- Since std::is_empty<_2_emptyB>::value && std::is_empty<_2_emptyA>::value (as verified by the static assertions), GCC should not treat _2_emptyB differently from _2_emptyA when computing the structure's layout. The IA64 C++ ABI only talks about pod, data, and empty structures, so the ABI specification does not distinguish between _2_emptyB and _2_emptyA. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39981
[Bug c++/39981] zero-size base class optimization fails in certain scenarios
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-30 19:01 --- I think GCC is doing the correct thing here as there is no padding to put _2_emptyB in. And this is not a zero-size base class optimization but rather padding filling class optimization. Have you read the IA64 C++ ABI (or the ARM EABI C++ ABI) to see what it has to say about this case? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39981
[Bug c++/39981] zero-size base class optimization fails in certain scenarios
--- Comment #2 from navinkumar+bugs at gmail dot com 2009-04-30 18:57 --- Tested with 2 versions of GCC, same behavior; Version #1 Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /1123/scratch/gcc4.4.0/src/configure --prefix=/1123/software/gcc4.4.0 --with-local-prefix=/1123/software/local --enable-languages=c,c++ --enable-checking=release --enable-tls --enable-threads --disable-multilib Thread model: posix gcc version 4.4.0 (GCC) Version #2 Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/usr --enable-shared --enable-languages=c,c++,fortran,objc,obj-c++,treelang --enable-threads=posix --mandir=/usr/share/man --infodir=/usr/share/info --enable-__cxa_atexit --disable-multilib --libdir=/usr/lib --libexecdir=/usr/lib --enable-clocale=gnu --disable-libstdcxx-pch --with-tune=generic Thread model: posix gcc version 4.3.3 (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39981
[Bug c++/39981] zero-size base class optimization fails in certain scenarios
--- Comment #1 from navinkumar+bugs at gmail dot com 2009-04-30 18:54 --- Created an attachment (id=17785) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17785&action=view) demonstrates scenarios when zero-size base class optimization fails compile with flag: -std=c++0x -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39981
