[Bug c++/17287] New: Different class layout generated by g++ 3.3, 3.4 and 3.5.

[yanliu at ca dot ibm dot com]

I found that g++ 3.3, 3.4 and 3.5 generate different class layouts for the
following testcase:
struct A {char a;};

struct B: virtual public A {};

struct C:public B{
  int c;
  virtual void f() {};
};
struct D {
        char d;
};
struct E {int:3;};
struct F: public C, virtual E, public D {
        char f1;
        virtual void f(){}
};
int main()
{F f;}

g++ 3.3's information is:
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --enable-languages=c,c++,f77,objc,java,ada
--disable-checking --libdir=/usr/lib --enable-libgcj
--with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib
--with-system-zlib --enable-shared --enable-__cxa_atexit
--host=powerpc-suse-linux --build=powerpc-suse-linux
--target=powerpc-suse-linux --enable-targets=powerpc64-suse-linux
--enable-biarch
Thread model: posix
gcc version 3.3.3 (SuSE Linux)
g++3.4's information is:
 Configured with: ../gcc/configure
--prefix=/.../torolab.ibm.com/fs/projects/vabld/run/gcc/linux_ppc/3.4-dev
--enable-languages=c,c++,f77,objc --enable-altivec --enable-shared
powerpc-suse-linux
Thread model: posix
gcc version 3.4.0 20040212 (prerelease)

g++ 3.5's information is:
Configured with: /private/var/tmp/gcc/gcc-1765.obj~1/src/configure
--disable-checking --prefix=/usr --disable-libmudflap --mandir=/share/man
--enable-languages=c,objc,c++ --disable-libada
--program-transform-name=/^[cg][^+.-]*$/s/$/-3.5/
--with-gxx-include-dir=/include/gcc/darwin/3.5/c++
--build=powerpc-apple-darwin --host=powerpc-apple-darwin
--target=powerpc-apple-darwin
Thread model: posix
gcc version 3.5.0-tree-ssa 20040321 (merged 20040529) (Apple Computer, Inc.
build 1765)

Three attached files contain the class layout results with three g++
compilers using -fdump-class-hierarchy options.

I noticed that from g++3.3 to g++3.4, you changed the rule of the starting
offset of virtual bases.  The virtual bases can be put at offset which is not
the multiple of the current class's alignment. In this testcase, after mapping
the virtual base class A while mapping of the most derived class F,  the
dsize(F)=11, size(F)=11, align(F)=4, and nvsize(E)=4, nvalign(E)=4.  So, when
mapping virtual base class E, the next available bits are at offset dsize(F)=11.
 E should be put at offset(F) which is the dsize(F) =11, and the final class
size should be 12. To me, g++3.4 gives the most reasonable result, I don't
understand why g++3.5 put E at offset 12, and the final class size is 16. 

Can you explain the class mapping rule in more detail?

-- 
           Summary: Different  class layout generated by  g++ 3.3, 3.4 and
                    3.5.
           Product: gcc
           Version: 3.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: yanliu at ca dot ibm dot com
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17287