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

[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

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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

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

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Well, you invoke undefined behavior here which means GCC can do anything it
wants.
In this case it simply marks the virtual call unreachable and simplifies the
code according to that.

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

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

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

--- Comment #2 from Markus Eisenmann <meisenmann.lba@fh-salzburg.ac.at> ---
I do not (completely) agree, that the code/result is undefined. Of course, this
sample doesn’t make any sense and shouldn’t never occur (in a similar form).

But - in this case - the C-style cast, like
    A& ref = (A&) arg;
is a “interpreted” as *):
    A& ref = *reinterpret_cast<A*>(&arg);

*) As (IMHO) described in C++ Standard (2003).

Assuming, that arg is passed on stack (Ie. Memory), the code seems to be valid.
If the passed value (itself) points to valid code (and based on the
vtable-layout) it’s may be a valid (sub-) call.

At least, I’ve wondered about the optimizer-result; regardless, whether it
makes sense and compared/based to my understanding of the C++ Standard (or
earlier GCC-releases or other C++-compilers).
>From gcc-bugs-return-473889-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jan 19 19:22:30 2015
Return-Path: <gcc-bugs-return-473889-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 24976 invoked by alias); 19 Jan 2015 19:22:29 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 24942 invoked by uid 48); 19 Jan 2015 19:22:20 -0000
From: "rth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libffi/64645] liibffi fails to build on cygwin-32
Date: Mon, 19 Jan 2015 19:22:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libffi
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rth at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on cc assigned_to everconfirmed
Message-ID: <bug-64645-4-VuKg8idYIf@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64645-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64645-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-01/txt/msg01883.txt.bz2
Content-length: 669

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd645

Richard Henderson <rth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2015-01-19
                 CC|                            |rth at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |rth at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #2 from Richard Henderson <rth at gcc dot gnu.org> ---
Mine.  We can't just omit the unwind info.