public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug middle-end/64642] New: Malformed code as result of C-cast to (polymorphic) object-reference (an opt-level ...)
@ 2015-01-17 9:23 meisenmann.lba@fh-salzburg.ac.at
2015-01-19 10:58 ` [Bug middle-end/64642] Malformed code as result of C-cast to (polymorphic) object-reference (depends on " rguenth at gcc dot gnu.org
2015-01-19 19:17 ` meisenmann.lba@fh-salzburg.ac.at
0 siblings, 2 replies; 3+ messages in thread
From: meisenmann.lba@fh-salzburg.ac.at @ 2015-01-17 9:23 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug middle-end/64642] Malformed code as result of C-cast to (polymorphic) object-reference (depends on opt-level ...)
2015-01-17 9:23 [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
@ 2015-01-19 10:58 ` rguenth at gcc dot gnu.org
2015-01-19 19:17 ` meisenmann.lba@fh-salzburg.ac.at
1 sibling, 0 replies; 3+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-01-19 10:58 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug middle-end/64642] Malformed code as result of C-cast to (polymorphic) object-reference (depends on opt-level ...)
2015-01-17 9:23 [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
2015-01-19 10:58 ` [Bug middle-end/64642] Malformed code as result of C-cast to (polymorphic) object-reference (depends on " rguenth at gcc dot gnu.org
@ 2015-01-19 19:17 ` meisenmann.lba@fh-salzburg.ac.at
1 sibling, 0 replies; 3+ messages in thread
From: meisenmann.lba@fh-salzburg.ac.at @ 2015-01-19 19:17 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-01-19 19:17 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-17 9:23 [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
2015-01-19 10:58 ` [Bug middle-end/64642] Malformed code as result of C-cast to (polymorphic) object-reference (depends on " rguenth at gcc dot gnu.org
2015-01-19 19:17 ` meisenmann.lba@fh-salzburg.ac.at
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).