From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 123334 invoked by alias); 15 Sep 2015 08:38:38 -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 123301 invoked by uid 48); 15 Sep 2015 08:38:35 -0000 From: "vegard.nossum at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/67582] New: typeof(*p) * fails when p is void * Date: Tue, 15 Sep 2015 08:38:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 4.8.4 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vegard.nossum at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: 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-09/txt/msg01203.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D67582 Bug ID: 67582 Summary: typeof(*p) * fails when p is void * Product: gcc Version: 4.8.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: vegard.nossum at gmail dot com Target Milestone: --- $ gcc --version gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4 $ cat voidptr=20 void foo(void *p) { typeof(*p) *x; } I'd expect this to work as if 'x' was declared 'void *x' (which is legal). = It works in C, but not in C++: $ gcc -x c -c - < voidptr && echo success success $ gcc -x c++ -c - < voidptr : In function =E2=80=98int foo(void*)=E2=80=99: :3:10: error: =E2=80=98void*=E2=80=99 is not a pointer-to-object type :3:15: error: invalid type in declaration before =E2=80=98;=E2=80=99= token >>From gcc-bugs-return-497226-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Sep 15 09:21:45 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 96726 invoked by alias); 15 Sep 2015 09:21:44 -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 96633 invoked by uid 48); 15 Sep 2015 09:21:40 -0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/67470] [5/6 Regression] ICE at -O3 on x86_64-linux-gnu in compute_live_loop_exits, at tree-ssa-loop-manip.c:235 Date: Tue, 15 Sep 2015 09:21:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 6.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 5.3 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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-09/txt/msg01204.txt.bz2 Content-length: 676 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67470 --- Comment #6 from Richard Biener --- g_40 = PHI <0B(9), &a(6)> invariant up to level 1, cost 21. pretmp_42 = g_40 == 0B; invariant up to level 1, cost 22. but we're only moving pretmp_42, not g_40. The PHI is controlled by if (f_16(D) != 0). But when applying stmt movement we are faced with g_40 = PHI <0B(9), &a(6)> turned into : # g_40 = PHI <0B(26), &a(21), &a(22), 0B(25)> whoops. That's because predicated store-motion already messed up the CFG without ensuring we have forwarder blocks that at least preserve the existing PHI node structure. This is a latent issue.