[Bug c++/60201] Issue with CRTP generation under 4.8.1

["pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Look at the original object:
    Baseclass<Subclass<ParamOne, ParamTwo>, ParamOne, ParamTwo> test;

test is of class Baseclass.  You call Method on it.
Method then has a cast from Baseclass to Subclass for *this but *this is only
of type Baseclass and not Subclass.

So when you call SubclassMethod on the object you just casted, it would really
be only a Baseclass and not a Subclass so m_SubClassValue never was initialized
and is in fact outside of the object.

If we run using valgrind we get:
==10910== Use of uninitialised value of size 8
==10910==    at 0x56167AB: _itoa_word (_itoa.c:195)
==10910==    by 0x5619347: vfprintf (vfprintf.c:1616)
==10910==    by 0x5621A59: printf (printf.c:35)
==10910==    by 0x400740: Subclass<ParamOne, ParamTwo>::SubclassMethod(ParamOne
const&, ParamTwo&) (t.cc:60)
==10910==    by 0x4007D6: Baseclass<Subclass<ParamOne, ParamTwo>, ParamOne,
ParamTwo>::Method(ParamOne const&) (t.cc:35)
==10910==    by 0x400787: main (t.cc:71)

If we run using address sanitizer we get:
================================================================
==11676== ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7fff3594a8d4 at pc 0x400a6f bp 0x7fff3594a7c0 sp 0x7fff3594a7b8
READ of size 4 at 0x7fff3594a8d4 thread T0
    #0 0x400a6e (/home/apinski/a.out+0x400a6e)
    #1 0x400cdd (/home/apinski/a.out+0x400cdd)
    #2 0x400bc8 (/home/apinski/a.out+0x400bc8)
    #3 0x7fe47a7b9c8c (/lib/libc-2.11.3.so+0x1ec8c)
    #4 0x4008d8 (/home/apinski/a.out+0x4008d8)
Address 0x7fff3594a8d4 is located at offset 36 in frame <main> of T0's stack:
  This frame has 2 object(s):
    [32, 36) 'test'
    [96, 104) 'one'


See how test ends at 36 but we are accessing location 36.