From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20788 invoked by alias); 19 Jan 2015 19:17:24 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 20734 invoked by uid 48); 19 Jan 2015 19:17:18 -0000 From: "meisenmann.lba@fh-salzburg.ac.at" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/64642] Malformed code as result of C-cast to (polymorphic) object-reference (depends on opt-level ...) Date: Mon, 19 Jan 2015 19:17:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 4.9.2 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: meisenmann.lba@fh-salzburg.ac.at X-Bugzilla-Status: RESOLVED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-01/txt/msg01882.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D64642 --- Comment #2 from Markus Eisenmann --- I do not (completely) agree, that the code/result is undefined. Of course, = this sample doesn=E2=80=99t make any sense and shouldn=E2=80=99t never occur (in= a similar form). But - in this case - the C-style cast, like A& ref =3D (A&) arg; is a =E2=80=9Cinterpreted=E2=80=9D as *): A& ref =3D *reinterpret_cast(&arg); *) As (IMHO) described in C++ Standard (2003). Assuming, that arg is passed on stack (Ie. Memory), the code seems to be va= lid. If the passed value (itself) points to valid code (and based on the vtable-layout) it=E2=80=99s may be a valid (sub-) call. At least, I=E2=80=99ve wondered about the optimizer-result; regardless, whe= ther 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: 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: List-Archive: List-Post: List-Help: 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" 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: In-Reply-To: References: 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?id=64645 Richard Henderson 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 --- Mine. We can't just omit the unwind info.