https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67133 --- Comment #9 from Markus Trippelsdorf --- trippels@gcc2-power8 llvm_build % cat AnalysisConsumer.ii class A; struct B { typedef A type; }; template struct I : B {}; class C { public: C(char *); int size(); }; template struct D; template > class F { class G { template static _Tp *__test(); typedef int _Del; public: typedef decltype(__test<_Del>()) type; }; public: typename I<_Tp>::type operator*() { typename G::type a = 0; return *a; } }; class H { F Out; H(); }; void fn1(void *, void *, int) __attribute__((__nonnull__)); class A { int OutBufEnd, OutBufCur; public: void operator<<(C p1) { int b, c = p1.size(); if (OutBufEnd) fn1(&OutBufCur, &b, c); } }; char* a; H::H() { *Out << a; } trippels@gcc2-power8 llvm_build % g++ -O2 -c AnalysisConsumer.ii AnalysisConsumer.ii: In constructor â€˜H::H()â€™: AnalysisConsumer.ii:43:1: internal compiler error: Segmentation fault H::H() { *Out << a; } ^ 0x10a18c53 crash_signal ../../gcc/gcc/toplev.c:352 0x1072af0c infer_nonnull_range_by_attribute(gimple_statement_base*, tree_node*) ../../gcc/gcc/gimple.c:2682 0x110a881f find_explicit_erroneous_behaviour ../../gcc/gcc/gimple-ssa-isolate-paths.c:410 0x110a881f gimple_ssa_isolate_erroneous_paths ../../gcc/gcc/gimple-ssa-isolate-paths.c:526 0x110a881f execute ../../gcc/gcc/gimple-ssa-isolate-paths.c:577 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. >From gcc-bugs-return-494320-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Aug 06 18:56:01 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 112574 invoked by alias); 6 Aug 2015 18:56:00 -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 112499 invoked by uid 48); 6 Aug 2015 18:55:56 -0000 From: "rsandifo at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/67124] [6 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu Date: Thu, 06 Aug 2015 18:56: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: 6.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rsandifo at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 6.0 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-08/txt/msg00462.txt.bz2 Content-length: 826 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67124 --- Comment #6 from rsandifo at gcc dot gnu.org --- (In reply to UroÅ¡ Bizjak from comment #5) > Wrong expansion, adding CC. The expand code looks OK to me. Assigning to one DImode word of a TImode isn't supposed to change the other half. I think the problem is in LRA. It tries to reload the low half of the TImode as follows: Creating newreg=104, assigning class NO_REGS to secondary r104 51: r104:DI=r103:DI Inserting the sec. move after: 52: r90:TI#0=r104:DI then allocates it as an xmm<-mem move: Choosing alt 14 in insn 52: (0) *v (1) m {*movdi_internal} That isn't right because the move won't preserve the high half of the xmm register. It would need to be a strict_lowpart to do that. >From gcc-bugs-return-494321-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Aug 06 19:05:01 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 129399 invoked by alias); 6 Aug 2015 19:05:01 -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 129334 invoked by uid 48); 6 Aug 2015 19:04:56 -0000 From: "boger at us dot ibm.com" To: gcc-bugs@gcc.gnu.org Subject: [Bug go/66870] split stack issues on ppc64le and ppc64 Date: Thu, 06 Aug 2015 19:05:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: go X-Bugzilla-Version: 6.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: boger at us dot ibm.com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: ian at airs dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created 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-08/txt/msg00463.txt.bz2 Content-length: 675 https://gcc.gnu.org/bugzilla/show_bug.cgi?idf870 --- Comment #21 from boger at us dot ibm.com --- Created attachment 36142 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id6142&actioníit Configure gold with split stack based on binutils version This is an updated version of the previous patch, simplifying the test done in gcc/configure.ac. Instead of trying to link a program this just checks the binutils version number on the ld.gold --version output. The configure check in libgo will fail if the gold linker doesn't have split stack support but only on pp64le. On ppc64 the version check should be sufficient to make sure the right gold linker is there.