[Bug middle-end/64642] New: Malformed code as result of C-cast to (polymorphic) object-reference (an opt-level ...)

[meisenmann.lba@fh-salzburg.ac.at]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64642

            Bug ID: 64642
           Summary: Malformed code as result of C-cast to (polymorphic)
                    object-reference (an opt-level ...)
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: meisenmann.lba@fh-salzburg.ac.at

Hi!

I've analyzed some (IMHO) malicious/mallformed cast(s) to a reference-type by
using a C-cast. Additional to the already documented issue on an ICE (see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64641), I've determined a similar
test, which generates malformed (assembler) code.

Note: I've used a (private) build of an GCC Cross-compiler (target=i386-elf,
host=mingw32), but the Mingw-W64 build of GCC 4.9.2 *) shows the same result.

*) Downloaded from
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.2/threads-posix/dwarf/
(package i686-4.9.2-release-posix-dwarf-rt_v3-rev1.7z)

Following (minimal) sample:
/*-----*/
class A
{
public:
    virtual int get() const { return m_val; }
protected:
    int m_val;
};

int Test3(int arg)
{
    A& ref = (A&) arg;
    return ref.get();
}
/*-----*/

The difference to the "ICE-sample" (bug 64641) is only the type of the argument
(Ie. using 'int' instead of 'int*').

If the method get() has an inline-definition (like above) and if (for example)
the compiler-optimization '-Os' is used, the generated i386/x86-code is:

__Z5Test3i:
LFB1:
        .cfi_startproc
        pushl   %ebp
        .cfi_def_cfa_offset 8
        .cfi_offset 5, -8
        movl    %esp, %ebp
        .cfi_def_cfa_register 5
        .cfi_endproc

And nothing "more"; Ie. only the function-prolog is there, but the body (cast,
virtual call) and function-epilog is dropped!

Note: As noted above, it' depends on the inline-definition and opt-level (maybe
other optimization-options).

Best regards from Salzburg,
Markus