From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 103045 invoked by alias); 6 Feb 2017 21:15: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 Received: (qmail 102806 invoked by uid 55); 6 Feb 2017 21:14:46 -0000 From: "hubicka at ucw dot cz" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/68664] [6/7 Regression] Speculative sqrt in c-ray main loop causes large slow down Date: Mon, 06 Feb 2017 21:15:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 6.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: hubicka at ucw dot cz X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: segher at gcc dot gnu.org X-Bugzilla-Target-Milestone: 6.4 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: 2017-02/txt/msg00708.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D68664 --- Comment #20 from Jan Hubicka --- > Scheduling should never move very expensive instructions to places they > are executed more frequently. This patch fixes that, reducing the > execution time of c-ray by over 40% (I tested on a BE Power7 system). >=20 > This introduces a new target hook sched.can_speculate_insn which returns > whether the scheduler is allowed to speculate a given instruction. The > rs6000 implementation disallows all divide and square root instructions. >=20 >=20 > PR rtl-optimization/68664 > * target.def (can_speculate_insn): New hook. > * doc/tm.texi.in (TARGET_SCHED_CAN_SPECULATE_INSN): New hook. > * doc/tm.texi: Regenerate. > * sched-rgn.c (can_schedule_ready_p): Use the new hook. > * config/rs6000/rs6000.c (TARGET_SCHED_CAN_SPECULATE_INSN): New m= acro. > (rs6000_sched_can_speculate_insn): New function. There was also regression on cray for x86-64 https://gcc.opensuse.org/c++bench-czerny/c-ray/ Is it the same issue? Also with profile feedback perhaps you have enough info to tell that the speculative path is almost as likely as the original placement. I wonder if we can provie resonable default by RTX cost... Honza >>From gcc-bugs-return-553177-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Feb 06 21:24:32 2017 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 115228 invoked by alias); 6 Feb 2017 21:24:04 -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 114816 invoked by uid 48); 6 Feb 2017 21:23:52 -0000 From: "hubicka at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/68664] [6/7 Regression] Speculative sqrt in c-ray main loop causes large slow down Date: Mon, 06 Feb 2017 21:24:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 6.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: hubicka at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: segher at gcc dot gnu.org X-Bugzilla-Target-Milestone: 6.4 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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: 2017-02/txt/msg00709.txt.bz2 Content-length: 438 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D68664 Jan Hubicka changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hubicka at gcc dot gnu.org --- Comment #21 from Jan Hubicka --- The two regressions happened at 2017 01-13 and 2016 08-11 >>From gcc-bugs-return-553178-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Feb 06 21:32:18 2017 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 76437 invoked by alias); 6 Feb 2017 21:32:18 -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 76218 invoked by uid 48); 6 Feb 2017 21:32:06 -0000 From: "segher at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/68664] [6/7 Regression] Speculative sqrt in c-ray main loop causes large slow down Date: Mon, 06 Feb 2017 21:32:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 6.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: segher at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: segher at gcc dot gnu.org X-Bugzilla-Target-Milestone: 6.4 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: 2017-02/txt/msg00710.txt.bz2 Content-length: 694 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D68664 --- Comment #22 from Segher Boessenkool --- (In reply to Jan Hubicka from comment #20) > There was also regression on cray for x86-64 > https://gcc.opensuse.org/c++bench-czerny/c-ray/ > Is it the same issue? I don't think so. But I don't know much about that bug, it is something with AVX I think? If you are talking about PR79224. > Also with profile feedback perhaps you have enough info to tell that the > speculative path is almost as likely as the original placement. Maybe. The gain will be tiny though, afaics. > I wonder if we can provie resonable default by RTX cost... Not for rs6000 at least. >>From gcc-bugs-return-553179-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Feb 06 21:59:40 2017 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 63945 invoked by alias); 6 Feb 2017 21:59:40 -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 63901 invoked by uid 48); 6 Feb 2017 21:59:35 -0000 From: "cantabile.desu at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/71107] wstring_convert::from_bytes produces wide chars with the wrong byte order Date: Mon, 06 Feb 2017 21:59:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 6.1.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: cantabile.desu at gmail dot com 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: --- 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: 2017-02/txt/msg00711.txt.bz2 Content-length: 152 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D71107 --- Comment #9 from Bitterblue --- Still broken in GCC 6.3.1... >>From gcc-bugs-return-553180-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Feb 06 22:14:57 2017 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 84387 invoked by alias); 6 Feb 2017 22:14:57 -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 84247 invoked by uid 48); 6 Feb 2017 22:14:44 -0000 From: "roland.illig at gmx dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug translation/79397] New: AltiVec spelled incorrectly in rs6000.opt Date: Mon, 06 Feb 2017 22:14:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: translation X-Bugzilla-Version: 7.0.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: roland.illig at gmx dot de 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: 2017-02/txt/msg00712.txt.bz2 Content-length: 575 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D79397 Bug ID: 79397 Summary: AltiVec spelled incorrectly in rs6000.opt Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- In config/rs6000/rs6000.opt, the word AltiVec is sometimes spelled "Altivec" and sometimes "AltiVec". The latter form should be used consistently. >>From gcc-bugs-return-553181-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Feb 06 22:28:52 2017 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 111732 invoked by alias); 6 Feb 2017 22:28:52 -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 111507 invoked by uid 48); 6 Feb 2017 22:28:39 -0000 From: "msebor at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/79398] New: misleading error static constexpr member function called in a constant expression before its definition is complete Date: Mon, 06 Feb 2017 22:28: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: 7.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: msebor at gcc dot gnu.org 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: 2017-02/txt/msg00713.txt.bz2 Content-length: 1535 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D79398 Bug ID: 79398 Summary: misleading error static constexpr member function called in a constant expression before its definition is complete Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- The error below is a bit confusing: the definition of B::bar() is complete = when it's called. I think I understand that the reason for the error below is actually that t= he function is called before the definition of the class of which it's a membe= r is complete. The error should make that clear, although it seems that accepti= ng it (e.g., as an extension) would make static constexpr member functions qui= te a bit more useful. $ cat y.C && gcc -S -Wall -Wextra -Wpedantic y.C=20 struct A { static constexpr int foo () { return 1; } }; struct B: A { static constexpr int bar () { return 2; } enum E { e =3D B::foo () }; enum F { f =3D B::bar () }; }; y.C:8:23: error: =E2=80=98static constexpr int B::bar()=E2=80=99 called in = a constant expression before its definition is complete enum F { f =3D B::bar () }; ~~~~~~~^~ y.C:8:24: error: enumerator value for =E2=80=98f=E2=80=99 is not an integer= constant enum F { f =3D B::bar () }; ^ >>From gcc-bugs-return-553182-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Feb 06 22:29:15 2017 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 112661 invoked by alias); 6 Feb 2017 22:29:15 -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 112490 invoked by uid 48); 6 Feb 2017 22:29:02 -0000 From: "msebor at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/79398] misleading error static constexpr member function called in a constant expression before its definition is complete Date: Mon, 06 Feb 2017 22:29:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 7.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: minor X-Bugzilla-Who: msebor at gcc dot gnu.org 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: keywords bug_severity 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: 2017-02/txt/msg00714.txt.bz2 Content-length: 352 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D79398 Martin Sebor changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |diagnostic Severity|normal |minor >>From gcc-bugs-return-553184-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Feb 06 23:16:58 2017 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 64488 invoked by alias); 6 Feb 2017 23:16:58 -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 64272 invoked by uid 55); 6 Feb 2017 23:16:45 -0000 From: "hubicka at ucw dot cz" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/68664] [6/7 Regression] Speculative sqrt in c-ray main loop causes large slow down Date: Mon, 06 Feb 2017 23:16:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 6.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: hubicka at ucw dot cz X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: segher at gcc dot gnu.org X-Bugzilla-Target-Milestone: 6.4 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: 2017-02/txt/msg00716.txt.bz2 Content-length: 1029 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D68664 --- Comment #23 from Jan Hubicka --- >=20 > I don't think so. But I don't know much about that bug, it is something > with AVX I think? If you are talking about PR79224. I see, we have separate PR for that, good ;) >=20 > > Also with profile feedback perhaps you have enough info to tell that the > > speculative path is almost as likely as the original placement. >=20 > Maybe. The gain will be tiny though, afaics. Usually profile is useful while driving speculation. I would add an param that prevents moving insn when bb->count or bb->frequency increases by large amount (like 100 times). Speculatively executing insn that will be ignored 99% of times is probably not paying back... Without profile that will probably only trigger for paths leading to abort() or similar cases, but with profiles that may hit quite common scenarios. Honza >=20 > > I wonder if we can provie resonable default by RTX cost... >=20 > Not for rs6000 at least. >>From gcc-bugs-return-553183-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Feb 06 23:16:11 2017 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 62790 invoked by alias); 6 Feb 2017 23:16:10 -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 62773 invoked by uid 89); 6 Feb 2017 23:16:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=profiles, Hx-languages-length:1004, driving, gain X-Spam-User: qpsmtpd, 2 recipients X-HELO: atrey.karlin.mff.cuni.cz Received: from atrey.karlin.mff.cuni.cz (HELO atrey.karlin.mff.cuni.cz) (195.113.26.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 06 Feb 2017 23:16:08 +0000 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 4018) id 031F681569; Tue, 7 Feb 2017 00:16:04 +0100 (CET) Date: Mon, 06 Feb 2017 23:16:00 -0000 From: Jan Hubicka To: "segher at gcc dot gnu.org" Cc: gcc-bugs@gcc.gnu.org Subject: Re: [Bug rtl-optimization/68664] [6/7 Regression] Speculative sqrt in c-ray main loop causes large slow down Message-ID: <20170206231604.GB20549@atrey.karlin.mff.cuni.cz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg00715.txt.bz2 Content-length: 905 > > I don't think so. But I don't know much about that bug, it is something > with AVX I think? If you are talking about PR79224. I see, we have separate PR for that, good ;) > > > Also with profile feedback perhaps you have enough info to tell that the > > speculative path is almost as likely as the original placement. > > Maybe. The gain will be tiny though, afaics. Usually profile is useful while driving speculation. I would add an param that prevents moving insn when bb->count or bb->frequency increases by large amount (like 100 times). Speculatively executing insn that will be ignored 99% of times is probably not paying back... Without profile that will probably only trigger for paths leading to abort() or similar cases, but with profiles that may hit quite common scenarios. Honza > > > I wonder if we can provie resonable default by RTX cost... > > Not for rs6000 at least.