From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 42255 invoked by alias); 29 Nov 2019 09:01:20 -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 42174 invoked by uid 48); 29 Nov 2019 09:01:15 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/92714] [missed-optimization] aggregate initialization of an array fills the whole array with zeros first, including leading non-zero elements Date: Fri, 29 Nov 2019 09:01: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: 8.1.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub 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: --- 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: 2019-11/txt/msg03557.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92714 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Or in theory store-merging could do this, although it can handle only the = =3D {} and not memset right now. That said, just unconditionally adjusting the clearing store not to cover the boundaries which are overwritten is not a g= ood idea, it is much faster to start with an 8 or 16 byte aligned address over skipping 3 or 7 bytes there. >>From gcc-bugs-return-661764-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 09:04:02 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 44959 invoked by alias); 29 Nov 2019 09:04:02 -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 44890 invoked by uid 55); 29 Nov 2019 09:03:57 -0000 From: "marxin at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/91574] [10 Regression] ICE in types_same_for_odr at gcc/ipa-devirt.c:355 since r272037 Date: Fri, 29 Nov 2019 09:04:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: lto X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: ice-on-valid-code, patch X-Bugzilla-Severity: normal X-Bugzilla-Who: marxin at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: marxin at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.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: 2019-11/txt/msg03558.txt.bz2 Content-length: 728 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D91574 --- Comment #2 from Martin Li=C5=A1ka --- Author: marxin Date: Fri Nov 29 09:03:25 2019 New Revision: 278829 URL: https://gcc.gnu.org/viewcvs?rev=3D278829&root=3Dgcc&view=3Drev Log: Check for TYPE_NAME in type_with_linkage_p. 2019-11-29 Martin Liska PR lto/91574 * ipa-devirt.c (types_same_for_odr): Check for existence of TYPE_NAMEs first. 2019-11-29 Martin Liska PR lto/91574 * g++.dg/lto/pr91574_0.C: New test. Added: trunk/gcc/testsuite/g++.dg/lto/pr91574_0.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-devirt.c trunk/gcc/testsuite/ChangeLog >>From gcc-bugs-return-661765-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 09:08:29 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 55759 invoked by alias); 29 Nov 2019 09:08:28 -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 55702 invoked by uid 55); 29 Nov 2019 09:08:24 -0000 From: "ebotcazou at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug ada/92489] [9 regression] internal error on Invalid_Value Attribute attribute Date: Fri, 29 Nov 2019 09:08:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: ada X-Bugzilla-Version: 9.2.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ebotcazou at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: ebotcazou at gcc dot gnu.org X-Bugzilla-Target-Milestone: 9.3 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: 2019-11/txt/msg03559.txt.bz2 Content-length: 656 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92489 --- Comment #4 from Eric Botcazou --- Author: ebotcazou Date: Fri Nov 29 09:07:53 2019 New Revision: 278830 URL: https://gcc.gnu.org/viewcvs?rev=3D278830&root=3Dgcc&view=3Drev Log: PR ada/92489 Backport from mainline 2019-07-01 Ed Schonberg * exp_attr.adb (Expand_Attribute_Reference, case Invalid_Value): Resolve result of call to Get_Simple_Init_Val, which may be a conversion of a literal. Modified: branches/gcc-9-branch/gcc/ada/ChangeLog branches/gcc-9-branch/gcc/ada/exp_attr.adb >>From gcc-bugs-return-661767-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 09:09:31 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 59693 invoked by alias); 29 Nov 2019 09:09:31 -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 58911 invoked by uid 55); 29 Nov 2019 09:09:23 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/60228] ICE using lambda in #pragma omp declare reduction Date: Fri, 29 Nov 2019 09:09: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: 4.9.0 X-Bugzilla-Keywords: ice-on-valid-code, openmp X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jakub 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: 2019-11/txt/msg03561.txt.bz2 Content-length: 1620 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D60228 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Fri Nov 29 09:08:46 2019 New Revision: 278831 URL: https://gcc.gnu.org/viewcvs?rev=3D278831&root=3Dgcc&view=3Drev Log: PR c++/60228 * parser.c (cp_parser_omp_declare_reduction_exprs): If processing_template_decl, wrap the combiner or initializer into EXPR_STMT. * decl.c (start_preparsed_function): Don't start a lambda scope for DECL_OMP_DECLARE_REDUCTION_P functions. (finish_function): Don't finish a lambda scope for DECL_OMP_DECLARE_REDUCTION_P functions, nor cp_fold_function them nor cp_genericize them. * mangle.c (decl_mangling_context): Look through DECL_OMP_DECLARE_REDUCTION_P functions. * semantics.c (expand_or_defer_fn_1): For DECL_OMP_DECLARE_REDUCTIO= N_P functions, use tentative linkage, don't keep their bodies with -fkeep-inline-functions and return false at the end. * g++.dg/gomp/openmp-simd-2.C: Don't expect bodies for DECL_OMP_DECLARE_REDUCTION_P functions. * testsuite/libgomp.c++/udr-20.C: New test. * testsuite/libgomp.c++/udr-21.C: New test. Added: trunk/libgomp/testsuite/libgomp.c++/udr-20.C trunk/libgomp/testsuite/libgomp.c++/udr-21.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/mangle.c trunk/gcc/cp/parser.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/gomp/openmp-simd-2.C trunk/libgomp/ChangeLog >>From gcc-bugs-return-661766-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 09:09:19 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 58460 invoked by alias); 29 Nov 2019 09:09:19 -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 57881 invoked by uid 48); 29 Nov 2019 09:09:13 -0000 From: "ebotcazou at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug ada/92489] [9 regression] internal error on Invalid_Value Attribute attribute Date: Fri, 29 Nov 2019 09:09:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: ada X-Bugzilla-Version: 9.2.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ebotcazou at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: ebotcazou at gcc dot gnu.org X-Bugzilla-Target-Milestone: 9.3 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution 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: 2019-11/txt/msg03560.txt.bz2 Content-length: 458 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92489 Eric Botcazou changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Eric Botcazou --- Thanks for reporting the problem. >>From gcc-bugs-return-661768-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 09:11:20 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 64072 invoked by alias); 29 Nov 2019 09:11:19 -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 63992 invoked by uid 55); 29 Nov 2019 09:11:15 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/60228] ICE using lambda in #pragma omp declare reduction Date: Fri, 29 Nov 2019 09:11: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: 4.9.0 X-Bugzilla-Keywords: ice-on-valid-code, openmp X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jakub 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: 2019-11/txt/msg03562.txt.bz2 Content-length: 1367 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D60228 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Fri Nov 29 09:10:44 2019 New Revision: 278832 URL: https://gcc.gnu.org/viewcvs?rev=3D278832&root=3Dgcc&view=3Drev Log: PR c++/60228 * parser.c (cp_parser_omp_declare_reduction_exprs): If processing_template_decl, wrap the combiner or initializer into EXPR_STMT. * decl.c (start_preparsed_function): Don't start a lambda scope for DECL_OMP_DECLARE_REDUCTION_P functions. (finish_function): Don't finish a lambda scope for DECL_OMP_DECLARE_REDUCTION_P functions, nor cp_fold_function them nor cp_genericize them. * mangle.c (decl_mangling_context): Look through DECL_OMP_DECLARE_REDUCTION_P functions. * semantics.c (expand_or_defer_fn_1): For DECL_OMP_DECLARE_REDUCTIO= N_P functions, use tentative linkage, don't keep their bodies with -fkeep-inline-functions and return false at the end. * g++.dg/gomp/openmp-simd-2.C: Don't expect bodies for DECL_OMP_DECLARE_REDUCTION_P functions. * testsuite/libgomp.c++/udr-20.C: New test. * testsuite/libgomp.c++/udr-21.C: New test. Modified: trunk/libgomp/testsuite/libgomp.c++/udr-20.C trunk/libgomp/testsuite/libgomp.c++/udr-21.C >>From gcc-bugs-return-661769-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 09:14:27 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 74394 invoked by alias); 29 Nov 2019 09:14:23 -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 74338 invoked by uid 48); 29 Nov 2019 09:14:19 -0000 From: "dcb314 at hotmail dot com" To: gcc-bugs@gcc.gnu.org Subject: =?UTF-8?B?W0J1ZyB0cmVlLW9wdGltaXphdGlvbi85MjcxNV0gWzEwIFJlZ3Jlc3Npb25d?= =?UTF-8?B?IGVycm9yOiBwb3NpdGlvbiBwbHVzIHNpemUgZXhjZWVkcyBzaXplIG9mIHJl?= =?UTF-8?B?ZmVyZW5jZWQgb2JqZWN0IGluICDigJhiaXRfZmllbGRfcmVm4oCZ?= Date: Fri, 29 Nov 2019 09:14: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: 10.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: dcb314 at hotmail dot com X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.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: 2019-11/txt/msg03563.txt.bz2 Content-length: 3725 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92715 --- Comment #5 from David Binderman --- Reduced C++ code: typedef double a __attribute__((__vector_size__(32))); double b; a c; enum { d, e }; template struct h; template class i; template class aa; template class j; template class ab; template struct ae; template struct w; template struct x { typedef typename ae::k k; }; template struct y { typedef j k; }; template ai aj(const typename w::k &); template <> struct ae { typedef a k; }; template <> struct w { typedef double k; }; template <> a aj(const double &ak) { c =3D a{ak, ak, ak, ak}; return c; } struct z { z(double am) : an(am) {} template void ao() { aj(an); } double an; }; struct ap { template void aq(double *, ai); }; template class ar { public: typedef typename h::al al; typedef aa::as, h::at, e, h::au, h::av> aw; typedef ab ax; const ax ay(const al &); template const ab ba(const az &); ah &operator/=3D(const al &); }; template class j : public ar {}; template struct ac { typename ah::al &bb(long); }; template struct ac> : ac>> { typedef aa bh; ac(bh); }; struct bi { template void ao(z bk, bj) { bk.ao(); } }; template struct ac> { ac(ab l) : bn(l.bo()) {} template ag bp(bj bq) { br.ao(bn, bq)= ; } bl bn; bi br; }; template struct bt { typedef typename bs::bh bu; typedef typename x::k ag; }; template struct bw { static void bx(bv by) { enum { bz, ca, cb }; by.template aq(bz); } }; template class cf { public: typedef cc cg; typedef cd ch; typedef typename bt::ag ag; cf(cg ci, ch cj, ce, cc) : ck(ci), cl(cj) {} template void aq(long bq) { bn.template aq(&ck.bb(bq), cl.template bp(bq)); } cg ck; ch cl; ce bn; }; template void cp(cn ci, co cj, ce c= q) { typedef ac cg; typedef ac ch; ch a(cj); cg d(ci); typedef cf bv; bv e(d, a, cq, ci); bw::bx(e); } template void m(bu ci, cr cj, cs cq= ) { ab> n =3D cj; cp(ci, n, cq); } template class i : public y::k {}; template struct h> { typedef o al; enum { as, at, au, av }; }; template class aa : public i> {}; template class ab { public: ab(long, long, z cq) : bn(cq) {} z bo() { return bn; } z bn; }; template template const ab::aw> ar::ba(const az &cq) { return ab(0, 0, cq); } template const typename ar::ax ar::ay(const al &p) { return ba(z(p)); } template ah &ar::operator/=3D(const al &am) { ah s; ab> t =3D ay(am); m(s, t, ap()); } void v() { aa f; __attribute__((__vector_size__(2 * sizeof(double)))) double g; b =3D g[0]; f /=3D b; } >>From gcc-bugs-return-661771-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 09:19:24 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 84349 invoked by alias); 29 Nov 2019 09:19: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 Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 84286 invoked by uid 55); 29 Nov 2019 09:19:20 -0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: =?UTF-8?B?W0J1ZyB0cmVlLW9wdGltaXphdGlvbi85MjcxNV0gWzEwIFJlZ3Jlc3Npb25d?= =?UTF-8?B?IGVycm9yOiBwb3NpdGlvbiBwbHVzIHNpemUgZXhjZWVkcyBzaXplIG9mIHJl?= =?UTF-8?B?ZmVyZW5jZWQgb2JqZWN0IGluICDigJhiaXRfZmllbGRfcmVm4oCZ?= Date: Fri, 29 Nov 2019 09:19: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: 10.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.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: 2019-11/txt/msg03565.txt.bz2 Content-length: 724 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92715 --- Comment #7 from Richard Biener --- Author: rguenth Date: Fri Nov 29 09:18:48 2019 New Revision: 278833 URL: https://gcc.gnu.org/viewcvs?rev=3D278833&root=3Dgcc&view=3Drev Log: 2019-11-29 Richard Biener PR tree-optimization/92715 * tree-ssa-forwprop.c (simplify_vector_constructor): Bail out for uniform vectors and source vectors with less elements than the destination. * gcc.dg/torture/pr92715.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr92715.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-forwprop.c >>From gcc-bugs-return-661770-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 09:19:12 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 83616 invoked by alias); 29 Nov 2019 09:19:12 -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 83543 invoked by uid 48); 29 Nov 2019 09:19:08 -0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: =?UTF-8?B?W0J1ZyB0cmVlLW9wdGltaXphdGlvbi85MjcxNV0gWzEwIFJlZ3Jlc3Npb25d?= =?UTF-8?B?IGVycm9yOiBwb3NpdGlvbiBwbHVzIHNpemUgZXhjZWVkcyBzaXplIG9mIHJl?= =?UTF-8?B?ZmVyZW5jZWQgb2JqZWN0IGluICDigJhiaXRfZmllbGRfcmVm4oCZ?= Date: Fri, 29 Nov 2019 09:19: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: 10.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: priority bug_status resolution 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: 2019-11/txt/msg03564.txt.bz2 Content-length: 481 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92715 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P1 |P3 Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Fixed. >>From gcc-bugs-return-661772-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 10:12:12 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 105484 invoked by alias); 29 Nov 2019 10:12:12 -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 105415 invoked by uid 48); 29 Nov 2019 10:12:08 -0000 From: "avi@cloudius-systems.com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/92722] gcc considers "padding" byte of empty lambda to be uninitialized Date: Fri, 29 Nov 2019 10:12: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: 9.2.1 X-Bugzilla-Keywords: diagnostic, missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: avi@cloudius-systems.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: 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: 2019-11/txt/msg03566.txt.bz2 Content-length: 504 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92722 Avi Kivity changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |avi@cloudius-systems.com --- Comment #2 from Avi Kivity --- Maybe those 1-byte elements generated for empty structs should be considered padding. They certainly don't correspond to any member. >>From gcc-bugs-return-661773-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 10:42:55 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 38946 invoked by alias); 29 Nov 2019 10:42:54 -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 38896 invoked by uid 48); 29 Nov 2019 10:42:50 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/92722] gcc considers "padding" byte of empty lambda to be uninitialized Date: Fri, 29 Nov 2019 10:42: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: 9.2.1 X-Bugzilla-Keywords: diagnostic, missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub 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: --- 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: 2019-11/txt/msg03567.txt.bz2 Content-length: 599 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92722 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- During expansion we avoid the moves when an empty struct is being copied. But this testcase explicitly copies the underlying bytes rather than copying the empty struct, I don't see what the compiler could do in that case. >>From gcc-bugs-return-661774-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 10:58:16 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 67028 invoked by alias); 29 Nov 2019 10:58: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 66365 invoked by uid 48); 29 Nov 2019 10:58:09 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/92510] ICE in native_encode_rtx, at simplify-rtx.c:6272 Date: Fri, 29 Nov 2019 10:58: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: 10.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub 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: 10.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status assigned_to short_desc 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: 2019-11/txt/msg03568.txt.bz2 Content-length: 722 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92510 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEW Assignee|jakub at gcc dot gnu.org |unassigned at gcc d= ot gnu.org Summary|[10 Regression] ICE in |ICE in native_encode_rtx, |native_encode_rtx, at |at simplify-rtx.c:6272 |simplify-rtx.c:6272 | --- Comment #9 from Jakub Jelinek --- The regression is fixed. Keeping open if Segher wants to do some further fixes. >>From gcc-bugs-return-661775-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 11:08:59 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 38936 invoked by alias); 29 Nov 2019 11:08:59 -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 38887 invoked by uid 48); 29 Nov 2019 11:08:55 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/92705] [10 Regression] ICE: Segmentation fault (in build_new_op_1) Date: Fri, 29 Nov 2019 11:08: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: 10.0 X-Bugzilla-Keywords: ice-on-invalid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub 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: 10.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords bug_status cf_reconfirmed_on cc everconfirmed 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: 2019-11/txt/msg03569.txt.bz2 Content-length: 949 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92705 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|error-recovery | Status|UNCONFIRMED |NEW Last reconfirmed| |2019-11-29 CC| |jakub at gcc dot gnu.org, | |jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r277864. This isn't error-recovery, there is no error printed before it ICEs. Slightly shortened: struct A {}; struct B {}; struct C { operator B*(); }; struct D { operator B*(); }; struct E : C, D { operator A*(); }; void foo(E e, int B::* pmf) { int i =3D e->*pmf; } >>From gcc-bugs-return-661776-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 11:30:55 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 30446 invoked by alias); 29 Nov 2019 11:30:55 -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 30241 invoked by uid 48); 29 Nov 2019 11:30:45 -0000 From: "marxin at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug ipa/92685] In IPA's execute stage create_version_clone_with_body fails with non-vNULL callers Date: Fri, 29 Nov 2019 11:30:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: ipa X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: marxin at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: INVALID 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_status resolution 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: 2019-11/txt/msg03570.txt.bz2 Content-length: 883 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92685 Martin Li=C5=A1ka changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Martin Li=C5=A1ka --- Hello. Yes, for usage of create_version_clone_with_body one needs to load GIMPLE b= ody of both caller and callee function. Anyway, can you please rather write to https://gcc.gnu.org/ml/gcc/ mailing list? Note that we use create_version_clone_with_body mainly in IPA passes that a= re not part of INSERT_PASSES_AFTER (all_regular_ipa_passes). Can you please describe what kind of IPA pass you're intending to write? Please write to t= he mailing list. >>From gcc-bugs-return-661778-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 11:35:53 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 38213 invoked by alias); 29 Nov 2019 11:35: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 37927 invoked by uid 48); 29 Nov 2019 11:35:48 -0000 From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/92720] cc1 accepts #include /dev/stdin inline Date: Fri, 29 Nov 2019 11:35: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: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: redi at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: INVALID 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: 2019-11/txt/msg03572.txt.bz2 Content-length: 831 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92720 --- Comment #3 from Jonathan Wakely --- (In reply to Andrew Pinski from comment #1) > GCC does not check the files.=20=20 >=20 > >echo '\042hello botfelk\\n\042' > This one fails for me too: > In file included from t8.c:5:0: > /dev/stdin: In function =E2=80=98main=E2=80=99: > /dev/stdin:1:1: error: stray =E2=80=98\=E2=80=99 in program > /dev/stdin:1:2: error: invalid suffix "hello" on integer constant > /dev/stdin:1:11: error: expected =E2=80=98)=E2=80=99 before =E2=80=98botf= elk=E2=80=99 > /dev/stdin:1:18: error: stray =E2=80=98\=E2=80=99 in program > /dev/stdin:1:19: error: stray =E2=80=98\=E2=80=99 in program > /dev/stdin:1:21: error: stray =E2=80=98\=E2=80=99 in program You need to use -e for GNU echo to interpret the \042 characters. >>From gcc-bugs-return-661777-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 11:35:26 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 37086 invoked by alias); 29 Nov 2019 11:35:26 -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 37054 invoked by uid 48); 29 Nov 2019 11:35:22 -0000 From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/92720] cc1 accepts #include /dev/stdin inline Date: Fri, 29 Nov 2019 11:35: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: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: redi at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: INVALID 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: 2019-11/txt/msg03571.txt.bz2 Content-length: 537 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92720 --- Comment #2 from Jonathan Wakely --- (In reply to Dennis Clarke from comment #0) > This may require a bit of a dive into the specifications however > an inline include of /dev/stdin seems wrong for some definition > of wrong.=20 There's no such thing as an "inline include", the preprocessor just substit= utes the content of the named file wherever a #include directive appears. If that file happens to be /dev/stdin then it happens to be /dev/stdin. >>From gcc-bugs-return-661779-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 11:38:17 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 43925 invoked by alias); 29 Nov 2019 11:38:16 -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 43872 invoked by uid 48); 29 Nov 2019 11:38:12 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/92705] [10 Regression] ICE: Segmentation fault (in build_new_op_1) Date: Fri, 29 Nov 2019 11:38: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: 10.0 X-Bugzilla-Keywords: ice-on-invalid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub 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: 10.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: 2019-11/txt/msg03573.txt.bz2 Content-length: 2584 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92705 --- Comment #2 from Jakub Jelinek --- The ICE is because conv is ck_ambig with user_conv_p set. Looking at other conv->user_conv_p tests, e.g. reference_binding does: if (conv->user_conv_p) { ... for (conversion *t =3D conv; t; t =3D next_conversion (t)) if (t->kind =3D=3D ck_user && DECL_CONV_FN_P (t->cand->fn)) { and doesn't expect that user_conv_p implies that ck_user will appear. The following patch restores the previous diagnostics on the testcase, but = I'm afraid I have no idea what is right. If ck_ambig with user_conv_p set is right, then it itself isn't ck_user and next_conversion on it is NULL. --- gcc/cp/call.c.jj 2019-11-28 18:58:55.671297387 +0100 +++ gcc/cp/call.c 2019-11-29 12:33:04.033386816 +0100 @@ -6370,8 +6370,12 @@ build_new_op_1 (const op_location_t &loc conv =3D cand->convs[0]; if (conv->user_conv_p) { - while (conv->kind !=3D ck_user) - conv =3D next_conversion (conv); + for (conversion *t =3D conv; t; t =3D next_conversion (t)) + if (t->kind =3D=3D ck_user) + { + conv =3D t; + break; + } arg1 =3D convert_like (conv, arg1, complain); } @@ -6380,8 +6384,12 @@ build_new_op_1 (const op_location_t &loc conv =3D cand->convs[1]; if (conv->user_conv_p) { - while (conv->kind !=3D ck_user) - conv =3D next_conversion (conv); + for (conversion *t =3D conv; t; t =3D next_conversion (t)) + if (t->kind =3D=3D ck_user) + { + conv =3D t; + break; + } arg2 =3D convert_like (conv, arg2, complain); } } @@ -6391,8 +6399,12 @@ build_new_op_1 (const op_location_t &loc conv =3D cand->convs[2]; if (conv->user_conv_p) { - while (conv->kind !=3D ck_user) - conv =3D next_conversion (conv); + for (conversion *t =3D conv; t; t =3D next_conversion (t)) + if (t->kind =3D=3D ck_user) + { + conv =3D t; + break; + } arg3 =3D convert_like (conv, arg3, complain); } } >>From gcc-bugs-return-661780-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 11:43:33 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 54349 invoked by alias); 29 Nov 2019 11:43:33 -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 54295 invoked by uid 48); 29 Nov 2019 11:43:29 -0000 From: "marxin at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/91574] [10 Regression] ICE in types_same_for_odr at gcc/ipa-devirt.c:355 since r272037 Date: Fri, 29 Nov 2019 11:43:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: lto X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: ice-on-valid-code, patch X-Bugzilla-Severity: normal X-Bugzilla-Who: marxin at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: marxin at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution 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: 2019-11/txt/msg03574.txt.bz2 Content-length: 433 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D91574 Martin Li=C5=A1ka changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Li=C5=A1ka --- Fixed. >>From gcc-bugs-return-661781-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 11:51:30 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 63557 invoked by alias); 29 Nov 2019 11:51:30 -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 63497 invoked by uid 48); 29 Nov 2019 11:51:25 -0000 From: "iains at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug bootstrap/92719] MacOS 10.15 Catalina build fails Date: Fri, 29 Nov 2019 11:51:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: bootstrap X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: build X-Bugzilla-Severity: normal X-Bugzilla-Who: iains 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: 10.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cf_gcctarget cc target_milestone cf_gccbuild 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: 2019-11/txt/msg03575.txt.bz2 Content-length: 1455 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92719 Iain Sandoe changed: What |Removed |Added ---------------------------------------------------------------------------- Target| |x86_64-apple-darwin19.0.0 CC| |iains at gcc dot gnu.org Target Milestone|--- |10.0 Build| |x86_64-apple-darwin19.0.0 --- Comment #1 from Iain Sandoe --- please could you identify the version of Xcode and the SDK in use? (anything less than 11.3beta is known to have problems). you have some configuration options that don't apply to 10.15:=20 --enable-multilib (this would just break later) and some that are unnecessary: --enable-bootstrap (default) lto in the languages (default) It is likely the --enable-host-shared option that is causing some difficulty here, it is rarely used/tested. (I will try to repeat that locally) It seems that your GMP installation is in /usr/local (or somehow found automatically)? This could also be a problem when using a sysroot (/usr/local is not added = at present) see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D90834#c13 could you check ---=20 ../configure --prefix=3D$PWD/usr --with-sysroot=3D$OSX_SDK_PATH --enable-languages=3Dc,c++,fortran --with-gmp=3D/path/to/gmp/prefix >>From gcc-bugs-return-661782-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 11:54:23 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 65991 invoked by alias); 29 Nov 2019 11:54:23 -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 65918 invoked by uid 48); 29 Nov 2019 11:54:19 -0000 From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/92720] cc1 accepts #include /dev/stdin inline Date: Fri, 29 Nov 2019 11:54: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: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: redi at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: INVALID 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: 2019-11/txt/msg03576.txt.bz2 Content-length: 799 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92720 --- Comment #4 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #2) > (In reply to Dennis Clarke from comment #0) > > This may require a bit of a dive into the specifications however > > an inline include of /dev/stdin seems wrong for some definition > > of wrong.=20 >=20 > There's no such thing as an "inline include", the preprocessor just > substitutes the content of the named file wherever a #include directive > appears. >=20 > If that file happens to be /dev/stdin then it happens to be /dev/stdin. The actual mapping from a #include directive to a physical file is implementation defined, so it seems OK for one compiler to refuse to do inc= lude certain paths, and OK for another to do so. >>From gcc-bugs-return-661783-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 12:02:32 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 74461 invoked by alias); 29 Nov 2019 12:02:32 -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 73799 invoked by uid 48); 29 Nov 2019 12:02:26 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/92705] [10 Regression] ICE: Segmentation fault (in build_new_op_1) Date: Fri, 29 Nov 2019 12:02: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: 10.0 X-Bugzilla-Keywords: ice-on-invalid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub 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: 10.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: 2019-11/txt/msg03577.txt.bz2 Content-length: 357 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92705 --- Comment #3 from Jakub Jelinek --- Though, previously the convert_like calls were done no matter what the conversion is, so with the above patch maybe after the if (conv->user_conv_= p) ... stmts, with whatever the conv is. Not sure if it makes a difference for anything. >>From gcc-bugs-return-661784-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 12:18:48 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 109023 invoked by alias); 29 Nov 2019 12:18:48 -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 108874 invoked by uid 48); 29 Nov 2019 12:18:43 -0000 From: "marxin at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug ada/92724] New: Can't link 9.2.0 ada with latest GCC Date: Fri, 29 Nov 2019 12:18:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: ada X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: marxin 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 cc 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: 2019-11/txt/msg03578.txt.bz2 Content-length: 10023 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92724 Bug ID: 92724 Summary: Can't link 9.2.0 ada with latest GCC Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: ebotcazou at gcc dot gnu.org Target Milestone: --- Using latest GCC master, I can't build gcc-9 branch with it. It's very like= ly caused by switch to -fno-common: $ g++ -no-pie -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o gnatbind ada/b_gnatb.o ada/libgnat/a-elchha.o ada/libgnat/a-except.o ada/libgnat/ada.o ada/adaint.o ada/ali-util.o ada/ali.o ada/alloc.o ada/argv.o ada/aspects.o ada/atree.o ada/bcheck.o ada/binde.o ada/binderr.o ada/bindgen.o ada/bindusg.o ada/buti= l.o ada/casing.o ada/cio.o ada/csets.o ada/cstreams.o ada/debug.o ada/einfo.o ada/elists.o ada/env.o ada/err_vars.o ada/errout.o ada/erroutc.o ada/exit.o ada/final.o ada/fmap.o ada/fname-uf.o ada/fname.o ada/libgnat/g-byorma.o ada/libgnat/g-hesora.o ada/libgnat/g-htable.o ada/libgnat/gnat.o ada/gnatbi= nd.o ada/gnatvsn.o ada/hostparm.o ada/init.o ada/initialize.o ada/libgnat/interf= ac.o ada/krunch.o ada/lib.o ada/link.o ada/namet.o ada/nlists.o ada/opt.o ada/osint-b.o ada/osint.o ada/output.o ada/raise.o ada/raise-gcc.o ada/restrict.o ada/rident.o ada/rtfinal.o ada/rtinit.o ada/libgnat/s-addope= .o ada/libgnat/s-assert.o ada/libgnat/s-carun8.o ada/libgnat/s-casuti.o ada/libgnat/s-conca2.o ada/libgnat/s-conca3.o ada/libgnat/s-conca4.o ada/libgnat/s-conca5.o ada/libgnat/s-conca6.o ada/libgnat/s-conca7.o ada/libgnat/s-conca8.o ada/libgnat/s-conca9.o ada/libgnat/s-crc32.o ada/libgnat/s-crtl.o ada/libgnat/s-excdeb.o ada/libgnat/s-except.o ada/libgnat/s-excmac.o ada/libgnat/s-exctab.o ada/libgnat/s-htable.o ada/libgnat/s-imenne.o ada/libgnat/s-imgenu.o ada/libgnat/s-imgint.o ada/libgnat/s-mastop.o ada/libgnat/s-memory.o ada/libgnat/s-os_lib.o ada/libgnat/s-parame.o ada/libgnat/s-resfil.o ada/libgnat/s-restri.o ada/libgnat/s-secsta.o ada/libgnat/s-soflin.o ada/libgnat/s-soliin.o ada/libgnat/s-sopco3.o ada/libgnat/s-sopco4.o ada/libgnat/s-sopco5.o ada/libgnat/s-stache.o ada/libgnat/s-stalib.o ada/libgnat/s-stoele.o ada/libgnat/s-strhas.o ada/libgnat/s-string.o ada/libgnat/s-strops.o ada/libgnat/s-traent.o ada/libgnat/s-traceb.o ada/libgnat/s-unstyp.o ada/libgnat/s-utf_32.o ada/libgnat/s-wchcnv.o ada/libgnat/s-wchcon.o ada/libgnat/s-wchjis.o ada/libgnat/s-wchstw.o ada/scans.o ada/scil_ll.o ada/scng.o ada/sdefault.o ada/seh_init.o ada/sem_aux.o ada/sinfo.o ada/sinput-c.o ada/sinput.o ada/snames.o ada/stand.o ada/stringt.o ada/styl= e.o ada/styleg.o ada/stylesw.o ada/switch-b.o ada/switch.o ada/libgnat/system.o ada/table.o ada/targext.o ada/targparm.o ada/tree_io.o ada/types.o ada/uint= p.o ada/uname.o ada/urealp.o ada/widechar.o ggc-none.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -g=20 mv -f Tlto-wrapper lto-wrapper /usr/bin/ld: ada/ali.o: in function `ali__scan_ali': /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/ali.adb:2767: undefi= ned reference to `__gnat_begin_handler_v1' /usr/bin/ld: /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/ali.adb:2767: undefi= ned reference to `__gnat_end_handler_v1' /usr/bin/ld: /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/ali.adb:1587: undefi= ned reference to `__gnat_begin_handler_v1' /usr/bin/ld: /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/ali.adb:1587: undefi= ned reference to `__gnat_end_handler_v1' /usr/bin/ld: /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/ali.adb:2805: undefi= ned reference to `__gnat_begin_handler_v1' /usr/bin/ld: /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/ali.adb:2805: undefi= ned reference to `__gnat_end_handler_v1' /usr/bin/ld: /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/ali.adb:1416: undefi= ned reference to `__gnat_begin_handler_v1' /usr/bin/ld: /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/ali.adb:1416: undefi= ned reference to `__gnat_end_handler_v1' /usr/bin/ld: /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/ali.adb:1552: undefi= ned reference to `__gnat_begin_handler_v1' /usr/bin/ld: /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/ali.adb:1552: undefi= ned reference to `__gnat_end_handler_v1' /usr/bin/ld: /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/ali.adb:2767: undefi= ned reference to `__gnat_end_handler_v1' /usr/bin/ld: ada/gnatbind.o: in function `_ada_gnatbind': /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/gnatbind.adb:899: undefined reference to `__gnat_begin_handler_v1' /usr/bin/ld: /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/gnatbind.adb:899: undefined reference to `__gnat_end_handler_v1' /usr/bin/ld: ada/output.o: in function `output__flush_buffer': /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/output.adb:163: undefined reference to `__gnat_begin_handler_v1' /usr/bin/ld: /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/output.adb:163: undefined reference to `__gnat_end_handler_v1' /usr/bin/ld: ada/restrict.o: in function `restrict__check_restriction__update_restrictions': /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/restrict.adb:482: undefined reference to `__gnat_begin_handler_v1' /usr/bin/ld: /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/restrict.adb:482: undefined reference to `__gnat_end_handler_v1' /usr/bin/ld: ada/libgnat/s-os_lib.o: in function `system__os_lib__gm_split': /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/libgnat/s-os_lib.adb= :1393: undefined reference to `__gnat_begin_handler_v1' /usr/bin/ld: /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/libgnat/s-os_lib.adb= :1393: undefined reference to `__gnat_end_handler_v1' /usr/bin/ld: ada/libgnat/s-os_lib.o: in function `system__os_lib__create_temp_file_internal': /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/libgnat/s-os_lib.adb= :920: undefined reference to `__gnat_begin_handler_v1' /usr/bin/ld: /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/libgnat/s-os_lib.adb= :920: undefined reference to `__gnat_end_handler_v1' /usr/bin/ld: ada/libgnat/s-os_lib.o: in function `system__os_lib__copy_file= ': /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/libgnat/s-os_lib.adb= :600: undefined reference to `__gnat_begin_handler_v1' /usr/bin/ld: /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/libgnat/s-os_lib.adb= :600: undefined reference to `__gnat_end_handler_v1' /usr/bin/ld: ada/libgnat/s-resfil.o: in function `system__response_file__arguments_from__recurse': /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/libgnat/s-resfil.adb= :486: undefined reference to `__gnat_begin_handler_v1' /usr/bin/ld: /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/libgnat/s-resfil.adb= :486: undefined reference to `__gnat_end_handler_v1' /usr/bin/ld: ada/libgnat/s-resfil.o: in function `system__response_file__arguments_from': /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/libgnat/s-resfil.adb= :509: undefined reference to `__gnat_begin_handler_v1' /usr/bin/ld: /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/libgnat/s-resfil.adb= :509: undefined reference to `__gnat_end_handler_v1' /usr/bin/ld: ada/libgnat/s-secsta.o: in function `system__secondary_stack__allocate_dynamic__allocate_new_chunk': /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/libgnat/s-secsta.adb= :199: undefined reference to `__gnat_begin_handler_v1' /usr/bin/ld: /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/libgnat/s-secsta.adb= :199: undefined reference to `__gnat_end_handler_v1' /usr/bin/ld: ada/switch-b.o: in function `switch__b__scan_binder_switches__get_stack_size': /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/switch-b.adb:110: undefined reference to `__gnat_begin_handler_v1' /usr/bin/ld: /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/switch-b.adb:110: undefined reference to `__gnat_end_handler_v1' /usr/bin/ld: ada/switch-b.o: in function `switch__b__scan_binder_switches': /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/switch-b.adb:530: undefined reference to `__gnat_begin_handler_v1' /usr/bin/ld: /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/switch-b.adb:530: undefined reference to `__gnat_end_handler_v1' /usr/bin/ld: ada/targparm.o: in function `targparm__get_target_parameters': /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/targparm.adb:431: undefined reference to `__gnat_begin_handler_v1' /usr/bin/ld: /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/targparm.adb:431: undefined reference to `__gnat_end_handler_v1' /usr/bin/ld: ada/tree_io.o: in function `tree_io__tree_read_terminate': /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/tree_io.adb:380: undefined reference to `__gnat_begin_handler_v1' /usr/bin/ld: /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/tree_io.adb:380: undefined reference to `__gnat_end_handler_v1' /usr/bin/ld: ada/widechar.o: in function `widechar__scan_wide': /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/widechar.adb:142: undefined reference to `__gnat_begin_handler_v1' /usr/bin/ld: /home/marxin/Programming/gcc2/objdir/gcc/../../gcc/ada/widechar.adb:142: undefined reference to `__gnat_end_handler_v1' collect2: error: ld returned 1 exit status make: *** [../../gcc/ada/gcc-interface/Make-lang.in:664: gnatbind] Error 1 make: *** Waiting for unfinished jobs.... ^Cmake: *** [Makefile:1116: gimple-match.o] Interrupt make: *** [Makefile:1116: insn-emit.o] Interrupt make: *** [Makefile:1116: generic-match.o] Interrupt >>From gcc-bugs-return-661785-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 12:19:26 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 110119 invoked by alias); 29 Nov 2019 12:19:26 -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 110067 invoked by uid 55); 29 Nov 2019 12:19:22 -0000 From: "burnus at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/84963] [8 Regression] ICE in get_constraint_for_ssa_var, at tree-ssa-structalias.c:2955 Date: Fri, 29 Nov 2019 12:19:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 8.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: burnus at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: marxin at gcc dot gnu.org X-Bugzilla-Target-Milestone: 8.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: 2019-11/txt/msg03579.txt.bz2 Content-length: 546 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D84963 --- Comment #6 from Tobias Burnus --- Author: burnus Date: Fri Nov 29 12:18:50 2019 New Revision: 278836 URL: https://gcc.gnu.org/viewcvs?rev=3D278836&root=3Dgcc&view=3Drev Log: Fix testcase - was missing -fopenacc PR ipa/84963 * gfortran.dg/goacc/pr84963.f90: Use dg-additional-options not dg-options as otherwise -fopenacc is not used. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/goacc/pr84963.f90 >>From gcc-bugs-return-661786-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 12:20:30 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 115616 invoked by alias); 29 Nov 2019 12:20: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 115526 invoked by uid 48); 29 Nov 2019 12:20:25 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/91825] [10 regression] Bogus -Wmaybe-uninitialized with r275744 breaks bootstrap Date: Fri, 29 Nov 2019 12:20: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: 10.0 X-Bugzilla-Keywords: build, diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub 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: 10.0 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: 2019-11/txt/msg03580.txt.bz2 Content-length: 9841 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D91825 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- Slightly tweaked, so that no other warnings are reported on it with -O2 -Wa= ll, except this -Wmaybe-uninitialized starting with the r277864 change and noth= ing before: typedef struct rtx_def *rtx; enum machine_mode { E_VOIDmode, E_BLKmode, E_CCmode, E_CCFPmode, E_CCFPEmode, E_CC_SWPmode, E_CC_NZCmode, E_CC_NZmode, E_CC_Zmode, E_CC_Cmode, E_CC_ADCmode, E_CC_Vmode, E_BImode, E_QImode, E_HImode, E_SImode, E_DImode, E_TImode, E_OImode, E_CImode, E_XImode, E_QQmode, E_HQmode, E_SQmode, E_DQmode, E_TQmode, E_UQQmode, E_UHQmode, E_USQmode, E_UDQmode, E_UTQmode, E_HAmode, E_SAmode, E_DAmode, E_TAmode, E_UHAmode, E_USAmode, E_UDAmode, E_UTAmode, E_HFmode, E_SFmode, E_DFmode, E_TFmode, E_SDmode, E_DDmode, E_TDmode, E_CQImode, E_CHImode, E_CSImode, E_CDImode, E_CTImode, E_COImode, E_CCImode, E_CXImo= de, E_HCmode, E_SCmode, E_DCmode, E_TCmode, E_V8QImode, E_V4HImode, E_V2SImode, E_V16QImode, E_V8HImode, E_V4SImode, E_V2DImode, E_VNx2TImode, E_VNx3TImode, E_VNx4TImode, E_VNx2OImode, E_V2HFmode, E_V4HFmode, E_V2SFm= ode, E_V2DFmode, NUM_MACHINE_MODES }; template struct A { int coeffs[N]; }; template class C : public A { public: template C(const C0 &); }; machine_mode mode_size_inline_mode, emit_store_flag_1_target_mode; A<2> mode_size[1]; struct B { enum from_int {}; }; extern const char mode_class[NUM_MACHINE_MODES]; template T as_a(machine_mode); class scalar_int_mode { public: scalar_int_mode() {} scalar_int_mode(B::from_int p1) : m_mode(machine_mode(p1)) {} operator machine_mode() { return m_mode; } machine_mode m_mode; } mode_to_bytes_mode; scalar_int_mode word_mode; template bool is_int_mode(machine_mode p1, T p2) { if (mode_class[p1]) { *p2 =3D B::from_int(p1); return true; } return false; } enum insn_code {}; enum rtx_code { GE, LE, LT }; struct rtx_def { rtx_code code; machine_mode mode; }; rtx const_int_rtx_63, const_int_rtx_64, emit_store_flag_1_subtarget, emit_store_flag_1_tem, emit_store_flag_1_op00, emit_store_flag_1_op01, emit_store_flag_1_op0h, emit_store_flag_1_target, emit_store_flag_1_op0, emit_store_flag_1_op1; enum tree_code { RSHIFT_EXPR }; enum optab_tag { and_optab, ior_optab, one_cmpl_optab }; enum optab_methods { OPTAB_DIRECT }; insn_code emit_store_flag_1_icode; rtx_code emit_store_flag_1_code; int emit_store_flag_1_unsignedp, emit_store_flag_1_normalizep; short emit_store_flag_1___trans_tmp_24, emit_store_flag_1___trans_tmp_23; bool iterate_p(); inline __attribute__((__always_inline__)) C<2> mode_size_inline() { A<2> mode_size; switch (mode_size_inline_mode) { case E_VOIDmode: return 0; case E_BLKmode: return 0; case E_CCmode: return 4; case E_CCFPmode: return 4; case E_CCFPEmode: return 4; case E_CC_SWPmode: return 4; case E_CC_NZCmode: return 4; case E_CC_NZmode: return 4; case E_CC_Zmode: return 4; case E_CC_Cmode: return 4; case E_CC_ADCmode: return 4; case E_CC_Vmode: return 4; case E_BImode: return 1; case E_QImode: return 1; case E_HImode: return 2; case E_SImode: return 4; case E_DImode: return 8; case E_TImode: return 6; case E_OImode: return 2; case E_CImode: return 8; case E_XImode: return 4; case E_QQmode: return 1; case E_HQmode: return 2; case E_SQmode: return 4; case E_DQmode: return 8; case E_TQmode: return 6; case E_UQQmode: return 1; case E_UHQmode: return 2; case E_USQmode: return 4; case E_UDQmode: return 8; case E_UTQmode: return 6; case E_HAmode: return 2; case E_SAmode: return 4; case E_DAmode: return 8; case E_TAmode: return 6; case E_UHAmode: return 2; case E_USAmode: return 4; case E_UDAmode: return 8; case E_UTAmode: return 6; case E_HFmode: return 2; case E_SFmode: return 4; case E_DFmode: return 8; case E_TFmode: return 6; case E_SDmode: return 4; case E_DDmode: return 8; case E_TDmode: return 6; case E_CQImode: return 2; case E_CHImode: return 4; case E_CSImode: return 8; case E_CDImode: return 6; case E_CTImode: return 2; case E_COImode: return 4; case E_CCImode: return 6; case E_CXImode: return 8; case E_HCmode: return 4; case E_SCmode: return 8; case E_DCmode: return 6; case E_TCmode: return 2; case E_V8QImode: return 8; case E_V4HImode: return 8; case E_V2SImode: return 8; case E_V16QImode: return 6; case E_V8HImode: return 6; case E_V4SImode: return 6; case E_V2DImode: return 6; case E_VNx2TImode: return 2; case E_VNx3TImode: return 8; case E_VNx4TImode: return 4; case E_VNx2OImode: return 4; case E_V2HFmode: return 4; case E_V4HFmode: return 8; case E_V2SFmode: return 8; case E_V2DFmode: return 6; default: return mode_size; } } inline __attribute__((always_inline)) C<2> mode_to_bytes() { return mode_to_bytes_mode ? mode_size_inline() : mode_size[0]; } inline __attribute__((always_inline)) C<2> mode_to_bits() { mode_to_bytes(); return 0; } inline __attribute__((always_inline)) short GET_MODE_SIZE(scalar_int_mode) { return mode_to_bytes().coeffs[0]; } inline __attribute__((always_inline)) short GET_MODE_BITSIZE(scalar_int_mod= e) { return mode_to_bits().coeffs[0]; } void get_wider(); void simplify_gen_subreg(machine_mode, rtx, machine_mode, C<2>); bool val_signbit_known_set_p(machine_mode, long); rtx emit_store_flag(rtx, rtx_code, rtx, rtx, machine_mode, int, int); rtx expand_shift(tree_code, machine_mode, rtx, C<2>, rtx, int); insn_code optab_handler(); void expand_binop(machine_mode, optab_tag, rtx, rtx, rtx, int, optab_method= s); rtx expand_unop(machine_mode, optab_tag, rtx, rtx, int); void convert_move(rtx, rtx, int); rtx convert_modes(machine_mode, machine_mode, rtx, int); rtx emit_cstore(); rtx emit_store_flag_1(machine_mode p1) { scalar_int_mode int_mode; emit_store_flag_1___trans_tmp_23 =3D mode_to_bits().coeffs[0]; if (is_int_mode(p1, &int_mode) && (emit_store_flag_1_op0->code || emit_store_flag_1_op0)) if (emit_store_flag_1_code && const_int_rtx_63) { machine_mode __trans_tmp_3 =3D word_mode, __trans_tmp_4 =3D int_mode, __trans_tmp_5 =3D word_mode, __trans_tmp_6 =3D int_mode, __trans_tmp_7 =3D word_mode; simplify_gen_subreg(__trans_tmp_3, emit_store_flag_1_op0, __trans_tmp= _4, 0); simplify_gen_subreg(__trans_tmp_5, emit_store_flag_1_op0, __trans_tmp= _6, 8); expand_binop(__trans_tmp_7, const_int_rtx_64 ? ior_optab : and_optab, emit_store_flag_1_op00, emit_store_flag_1_op01, 0, emit_store_flag_1_unsignedp, OPTAB_DIRECT); if (emit_store_flag_1_tem) { machine_mode __trans_tmp_8 =3D word_mode; emit_store_flag(0, emit_store_flag_1_code, emit_store_flag_1_tem, emit_store_flag_1_op1, __trans_tmp_8, emit_store_flag_1_unsignedp, emit_store_flag_1_normalizep); } } if ((emit_store_flag_1_code || emit_store_flag_1_code) && const_int_rtx_6= 4) ; machine_mode __trans_tmp_10 __attribute__((unused)) =3D int_mode; machine_mode __trans_tmp_12 =3D word_mode, __trans_tmp_14 =3D word_mode; emit_store_flag_1_tem =3D emit_store_flag( 0, emit_store_flag_1_code, emit_store_flag_1_op0h, emit_store_flag_1_= op1, __trans_tmp_12, emit_store_flag_1_unsignedp, emit_store_flag_1_target_mode || emit_store_flag_1_tem->mode =3D=3D emit_store_flag_1_target_mode); bool __trans_tmp_13 =3D val_signbit_known_set_p( __trans_tmp_14, emit_store_flag_1_normalizep ?: 1); convert_move(emit_store_flag_1_target, 0, __trans_tmp_13); if (emit_store_flag_1_op1 =3D=3D const_int_rtx_64 && (emit_store_flag_1_code =3D=3D LT || emit_store_flag_1_code =3D=3D GE= ) && is_int_mode(p1, &int_mode)) { scalar_int_mode int_target_mode =3D=20 as_a(emit_store_flag_1_target_mode); emit_store_flag_1___trans_tmp_24 =3D mode_to_bytes().coeffs[0]; if (GET_MODE_SIZE(int_mode)) { machine_mode __trans_tmp_15 =3D int_target_mode, __trans_tmp_16 =3D i= nt_mode; emit_store_flag_1_op0 =3D convert_modes(__trans_tmp_15, __trans_tmp_1= 6, emit_store_flag_1_op0, 0); } int_mode =3D int_target_mode; if (int_mode) emit_store_flag_1_subtarget =3D 0; if (emit_store_flag_1_code) { machine_mode __trans_tmp_17 =3D int_mode, __trans_tmp_18 =3D int_mode; emit_store_flag_1_op0 =3D expand_unop(__trans_tmp_17, one_cmpl_optab, emit_store_flag_1_op0, emit_store_flag_1_subtarget, 0); GET_MODE_BITSIZE(int_mode); emit_store_flag_1_normalizep =3D 1; emit_store_flag_1_op0 =3D expand_shift(RSHIFT_EXPR, __trans_tmp_18, emit_store_flag_1_op0, = 1, emit_store_flag_1_subtarget, 1); } if ((int_mode =3D int_target_mode)) { machine_mode __trans_tmp_20 =3D int_target_mode, __trans_tmp_21 =3D i= nt_mode; emit_store_flag_1_op0 =3D convert_modes(__trans_tmp_20, __trans_tmp_2= 1, emit_store_flag_1_op0, 0); } } for (; iterate_p();) emit_store_flag_1_icode =3D optab_handler(); if (emit_store_flag_1_icode) get_wider(); rtx tem =3D emit_cstore(); if (tem) if (mode_class[p1]) tem =3D emit_cstore(); if (tem) return tem; return 0; } >>From gcc-bugs-return-661787-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 12:28:10 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 403 invoked by alias); 29 Nov 2019 12:28:09 -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 366 invoked by uid 55); 29 Nov 2019 12:28:05 -0000 From: "burnus at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/84963] [8 Regression] ICE in get_constraint_for_ssa_var, at tree-ssa-structalias.c:2955 Date: Fri, 29 Nov 2019 12:28:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 8.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: burnus at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: marxin at gcc dot gnu.org X-Bugzilla-Target-Milestone: 8.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: 2019-11/txt/msg03581.txt.bz2 Content-length: 670 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D84963 --- Comment #7 from Tobias Burnus --- Author: burnus Date: Fri Nov 29 12:27:34 2019 New Revision: 278838 URL: https://gcc.gnu.org/viewcvs?rev=3D278838&root=3Dgcc&view=3Drev Log: Fix testcase - was missing -fopenacc Backport from mainline 2019-11-29 Tobias Burnus PR ipa/84963 * gfortran.dg/goacc/pr84963.f90: Use dg-additional-options not dg-options as otherwise -fopenacc is not used. Modified: branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/testsuite/gfortran.dg/goacc/pr84963.f90 >>From gcc-bugs-return-661788-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 12:32:59 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 9808 invoked by alias); 29 Nov 2019 12:32:59 -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 9752 invoked by uid 48); 29 Nov 2019 12:32:56 -0000 From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/91997] pretty printers: The __node_type type alias in _Hashtable is not available Date: Fri, 29 Nov 2019 12:32: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: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: redi at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: redi at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.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: 2019-11/txt/msg03582.txt.bz2 Content-length: 273 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D91997 --- Comment #6 from Jonathan Wakely --- The problem is not missing debuginfo, it's a GDB bug: https://sourceware.org/bugzilla/show_bug.cgi?id=3D25234 I have a workaround for libstdc++ though. >>From gcc-bugs-return-661789-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 12:40:44 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 104178 invoked by alias); 29 Nov 2019 12:40: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 104133 invoked by uid 48); 29 Nov 2019 12:40:40 -0000 From: "anbu1024.me at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/92725] New: ICE: Segmentation fault during GIMPLE pass Date: Fri, 29 Nov 2019 12:40:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 8.3.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: anbu1024.me 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: 2019-11/txt/msg03583.txt.bz2 Content-length: 2210 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92725 Bug ID: 92725 Summary: ICE: Segmentation fault during GIMPLE pass Product: gcc Version: 8.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: anbu1024.me at gmail dot com Target Milestone: --- $ cat 0.c=20 int global ;=20 void foo() ;=20 __attribute__((returns_twice)) int bar() ;=20 void baz(int, int);=20 void main ( )=20 {=20 int x; for ( ; ; )=20 foo();=20 baz(bar(), global);=20 } ---------------------------------------------------------------------------= ----- $ gcc-snapshot8 --version gcc (GCC) 8.3.1 20191122 Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ---------------------------------------------------------------------------= ----- $ gcc-snapshot8 0.c=20 during GIMPLE pass: *build_cgraph_edges 0.c: In function =E2=80=98main=E2=80=99: 0.c:10:6: internal compiler error: Segmentation fault void main ( ) ^~~~ 0xa654af crash_signal ../../gcc-8-20191122/gcc/toplev.c:325 0x8275a0 useless_type_conversion_p(tree_node*, tree_node*) ../../gcc-8-20191122/gcc/gimple-expr.c:70 0x70606d types_compatible_p ../../gcc-8-20191122/gcc/gimple-expr.h:66 0x70606d gimple_check_call_args ../../gcc-8-20191122/gcc/cgraph.c:3798 0x70606d gimple_check_call_matching_types(gimple*, tree_node*, bool) ../../gcc-8-20191122/gcc/cgraph.c:3848 0x708346 symbol_table::create_edge(cgraph_node*, cgraph_node*, gcall*, profile_count, bool) ../../gcc-8-20191122/gcc/cgraph.c:879 0x708544 cgraph_node::create_edge(cgraph_node*, gcall*, profile_count) ../../gcc-8-20191122/gcc/cgraph.c:914 0x70df6e execute ../../gcc-8-20191122/gcc/cgraphbuild.c:322 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-661790-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 12:42:19 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 106356 invoked by alias); 29 Nov 2019 12:42:19 -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 106285 invoked by uid 48); 29 Nov 2019 12:42:15 -0000 From: "burnus at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/92713] ICE in libsupc++ building an offload compiler targeting amdgcn-unknown-amdhsa Date: Fri, 29 Nov 2019 12:42:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: build, ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: burnus 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: 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: 2019-11/txt/msg03584.txt.bz2 Content-length: 736 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92713 Tobias Burnus changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus --- Notes from the #gcc IRC: * Workaround: --enable-languages=3Dc,lto,fortran =E2=80=93 i.e. do not buil= d the C++ compiler for AMD GCN * Note: the offload compiler doesn't need any frontends (but lto) * Only (offloaded) code which does not need libstc++ will work. * For C++ support on GCN itself: a few features are currently missing such as exceptions >>From gcc-bugs-return-661791-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 12:49:05 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 116963 invoked by alias); 29 Nov 2019 12:49:05 -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 116895 invoked by uid 48); 29 Nov 2019 12:49:01 -0000 From: "charlet at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug ada/92724] Can't link 9.2.0 ada with latest GCC Date: Fri, 29 Nov 2019 12:49:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: ada X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: charlet at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: INVALID X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc resolution target_milestone 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: 2019-11/txt/msg03585.txt.bz2 Content-length: 737 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92724 Arnaud Charlet changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED CC| |charlet at gcc dot gnu.org Resolution|--- |INVALID Target Milestone|--- |10.0 --- Comment #1 from Arnaud Charlet --- You cannot build GNAT with a more recent version of GNAT in general, as explained in https://gcc.gnu.org/install/prerequisites.html. This PR is an occurrence of such incompatibility. >>From gcc-bugs-return-661792-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 12:57:26 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 44043 invoked by alias); 29 Nov 2019 12:57:26 -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 43980 invoked by uid 48); 29 Nov 2019 12:57:21 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/91825] [10 regression] Bogus -Wmaybe-uninitialized with r275744 breaks bootstrap Date: Fri, 29 Nov 2019 12:57: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: 10.0 X-Bugzilla-Keywords: build, diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub 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: 10.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: 2019-11/txt/msg03586.txt.bz2 Content-length: 303 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D91825 --- Comment #10 from Jakub Jelinek --- Though, I'm afraid the reduced testcases are bad, because it doesn't reprod= uce without the incorrect __trans_tmp_10 that uses int_mode even outside of code where it is initialized. >>From gcc-bugs-return-661793-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 12:59:36 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 47952 invoked by alias); 29 Nov 2019 12:59:36 -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 47913 invoked by uid 48); 29 Nov 2019 12:59:32 -0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/92725] ICE: Segmentation fault during GIMPLE pass Date: Fri, 29 Nov 2019 12:59: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: 8.3.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth 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: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on cf_known_to_work everconfirmed cf_known_to_fail 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: 2019-11/txt/msg03587.txt.bz2 Content-length: 685 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92725 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2019-11-29 Known to work| |10.0, 9.1.0 Ever confirmed|0 |1 Known to fail| |7.1.0, 8.1.0, 8.3.1 --- Comment #1 from Richard Biener --- Confirmed. I think we have a duplicate for this, it works on the GCC 9 bra= nch. >>From gcc-bugs-return-661794-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 13:05:32 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 46869 invoked by alias); 29 Nov 2019 13:05:32 -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 46826 invoked by uid 55); 29 Nov 2019 13:05:27 -0000 From: "rsandifo at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/92710] [9/10 Regression] Vectoriser generates invalid simd call for bool arguments Date: Fri, 29 Nov 2019 13:05: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: 10.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rsandifo at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rsandifo at gcc dot gnu.org X-Bugzilla-Target-Milestone: 9.3 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: 2019-11/txt/msg03588.txt.bz2 Content-length: 1295 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92710 --- Comment #2 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Fri Nov 29 13:04:56 2019 New Revision: 278839 URL: https://gcc.gnu.org/viewcvs?rev=3D278839&root=3Dgcc&view=3Drev Log: Don't pass booleans as mask types to simd clones (PR 92710) In this PR we assigned a vector mask type to the result of a comparison and then tried to pass that mask type to a simd clone, which expected a normal (non-mask) type instead. This patch simply punts on call arguments that have a mask type. A better fix would be to pattern-match the comparison to a COND_EXPR, like we would if the comparison was stored to memory, but doing that isn't gcc 9 or 10 material. Note that this doesn't affect x86_64-linux-gnu because the ABI promotes bool arguments to ints. 2019-11-29 Richard Sandiford gcc/ PR tree-optimization/92710 * tree-vect-stmts.c (vectorizable_simd_clone_call): Reject vector mask arguments. gcc/testsuite/ PR tree-optimization/92710 * gcc.dg/vect/pr92710.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr92710.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-stmts.c >>From gcc-bugs-return-661795-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 13:17:07 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 64496 invoked by alias); 29 Nov 2019 13:17:06 -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 64451 invoked by uid 55); 29 Nov 2019 13:17:03 -0000 From: "burnus at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/84963] [8 Regression] ICE in get_constraint_for_ssa_var, at tree-ssa-structalias.c:2955 Date: Fri, 29 Nov 2019 13:17:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 8.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: burnus at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: marxin at gcc dot gnu.org X-Bugzilla-Target-Milestone: 8.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: 2019-11/txt/msg03589.txt.bz2 Content-length: 670 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D84963 --- Comment #8 from Tobias Burnus --- Author: burnus Date: Fri Nov 29 13:16:31 2019 New Revision: 278840 URL: https://gcc.gnu.org/viewcvs?rev=3D278840&root=3Dgcc&view=3Drev Log: Fix testcase - was missing -fopenacc Backport from mainline 2019-11-29 Tobias Burnus PR ipa/84963 * gfortran.dg/goacc/pr84963.f90: Use dg-additional-options not dg-options as otherwise -fopenacc is not used. Modified: branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/gfortran.dg/goacc/pr84963.f90 >>From gcc-bugs-return-661796-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 13:26:50 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 120306 invoked by alias); 29 Nov 2019 13:26:50 -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 120255 invoked by uid 48); 29 Nov 2019 13:26:45 -0000 From: "tschwinge at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libgomp/92726] New: OpenACC: 'NULL'-in -> no-op, and/or 'NULL'-out Date: Fri, 29 Nov 2019 13:26:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libgomp X-Bugzilla-Version: unknown X-Bugzilla-Keywords: openacc X-Bugzilla-Severity: normal X-Bugzilla-Who: tschwinge 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 keywords bug_severity priority component assigned_to reporter cc 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: 2019-11/txt/msg03590.txt.bz2 Content-length: 652 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92726 Bug ID: 92726 Summary: OpenACC: 'NULL'-in -> no-op, and/or 'NULL'-out Product: gcc Version: unknown Status: UNCONFIRMED Keywords: openacc Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- OpenACC is being clarified that when you pass 'NULL' into data clauses, or runtime API functions, that means no-op, and/or a 'NULL' return value. >>From gcc-bugs-return-661797-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 13:29:52 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 48251 invoked by alias); 29 Nov 2019 13:29: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 48221 invoked by uid 48); 29 Nov 2019 13:29:48 -0000 From: "david at westcontrol dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/92727] New: Idea for better error messages Date: Fri, 29 Nov 2019 13:29: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: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: david at westcontrol 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: 2019-11/txt/msg03591.txt.bz2 Content-length: 1799 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92727 Bug ID: 92727 Summary: Idea for better error messages Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: david at westcontrol dot com Target Milestone: --- Consider this code: #include #include class Y {int i;}; class X { std::unique_ptr sp; int i; }; int main() { std::vector v; X x; v.push_back(x); // Line A // v.push_back(std::move(x)); // Line B } It is a simple mistake - class X has a unique_ptr and can't be copied, but = the push_back tries to copy it. The errors generated, however, contain a lot of unhelpful information about allocators for the vector. They hide the useful part of the messages, which is: note: 'X::X(const X&)' is implicitly deleted because the default defini= tion would be ill-formed It is an extra note, rather than the error message, but is key for the user= to identify the problem. Would it be possible to hide the messages concerning the allocator here? In general, would it be possible to hide the messages that deal with template parameters that are unchanged from the default? That would let the user see messages that are relevant to the code /they/ have written, rather than implementation details in the libraries and headers. Even better, in this case, would be a hint that the user needs a std::move,= as shown in line B. (Yes, I know I may be asking for the impossible here, or at least for the v= ery difficult. But it is the kind of thing that makes C++ development harder t= han it should be.) >>From gcc-bugs-return-661798-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 13:30:42 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 49519 invoked by alias); 29 Nov 2019 13:30:42 -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 49348 invoked by uid 55); 29 Nov 2019 13:30:25 -0000 From: "jamborm at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug ipa/92476] [10 regression] SEGV in cgraph_edge_brings_value_p Date: Fri, 29 Nov 2019 13:30:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: ipa X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jamborm at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: mjambor at suse dot cz X-Bugzilla-Target-Milestone: 10.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: 2019-11/txt/msg03592.txt.bz2 Content-length: 1041 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92476 --- Comment #5 from Martin Jambor --- Author: jamborm Date: Fri Nov 29 13:29:35 2019 New Revision: 278841 URL: https://gcc.gnu.org/viewcvs?rev=3D278841&root=3Dgcc&view=3Drev Log: ipa-cp: Avoid ICEs when looking at expanded thunks and unoptimized functions 2019-11-29 Martin Jambor PR ipa/92476 * ipa-cp.c (set_single_call_flag): Set node_calling_single_call in the summary only if the summary exists. (find_more_scalar_values_for_callers_subset): Check node_dead in the summary only if the summary exists. (ipcp_store_bits_results): Ignore nodes without lattices. (ipcp_store_vr_results): Likewise. * cgraphclones.c: Include ipa-fnsummary.h and ipa-prop.h and the header files required by them. (cgraph_node::expand_all_artificial_thunks): Analyze expanded thunk= s. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphclones.c trunk/gcc/ipa-cp.c >>From gcc-bugs-return-661799-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 13:34:37 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 61173 invoked by alias); 29 Nov 2019 13:34:37 -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 61042 invoked by uid 48); 29 Nov 2019 13:34:33 -0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/91003] [10 Regression] ICE when compiling LAPACK (CGEGV) with optimization Date: Fri, 29 Nov 2019 13:34:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 10.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: 10.0 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: 2019-11/txt/msg03593.txt.bz2 Content-length: 1394 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D91003 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rsandifo at gcc dot gnu.org --- Comment #6 from Richard Biener --- So this is another "boolean" case. In vect_get_constant_vectors we run into /* ??? SLP analysis should compute the vector type for the constant / invariant and store it in the SLP node. */ tree op =3D op_node->ops[0]; /* Check if vector type is a boolean vector. */ tree stmt_vectype =3D STMT_VINFO_VECTYPE (stmt_vinfo); if (VECT_SCALAR_BOOLEAN_TYPE_P (TREE_TYPE (op)) && vect_mask_constant_operand_p (stmt_vinfo)) vector_type =3D truth_type_for (stmt_vectype); else vector_type =3D get_vectype_for_scalar_type (vinfo, TREE_TYPE (op), op_= node); for h_18 =3D _129 ? 1 : 0; with unsigned boolean (kind=3D=3D4) typed result/then/else values (SImode). IIRC I couldn't simply remove this and rely on get_vectype_for_scalar_type to do the right thing (TM) in general. Plus we don't have a stmt-info for the constant operands (but we do now have an SLP node for them). I hope Richards patches improve things here but I don't remember them touching this particular place. >>From gcc-bugs-return-661800-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 13:35:38 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 62813 invoked by alias); 29 Nov 2019 13:35: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 Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 62748 invoked by uid 48); 29 Nov 2019 13:35:34 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/92712] [8/9/10 Regression] Performance regression with assumed values Date: Fri, 29 Nov 2019 13:35: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: 9.2.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub 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: 8.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: 2019-11/txt/msg03594.txt.bz2 Content-length: 1078 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92712 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jakub at gcc dot gnu.org, | |law at gcc dot gnu.org, | |uros at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I don't think the testcase is actually very good, because it uses volatile = that asks the compiler not to optimize that part. But it can be reproduced with: static int func_base(int t, const int v) { int x =3D 0; for (int i =3D 0; i < t; ++i) x +=3D v; return x; } int func_default(int t, const int v) { return func_base(t, v); } int func_assumed(int t, const int v) { if (t < 0) __builtin_unreachable(); return func_base(t, v); } too. The first change in func_assumed was r233207 and the -1;mul;add inste= ad of mul appeared with r263652. >>From gcc-bugs-return-661801-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 13:37:22 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 67769 invoked by alias); 29 Nov 2019 13:37:22 -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 64743 invoked by uid 55); 29 Nov 2019 13:37:18 -0000 From: "jamborm at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug ipa/92476] [10 regression] SEGV in cgraph_edge_brings_value_p Date: Fri, 29 Nov 2019 13:37:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: ipa X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jamborm at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: mjambor at suse dot cz X-Bugzilla-Target-Milestone: 10.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: 2019-11/txt/msg03595.txt.bz2 Content-length: 557 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92476 --- Comment #6 from Martin Jambor --- Author: jamborm Date: Fri Nov 29 13:36:47 2019 New Revision: 278842 URL: https://gcc.gnu.org/viewcvs?rev=3D278842&root=3Dgcc&view=3Drev Log: Add an x86_64 test for PR 92476 2019-11-29 Martin Jambor PR ipa/92476 * g++.dg/lto/pr92476_[01].C: New test. Added: trunk/gcc/testsuite/g++.dg/lto/pr92476_0.C trunk/gcc/testsuite/g++.dg/lto/pr92476_1.C Modified: trunk/gcc/testsuite/ChangeLog >>From gcc-bugs-return-661802-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 13:42:24 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 20265 invoked by alias); 29 Nov 2019 13:42:23 -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 20210 invoked by uid 48); 29 Nov 2019 13:42:20 -0000 From: "marxin at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/92711] GCC 10 libxul.so -fprofile-generate binary is 360MB while clang needs only 163MB. Date: Fri, 29 Nov 2019 13:42: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: 10.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: marxin 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: 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: 2019-11/txt/msg03596.txt.bz2 Content-length: 378 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92711 --- Comment #5 from Martin Li=C5=A1ka --- One particular change that has happened in the GCC 10 devel cycle is that we started using TOP N counters for indirect calls and value profiling. Right = now, we track 4 key:value pairs for each counter plus one counter for total numb= er of executions. >>From gcc-bugs-return-661803-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 13:43:46 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 22512 invoked by alias); 29 Nov 2019 13:43:46 -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 22426 invoked by uid 48); 29 Nov 2019 13:43:40 -0000 From: "jamborm at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug ipa/92476] [10 regression] SEGV in cgraph_edge_brings_value_p Date: Fri, 29 Nov 2019 13:43:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: ipa X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jamborm at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jamborm at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc resolution assigned_to 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: 2019-11/txt/msg03597.txt.bz2 Content-length: 588 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92476 Martin Jambor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED CC| |jamborm at gcc dot gnu.org Resolution|--- |FIXED Assignee|mjambor at suse dot cz |jamborm at gcc dot = gnu.org --- Comment #7 from Martin Jambor --- Fixed. >>From gcc-bugs-return-661804-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 13:48:57 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 39633 invoked by alias); 29 Nov 2019 13:48:56 -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 39566 invoked by uid 48); 29 Nov 2019 13:48:53 -0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/91003] [10 Regression] ICE when compiling LAPACK (CGEGV) with optimization Date: Fri, 29 Nov 2019 13:48:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 10.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: 10.0 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: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2019-11/txt/msg03598.txt.bz2 Content-length: 324 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D91003 --- Comment #7 from Richard Biener --- Created attachment 47396 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D47396&action=3Dedit untested patch The following fixes the testcase but possibly makes the issue just harder to trigger. >>From gcc-bugs-return-661805-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 13:49:40 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 40739 invoked by alias); 29 Nov 2019 13:49:39 -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 40624 invoked by uid 55); 29 Nov 2019 13:49:32 -0000 From: "hubicka at ucw dot cz" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/92711] GCC 10 libxul.so -fprofile-generate binary is 360MB while clang needs only 163MB. Date: Fri, 29 Nov 2019 13:49: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: 10.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: hubicka at ucw dot cz 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: 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: 2019-11/txt/msg03599.txt.bz2 Content-length: 207 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92711 --- Comment #6 from Jan Hubicka --- With GCC9 like inliner parameters I get 308MB binary, so it is still somehwat bigger. Honza >>From gcc-bugs-return-661806-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 13:50:38 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 42908 invoked by alias); 29 Nov 2019 13:50: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 Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 42845 invoked by uid 48); 29 Nov 2019 13:50:34 -0000 From: "joel.hutton at arm dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug testsuite/92391] gcc.dg/vect/bb-slp-40.c FAILs Date: Fri, 29 Nov 2019 13:50:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: testsuite X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: joel.hutton at arm 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: 10.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: 2019-11/txt/msg03600.txt.bz2 Content-length: 211 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92391 --- Comment #13 from Joel Hutton --- This appears to no longer be failing in the latest 'gcc-testresults' can th= is be closed? >>From gcc-bugs-return-661807-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 13:57:48 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 91549 invoked by alias); 29 Nov 2019 13:57:48 -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 91484 invoked by uid 48); 29 Nov 2019 13:57:44 -0000 From: "marxin at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/92711] GCC 10 libxul.so -fprofile-generate binary is 360MB while clang needs only 163MB. Date: Fri, 29 Nov 2019 13:57: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: 10.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: marxin 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: 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: 2019-11/txt/msg03601.txt.bz2 Content-length: 370 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92711 --- Comment #7 from Martin Li=C5=A1ka --- (In reply to Jan Hubicka from comment #6) > With GCC9 like inliner parameters I get 308MB binary, so it is still > somehwat bigger. >=20 > Honza I would try to set: #define GCOV_TOPN_VALUES 1 then you should see the different of TOP N counters. >>From gcc-bugs-return-661808-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 14:03:01 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 127251 invoked by alias); 29 Nov 2019 14:03: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 127143 invoked by uid 48); 29 Nov 2019 14:02:57 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/92712] [8/9/10 Regression] Performance regression with assumed values Date: Fri, 29 Nov 2019 14:03: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: 9.2.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub 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: 8.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: 2019-11/txt/msg03602.txt.bz2 Content-length: 1512 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92712 --- Comment #3 from Jakub Jelinek --- Before the first revision mentioned above *.optimized dump contained just t= * v, the second one doesn't change anything in *.optimized and is a RTL costi= ng matter. _4 =3D (unsigned int) t_1(D); _10 =3D _4 + 4294967295; _8 =3D (int) _10; _13 =3D v_3(D) * _8; x_5 =3D v_3(D) + _13; and can be seen even on simpler: int foo (int t, int v) { t =3D t - 1U; v *=3D t; return v + t; } which we don't optimize at GIMPLE level. We don't optimize even: int bar (int t, int v) { t =3D t - 1; v *=3D t; return v + t; } Rather than hoping it is optimized during combine (the change there was that while combining b=3Da-1 into c=3Db*d we attempted c=3Da*d-d we now attempt = c=3D(a-1)*d and similarly for the 3 insn combination with e=3Dc+d, where we attempted a= nd succeeded to combine that into e=3Da*d while now we attempt and fail e=3D(a= -1)*d+d: -Successfully matched this instruction: +Failed to match this instruction: (parallel [ (set (reg/v:SI 91 [ ]) - (mult:SI (reg/v:SI 92 [ t ]) + (plus:SI (mult:SI (plus:SI (reg/v:SI 92 [ t ]) + (const_int -1 [0xffffffffffffffff])) + (reg/v:SI 93 [ v ])) (reg/v:SI 93 [ v ]))) (clobber (reg:CC 17 flags)) ]) ), I think it would be useful to optimize this in match.pd, plus maybe teach simplify-rtx.c to handle this. >>From gcc-bugs-return-661809-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 14:08:03 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 2554 invoked by alias); 29 Nov 2019 14:08:02 -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 2432 invoked by uid 55); 29 Nov 2019 14:07:58 -0000 From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/92712] [8/9/10 Regression] Performance regression with assumed values Date: Fri, 29 Nov 2019 14:08: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: 9.2.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenther at suse dot de 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: 8.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: 2019-11/txt/msg03603.txt.bz2 Content-length: 2078 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92712 --- Comment #4 from rguenther at suse dot de --- On Fri, 29 Nov 2019, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92712 >=20 > --- Comment #3 from Jakub Jelinek --- > Before the first revision mentioned above *.optimized dump contained just= t * > v, the second one doesn't change anything in *.optimized and is a RTL cos= ting > matter. > _4 =3D (unsigned int) t_1(D); > _10 =3D _4 + 4294967295; > _8 =3D (int) _10; > _13 =3D v_3(D) * _8; > x_5 =3D v_3(D) + _13; > and can be seen even on simpler: > int > foo (int t, int v) > { > t =3D t - 1U; > v *=3D t; > return v + t; > } > which we don't optimize at GIMPLE level. We don't optimize even: > int > bar (int t, int v) > { > t =3D t - 1; > v *=3D t; > return v + t; > } > Rather than hoping it is optimized during combine (the change there was t= hat > while combining b=3Da-1 into c=3Db*d we attempted c=3Da*d-d we now attemp= t c=3D(a-1)*d > and similarly for the 3 insn combination with e=3Dc+d, where we attempted= and > succeeded to combine that into e=3Da*d while now we attempt and fail e=3D= (a-1)*d+d: > -Successfully matched this instruction: > +Failed to match this instruction: > (parallel [ > (set (reg/v:SI 91 [ ]) > - (mult:SI (reg/v:SI 92 [ t ]) > + (plus:SI (mult:SI (plus:SI (reg/v:SI 92 [ t ]) > + (const_int -1 [0xffffffffffffffff])) > + (reg/v:SI 93 [ v ])) > (reg/v:SI 93 [ v ]))) > (clobber (reg:CC 17 flags)) > ]) > ), I think it would be useful to optimize this in match.pd, plus maybe te= ach > simplify-rtx.c to handle this. I think fold_plusminus_mult_expr does this on GENERIC, but it was dumbed down at some point because of undefined overflow issues. Because for (t - 1) * v + v, (t - 1) might be zero and with large v t * v might overflow (or so, need to track down history of that function).=20 Richard. >>From gcc-bugs-return-661810-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 14:13:37 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 26723 invoked by alias); 29 Nov 2019 14:13:37 -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 26693 invoked by uid 48); 29 Nov 2019 14:13:33 -0000 From: "burnus at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/92728] New: [OpenMP][OpenACC] Common-block name clause matching issues: common block needs to be defined before + blank common not supported Date: Fri, 29 Nov 2019 14:13:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: openacc, openmp X-Bugzilla-Severity: normal X-Bugzilla-Who: burnus 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 keywords 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: 2019-11/txt/msg03604.txt.bz2 Content-length: 1761 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92728 Bug ID: 92728 Summary: [OpenMP][OpenACC] Common-block name clause matching issues: common block needs to be defined before + blank common not supported Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: openacc, openmp Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- Based on the discussion at https://gcc.gnu.org/ml/gcc-patches/2019-11/threads.html#00717 The current clause matching code in openmp.c's gfc_match_omp_variable_list does: m =3D gfc_match (" / %n /", n); =E2=80=A6 st =3D gfc_find_symtree (gfc_current_ns->common_root, n); if (st =3D=3D NULL) { gfc_error ("COMMON block /%s/ not found at %C", n); Hence: (1) This code requires the ordering common /name/ =E2=80=A6 !$omp =E2=80=A6 (/name/) !$acc =E2=80=A6 (/name/) while it would be (also) natural to use !$omp =E2=80=A6 (/name/) !$acc =E2=80=A6 (/name/) common /name/ =E2=80=A6 The Fortran standard usually permits this and at least part of the Open= XXX specs talk only about the specification section, not imposing any order= ing. * Blank commons (i.e. common blocks without a name) cannot be matched. Regarding blank commons: neither OpenMP nor OpenACC are clear whether they = are permitted and where. =E2=80=93 However, in some clauses, OpenMP explicitly = mentions that blank commons are not permitted, implying that they are permitted elsewhere. (See linked emails in the thread.) >>From gcc-bugs-return-661811-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 14:22:11 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 37651 invoked by alias); 29 Nov 2019 14:22:11 -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 37550 invoked by uid 48); 29 Nov 2019 14:22:07 -0000 From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/79592] incomplete diagnostic "is not usable as a constexpr function because:" Date: Fri, 29 Nov 2019 14:22: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: 6.3.1 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: redi 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: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords cf_reconfirmed_on 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: 2019-11/txt/msg03605.txt.bz2 Content-length: 638 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D79592 Jonathan Wakely changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|accepts-invalid | Last reconfirmed|2017-08-21 00:00:00 |2019-11-29 --- Comment #3 from Jonathan Wakely --- (In reply to Eric Gallager from comment #1) > On a 32-bit target, it is always incorrectly accepted; adding -m64 is > necessary to get the incomplete diagnostic: That was a separate problem, fixed by r257161 for PR 68810. >>From gcc-bugs-return-661812-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 14:23:27 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 39095 invoked by alias); 29 Nov 2019 14:23:26 -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 39041 invoked by uid 48); 29 Nov 2019 14:23:22 -0000 From: "jamborm at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug ipa/92697] IPA-SRA modifies ifunc_resolvers Date: Fri, 29 Nov 2019 14:23:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: ipa X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jamborm at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jamborm at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution 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: 2019-11/txt/msg03606.txt.bz2 Content-length: 427 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92697 Martin Jambor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Jambor --- Fixed. >>From gcc-bugs-return-661813-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 14:25:47 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 84141 invoked by alias); 29 Nov 2019 14:25:47 -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 83685 invoked by uid 48); 29 Nov 2019 14:25:43 -0000 From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/79592] incomplete diagnostic "is not usable as a constexpr function because:" Date: Fri, 29 Nov 2019 14:25: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: 6.3.1 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: redi 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: --- 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: 2019-11/txt/msg03607.txt.bz2 Content-length: 308 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D79592 --- Comment #4 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #0) > If the expression is (void*)1 rather than (void*)1LL then it is incorrect= ly > accepted. And that was the same problem, fixed by r257161. >>From gcc-bugs-return-661814-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 14:25:50 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 84462 invoked by alias); 29 Nov 2019 14:25:50 -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 84018 invoked by uid 48); 29 Nov 2019 14:25:45 -0000 From: "glisse at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/92712] [8/9/10 Regression] Performance regression with assumed values Date: Fri, 29 Nov 2019 14:25: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: 9.2.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: glisse 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: 8.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: 2019-11/txt/msg03608.txt.bz2 Content-length: 418 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92712 --- Comment #5 from Marc Glisse --- a*x+x -> (a+1)*x is unsafe (a=3DINT_MAX, x=3D0), but there are cases where = we could prove that it is safe, in particular when a is actually b-1 (more generally= for a*x+b*x when we can prove (with VRP?) that a+b cannot overflow). Also, enabling -fwrapv for the last few gimple passes would help. >>From gcc-bugs-return-661815-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 14:27:57 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 86713 invoked by alias); 29 Nov 2019 14:27:56 -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 86655 invoked by uid 48); 29 Nov 2019 14:27:52 -0000 From: "ro at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug testsuite/92391] gcc.dg/vect/bb-slp-40.c FAILs Date: Fri, 29 Nov 2019 14:27:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: testsuite X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ro at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution 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: 2019-11/txt/msg03609.txt.bz2 Content-length: 413 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92391 Rainer Orth changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Rainer Orth --- Sure. >>From gcc-bugs-return-661816-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 14:35:09 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 94676 invoked by alias); 29 Nov 2019 14:35:09 -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 94574 invoked by uid 48); 29 Nov 2019 14:35:05 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/92712] [8/9/10 Regression] Performance regression with assumed values Date: Fri, 29 Nov 2019 14:35: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: 9.2.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub 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: 8.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: 2019-11/txt/msg03610.txt.bz2 Content-length: 687 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92712 --- Comment #6 from Jakub Jelinek --- At least from the comments it seems fold_plusminus_mult_expr only handles (A * C) +- (B * C) -> (A +- B) * C (A * C) +- A -> A * (C +- 1) so for the testcases in question that is the latter and we punt because it = is not wrapping arithmetics and it doesn't match one of the special cases in there. The suggestion I'll try to work on is to check if C isn't a plus/minus expr with constant second operand that doesn't go in the other direction and thus where the transformation isn't introducing UB. I guess it should be enough to do this in match.pd though. >>From gcc-bugs-return-661817-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 14:35:52 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 95733 invoked by alias); 29 Nov 2019 14:35: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 95655 invoked by uid 48); 29 Nov 2019 14:35:48 -0000 From: "segher at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/92510] ICE in native_encode_rtx, at simplify-rtx.c:6272 Date: Fri, 29 Nov 2019 14:35: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: 10.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: segher at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution 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: 2019-11/txt/msg03611.txt.bz2 Content-length: 543 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92510 Segher Boessenkool changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Segher Boessenkool --- This is a bad PR to track all improvements that could be made to combine (and RTL in general). Closing as fixed. >>From gcc-bugs-return-661818-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 14:36:05 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 96507 invoked by alias); 29 Nov 2019 14:36:05 -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 96424 invoked by uid 48); 29 Nov 2019 14:36:01 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/92712] [8/9/10 Regression] Performance regression with assumed values Date: Fri, 29 Nov 2019 14:36: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: 9.2.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: 8.4 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status assigned_to 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: 2019-11/txt/msg03612.txt.bz2 Content-length: 378 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92712 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gn= u.org >>From gcc-bugs-return-661819-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 14:38:05 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 100825 invoked by alias); 29 Nov 2019 14:38:05 -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 100761 invoked by uid 48); 29 Nov 2019 14:38:01 -0000 From: "glaubitz at physik dot fu-berlin.de" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/92729] New: [avr] Convert the backend to MODE_CC so it can be kept in future releases Date: Fri, 29 Nov 2019 14:38:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: glaubitz at physik dot fu-berlin.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 cf_gcctarget 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: 2019-11/txt/msg03613.txt.bz2 Content-length: 834 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92729 Bug ID: 92729 Summary: [avr] Convert the backend to MODE_CC so it can be kept in future releases Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: glaubitz at physik dot fu-berlin.de Target Milestone: --- Target: avr-*-* This is a tracker bug for the convert the avr backend from CC0 to MODE_CC s= o it can be kept in future releases. See: https://gcc.gnu.org/wiki/CC0Transition I will be using this bug report to create a bounty on BountySource.com. We have already successfully funded such a conversion for the m68k backend,= see #91851. >>From gcc-bugs-return-661820-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 14:39:59 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 103882 invoked by alias); 29 Nov 2019 14:39: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 103829 invoked by uid 48); 29 Nov 2019 14:39:53 -0000 From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/92727] Idea for better error messages Date: Fri, 29 Nov 2019 14:39: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: unknown X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: enhancement X-Bugzilla-Who: redi 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: 2019-11/txt/msg03614.txt.bz2 Content-length: 2465 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92727 Jonathan Wakely changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |diagnostic Severity|normal |enhancement --- Comment #1 from Jonathan Wakely --- (In reply to David Brown from comment #0) > Would it be possible to hide the messages concerning the allocator here? I don't see how. It's the allocator that tries to use the X(const X&) copy constructor. Why would you want to hide it? > In > general, would it be possible to hide the messages that deal with template > parameters that are unchanged from the default? Can you clarify what you mean? Nothing in this error has anything to do with default template arguments. You'll get exactly the same error with std::vector>. > That would let the user see > messages that are relevant to the code /they/ have written, rather than > implementation details in the libraries and headers. While that seems a noble goal, I don't think "hide the messages concerning = the allocator" or "hide the messages that deal with template parameters that are unchanged from the default" get anywhere near that goal. > Even better, in this case, would be a hint that the user needs a std::mov= e, > as shown in line B. Where should the compiler suggest that move? How does it know whether the missing std::move should be in main(), or inside std::vector::push_back, or inside allocator::construct? A reasonable heuristic would be to assume code inside system headers is correct, and that the code using those system headers is at fault, but it's still going to suggest the wrong place often. A better one would be to assume system headers are correct, and not suggest adding it anywhere that already uses std::forward, because that's probably generic code dealing with perfect forwarding, and the move should have been= in the caller of *that* code. And you don't want to suggest adding std::move to a const value, because th= at won't help. The general problem is that inserting a std::move at some point in the call graph can completely change everything after that point, and so won't necessarily even reach the code that gave an error. Is that a "fix"? It's impossible to know without grokking the code. >>From gcc-bugs-return-661823-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 14:43:52 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 121817 invoked by alias); 29 Nov 2019 14:43: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 118927 invoked by uid 48); 29 Nov 2019 14:43:48 -0000 From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/92727] Idea for better error messages Date: Fri, 29 Nov 2019 14:43: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: unknown X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: enhancement X-Bugzilla-Who: redi 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: 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: 2019-11/txt/msg03617.txt.bz2 Content-length: 639 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92727 --- Comment #2 from Jonathan Wakely --- Are you suggesting that everything inside libstdc++ code should be treated = as a black box for the purposes of diagnostics, so that the location of the actu= al problem: error: use of deleted function =E2=80=98X::X(const X&)=E2=80=99 is shown as the "entry point" into the library code, i.e. the call to push_= back in the user's code? That would be novel, and very unpopular with some people (who do want to be able to examine the library headers and see how/why they got to that point = and what didn't compile). >>From gcc-bugs-return-661821-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 14:43:50 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 121081 invoked by alias); 29 Nov 2019 14:43:50 -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 117795 invoked by uid 48); 29 Nov 2019 14:43:46 -0000 From: "marxin at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/89280] [8 Regression] ICE: Segmentation fault (in is_gimple_reg_type) Date: Fri, 29 Nov 2019 14:43: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: 9.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: marxin at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: 8.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: 2019-11/txt/msg03615.txt.bz2 Content-length: 187 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D89280 --- Comment #15 from Martin Li=C5=A1ka --- *** Bug 92725 has been marked as a duplicate of this bug. *** >>From gcc-bugs-return-661822-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 14:43:50 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 121430 invoked by alias); 29 Nov 2019 14:43:50 -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 117531 invoked by uid 48); 29 Nov 2019 14:43:45 -0000 From: "marxin at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/92725] ICE: Segmentation fault during GIMPLE pass Date: Fri, 29 Nov 2019 14:43: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: 8.3.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: marxin at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: DUPLICATE 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_status cc resolution 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: 2019-11/txt/msg03616.txt.bz2 Content-length: 572 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92725 Martin Li=C5=A1ka changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |marxin at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Martin Li=C5=A1ka --- Dup. *** This bug has been marked as a duplicate of bug 89280 *** >>From gcc-bugs-return-661824-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 14:44:26 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 18148 invoked by alias); 29 Nov 2019 14:44:25 -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 11600 invoked by uid 48); 29 Nov 2019 14:44:21 -0000 From: "marxin at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/92379] rs6000.c:5598:13: runtime error: shift exponent 64 is too large for 64-bit type 'long int' Date: Fri, 29 Nov 2019 14:44:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: marxin at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P5 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: 2019-11/txt/msg03618.txt.bz2 Content-length: 154 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92379 --- Comment #4 from Martin Li=C5=A1ka --- Any update about this Segher? >>From gcc-bugs-return-661825-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 14:47:40 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 34320 invoked by alias); 29 Nov 2019 14:47: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 33952 invoked by uid 55); 29 Nov 2019 14:47:35 -0000 From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/91997] pretty printers: The __node_type type alias in _Hashtable is not available Date: Fri, 29 Nov 2019 14:47: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: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: redi at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: redi at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.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: 2019-11/txt/msg03619.txt.bz2 Content-length: 2477 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D91997 --- Comment #7 from Jonathan Wakely --- Author: redi Date: Fri Nov 29 14:47:03 2019 New Revision: 278846 URL: https://gcc.gnu.org/viewcvs?rev=3D278846&root=3Dgcc&view=3Drev Log: libstdc++:: improve how pretty printers find node types (PR 91997) This fixes two related problems. The iterators for node-based containers use nested typedefs such as std::list::iterator::_Node to denote their node types. As reported in https://bugzilla.redhat.com/show_bug.cgi?id=3D1053438 those typedefs are not always present in the debug info. That means the pretty printers cannot find them using gdb.lookup_type (via the find_type helper). Instead of looking up the nested typedefs this patch makes the printers look up the actual class templates directly. A related problem (and the original topic of PR 91997) is that GDB fails to find types via gdb.lookup_type when printing a backtrace from a non-C++ functiion: https://sourceware.org/bugzilla/show_bug.cgi?id=3D25234 That is also solved by not looking up the nested typedef. PR libstdc++/91997 * python/libstdcxx/v6/printers.py (find_type): Fail more gracefully if we run out of base classes to look at. (llokup_templ_spec, lookup_node_type): New utilities to find node types for node-based containers. (StdListPrinter.children, NodeIteratorPrinter.__init__) (NodeIteratorPrinter.to_string, StdSlistPrinter.children) (StdSlistIteratorPrinter.to_string, StdRbtreeIteratorPrinter.__init= __) (StdMapPrinter.children, StdSetPrinter.children) (StdForwardListPrinter.children): Use lookup_node_type instead of find_type. (StdListIteratorPrinter.__init__, StdFwdListIteratorPrinter.__init_= _): Pass name of node type to NodeIteratorPrinter constructor. (Tr1HashtableIterator.__init__): Rename argument. (StdHashtableIterator.__init__): Likewise. Use lookup_templ_spec instead of find_type. * testsuite/libstdc++-prettyprinters/59161.cc: Remove workaround for _Node typedef not being present in debuginfo. * testsuite/libstdc++-prettyprinters/91997.cc: New test. Added: trunk/libstdc++-v3/testsuite/libstdc++-prettyprinters/91997.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/python/libstdcxx/v6/printers.py trunk/libstdc++-v3/testsuite/libstdc++-prettyprinters/59161.cc >>From gcc-bugs-return-661826-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 14:48:42 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 36562 invoked by alias); 29 Nov 2019 14:48:36 -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 36126 invoked by uid 55); 29 Nov 2019 14:48:30 -0000 From: "rsandifo at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/92710] [9/10 Regression] Vectoriser generates invalid simd call for bool arguments Date: Fri, 29 Nov 2019 14:48: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: 10.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rsandifo at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rsandifo at gcc dot gnu.org X-Bugzilla-Target-Milestone: 9.3 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: 2019-11/txt/msg03620.txt.bz2 Content-length: 5455 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92710 --- Comment #3 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Fri Nov 29 14:47:44 2019 New Revision: 278851 URL: https://gcc.gnu.org/viewcvs?rev=3D278851&root=3Dgcc&view=3Drev Log: Don't defer choice of vector type for bools (PR 92596) Now that stmt_vec_info records the choice between vector mask types and normal nonmask types, we can use that information in vect_get_vector_types_for_stmt instead of deferring the choice of vector type till later. vect_get_mask_type_for_stmt used to check whether the boolean inputs to an operation: (a) consistently used mask types or consistently used nonmask types; and (b) agreed on the number of elements. (b) shouldn't be a problem when (a) is met. If the operation consistently uses mask types, tree-vect-patterns.c will have corrected any mismatches in mask precision. (This is because we only use mask types for a small well-known set of operations and tree-vect-patterns.c knows how to handle any that could have different mask precisions.) And if the operation consistently uses normal nonmask types, there's no reason why booleans should need extra vector compatibility checks compared to ordinary integers. So the potential difficulties all seem to come from (a). Now that we've chosen the result type ahead of time, we also have to consider whether the outputs and inputs consistently use mask types. Taking each vectorizable_* routine in turn: - vectorizable_call vect_get_vector_types_for_stmt only handled booleans specially for gassigns, so vect_get_mask_type_for_stmt never had chance to handle calls. I'm not sure we support any calls that operate on booleans, but as things stand, a boolean result would always have a nonmask type. Presumably any vector argument would also need to use nonmask types, unless it corresponds to internal_fn_mask_index (which is already a special case). For safety, I've added a check for mask/nonmask combinations here even though we didn't check this previously. - vectorizable_simd_clone_call Again, vect_get_mask_type_for_stmt never had chance to handle calls. The result of the call will always be a nonmask type and the patch for PR 92710 rejects mask arguments. So all booleans should consistently use nonmask types here. - vectorizable_conversion The function already rejects any conversion between booleans in which one type isn't a mask type. - vectorizable_operation This function definitely needs a consistency check, e.g. to handle & and | in which one operand is loaded from memory and the other is a comparison result. Ideally we'd handle this via pattern stmts instead (like we do for the all-mask case), but that's future work. - vectorizable_assignment VECT_SCALAR_BOOLEAN_TYPE_P requires single-bit precision, so the current code already rejects problematic cases. - vectorizable_load Loads always produce nonmask types and there are no relevant inputs to check against. - vectorizable_store vect_check_store_rhs already rejects mask/nonmask combinations via useless_type_conversion_p. - vectorizable_reduction - vectorizable_lc_phi PHIs always have nonmask types. After the change above, attempts to combine the PHI result with a mask type would be rejected by vectorizable_operation. (Again, it would be better to handle this using pattern stmts.) - vectorizable_induction We don't generate inductions for booleans. - vectorizable_shift The function already rejects boolean shifts via type_has_mode_precision= _p. - vectorizable_condition The function already rejects mismatches via useless_type_conversion_p. - vectorizable_comparison The function already rejects comparisons between mask and nonmask types. The result is always a mask type. 2019-11-29 Richard Sandiford gcc/ PR tree-optimization/92596 * tree-vect-stmts.c (vectorizable_call): Punt on hybrid mask/nonmask operations. (vectorizable_operation): Likewise, instead of relying on vect_get_mask_type_for_stmt to do this. (vect_get_vector_types_for_stmt): Always return a vector type immediately, rather than deferring the choice for boolean results. Use a vector mask type instead of a normal vector if vect_use_mask_type_p. (vect_get_mask_type_for_stmt): Delete. * tree-vect-loop.c (vect_determine_vf_for_stmt_1): Remove mask_producers argument and special boolean_type_node handling. (vect_determine_vf_for_stmt): Remove mask_producers argument and update calls to vect_determine_vf_for_stmt_1. Remove doubled call. (vect_determine_vectorization_factor): Update call accordingly. * tree-vect-slp.c (vect_build_slp_tree_1): Remove special boolean_type_node handling. (vect_slp_analyze_node_operations_1): Likewise. gcc/testsuite/ PR tree-optimization/92596 * gcc.dg/vect/bb-slp-pr92596.c: New test. * gcc.dg/vect/bb-slp-43.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/vect/bb-slp-43.c trunk/gcc/testsuite/gcc.dg/vect/bb-slp-pr92596.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c trunk/gcc/tree-vect-slp.c trunk/gcc/tree-vect-stmts.c >>From gcc-bugs-return-661827-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 14:48:42 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 36627 invoked by alias); 29 Nov 2019 14:48: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 36129 invoked by uid 55); 29 Nov 2019 14:48:30 -0000 From: "rsandifo at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/92596] [10 Regression] ICE in exact_div, at poly-int.h:2162 since r278406 Date: Fri, 29 Nov 2019 14:48: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: 10.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rsandifo at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: rsandifo at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.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: 2019-11/txt/msg03622.txt.bz2 Content-length: 5456 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92596 --- Comment #11 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Fri Nov 29 14:47:44 2019 New Revision: 278851 URL: https://gcc.gnu.org/viewcvs?rev=3D278851&root=3Dgcc&view=3Drev Log: Don't defer choice of vector type for bools (PR 92596) Now that stmt_vec_info records the choice between vector mask types and normal nonmask types, we can use that information in vect_get_vector_types_for_stmt instead of deferring the choice of vector type till later. vect_get_mask_type_for_stmt used to check whether the boolean inputs to an operation: (a) consistently used mask types or consistently used nonmask types; and (b) agreed on the number of elements. (b) shouldn't be a problem when (a) is met. If the operation consistently uses mask types, tree-vect-patterns.c will have corrected any mismatches in mask precision. (This is because we only use mask types for a small well-known set of operations and tree-vect-patterns.c knows how to handle any that could have different mask precisions.) And if the operation consistently uses normal nonmask types, there's no reason why booleans should need extra vector compatibility checks compared to ordinary integers. So the potential difficulties all seem to come from (a). Now that we've chosen the result type ahead of time, we also have to consider whether the outputs and inputs consistently use mask types. Taking each vectorizable_* routine in turn: - vectorizable_call vect_get_vector_types_for_stmt only handled booleans specially for gassigns, so vect_get_mask_type_for_stmt never had chance to handle calls. I'm not sure we support any calls that operate on booleans, but as things stand, a boolean result would always have a nonmask type. Presumably any vector argument would also need to use nonmask types, unless it corresponds to internal_fn_mask_index (which is already a special case). For safety, I've added a check for mask/nonmask combinations here even though we didn't check this previously. - vectorizable_simd_clone_call Again, vect_get_mask_type_for_stmt never had chance to handle calls. The result of the call will always be a nonmask type and the patch for PR 92710 rejects mask arguments. So all booleans should consistently use nonmask types here. - vectorizable_conversion The function already rejects any conversion between booleans in which one type isn't a mask type. - vectorizable_operation This function definitely needs a consistency check, e.g. to handle & and | in which one operand is loaded from memory and the other is a comparison result. Ideally we'd handle this via pattern stmts instead (like we do for the all-mask case), but that's future work. - vectorizable_assignment VECT_SCALAR_BOOLEAN_TYPE_P requires single-bit precision, so the current code already rejects problematic cases. - vectorizable_load Loads always produce nonmask types and there are no relevant inputs to check against. - vectorizable_store vect_check_store_rhs already rejects mask/nonmask combinations via useless_type_conversion_p. - vectorizable_reduction - vectorizable_lc_phi PHIs always have nonmask types. After the change above, attempts to combine the PHI result with a mask type would be rejected by vectorizable_operation. (Again, it would be better to handle this using pattern stmts.) - vectorizable_induction We don't generate inductions for booleans. - vectorizable_shift The function already rejects boolean shifts via type_has_mode_precision= _p. - vectorizable_condition The function already rejects mismatches via useless_type_conversion_p. - vectorizable_comparison The function already rejects comparisons between mask and nonmask types. The result is always a mask type. 2019-11-29 Richard Sandiford gcc/ PR tree-optimization/92596 * tree-vect-stmts.c (vectorizable_call): Punt on hybrid mask/nonmask operations. (vectorizable_operation): Likewise, instead of relying on vect_get_mask_type_for_stmt to do this. (vect_get_vector_types_for_stmt): Always return a vector type immediately, rather than deferring the choice for boolean results. Use a vector mask type instead of a normal vector if vect_use_mask_type_p. (vect_get_mask_type_for_stmt): Delete. * tree-vect-loop.c (vect_determine_vf_for_stmt_1): Remove mask_producers argument and special boolean_type_node handling. (vect_determine_vf_for_stmt): Remove mask_producers argument and update calls to vect_determine_vf_for_stmt_1. Remove doubled call. (vect_determine_vectorization_factor): Update call accordingly. * tree-vect-slp.c (vect_build_slp_tree_1): Remove special boolean_type_node handling. (vect_slp_analyze_node_operations_1): Likewise. gcc/testsuite/ PR tree-optimization/92596 * gcc.dg/vect/bb-slp-pr92596.c: New test. * gcc.dg/vect/bb-slp-43.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/vect/bb-slp-43.c trunk/gcc/testsuite/gcc.dg/vect/bb-slp-pr92596.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c trunk/gcc/tree-vect-slp.c trunk/gcc/tree-vect-stmts.c >>From gcc-bugs-return-661828-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 14:48:55 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 37649 invoked by alias); 29 Nov 2019 14:48:49 -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 37050 invoked by uid 48); 29 Nov 2019 14:48:44 -0000 From: "segher at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/92379] rs6000.c:5598:13: runtime error: shift exponent 64 is too large for 64-bit type 'long int' Date: Fri, 29 Nov 2019 14:48:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: segher at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P5 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: 2019-11/txt/msg03621.txt.bz2 Content-length: 195 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92379 --- Comment #5 from Segher Boessenkool --- It's not top priority; it is fine for stage 4, too. Patches welcome. >>From gcc-bugs-return-661829-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 14:49:08 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 38835 invoked by alias); 29 Nov 2019 14:49:08 -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 38746 invoked by uid 55); 29 Nov 2019 14:49:04 -0000 From: "rsandifo at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/92677] [10 Regression] ICE in get_group_load_store_type, at tree-vect-stmts.c:2261 since r271704 Date: Fri, 29 Nov 2019 14:49: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: 10.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rsandifo at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: rsandifo at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.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: 2019-11/txt/msg03623.txt.bz2 Content-length: 935 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92677 --- Comment #2 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Fri Nov 29 14:48:30 2019 New Revision: 278852 URL: https://gcc.gnu.org/viewcvs?rev=3D278852&root=3Dgcc&view=3Drev Log: Fix DR_GROUP_GAP for strided accesses (PR 92677) When dissolving an SLP-only group of accesses, we should only set the gap to group_size - 1 for normal non-strided groups. 2019-11-29 Richard Sandiford gcc/ PR tree-optimization/92677 * tree-vect-loop.c (vect_dissolve_slp_only_groups): Set the gap to zero when dissolving a group of strided accesses. gcc/testsuite/ PR tree-optimization/92677 * gcc.dg/vect/pr92677.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr92677.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c >>From gcc-bugs-return-661830-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 14:49:19 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 39539 invoked by alias); 29 Nov 2019 14:49: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 39463 invoked by uid 48); 29 Nov 2019 14:49:14 -0000 From: "glisse at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/92712] [8/9/10 Regression] Performance regression with assumed values Date: Fri, 29 Nov 2019 14:49: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: 9.2.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: glisse at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: 8.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: 2019-11/txt/msg03624.txt.bz2 Content-length: 686 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92712 --- Comment #7 from Marc Glisse --- The first question could be why SCCP produces (const int) ((unsigned int) t_2(D) + 4294967295) * v_3(D) + v_3(D) and not directly t*v. Several loop passes do have this tendency to split out the last (or first) iteration and produce strange expressions that we have trouble cleaning up afterwards. Anyway, in VRP2, I see _10: int [0, 2147483646] _14 =3D v_3(D) * _10; x_6 =3D v_3(D) + _14; so range info would allow to prove that _10 + 1 cannot overflow, and thus to factor out v_3(D). I have long wanted a op_cannot_overflow(tree_code,tree,t= ree) utility... >>From gcc-bugs-return-661831-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 14:52:23 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 46097 invoked by alias); 29 Nov 2019 14:52:23 -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 46010 invoked by uid 48); 29 Nov 2019 14:52:19 -0000 From: "glisse at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/92712] [8/9/10 Regression] Performance regression with assumed values Date: Fri, 29 Nov 2019 14:52: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: 9.2.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: glisse at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: 8.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: 2019-11/txt/msg03625.txt.bz2 Content-length: 557 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92712 --- Comment #8 from Marc Glisse --- (In reply to Jakub Jelinek from comment #6) > The suggestion I'll try to work on is to check if C isn't a plus/minus ex= pr > with constant second operand that doesn't go in the other direction and t= hus > where the transformation isn't introducing UB. In the testcase, t-1 is computed in some unsigned type and then cast back to signed, so I don't think it will work. > I guess it should be enough to do this in match.pd though. Yes. >>From gcc-bugs-return-661832-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 14:54:56 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 15351 invoked by alias); 29 Nov 2019 14:54:55 -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 8162 invoked by uid 48); 29 Nov 2019 14:54:52 -0000 From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/91997] pretty printers: The __node_type type alias in _Hashtable is not available Date: Fri, 29 Nov 2019 14:54: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: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: redi at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: redi at gcc dot gnu.org X-Bugzilla-Target-Milestone: 8.4 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: target_milestone 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: 2019-11/txt/msg03626.txt.bz2 Content-length: 395 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D91997 Jonathan Wakely changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|10.0 |8.4 --- Comment #8 from Jonathan Wakely --- Fixed on trunk, backports to follow. >>From gcc-bugs-return-661833-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 14:57:37 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 5458 invoked by alias); 29 Nov 2019 14:57:37 -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 5397 invoked by uid 55); 29 Nov 2019 14:57:33 -0000 From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/92712] [8/9/10 Regression] Performance regression with assumed values Date: Fri, 29 Nov 2019 14:57: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: 9.2.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenther at suse dot de X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: 8.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: 2019-11/txt/msg03627.txt.bz2 Content-length: 703 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92712 --- Comment #9 from rguenther at suse dot de --- On November 29, 2019 3:25:45 PM GMT+01:00, "glisse at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92712 > >--- Comment #5 from Marc Glisse --- >a*x+x -> (a+1)*x is unsafe (a=3DINT_MAX, x=3D0), but there are cases where >we could >prove that it is safe, in particular when a is actually b-1 (more >generally for >a*x+b*x when we can prove (with VRP?) that a+b cannot overflow). > >Also, enabling -fwrapv for the last few gimple passes would help. I had a patch for that, RTL is also wrapv. >>From gcc-bugs-return-661834-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 14:59:49 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 8928 invoked by alias); 29 Nov 2019 14:59:49 -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 8845 invoked by uid 48); 29 Nov 2019 14:59:45 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/92712] [8/9/10 Regression] Performance regression with assumed values Date: Fri, 29 Nov 2019 14:59: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: 9.2.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: 8.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: 2019-11/txt/msg03628.txt.bz2 Content-length: 803 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92712 --- Comment #10 from Jakub Jelinek --- (In reply to Marc Glisse from comment #8) > (In reply to Jakub Jelinek from comment #6) > > The suggestion I'll try to work on is to check if C isn't a plus/minus = expr > > with constant second operand that doesn't go in the other direction and= thus > > where the transformation isn't introducing UB. >=20 > In the testcase, t-1 is computed in some unsigned type and then cast back= to > signed, so I don't think it will work. I know, it will be a small complication, sure, but it can be handled. Using range info is certainly useful, but e.g. for this case with -1U it wi= ll not be able to do anything, as the range of (int)(t-1U) will be varying. S= o I think we want both. >>From gcc-bugs-return-661835-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 15:01:13 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 10950 invoked by alias); 29 Nov 2019 15:01:13 -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 10903 invoked by uid 48); 29 Nov 2019 15:01:08 -0000 From: "marxin at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/92286] Possible improvement for -Wduplicated-cond warning Date: Fri, 29 Nov 2019 15:01: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: 10.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: marxin at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: WONTFIX 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_status resolution 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: 2019-11/txt/msg03629.txt.bz2 Content-length: 482 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92286 Martin Li=C5=A1ka changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Martin Li=C5=A1ka --- Based on Eric wrote, I tend to close it as won't fix. >>From gcc-bugs-return-661836-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 15:05:51 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 27993 invoked by alias); 29 Nov 2019 15:05:51 -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 27914 invoked by uid 48); 29 Nov 2019 15:05:45 -0000 From: "vmakarov at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2 Date: Fri, 29 Nov 2019 15:05: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: 10.0 X-Bugzilla-Keywords: ra, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: vmakarov 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: 10.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: 2019-11/txt/msg03630.txt.bz2 Content-length: 3347 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92283 --- Comment #26 from Vladimir Makarov --- I think I find the problem root. We have ********** Local #2: ********** Choosing alt 0 in insn 1804: (0) =3Dv (1) %0 (2) vm (3) v {*fma_fmadd_df} Creating newreg=3D4707 from oldreg=3D1801, assigning class ALL_SSE_RE= GS to r4707 Creating newreg=3D4708 from oldreg=3D1801, assigning class ALL_SSE_RE= GS to r4708 Making reload reg 4708 for reg 1801 optional 1804: r4707:DF=3D{r4707:DF*r4708:DF+r984:DF} ! REG_DEAD r1801:DF REG_DEAD r984:DF Inserting insn reload before: 10917: r4707:DF=3Dr1801:DF 10919: r4708:DF=3Dr1801:DF Inserting insn reload after: 10918: r238:DF=3Dr4707:DF ......... Choosing alt 2 in insn 1814: (0) v (1) v (2) vm (3) 0 {*fma_fmadd_df} Creating newreg=3D4709 from oldreg=3D1801, assigning class ALL_SSE_RE= GS to r4709 Making reload reg 4709 for reg 1801 optional 1814: r244:DF=3D{r1795:DF*r4709:DF+r1803:DF} REG_DEAD r1801:DF REG_DEAD r1803:DF Inserting insn reload before: 10920: r4709:DF=3Dr1801:DF ********** Inheritance #2: ********** <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Use smallest class of ALL_SSE_REGS and SSE_REGS Creating newreg=3D4778 from oldreg=3D1801, assigning class ALL_SSE_RE= GS to inheritance r4778 Original reg change 1801->4778 (bb177): 10920: r4709:DF=3Dr4778:DF Add inheritance<-original before: 10995: r4778:DF=3Dr1801:DF Inheritance reuse change 1801->4778 (bb177): 10019: r3911:DF=3Dr4778:DF REG_DEAD r4778:DF >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Use smallest class of ALL_SSE_REGS and SSE_REGS Creating newreg=3D4779 from oldreg=3D1801, assigning class ALL_SSE_RE= GS to inheritance r4779 Original reg change 1801->4779 (bb177): ! 10919: r4708:DF=3Dr4779:DF Add inheritance<-original before: 10996: r4779:DF=3Dr1801:DF Inheritance reuse change 1801->4779 (bb177): 10995: r4778:DF=3Dr4779:DF >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ********** Assignment #2: ********** Assigning to 4779 (cl=3DALL_SSE_REGS, orig=3D1801, freq=3D18, tfir= st=3D4707, tfreq=3D36)... Assigning to 4778 (cl=3DALL_SSE_REGS, orig=3D1801, freq=3D18, tfir= st=3D4707, tfreq=3D36)... Assigning to 4780 (cl=3DALL_SSE_REGS, orig=3D1801, freq=3D18, tfir= st=3D4707, tfreq=3D36)... Assign 26 to inheritance r4780 (freq=3D18) Reassigning non-reload pseudos Assign 4 to r237 (freq=3D26) Assign 26 to inheritance r4778 (freq=3D18) ! Hard reg 26 is preferable by r4779 with profit 24 Assign 26 to inheritance r4779 (freq=3D18) We assigned 26 for conflicting 4779 and 4707 because they have the same val= ue 1802 (from r1801). 4707 got the same value as 1801 because LRA sees wrong (REG_DEAD r1801:DF) = in insn 1804. In most cases LRA uses live-ranges but in constraint sub-pass it can use reg notes too. Live ranges and reg notes should be synchronized but in this case we did not update notes after first inheritance sub-pass although there were some changes there too. I working on a patch. If the tests are ok, I commit the patch today. >>From gcc-bugs-return-661837-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 15:08:23 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 31428 invoked by alias); 29 Nov 2019 15:08:23 -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 31377 invoked by uid 48); 29 Nov 2019 15:08:19 -0000 From: "rsandifo at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/92710] [9 Regression] Vectoriser generates invalid simd call for bool arguments Date: Fri, 29 Nov 2019 15:08: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: 10.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rsandifo at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rsandifo at gcc dot gnu.org X-Bugzilla-Target-Milestone: 9.3 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: short_desc 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: 2019-11/txt/msg03631.txt.bz2 Content-length: 632 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92710 rsandifo at gcc dot gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|[9/10 Regression] |[9 Regression] Vectoriser |Vectoriser generates |generates invalid simd call |invalid simd call for bool |for bool arguments |arguments | --- Comment #4 from rsandifo at gcc dot gnu.org --- Fixed on trunk so far. >>From gcc-bugs-return-661838-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 15:09:16 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 32726 invoked by alias); 29 Nov 2019 15:09:16 -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 32619 invoked by uid 48); 29 Nov 2019 15:09:12 -0000 From: "rsandifo at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/92596] [10 Regression] ICE in exact_div, at poly-int.h:2162 since r278406 Date: Fri, 29 Nov 2019 15:09: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: 10.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rsandifo at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: rsandifo at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution 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: 2019-11/txt/msg03632.txt.bz2 Content-length: 460 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92596 rsandifo at gcc dot gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #12 from rsandifo at gcc dot gnu.org --- Fixed. >>From gcc-bugs-return-661839-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 15:10:02 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 35315 invoked by alias); 29 Nov 2019 15:10:02 -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 35059 invoked by uid 48); 29 Nov 2019 15:09:58 -0000 From: "rsandifo at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/92677] [10 Regression] ICE in get_group_load_store_type, at tree-vect-stmts.c:2261 since r271704 Date: Fri, 29 Nov 2019 15:10: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: 10.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rsandifo at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: rsandifo at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution 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: 2019-11/txt/msg03633.txt.bz2 Content-length: 459 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92677 rsandifo at gcc dot gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #3 from rsandifo at gcc dot gnu.org --- Fixed. >>From gcc-bugs-return-661840-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 15:19:55 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 48823 invoked by alias); 29 Nov 2019 15:19:55 -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 48771 invoked by uid 48); 29 Nov 2019 15:19:51 -0000 From: "david at westcontrol dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/92727] Idea for better error messages Date: Fri, 29 Nov 2019 15:19: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: unknown X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: enhancement X-Bugzilla-Who: david at westcontrol 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: 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: 2019-11/txt/msg03634.txt.bz2 Content-length: 2674 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92727 --- Comment #3 from David Brown --- I may not have been very clear here. Let me try and take a step back here. >>From the user's viewpoint, the problem is that they have made a class that can't be copied, and they have written code that tries to copy it. With the current error messages, point comes across - but it is hidden amongst a lot= of messages about "allocators" that will be unfamiliar to many users, and unhelpful to most users. I fully appreciate the problem occurs when the allocator that tries to use = the copy constructor. But the user has not specified an allocator, or picked an allocator, or mentioned allocators in their code - and perhaps does not even know what they are. Most users are happy to accept "it goes in memory somewhere", or "it is on the heap", without worrying about the details. Wh= at I am hoping for here is some way to help the user get the part of the error information that is important to them, and will help them fix their code, without unnecessary detail. What I meant about default template parameters is that - as you say - some people /do/ want all the details of the messages about the allocator. These are mostly in two groups - people using non-default allocators, and people = who want to deal with the details of the standard library. The first group can= be identified by their use of explicit allocators in the template instantiation rather than using the defaults, and the second could perhaps use an additio= nal compiler switch (a little like the current "-Wsystem-headers" switch). So yes, I /am/ suggesting that the error location should be given as the "v.push_back(x);" line. And yes, I am aware that it would not be ideal for experts - but I think it would be clearer to a majority of users. And that would be novel! Part of the job of a compiler is to help people write corr= ect code, and clear error and warning messages are essential for that. (Let me also say that gcc does a fine job here, and has improved enormously over the years that I have used it - though it could still be better.) Perhaps this could be better handled using concepts? Maybe "push_back" cou= ld be declared to take a parameter with a concept requiring either a type that could be copied into the vector or a type that is a compatible rvalue reference? Or perhaps concepts and "if constexpr" in C++17 would make it practical to make the "push_back(const T&)" overload unavailable if T is not copyable? That would get you straight to a "no matching function call for std::vector::push_back(X&)" message on the offending line. >>From gcc-bugs-return-661841-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 15:43:00 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 111651 invoked by alias); 29 Nov 2019 15:43: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 111535 invoked by uid 48); 29 Nov 2019 15:42:56 -0000 From: "glisse at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/92712] [8/9/10 Regression] Performance regression with assumed values Date: Fri, 29 Nov 2019 15:43: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: 9.2.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: glisse at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: 8.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: 2019-11/txt/msg03635.txt.bz2 Content-length: 1029 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92712 --- Comment #11 from Marc Glisse --- (In reply to Jakub Jelinek from comment #10) > I know, it will be a small complication, sure, but it can be handled. Ah, I think I understand now. But still x=3D-1 a=3DINT_MAX a*x+x gives INT_MIN without overflow. Now a could be (int)((unsigned)b-1) where b is INT_MIN. But we don't want to generate b*x for that (INT_MIN*-1), since it overflows. So we would need to= do the multiplication in some unsigned type. If we go there (do everything unsigned), we could do the transformation always, and restricting it is jus= t a heuristic for when the signed type information might be more useful than the factorized form. > Using range info is certainly useful, but e.g. for this case with -1U it > will not be able to do anything, as the range of (int)(t-1U) will be > varying. So I think we want both. In this very particular case, it happens that we have if(t>0) dominating th= is stuff, which helps VRP. >>From gcc-bugs-return-661842-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 15:47:29 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 1950 invoked by alias); 29 Nov 2019 15:47: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 1930 invoked by uid 48); 29 Nov 2019 15:47:25 -0000 From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/92727] Idea for better error messages Date: Fri, 29 Nov 2019 15:47: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: unknown X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: enhancement X-Bugzilla-Who: redi 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: 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: 2019-11/txt/msg03636.txt.bz2 Content-length: 3039 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92727 --- Comment #4 from Jonathan Wakely --- (In reply to David Brown from comment #3) > Perhaps this could be better handled using concepts? Yes, ideally. That stops compilation as soon as you try to call something t= hat fails to satisfy the constraints (in this case, that the vector's value typ= e is constructible from the argument to push_back). > Maybe "push_back" > could be declared to take a parameter with a concept requiring either a t= ype > that could be copied into the vector or a type that is a compatible rvalue > reference? We can't change the parameter type of push_back, that would not be conformi= ng. > Or perhaps concepts and "if constexpr" in C++17 would make it > practical to make the "push_back(const T&)" overload unavailable if T is = not > copyable? That would get you straight to a "no matching function call for > std::vector::push_back(X&)" message on the offending line. if-constexpr can't help, that can only be used inside the function, by which point it's too late. I don't think concepts are really practical either, because we're limited w= here we can reasonably use them. std::vector has to be usable in C++98 still, and implementing the whole thing twice (with and without concepts in the API) w= ould be a maintenance nightmare. Also, altering the overload set as you suggest needs to be done *very* carefuly, or what happens is you end up removing one bad function and so a different function gets called instead. You need to consider the entire overload set at once. I think a much more maintainable approach is something like: --- a/libstdc++-v3/include/bits/stl_vector.h +++ b/libstdc++-v3/include/bits/stl_vector.h @@ -1183,6 +1183,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER void push_back(const value_type& __x) { +#if __cplusplus >=3D 201703L + if constexpr (is_same_v>) + static_assert(is_copy_constructible_v); +#endif if (this->_M_impl._M_finish !=3D this->_M_impl._M_end_of_storage) { _GLIBCXX_ASAN_ANNOTATE_GROW(1); With that change your example prints: In file included from /home/jwakely/gcc/10/include/c++/10.0.0/vector:67, from up.cc:1: /home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_vector.h: In instantiation= of 'void std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp =3D = X; _Alloc =3D std::allocator; std::vector<_Tp, _Alloc>::value_type =3D X]': up.cc:14:18: required from here /home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_vector.h:1188:18: error: static assertion failed 1188 | static_assert(is_copy_constructible_v); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I think trying to do this via "smart" diagnostics would be doomed to failur= e. Enforcing preconditions via static_assert is much more reliable, and easier= to tweak to improve it. Somebody just needs to add those assertions. >>From gcc-bugs-return-661843-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 15:55:31 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 12582 invoked by alias); 29 Nov 2019 15:55:30 -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 12540 invoked by uid 48); 29 Nov 2019 15:55:26 -0000 From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/92727] Idea for better error messages Date: Fri, 29 Nov 2019 15:55: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: unknown X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: enhancement X-Bugzilla-Who: redi 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: 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: 2019-11/txt/msg03637.txt.bz2 Content-length: 438 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92727 --- Comment #5 from Jonathan Wakely --- The downside of this (and your suggestion to remove push_back from the over= load set) is that you no longer get told the copy constructor is deleted and why. That note is only printed when the copy constructor is needed, but this approach means it never gets used, because the assertions stops it getting = that far. >>From gcc-bugs-return-661844-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 15:59:39 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 5974 invoked by alias); 29 Nov 2019 15:59:39 -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 5908 invoked by uid 48); 29 Nov 2019 15:59:35 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/92712] [8/9/10 Regression] Performance regression with assumed values Date: Fri, 29 Nov 2019 15:59: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: 9.2.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: 8.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: 2019-11/txt/msg03638.txt.bz2 Content-length: 1333 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92712 --- Comment #12 from Jakub Jelinek --- (In reply to Marc Glisse from comment #11) > (In reply to Jakub Jelinek from comment #10) > > I know, it will be a small complication, sure, but it can be handled. >=20 > Ah, I think I understand now. But still >=20 > x=3D-1 > a=3DINT_MAX > a*x+x gives INT_MIN without overflow. > Now a could be (int)((unsigned)b-1) where b is INT_MIN. But we don't want= to > generate b*x for that (INT_MIN*-1), since it overflows. So we would need = to > do the multiplication in some unsigned type. If we go there (do everything > unsigned), we could do the transformation always, and restricting it is j= ust > a heuristic for when the signed type information might be more useful than > the factorized form. The comments at least in fold-const.c say clearly that we do not want to perform unsigned multiplication. I was talking about the int a, b; ((int)(a-1U))*b+b transformation into a*b. Even for a=3D0, it is -1*b+b into 0, there could be UB before, but there is= none after. a=3DINT_MIN used to be INT_MAX*b+b and newly INT_MIN*b, well define= d for b=3D0, UB for b > 0, UB for b < -1, but it is true that INT_MAX*-1+-1 is we= ll defined INT_MIN, but INT_MIN*-1 is UB. So guess we need to use range info only then. >>From gcc-bugs-return-661845-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 16:10:14 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 21991 invoked by alias); 29 Nov 2019 16:10:12 -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 21890 invoked by uid 48); 29 Nov 2019 16:10:06 -0000 From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/92193] Poor diagnostics when a constexpr function call follows a failed static_assert Date: Fri, 29 Nov 2019 16:10: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: 10.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: redi 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: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on everconfirmed 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: 2019-11/txt/msg03639.txt.bz2 Content-length: 7048 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92193 Jonathan Wakely changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2019-11-29 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- This results in a far worse experience for users in C++20, where lots more things become constexpr. With the patch I suggested in Bug 92727 comment 4 the diagnostic in C++17 m= ode would be: In file included from /home/jwakely/gcc/10/include/c++/10.0.0/vector:67, from up.cc:1: /home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_vector.h: In instantiation= of 'void std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp =3D = X; _Alloc =3D std::allocator; std::vector<_Tp, _Alloc>::value_type =3D X]': up.cc:14:18: required from here /home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_vector.h:1188:18: error: static assertion failed 1188 | static_assert(is_copy_constructible_v); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ But compiling the exact same code with -std=3Dgnu++2a gives: In file included from /home/jwakely/gcc/10/include/c++/10.0.0/vector:67, from up.cc:1: /home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_vector.h: In instantiation= of 'void std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp =3D = X; _Alloc =3D std::allocator; std::vector<_Tp, _Alloc>::value_type =3D X]': up.cc:14:18: required from here /home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_vector.h:1188:18: error: static assertion failed 1188 | static_assert(is_copy_constructible_v); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from /home/jwakely/gcc/10/include/c++/10.0.0/ext/alloc_traits.h:34, from /home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_uninitialized.h:67, from /home/jwakely/gcc/10/include/c++/10.0.0/vector:66, from up.cc:1: /home/jwakely/gcc/10/include/c++/10.0.0/bits/alloc_traits.h: In instantiati= on of 'static constexpr void std::allocator_traits >::construct(std::allocator_traits >::allocator_type&, _Up*, _Args&& ...) [with _Up =3D X; _Args =3D {const X&}; _Tp =3D X; std::allocator_traits >::allocator_type =3D std::allocator]': /home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_vector.h:1193:30: requir= ed from 'void std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp= =3D X; _Alloc =3D std::allocator; std::vector<_Tp, _Alloc>::value_type =3D X= ]' up.cc:14:18: required from here /home/jwakely/gcc/10/include/c++/10.0.0/bits/alloc_traits.h:504:20: error: = use of deleted function 'X::X(const X&)' 504 | noexcept(noexcept(::new((void*)__p) _Up(std::declval<_Args>()...))) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ up.cc:6:7: note: 'X::X(const X&)' is implicitly deleted because the default definition would be ill-formed: 6 | class X { | ^ up.cc:6:7: error: use of deleted function 'std::unique_ptr<_Tp, _Dp>::unique_ptr(const std::unique_ptr<_Tp, _Dp>&) [with _Tp =3D Y; _Dp =3D std::default_delete]' In file included from /home/jwakely/gcc/10/include/c++/10.0.0/memory:82, from up.cc:2: /home/jwakely/gcc/10/include/c++/10.0.0/bits/unique_ptr.h:456:7: note: decl= ared here 456 | unique_ptr(const unique_ptr&) =3D delete; | ^~~~~~~~~~ In file included from /home/jwakely/gcc/10/include/c++/10.0.0/ext/alloc_traits.h:34, from /home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_uninitialized.h:67, from /home/jwakely/gcc/10/include/c++/10.0.0/vector:66, from up.cc:1: /home/jwakely/gcc/10/include/c++/10.0.0/bits/alloc_traits.h: In instantiati= on of 'static constexpr void std::allocator_traits >::construct(std::allocator_traits >::allocator_type&, _Up*, _Args&& ...) [with _Up =3D X; _Args =3D {const X&}; _Tp =3D X; std::allocator_traits >::allocator_type =3D std::allocator]': /home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_vector.h:1193:30: requir= ed from 'void std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp= =3D X; _Alloc =3D std::allocator; std::vector<_Tp, _Alloc>::value_type =3D X= ]' up.cc:14:18: required from here /home/jwakely/gcc/10/include/c++/10.0.0/bits/alloc_traits.h:509:21: error: = no matching function for call to 'construct_at(X*&, const X&)' 509 | std::construct_at(__p, std::forward<_Args>(__args)...); | ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from /home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_tempbuf.h:60, from /home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_algo.h:62, from /home/jwakely/gcc/10/include/c++/10.0.0/vector:62, from up.cc:1: /home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_construct.h:94:5: note: candidate: 'template constexpr decltype (::new(void*(0)) _Tp) std::construct_at(_Tp*, _Args&& ...)' 94 | construct_at(_Tp* __location, _Args&&... __args) | ^~~~~~~~~~~~ /home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_construct.h:94:5: note:=20= =20 template argument deduction/substitution failed: /home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_construct.h: In substituti= on of 'template constexpr decltype (::new(void*(0)) _Tp) std::construct_at(_Tp*, _Args&& ...) [with _Tp =3D X; _Args =3D {const= X&}]': /home/jwakely/gcc/10/include/c++/10.0.0/bits/alloc_traits.h:509:21: requi= red from 'static constexpr void std::allocator_traits >::construct(std::allocator_traits >::allocator_type&, _Up*, _Args&& ...) [with _Up =3D X; _Args =3D {const X&}; _Tp =3D X; std::allocator_traits >::allocator_type =3D std::allocator]' /home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_vector.h:1193:30: requir= ed from 'void std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp= =3D X; _Alloc =3D std::allocator; std::vector<_Tp, _Alloc>::value_type =3D X= ]' up.cc:14:18: required from here /home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_construct.h:96:17: error: = use of deleted function 'X::X(const X&)' 96 | -> decltype(::new((void*)0) _Tp(std::declval<_Args>()...)) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ That's because in C++20 some of the code following the static assertion involves a constexpr function, which calls another constexpr function, which calls another ... and all of them get evaluated and barf out their errors. = The whole point of the static_assert is to stop that happening. >>From gcc-bugs-return-661846-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 16:12:09 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 23522 invoked by alias); 29 Nov 2019 16:12:05 -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 23489 invoked by uid 48); 29 Nov 2019 16:12:02 -0000 From: "david at westcontrol dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/92727] Idea for better error messages Date: Fri, 29 Nov 2019 16:12: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: unknown X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: enhancement X-Bugzilla-Who: david at westcontrol 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: 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: 2019-11/txt/msg03640.txt.bz2 Content-length: 690 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92727 --- Comment #6 from David Brown --- I can see it is a challenge to get enough detail in the messages to be good= for the more advanced users, and still simple enough and clear enough for more casual or inexperienced users. The static assertion looks good to me, and is clearly the easiest way to implement such a feature. But I appreciate that it would not be ideal for = some people, and would hide useful messages from them. Perhaps the a better place to focus would be on IDE's, maybe especially with parsing of the new JSON format, to help people see exactly where the problem lies in their code. >>From gcc-bugs-return-661847-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 16:14:55 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 29113 invoked by alias); 29 Nov 2019 16:14:54 -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 29075 invoked by uid 48); 29 Nov 2019 16:14:50 -0000 From: "burnus at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/92730] New: [OpenMP] Common blocks in map() clause not accepted Date: Fri, 29 Nov 2019 16:14:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: openmp X-Bugzilla-Severity: normal X-Bugzilla-Who: burnus 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 keywords 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: 2019-11/txt/msg03641.txt.bz2 Content-length: 2080 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92730 Bug ID: 92730 Summary: [OpenMP] Common blocks in map() clause not accepted Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: openmp Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- See also PR 92728 and the thread at https://gcc.gnu.org/ml/gcc-patches/2019-11/threads.html#00717 Pre-remark, as remembered just now: "Named common blocks of the same name shall be of the same size in all scop= ing units of a program in which they appear, but blank common blocks may be of different sizes." (Fortran 2018, 8.10.2.5) =46rom the thread: > In OpenMP 5, common blocks appear twice =E2=80=93 once [2.1, p.39, ll.11f= f.] as=20 > general rule in the definition of "list item" (which are inherited by=20 > "extended list item" and "locator-list item"). [There are also some=20 > constraints and notes regarding common blocks)]. It does not really tell= =20 > whether blank commons are permitted or not; some description is=20 > explicitly for named-common variables, leaving blank-common ones out=20 > (and undefined). But later sections explicitly make reference to blank=20 > commons, hence, one can assume they are permitted unless explicitly=20 > stated that they are not. > > And then very selectively for some items: > * allocate =E2=80=93 only with default allocator. > * declare target =E2=80=93 some restrictions and no blank commons > * depend clause =E2=80=93 no common permitted > * threadprivate =E2=80=93 some notes and explanation of the syntax (why?) > also only here requirement regarding common blocks with bind(c) > (why not also for declare target?) > * linear clause =E2=80=93 no common permitted > * copyin =E2=80=93 some notes > * copyprivate =E2=80=93 some notes > > As target test cases were suspiciously left out, I tries '!$omp target=20 > map(/name/)' which was rejected. >>From gcc-bugs-return-661848-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 16:16:17 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 30919 invoked by alias); 29 Nov 2019 16: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 30861 invoked by uid 48); 29 Nov 2019 16:16:05 -0000 From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/92727] Idea for better error messages Date: Fri, 29 Nov 2019 16:16: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: unknown X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: enhancement X-Bugzilla-Who: redi 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: 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: 2019-11/txt/msg03642.txt.bz2 Content-length: 1386 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92727 --- Comment #7 from Jonathan Wakely --- (In reply to David Brown from comment #6) > I can see it is a challenge to get enough detail in the messages to be go= od > for the more advanced users, and still simple enough and clear enough for > more casual or inexperienced users. >=20 > The static assertion looks good to me, and is clearly the easiest way to > implement such a feature. But I appreciate that it would not be ideal for > some people, and would hide useful messages from them. I disagree. The static assert contains all you need to know, expert or not.= The benefit of seeing all the gory details is to figure out why something didn't compile, and what (possibly implicit) requirement your code failed to meet.= If the maintainer of the library explicitly spelled out that requirement with a static_assert, then there's no need to see any more detail, because there's= no need to infer the requirement from the code. Unfortunately that nice diagnostic from the static_assert turns into a total mess in C++20 mode, see Bug 92193 comment 2. My preference for this bug would be to reassign it to libstdc++ and hope th= at people pick up the baton and submit patches to add static_assert in places where it improves the user experience. That can be done piecemeal, and impr= oved over time. >>From gcc-bugs-return-661849-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 16:20:05 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 33735 invoked by alias); 29 Nov 2019 16:20:05 -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 33625 invoked by uid 48); 29 Nov 2019 16:20:00 -0000 From: "burnus at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/92728] [OpenMP][OpenACC] Common-block name clause matching issues: common block needs to be defined before + blank common not supported Date: Fri, 29 Nov 2019 16:20:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: openacc, openmp X-Bugzilla-Severity: normal X-Bugzilla-Who: burnus 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: 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: 2019-11/txt/msg03643.txt.bz2 Content-length: 961 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92728 --- Comment #1 from Tobias Burnus --- See also PR 92730 for a related issue (OpenMP's map() does not handle /comm= on/) Remark, as I only just remembered: "Named common blocks of the same name shall be of the same size in all scop= ing units of a program in which they appear, but blank common blocks may be of different sizes." (Fortran 2018, 8.10.2.5) If the common block is only on the host =E2=80=93 and uses map(/block/), ma= pping single variables is fine. If it is only on the device, it is also fine =E2=80=93 i= t only becomes interesting if the same-named common block is on both device and ho= st. In this case, they have to be named (=3D same size) and a copy(/map/) should really copy the whole block and not only the (directly) used common-block variables. For OpenACC, device_resident seems to be about this feature, OpenMP seems t= o be silent on this topic. >>From gcc-bugs-return-661850-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 16:34:27 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 60225 invoked by alias); 29 Nov 2019 16:34:26 -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 60192 invoked by uid 48); 29 Nov 2019 16:34:22 -0000 From: "david at westcontrol dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/92727] Idea for better error messages Date: Fri, 29 Nov 2019 16:34: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: unknown X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: enhancement X-Bugzilla-Who: david at westcontrol 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: 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: 2019-11/txt/msg03644.txt.bz2 Content-length: 212 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92727 --- Comment #8 from David Brown --- I don't think there is anything more I can add at the moment. Thank you for your efforts. >>From gcc-bugs-return-661851-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 16:42:36 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 115836 invoked by alias); 29 Nov 2019 16:42:36 -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 115722 invoked by uid 48); 29 Nov 2019 16:42:30 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/92712] [8/9/10 Regression] Performance regression with assumed values Date: Fri, 29 Nov 2019 16:42: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: 9.2.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: 8.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: 2019-11/txt/msg03645.txt.bz2 Content-length: 1166 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92712 --- Comment #13 from Jakub Jelinek --- Ok, so match.pd does the following transformations: A*B+A -> (B+1)*A A*B-A -> (B-1)*A A-A*B -> (1-B)*A A*B+A*C -> (B+C)*A A*B-A*C -> (B-C)*A (ignoring equivalent expressions with commutative + or *). Let's consider for start just the simpler 3 cases. For those, I believe the only cases where these introduce UB when it wasn't before in two's complement world are: A*B+A -> (B+1)*A with A=3D=3D-1 && B=3D=3Dmax A*B+A -> (B+1)*A with A=3D=3D0 && B=3D=3Dmax A*B-A -> (B-1)*A with A=3D=3D0 && B=3D=3Dmin A-A*B -> (1-B)*A with A=3D=3D-1 && B=3D=3D-max A-A*B -> (1-B)*A with A=3D=3D0 && B=3D=3Dmin A-A*B -> (1-B)*A with A=3D=3D0 && B=3D=3D-max Now, the current match.pd patterns disable this optimization if A might be = 0 or -1. So, what we could do is: 1) for the A*B-A case, drop the must not be -1 che= ck 2) add the checks for the ranges of the other operand, say for the first on= e it is fine if we don't know anything about A (@0) if we know the B (@1) is not maximum. For the last 2, the question is if we can come up with something similar. >>From gcc-bugs-return-661852-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 16:47:06 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 125944 invoked by alias); 29 Nov 2019 16:47:05 -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 125889 invoked by uid 48); 29 Nov 2019 16:47:01 -0000 From: "glisse at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/92727] Idea for better error messages Date: Fri, 29 Nov 2019 16:47: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: unknown X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: enhancement X-Bugzilla-Who: glisse 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: 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: 2019-11/txt/msg03646.txt.bz2 Content-length: 842 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92727 --- Comment #9 from Marc Glisse --- (In reply to Jonathan Wakely from comment #7) > I disagree. The static assert contains all you need to know, expert or no= t. > The benefit of seeing all the gory details is to figure out why something > didn't compile, and what (possibly implicit) requirement your code failed= to > meet. If the maintainer of the library explicitly spelled out that > requirement with a static_assert, then there's no need to see any more > detail, because there's no need to infer the requirement from the code. Uh? Here, we would get an error message saying only that X is not copy-constructible. Sure, that's important to know. But it is helpful if the compiler can point out why it isn't copy-constructible, which it currently does. >>From gcc-bugs-return-661853-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 16:59:58 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 22221 invoked by alias); 29 Nov 2019 16:59: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 22143 invoked by uid 55); 29 Nov 2019 16:59:54 -0000 From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/92712] [8/9/10 Regression] Performance regression with assumed values Date: Fri, 29 Nov 2019 16:59: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: 9.2.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenther at suse dot de X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: 8.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: 2019-11/txt/msg03647.txt.bz2 Content-length: 1792 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92712 --- Comment #14 from rguenther at suse dot de --- On November 29, 2019 4:59:35 PM GMT+01:00, "jakub at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92712 > >--- Comment #12 from Jakub Jelinek --- >(In reply to Marc Glisse from comment #11) >> (In reply to Jakub Jelinek from comment #10) >> > I know, it will be a small complication, sure, but it can be >handled. >>=20 >> Ah, I think I understand now. But still >>=20 >> x=3D-1 >> a=3DINT_MAX >> a*x+x gives INT_MIN without overflow. >> Now a could be (int)((unsigned)b-1) where b is INT_MIN. But we don't >want to >> generate b*x for that (INT_MIN*-1), since it overflows. So we would >need to >> do the multiplication in some unsigned type. If we go there (do >everything >> unsigned), we could do the transformation always, and restricting it >is just >> a heuristic for when the signed type information might be more useful >than >> the factorized form. > >The comments at least in fold-const.c say clearly that we do not want >to >perform unsigned multiplication. Yeah, doing so early regresses things too much. Doing it late with wrapv wa= s my idea a while back. I've arranged it to be before the last reassoc pass but moved(?) the last VRP before that.=20 >I was talking about the int a, b; >((int)(a-1U))*b+b >transformation into a*b. >Even for a=3D0, it is -1*b+b into 0, there could be UB before, but there >is none >after. a=3DINT_MIN used to be INT_MAX*b+b and newly INT_MIN*b, well >defined for >b=3D0, UB for b > 0, UB for b < -1, but it is true that INT_MAX*-1+-1 is >well >defined INT_MIN, but INT_MIN*-1 is UB. >So guess we need to use range info only then. >>From gcc-bugs-return-661854-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 17:12:01 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 38413 invoked by alias); 29 Nov 2019 17:12: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 38355 invoked by uid 48); 29 Nov 2019 17:11:57 -0000 From: "rrrlasse at hotmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/92731] New: Data race on exception object thrown from std::future Date: Fri, 29 Nov 2019 17:12: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: 8.3.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rrrlasse at hotmail 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 attachments.created 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: 2019-11/txt/msg03648.txt.bz2 Content-length: 2607 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92731 Bug ID: 92731 Summary: Data race on exception object thrown from std::future Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: rrrlasse at hotmail dot com Target Milestone: --- Created attachment 47397 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D47397&action=3Dedit TSan output and .ii file The source is compiled with:=20 g++ cpp.cpp -lpthread -fsanitize=3Dthread -Wall -Wextra After running for around 100 - 500 iteration in the for-loop of the main thread, TSan reports a data race between the destructor of the exception ob= ject and the strlen() loop. If you omit the std::move(packaged_task) the warning disappears. uname -a: Linux ubuntu 5.0.0-29-generic #31-Ubuntu SMP Thu Sep 12 13:05:32 = UTC 2019 x86_64 x86_64 x86_64 GNU/Linux g++ --version: g++ (Ubuntu 8.3.0-6ubuntu1) 8.3.0 Since you can apparently only add a single attachment, I've colledted the .= ii file and tsan report in a zip file. Source code: #include #include #include #include #include #include std::condition_variable cv; std::mutex mu; std::function job; bool has_job =3D false; void looper() { for (;;) { std::unique_lock ul(mu); while (!has_job) { cv.wait(ul); } has_job =3D false; job(); } } // g++ cpp.cpp -lpthread -fsanitize=3Dthread -Wall -Wextra int main() { std::thread t =3D std::thread(looper); for (int c =3D 0; ; c++) { try { std::packaged_task packaged_task([]() { throw std::runtime_error("aaaaaaaaaaaaaaaaa"); }); std::future task_future =3D packaged_task.get_future(); { std::unique_lock ul(mu); job =3D [&]() { #if 1 // tsan warning std::packaged_task tmp(std::move(packaged_task= )); tmp(); #else // no warning packaged_task(); #endif }; has_job =3D true; cv.notify_one(); } task_future.get(); } catch (const std::runtime_error& e) { for (int i =3D 0; i < 10; i++) { [[maybe_unused]] int a =3D strlen(e.what()); } } } } >>From gcc-bugs-return-661855-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 17:22:26 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 64133 invoked by alias); 29 Nov 2019 17:22:26 -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 63998 invoked by uid 48); 29 Nov 2019 17:22:20 -0000 From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/92727] Idea for better error messages Date: Fri, 29 Nov 2019 17:22: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: unknown X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: enhancement X-Bugzilla-Who: redi 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: 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: 2019-11/txt/msg03649.txt.bz2 Content-length: 689 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92727 --- Comment #10 from Jonathan Wakely --- For this specific call, yes. For the general case of "arguments do not meet= the function's requirements" there are no such notes from the compiler. For example, v.emplace_back("blah") won't tell you anything more than that = you can't construct an X from "blah". The bug in this example is that the push_back call needs to make a copy and= the type is not copyable. It's not a bug that the copy constructor is implictly deleted. Knowing that the copy constructor is implicitly deleted and why, doesn't actually help you figure out that you need to use std::move. >>From gcc-bugs-return-661856-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 17:23:07 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 70710 invoked by alias); 29 Nov 2019 17:23:07 -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 68629 invoked by uid 55); 29 Nov 2019 17:23:01 -0000 From: "wilco at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug driver/89014] Use-after-free in aarch64 -march=native Date: Fri, 29 Nov 2019 17:23:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: driver X-Bugzilla-Version: 9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: wilco at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: dmalcolm 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: 2019-11/txt/msg03650.txt.bz2 Content-length: 1407 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D89014 --- Comment #9 from Wilco --- Author: wilco Date: Fri Nov 29 17:22:30 2019 New Revision: 278854 URL: https://gcc.gnu.org/viewcvs?rev=3D278854&root=3Dgcc&view=3Drev Log: aarch64: fix use-after-free in -march=3Dnative (PR driver/89014) Running: $ valgrind ./xgcc -B. -c test.c -march=3Dnative on aarch64 shows a use-after-free in host_detect_local_cpu due to the std::string result of aarch64_get_extension_string_for_isa_flags only living until immediately after a c_str call. This leads to corrupt "-march=3D" values being passed to cc1. This patch fixes the use-after-free, though it appears to also need Tamar's patch here: https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01302.html in order to generate valid values for cc1. This may have worked by accident in the past, if the corrupt "-march=3D" value happened to be 0-terminated in the "right" place; with this patch it now appears to reliably break without Tamar's patch. Backport from mainline 2019-01-23 David Malcolm PR driver/89014 * config/aarch64/driver-aarch64.c (host_detect_local_cpu): Fix use-after-free of the result of aarch64_get_extension_string_for_isa_flags. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/aarch64/driver-aarch64.c >>From gcc-bugs-return-661857-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 17:25:15 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 75218 invoked by alias); 29 Nov 2019 17:25: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 75188 invoked by uid 48); 29 Nov 2019 17:25:11 -0000 From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/92731] Data race on exception object thrown from std::future Date: Fri, 29 Nov 2019 17:25: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: 8.3.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: redi 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: 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: 2019-11/txt/msg03651.txt.bz2 Content-length: 191 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92731 --- Comment #1 from Jonathan Wakely --- (You can add as many attachments as you like, but only one at a time.) >>From gcc-bugs-return-661858-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 17:43:12 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 115125 invoked by alias); 29 Nov 2019 17:43:12 -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 115058 invoked by uid 48); 29 Nov 2019 17:43:08 -0000 From: "klaus.doldinger64 at googlemail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/92732] New: Bit-field with std::byte as member type cannot be initialized Date: Fri, 29 Nov 2019 17:43: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: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: klaus.doldinger64 at googlemail 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: 2019-11/txt/msg03652.txt.bz2 Content-length: 1015 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92732 Bug ID: 92732 Summary: Bit-field with std::byte as member type cannot be initialized Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: klaus.doldinger64 at googlemail dot com Target Milestone: --- Since C++20 bit-field initializer are possible.=20 There seems to be a bug with std::byte an bit-fields. struct Test { std::byte a : 2 =3D std::byte{0}; // NOK uint8_t b : 2 =3D 0; // OK }; Compiling this with g++ (GCC) 10.0.0 20191128 (experimental) yields: test93.cc:20:28: error: cannot convert 'std::byte' to 'unsigned char:2' in initialization 20 | std::byte a : 2 =3D std::byte{0}; // NOK | ^~~~~~~ | | | std::byte >>From gcc-bugs-return-661859-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 18:04:42 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 22499 invoked by alias); 29 Nov 2019 18:04:42 -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 22336 invoked by uid 48); 29 Nov 2019 18:04:37 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/92712] [8/9/10 Regression] Performance regression with assumed values Date: Fri, 29 Nov 2019 18:04: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: 9.2.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: 8.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: 2019-11/txt/msg03653.txt.bz2 Content-length: 897 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92712 --- Comment #15 from Jakub Jelinek --- For A*B+A*C -> (B+C)*A the problematic cases are A=3D=3D-1 and B > 0 and C=3D=3D(max-B)+1 (i.e. when B+C overflows to min) or A=3D=3D0 and B < 0 and C 0 and C>max-B (last two cases cover when B+C overflows) For A*B-A*C -> (B-C)*A the problematic cases are A=3D=3D-1 and B > 0 and C=3D=3Dmin+B (i.e. when B-C is min) or A=3D=3D0 and B < -1 and C>B-min or A=3D=3D0 and B >=3D 0 and C>From gcc-bugs-return-661860-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 18:11:25 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 28719 invoked by alias); 29 Nov 2019 18:11:25 -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 28660 invoked by uid 48); 29 Nov 2019 18:11:21 -0000 From: "glisse at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/92727] Idea for better error messages Date: Fri, 29 Nov 2019 18:11: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: unknown X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: enhancement X-Bugzilla-Who: glisse 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: 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: 2019-11/txt/msg03654.txt.bz2 Content-length: 1343 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92727 --- Comment #11 from Marc Glisse --- (In reply to Jonathan Wakely from comment #10) > The bug in this example is that the push_back call needs to make a copy a= nd > the type is not copyable. It's not a bug that the copy constructor is > implictly deleted. Knowing that the copy constructor is implicitly deleted > and why, doesn't actually help you figure out that you need to use std::m= ove. Indeed, there are 2 cases where you get the error: - the type is meant to be move-only and you forgot to call std::move - the type is meant to be copyable, but you did something that results in a non-copyable type In the first case, the static assertion is good and to the point. It could = even check if the type is move constructible and suggest using std::move in its message. In the second case, I'd love to know what I did wrong, and the extra information is more than welcome. As someone who is used to deciphering compiler messages, I tend to prefer having too much, in case it might be useful, rather than too little. Anyway= , I am talking about verbosity in general, not specifically for this case, maybe for this case the details are less important, I didn't think too hard about= it, and I am not preventing anyone from introducing the static_assert. >>From gcc-bugs-return-661861-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 18:28:05 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 100436 invoked by alias); 29 Nov 2019 18:28:05 -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 100294 invoked by uid 48); 29 Nov 2019 18:28:00 -0000 From: "glisse at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/92712] [8/9/10 Regression] Performance regression with assumed values Date: Fri, 29 Nov 2019 18:28: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: 9.2.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: glisse at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: 8.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: 2019-11/txt/msg03655.txt.bz2 Content-length: 598 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92712 --- Comment #16 from Marc Glisse --- (In reply to Jakub Jelinek from comment #15) > I guess we could handle those cases by using something like > check_for_binary_op_overflow, except that for the case where A might be -1 > and plusminus equal to MINUS_EXPR we also need to make sure the result of > B-C is known not to be min. You may not need to worry about the multiplication overflowing. If a*b+a*c = and b+c are computed with an undefined overflow type and do not overflow, then a*(b+c) cannot overflow either. >>From gcc-bugs-return-661862-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 18:35:36 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 113309 invoked by alias); 29 Nov 2019 18:35:36 -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 113270 invoked by uid 48); 29 Nov 2019 18:35:32 -0000 From: "rrrlasse at hotmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/92731] Data race on exception object thrown from std::future Date: Fri, 29 Nov 2019 18:35: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: 8.3.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rrrlasse at hotmail 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: 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: 2019-11/txt/msg03656.txt.bz2 Content-length: 529 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92731 --- Comment #2 from Lasse Reinhold --- As far as I remember I could only add a single file when I created the bug report, and the option to add more showed up after completion. Anyway, the c++ code isn't very idiomatic, but I can't see why it would be illegal to let the child thread do a dummy-move (through the lambda referen= ce capture), compared to doing a move in the main thread. An everything is ful= ly synchronized through mutexes... >>From gcc-bugs-return-661863-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 18:36:11 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 115170 invoked by alias); 29 Nov 2019 18:36:11 -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 115097 invoked by uid 48); 29 Nov 2019 18:36:07 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/92712] [8/9/10 Regression] Performance regression with assumed values Date: Fri, 29 Nov 2019 18:36: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: 9.2.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: 8.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: 2019-11/txt/msg03657.txt.bz2 Content-length: 3142 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92712 --- Comment #17 from Jakub Jelinek --- Untested patch: --- gcc/match.pd.jj 2019-11-05 14:59:22.546873967 +0100 +++ gcc/match.pd 2019-11-29 18:17:27.472002727 +0100 @@ -2480,18 +2480,42 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) (plusminus @0 (mult:c@3 @0 @2)) (if ((!ANY_INTEGRAL_TYPE_P (type) || TYPE_OVERFLOW_WRAPS (type) + /* For @0 + @0*@2 this transformation would introduce UB + (where there was none before) for @0 in [-1,0] and @2 max. + For @0 - @0*@2 this transformation would introduce UB + for @0 0 and @2 in [min,min+1] or @0 -1 and @2 min+1. */ || (INTEGRAL_TYPE_P (type) - && tree_expr_nonzero_p (@0) - && expr_not_equal_to (@0, wi::minus_one (TYPE_PRECISION (type))))) + && ((tree_expr_nonzero_p (@0) + && expr_not_equal_to (@0, + wi::minus_one (TYPE_PRECISION (type)))) + || (plusminus =3D=3D PLUS_EXPR + ? expr_not_equal_to (@2, + wi::max_value (TYPE_PRECISION (type), SIGNED)) + /* Let's ignore the @0 -1 and @2 min case. */ + : (expr_not_equal_to (@2, + wi::min_value (TYPE_PRECISION (type), SIGNED)) + && expr_not_equal_to (@2, + wi::min_value (TYPE_PRECISION (type), SIGNE= D) + + 1)))))) && single_use (@3)) (mult (plusminus { build_one_cst (type); } @2) @0))) (simplify (plusminus (mult:c@3 @0 @2) @0) (if ((!ANY_INTEGRAL_TYPE_P (type) || TYPE_OVERFLOW_WRAPS (type) + /* For @0*@2 + @0 this transformation would introduce UB + (where there was none before) for @0 in [-1,0] and @2 max. + For @0*@2 - @0 this transformation would introduce UB + for @0 0 and @2 min. */ || (INTEGRAL_TYPE_P (type) - && tree_expr_nonzero_p (@0) - && expr_not_equal_to (@0, wi::minus_one (TYPE_PRECISION (type))))) + && ((tree_expr_nonzero_p (@0) + && (plusminus =3D=3D MINUS_EXPR + || expr_not_equal_to (@0, + wi::minus_one (TYPE_PRECISION (type))))) + || expr_not_equal_to (@2, + (plusminus =3D=3D PLUS_EXPR + ? wi::max_value (TYPE_PRECISION (type), SIGNED) + : wi::min_value (TYPE_PRECISION (type), SIGNED))))= )) && single_use (@3)) (mult (plusminus @2 { build_one_cst (type); }) @0)))))) This doesn't try to do anything about the A*B+A*C cases. Fixes the #c0 testcase and shows I've screwed up my simplified testcases, the case that is fixed with this patch is e.g. int foo (int t, int v) { int a =3D t - 1; int b =3D a * v; return b + v; } where we don't know anything about v (VARYING), but from a =3D t - 1 we kno= w it is not INT_MAX and can use that in the optimization. >>From gcc-bugs-return-661864-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 18:42:37 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 28184 invoked by alias); 29 Nov 2019 18:42:36 -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 21813 invoked by uid 48); 29 Nov 2019 18:42:32 -0000 From: "msebor at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug bootstrap/92733] New: linker errors for missing std::__alloc_on_move with a cross-compiler Date: Fri, 29 Nov 2019 18:42:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: bootstrap X-Bugzilla-Version: 10.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: 2019-11/txt/msg03658.txt.bz2 Content-length: 4292 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92733 Bug ID: 92733 Summary: linker errors for missing std::__alloc_on_move with a cross-compiler Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- Building a cross-compiler (for all targets I've tried) fails with linker er= rors like those below: /build/gcc-svn/gcc/xg++ -B /build/gcc-svn/gcc -nostdinc++ -I /build/gcc-svn/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu= -I /build/gcc-svn/x86_64-pc-linux-gnu/libstdc++-v3/include -I /src/gcc/svn/libstdc++-v3/libsupc++ -I /src/gcc/svn/libstdc++-v3/include/backward -L /build/gcc-svn/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -no-pie -O0 -g3 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=3Dformat-diag -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o cc1 c/c-lang.o c-family/stub-objc.o attribs.o c/c-errors= .o c/c-decl.o c/c-typeck.o c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o c/c-fold.o c/gimple-parser.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-indentation.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o c-family/c-ubsan.o c-family/known-headers.o c-family/c-attribs.o c-family/c-warn.o c-family/c-spellcheck.o glibc-c.o rs6000-c.o \ cc1-checksum.o libbackend.a main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a=20 -L/ssd/build/powerpc64le-linux/gcc-svn/./isl/.libs -lisl -L/ssd/build/powerpc64le-linux/gcc-svn/./gmp/.libs -L/ssd/build/powerpc64le-linux/gcc-svn/./mpfr/src/.libs -L/ssd/build/powerpc64le-linux/gcc-svn/./mpc/src/.libs -lmpc -lmpfr -lgmp -rdynamic -ldl -L./../zlib -lz=20 /usr/bin/ld: /build/gcc-svn/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(strin= g-inst.o): in function `std::__cxx11::basic_string, std::allocator >::operator=3D(std::__cxx11::basic_string, std::allocator >&&)': /ssd/build/gcc-svn/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_stri= ng.h:716: undefined reference to `void std::__alloc_on_move >(std::allocator&, std::allocator&)' /usr/bin/ld: /build/gcc-svn/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(strin= g-inst.o): in function `std::__cxx11::basic_string, std::allocator >::assign(std::__cxx11::basic_string, std::allocator > const&)': /ssd/build/gcc-svn/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_stri= ng.h:1363: undefined reference to `void std::__alloc_on_copy >(std::allocator&, std::allocator const&)' /usr/bin/ld: /build/gcc-svn/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(strin= g-inst.o): in function `__gnu_cxx::__alloc_traits, char>::_S_on_swap(std::allocator&, std::allocator&)': /ssd/build/gcc-svn/x86_64-pc-linux-gnu/libstdc++-v3/include/ext/alloc_trait= s.h:101: undefined reference to `void std::__alloc_on_swap >(std::allocator&, std::allocator&)' collect2: error: ld returned 1 exit status make[2]: *** [/src/gcc/svn/gcc/c/Make-lang.in:85: cc1] Error 1 make[2]: Leaving directory '/ssd/build/powerpc64le-linux/gcc-svn/gcc' make[1]: *** [Makefile:4370: all-gcc] Error 2 make[1]: Leaving directory '/ssd/build/powerpc64le-linux/gcc-svn' make: *** [Makefile:966: all] Error 2 make: Leaving directory '/ssd/build/powerpc64le-linux/gcc-svn' Command exited with non-zero status 2 >>From gcc-bugs-return-661865-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 18:43:55 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 38245 invoked by alias); 29 Nov 2019 18:43:55 -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 38187 invoked by uid 48); 29 Nov 2019 18:43:51 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/92712] [8/9/10 Regression] Performance regression with assumed values Date: Fri, 29 Nov 2019 18:43: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: 9.2.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: 8.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: 2019-11/txt/msg03659.txt.bz2 Content-length: 916 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92712 --- Comment #18 from Jakub Jelinek --- (In reply to Marc Glisse from comment #16) > (In reply to Jakub Jelinek from comment #15) > > I guess we could handle those cases by using something like > > check_for_binary_op_overflow, except that for the case where A might be= -1 > > and plusminus equal to MINUS_EXPR we also need to make sure the result = of > > B-C is known not to be min. >=20 > You may not need to worry about the multiplication overflowing. If a*b+a*c > and b+c are computed with an undefined overflow type and do not overflow, > then a*(b+c) cannot overflow either. Yes, see above, for a*b+-a*c the only cases where UB would be introduced is when b+-c overflows (but a subset of that, if we knew that a is not 0, we c= ould do better, as then all we care about is that (unsigned)(b+-c) didn't overfl= ow to INT_MIN). >>From gcc-bugs-return-661866-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 18:46:18 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 42323 invoked by alias); 29 Nov 2019 18:46: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 42189 invoked by uid 48); 29 Nov 2019 18:46:14 -0000 From: "msebor at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/92683] [10 Regression] strncmp incorrect result with equal substrings and non-const bound Date: Fri, 29 Nov 2019 18:46: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: 10.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: msebor at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: msebor at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution 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: 2019-11/txt/msg03660.txt.bz2 Content-length: 708 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92683 Martin Sebor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Sebor --- Unless the problem in comment #0 persists on the targets please open new bu= gs for these kinds of target-specific regressions in the test suite. I can't build cross-compilers at the moment because of pr92733 so I can't easily ve= rify this but the test failure seems like a separate issue. >>From gcc-bugs-return-661867-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 18:46:18 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 42326 invoked by alias); 29 Nov 2019 18:46: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 42201 invoked by uid 48); 29 Nov 2019 18:46:14 -0000 From: "msebor at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/83819] [meta-bug] missing strlen optimizations Date: Fri, 29 Nov 2019 18:46:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: dep_changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 8.0 X-Bugzilla-Keywords: meta-bug, missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: msebor 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: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution 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: 2019-11/txt/msg03661.txt.bz2 Content-length: 510 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D83819 Bug 83819 depends on bug 92683, which changed state. Bug 92683 Summary: [10 Regression] strncmp incorrect result with equal subs= trings and non-const bound https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92683 What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED >>From gcc-bugs-return-661868-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 18:47:16 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 45537 invoked by alias); 29 Nov 2019 18:47:16 -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 45355 invoked by uid 48); 29 Nov 2019 18:47:12 -0000 From: "pinskia at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug bootstrap/92733] linker errors for missing std::__alloc_on_move with a cross-compiler Date: Fri, 29 Nov 2019 18:47:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: bootstrap X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: pinskia 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: 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: 2019-11/txt/msg03662.txt.bz2 Content-length: 253 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92733 --- Comment #1 from Andrew Pinski --- This error message does not make sense. Xgcc/xg++ should not be used to link cc1. For a cross. Can you provide how you configured? >>From gcc-bugs-return-661869-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 18:52:50 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 53995 invoked by alias); 29 Nov 2019 18:52:50 -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 53911 invoked by uid 48); 29 Nov 2019 18:52:46 -0000 From: "Theodore.Papadopoulo at inria dot fr" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/92727] Idea for better error messages Date: Fri, 29 Nov 2019 18:52: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: unknown X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: enhancement X-Bugzilla-Who: Theodore.Papadopoulo at inria dot fr 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: 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: 2019-11/txt/msg03663.txt.bz2 Content-length: 2418 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92727 Theodore.Papadopoulo at inria dot fr changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Theodore.Papadopoulo@inria. | |fr --- Comment #12 from Theodore.Papadopoulo at inria dot fr --- Sorry if this is message slightly diverges from the technical aspects... While I'm used to parse the g++ messages, I must agree that sometimes it is= too much and not straight to the point... There has to be a way to make message= s a little more readable. For one thing even finding the boundaries between two messages is not always visually trivial. It might not be very difficult (with colors or blank line= s or ...) to make this much easier to parse. I must also say that in extreme cases (like eg some boost spirit stuff or m= ore generally some meta-template code), the error stack is huge and I have appreciated what they do in boost spirit: In the code there is a comment th= at states "if you have an error at the next line, this usually means you have = done that mistake". Long before I was aware of static_assert, I considered implementing some ki= nd of pragma to achieve these high level messages, because this helps a lot. T= he static_assert solution evoked above might be a way to implement this without relying to extensions, which is nice... The only thing I regret slightly is= the verbiage related to the static_assert, which for me is an implementation de= tail (of the way the error was generated). I understand very well that's the way static_assert is supposed to work, but I would prefer a more normally looki= ng message, or maybe some visually easy to identify "hint" that would be provi= ded in addition to errors messages and that can help the developer at least in = the trivial cases... I think that the quality of the error messages is very important for a comp= iler and understand that this is a very difficult topic. I also know that very important improvements were made these last two years, and I take the opportunity to thank all those involved in that work. Yet we should never forget that error messages must have two qualities: - Allow to identify the cause of a problem (completeness). - Allow to do so as quickly as possible (efficiency). >>From gcc-bugs-return-661870-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 18:56:26 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 58962 invoked by alias); 29 Nov 2019 18:56:25 -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 58877 invoked by uid 48); 29 Nov 2019 18:56:21 -0000 From: "msebor at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug bootstrap/92733] linker errors for missing std::__alloc_on_move with a cross-compiler Date: Fri, 29 Nov 2019 18:56:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: bootstrap X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: msebor at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: INVALID 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_status resolution 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: 2019-11/txt/msg03664.txt.bz2 Content-length: 500 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92733 Martin Sebor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Martin Sebor --- Thanks for the hint! It was indeed caused by a problem with my configure script. >>From gcc-bugs-return-661871-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 19:03:55 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 69963 invoked by alias); 29 Nov 2019 19:03:54 -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 69849 invoked by uid 48); 29 Nov 2019 19:03:49 -0000 From: "msebor at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/92683] [10 Regression] strncmp incorrect result with equal substrings and non-const bound Date: Fri, 29 Nov 2019 19:03: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: 10.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: msebor at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: msebor at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.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: 2019-11/txt/msg03665.txt.bz2 Content-length: 2862 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92683 --- Comment #5 from Martin Sebor --- With pr92733 resolved I can verify that the test case from comment #0 is compiled correctly by the sparc-sun-solaris2.11 cross: $ cat pr92683.c && /build/sparc-sun-solaris2.11/gcc-svn/gcc/xgcc -B /build/sparc-sun-solaris2.11/gcc-svn/gcc -O1 -S -Wall -Wextra -fdump-tree-forwprop1=3D/dev/stdout pr92683.c int f (void) { return __builtin_strncmp ("123", "1234", 3); // correctly folded to zero } int g (void) { int n =3D 3; return __builtin_strncmp ("123", "1234", n); // incorrectly folded to -1 } ;; Function f (f, funcdef_no=3D0, decl_uid=3D1482, cgraph_uid=3D1, symbol_o= rder=3D0) f () { : return 0; } ;; Function g (g, funcdef_no=3D1, decl_uid=3D1485, cgraph_uid=3D2, symbol_o= rder=3D1) g () { int n; : return 0; } The gcc.dg/strcmpopt_8.c test also passes for me when compiled with the sparc-sun-solaris2.11 cross: $ nice make -C /build/sparc-sun-solaris2.11/gcc-svn/gcc check-c 'CFLAGS=3D= -O0 -g3' 'CXXFLAGS=3D-O0 -g3' 'STAGE1_CFLAGS=3D-O0 -g3' 'STAGE1_CXXFLAGS=3D-O0 = -g3' RUNTESTFLAGS=3D"dg.exp=3Dgcc.dg/strcmpopt_8.c" make: Entering directory '/ssd/build/sparc-sun-solaris2.11/gcc-svn/gcc' ... Test run by msebor on Fri Nov 29 11:59:25 2019 Target is sparc-sun-solaris2.11 Host is x86_64-pc-linux-gnu =3D=3D=3D gcc tests =3D=3D=3D Schedule of variations: unix Running target unix Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for targ= et. Using /src/gcc/svn/gcc/testsuite/config/default.exp as tool-and-target-spec= ific interface file. WARNING: Assuming target board is the local machine (which is probably wron= g). You may need to set your DEJAGNU environment variable. Running /src/gcc/svn/gcc/testsuite/gcc.dg/dg.exp ... =3D=3D=3D gcc Summary =3D=3D=3D # of expected passes 4 /ssd/build/sparc-sun-solaris2.11/gcc-svn/gcc/xgcc version 10.0.0 20191129 (experimental) (GCC)=20 make[1]: Leaving directory '/ssd/build/sparc-sun-solaris2.11/gcc-svn/gcc' make: Leaving directory '/ssd/build/sparc-sun-solaris2.11/gcc-svn/gcc' The output looks as expected: $ /build/sparc-sun-solaris2.11/gcc-svn/gcc/xgcc -B /build/sparc-sun-solaris2.11/gcc-svn/gcc -O1 -S -Wall -Wextra -fdump-tree-forwprop1=3D/dev/stdout /src/gcc/svn/gcc/testsuite/gcc.dg/strcmpopt_8.c ;; Function test_literal (test_literal, funcdef_no=3D0, decl_uid=3D1485, cgraph_uid=3D1, symbol_order=3D0) test_literal () { int zero; size_t max; : return; } ;; Function test_cst_array (test_cst_array, funcdef_no=3D1, decl_uid=3D1492, cgraph_uid=3D2, symbol_order=3D3) test_cst_array () { int zero; size_t max; : return; } >>From gcc-bugs-return-661872-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 19:10:53 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 80135 invoked by alias); 29 Nov 2019 19:10: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 80083 invoked by uid 48); 29 Nov 2019 19:10:48 -0000 From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/92732] Bit-field of scoped enumeration type cannot be initialized Date: Fri, 29 Nov 2019 19:10: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: 10.0 X-Bugzilla-Keywords: rejects-valid X-Bugzilla-Severity: normal X-Bugzilla-Who: redi 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: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords bug_status cf_reconfirmed_on short_desc everconfirmed 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: 2019-11/txt/msg03666.txt.bz2 Content-length: 1304 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92732 Jonathan Wakely changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed| |2019-11-29 Summary|Bit-field with std::byte as |Bit-field of scoped |member type cannot be |enumeration type cannot be |initialized |initialized Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- This is not a complete testcase, it's missing the relevant headers. I alrea= dy provided a reduced testcase on the mailing list (and explained that the pro= blem is not specific to std::byte). enum class byte : unsigned char { }; using uint8_t =3D unsigned char; struct Test { byte a : 2 =3D byte{0}; // NOK uint8_t b : 2 =3D 0; // OK }; bf.cc:6:18: error: cannot convert 'byte' to 'unsigned char:2' in initializa= tion 6 | byte a : 2 =3D byte{0}; // NOK | ^~~~~~~ | | | byte >>From gcc-bugs-return-661873-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 19:13:57 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 84958 invoked by alias); 29 Nov 2019 19:13: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 84887 invoked by uid 48); 29 Nov 2019 19:13:53 -0000 From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/92731] Data race on exception object thrown from std::future Date: Fri, 29 Nov 2019 19:13: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: 8.3.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: redi 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: 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: 2019-11/txt/msg03667.txt.bz2 Content-length: 476 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92731 --- Comment #3 from Jonathan Wakely --- (In reply to Lasse Reinhold from comment #2) > As far as I remember I could only add a single file when I created the bug > report, and the option to add more showed up after completion. As I said, you can only add one at a time. One on the original submission, = and then you can add another one, and submit that, and add another one, and sub= mit that. >>From gcc-bugs-return-661874-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 19:21:47 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 98749 invoked by alias); 29 Nov 2019 19:21:47 -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 98561 invoked by uid 48); 29 Nov 2019 19:21:43 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/92712] [8/9/10 Regression] Performance regression with assumed values Date: Fri, 29 Nov 2019 19: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: 9.2.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: 8.4 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: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2019-11/txt/msg03668.txt.bz2 Content-length: 262 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92712 --- Comment #19 from Jakub Jelinek --- Created attachment 47398 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D47398&action=3Dedit gcc10-pr92712.patch Full untested patch. >>From gcc-bugs-return-661875-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 19:21:59 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 99595 invoked by alias); 29 Nov 2019 19:21:59 -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 99442 invoked by uid 48); 29 Nov 2019 19:21:55 -0000 From: "segher at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/66773] sign-compare warning for == and != are pretty useless Date: Fri, 29 Nov 2019 19:21: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: 4.7.2 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: segher 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: 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: 2019-11/txt/msg03669.txt.bz2 Content-length: 778 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D66773 --- Comment #21 from Segher Boessenkool --- (In reply to Daniel Marjam=C3=A4ki from comment #20) > Ping. Your "much better" code does not work. I said that this is much better than an explicit cast. It is. And it beha= ves identically. If the user expects C to provide tests for "mathematically different", the user has some learning to do. If, as I said, the user uses explicit casts, that's not good. Much better already is to use implicit casts, as I said; and much better than that is to fix the problems at the root (use proper types everywhere), as I said. There is no simple fix, so GCC cannot give good guidance. Oh, and don't try to insult me please, I'm much too dumb for that. >>From gcc-bugs-return-661876-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 19:34:01 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 120681 invoked by alias); 29 Nov 2019 19:34: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 120347 invoked by uid 48); 29 Nov 2019 19:33:57 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/92734] New: Missing match.pd simplification done by fold_binary_loc on generic Date: Fri, 29 Nov 2019 19:34:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub 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: 2019-11/txt/msg03670.txt.bz2 Content-length: 913 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92734 Bug ID: 92734 Summary: Missing match.pd simplification done by fold_binary_loc on generic Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- While working on the PR92712 testcases, I had to remove one testcase I wrot= e, because we haven't simplified stuff in GIMPLE in that case (we do on RTL): int foo (int t) { return 1 - (int) (1U - t); } int bar (int t) { int a =3D 1U - t; return 1 - a; } The first function is optimized into return t during fold_binary_loc associ= ate: but there isn't anything in match.pd that handles this (or should it be some special pass?). >>From gcc-bugs-return-661877-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 19:54:14 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 33577 invoked by alias); 29 Nov 2019 19:54:14 -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 33467 invoked by uid 48); 29 Nov 2019 19:54:10 -0000 From: "msebor at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/92718] [8/9/10 Regression] Bogus Wstringop-overflow in __builtin_memset() of an element of array of size 1 of struct Date: Fri, 29 Nov 2019 19:54: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: 8.3.0 X-Bugzilla-Keywords: diagnostic, missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: msebor 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: 8.4 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords cc see_also blocked 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: 2019-11/txt/msg03671.txt.bz2 Content-length: 1021 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92718 Martin Sebor changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |missed-optimization CC| |msebor at gcc dot gnu.org See Also| |https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=3D36602 Blocks| |88443 --- Comment #2 from Martin Sebor --- Replacing the memset call with the assignment '*p =3D (struct s){ 0 };' avo= ids the warning and also results in better/optimal code. (As suggested in pr36= 602, that would be a useful optimization independent of the warning.) Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D88443 [Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings >>From gcc-bugs-return-661879-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 19:55:14 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 36368 invoked by alias); 29 Nov 2019 19:55:13 -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 36249 invoked by uid 48); 29 Nov 2019 19:55:09 -0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/91003] [10 Regression] ICE when compiling LAPACK (CGEGV) with optimization Date: Fri, 29 Nov 2019 19:55:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution 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: 2019-11/txt/msg03673.txt.bz2 Content-length: 429 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D91003 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #9 from Richard Biener --- Fixed. >>From gcc-bugs-return-661878-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 19:55:02 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 35531 invoked by alias); 29 Nov 2019 19:55:02 -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 35237 invoked by uid 55); 29 Nov 2019 19:54:58 -0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/91003] [10 Regression] ICE when compiling LAPACK (CGEGV) with optimization Date: Fri, 29 Nov 2019 19:55:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 10.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: 10.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: 2019-11/txt/msg03672.txt.bz2 Content-length: 832 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D91003 --- Comment #8 from Richard Biener --- Author: rguenth Date: Fri Nov 29 19:54:25 2019 New Revision: 278860 URL: https://gcc.gnu.org/viewcvs?rev=3D278860&root=3Dgcc&view=3Drev Log: 2019-11-29 Richard Biener PR tree-optimization/91003 * tree-vect-slp.c (vect_mask_constant_operand_p): Pass in the operand number, avoid handling the non-condition operands of COND_EXPRs as comparisons. (vect_get_constant_vectors): Pass down the operand number. (vect_get_slp_defs): Likewise. * gfortran.dg/pr91003.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/pr91003.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-slp.c >>From gcc-bugs-return-661880-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 20:22:59 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 89931 invoked by alias); 29 Nov 2019 20:22:59 -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 89842 invoked by uid 48); 29 Nov 2019 20:22:55 -0000 From: "glisse at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/92712] [8/9/10 Regression] Performance regression with assumed values Date: Fri, 29 Nov 2019 20:22: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: 9.2.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: glisse at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: 8.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: 2019-11/txt/msg03674.txt.bz2 Content-length: 288 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92712 --- Comment #20 from Marc Glisse --- (In reply to Jakub Jelinek from comment #19) > Created attachment 47398 [details] > gcc10-pr92712.patch >=20 > Full untested patch. The patch looks very good to me :-) >>From gcc-bugs-return-661881-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 20:35:03 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 100560 invoked by alias); 29 Nov 2019 20:35:02 -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 100490 invoked by uid 48); 29 Nov 2019 20:34:57 -0000 From: "tkoenig at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/92698] Unnecessary copy in overlapping array assignment Date: Fri, 29 Nov 2019 20:35:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 9.2.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: tkoenig 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: 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: 2019-11/txt/msg03675.txt.bz2 Content-length: 2025 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92698 Thomas Koenig changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tkoenig at gcc dot gnu.org --- Comment #1 from Thomas Koenig --- (In reply to mjr19 from comment #0) > subroutine cpy(a,src,dest,len) > integer, intent(in) :: src,dest,len > real(kind(1d0)), intent(inout) :: a(:) >=20 > a(dest:dest+len-1)=3Da(src:src+len-1) >=20 > end subroutine cpy >=20 >=20 > seems to compile to malloc tmp array, inline copy to tmp, inline copy from > tmp, free tmp in gfortran 7.4 and 8.3. Gfortran 9.2 modifies this by > replacing the inline copies with memcpy at -O3. >=20 > Fortran permits the source and destination to overlap, so a single call to > memcpy would be wrong. It would also be wrong for another reason: a is not known to be contiguous at compile-time. The subroutine has to account for the fact that the caller could pass a non-contiguous array slice, for example via call cpy (a(1:10:2),1,2,2) If the test case said subroutine cpy(a,src,dest,len) integer, intent(in) :: src,dest,len real(kind(1d0)), intent(inout), contiguous :: a(:) or subroutine cpy(a,src,dest,len,n) integer, intent(in) :: src,dest,len,n real(kind(1d0)), intent(inout), contiguous :: a(n) then putting in a memmove could indeed help, and the caller has to repack the array on call, and unpack on return (which would defeat the purpose of the optimization). However, I am not convinced that this is something worth pursuing. Instead of calling a subroutine, the user might as well write an assignment statement directly into the rogram. This also has the advantage that, if the relationship between src and dest is known, for example via a(n:n+len-1) =3D a(n+1:n+len) the compiler will actually optimize this into a memmove (provided it knows the array is contiguous). >>From gcc-bugs-return-661882-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 20:56:47 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 61729 invoked by alias); 29 Nov 2019 20:56:47 -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 61683 invoked by uid 55); 29 Nov 2019 20:56:42 -0000 From: "anlauf at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/92629] internal compiler error: in convert_mpz_to_unsigned, at fortran/simplify.c:173 Date: Fri, 29 Nov 2019 20:56:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: anlauf at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P4 X-Bugzilla-Assigned-To: anlauf 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: 2019-11/txt/msg03676.txt.bz2 Content-length: 772 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92629 --- Comment #5 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Fri Nov 29 20:56:11 2019 New Revision: 278862 URL: https://gcc.gnu.org/viewcvs?rev=3D278862&root=3Dgcc&view=3Drev Log: 2019-11-29 Harald Anlauf Backport from mainline PR fortran/92629 * simplify.c (convert_mpz_to_unsigned): Skip assert for argument range when -fno-range-check is specified. PR fortran/92629 * gfortran.dg/pr92629.f90: New testcase. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr92629.f90 Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/simplify.c branches/gcc-9-branch/gcc/testsuite/ChangeLog >>From gcc-bugs-return-661883-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 20:56:59 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 62418 invoked by alias); 29 Nov 2019 20:56: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 62384 invoked by uid 48); 29 Nov 2019 20:56:55 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/92732] Bit-field of scoped enumeration type cannot be initialized Date: Fri, 29 Nov 2019 20:56: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: 10.0 X-Bugzilla-Keywords: rejects-valid X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status assigned_to attachments.created 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: 2019-11/txt/msg03677.txt.bz2 Content-length: 579 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92732 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gn= u.org --- Comment #2 from Jakub Jelinek --- Created attachment 47399 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D47399&action=3Dedit gcc10-pr92732.patch Untested fix. >>From gcc-bugs-return-661884-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 20:59:15 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 66563 invoked by alias); 29 Nov 2019 20:59: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 66522 invoked by uid 55); 29 Nov 2019 20:59:11 -0000 From: "anlauf at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/92629] internal compiler error: in convert_mpz_to_unsigned, at fortran/simplify.c:173 Date: Fri, 29 Nov 2019 20:59:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: anlauf at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P4 X-Bugzilla-Assigned-To: anlauf 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: 2019-11/txt/msg03678.txt.bz2 Content-length: 772 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92629 --- Comment #6 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Fri Nov 29 20:58:39 2019 New Revision: 278863 URL: https://gcc.gnu.org/viewcvs?rev=3D278863&root=3Dgcc&view=3Drev Log: 2019-11-29 Harald Anlauf Backport from mainline PR fortran/92629 * simplify.c (convert_mpz_to_unsigned): Skip assert for argument range when -fno-range-check is specified. PR fortran/92629 * gfortran.dg/pr92629.f90: New testcase. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr92629.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/simplify.c branches/gcc-8-branch/gcc/testsuite/ChangeLog >>From gcc-bugs-return-661885-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 21:03:04 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 70723 invoked by alias); 29 Nov 2019 21:03: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 70591 invoked by uid 48); 29 Nov 2019 21:02:59 -0000 From: "anlauf at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/92629] internal compiler error: in convert_mpz_to_unsigned, at fortran/simplify.c:173 Date: Fri, 29 Nov 2019 21:03:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: anlauf at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P4 X-Bugzilla-Assigned-To: anlauf at gcc dot gnu.org X-Bugzilla-Target-Milestone: 8.4 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution target_milestone 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: 2019-11/txt/msg03679.txt.bz2 Content-length: 496 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92629 anlauf at gcc dot gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.4 --- Comment #7 from anlauf at gcc dot gnu.org --- Fixed on trunk, 9- and 8-branch. Thanks for the report. >>From gcc-bugs-return-661886-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 21:18:24 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 124527 invoked by alias); 29 Nov 2019 21:18: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 Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 124023 invoked by uid 48); 29 Nov 2019 21:18:18 -0000 From: "anlauf at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/71196] f951: internal compiler error: in gfc_conv_string_init, at fortran/trans-const.c:149 Date: Fri, 29 Nov 2019 21:18:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 6.1.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: anlauf at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P4 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- 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: 2019-11/txt/msg03680.txt.bz2 Content-length: 903 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D71196 anlauf at gcc dot gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |anlauf at gcc dot gnu.org --- Comment #6 from anlauf at gcc dot gnu.org --- (In reply to G. Steinmetz from comment #5) > $ cat z8.f90 > program p > type t > character(3) :: c > integer :: i > end type > type t2 > type(t) :: a > end type > type(t2) :: x > data x%a%i / 1 / > print *, x > end > # ICE, see comment above Adding -fdump-fortran-original may give a possible hint as to the origin of= the problem: symtree: 'x' || symbol: 'x'=20=20=20=20=20=20=20=20=20=20=20=20 type spec : (DERIVED t2) attributes: (VARIABLE DATA) value: t2(t(1)) This cannot be right. >>From gcc-bugs-return-661887-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 21:25:29 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 2920 invoked by alias); 29 Nov 2019 21:25: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 2785 invoked by uid 48); 29 Nov 2019 21:25:25 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/92734] Missing match.pd simplification done by fold_binary_loc on generic Date: Fri, 29 Nov 2019 21:25: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: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub 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: 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: 2019-11/txt/msg03681.txt.bz2 Content-length: 306 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92734 --- Comment #1 from Jakub Jelinek --- Of course we have reassoc, but in there we punt on the non-wrapping integral types, because reassociation is generally unsafe for them. There are just special cases that can be handled. >>From gcc-bugs-return-661888-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 21:31:49 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 30602 invoked by alias); 29 Nov 2019 21:31:48 -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 30558 invoked by uid 48); 29 Nov 2019 21:31:43 -0000 From: "anlauf at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/71196] f951: internal compiler error: in gfc_conv_string_init, at fortran/trans-const.c:149 Date: Fri, 29 Nov 2019 21:31:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 6.1.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: anlauf at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P4 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords 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: 2019-11/txt/msg03682.txt.bz2 Content-length: 989 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D71196 anlauf at gcc dot gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |wrong-code --- Comment #7 from anlauf at gcc dot gnu.org --- More fun and confusion: program p type t integer :: k integer :: j integer :: i end type t type t2 type(t) :: a end type t2 type(t2) :: x data x%a%k / 42 / data x%a%i / 1 / data x%a%j / -9 / print *, x end compiles ok but prints: -9 1 42 (should be: 42 -9 1) -fdump-fortran-original says: symtree: 'x' || symbol: 'x'=20=20=20=20=20=20=20=20=20=20=20=20 type spec : (DERIVED t2) attributes: (VARIABLE DATA) value: t2(t(-9 , 1 , 42)) How could the init data get mixed up, so that they are assigned in the reverse order of how the appear in the code? >>From gcc-bugs-return-661889-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 21:51:25 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 47747 invoked by alias); 29 Nov 2019 21:51:25 -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 47706 invoked by uid 48); 29 Nov 2019 21:51:20 -0000 From: "anlauf at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/71196] f951: internal compiler error: in gfc_conv_string_init, at fortran/trans-const.c:149 Date: Fri, 29 Nov 2019 21:51:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 6.1.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: anlauf at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P4 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: 2019-11/txt/msg03683.txt.bz2 Content-length: 644 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D71196 --- Comment #8 from anlauf at gcc dot gnu.org --- The issue seems to be related to the depth of DT nesting. If there is only one level, the issue does not occur. E.g. program p type t integer :: k integer :: j integer :: i end type t type(t) :: y data y%k / 42 / data y%i / 1 / data y%j / -9 / print *, y end prints: 42 -9 1 and we have: symtree: 'y' || symbol: 'y'=20=20=20=20=20=20=20=20=20=20=20=20 type spec : (DERIVED t) attributes: (VARIABLE DATA) value: t(42 , -9 , 1) as it should be. >>From gcc-bugs-return-661890-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 22:04:58 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 62514 invoked by alias); 29 Nov 2019 22:04: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 62421 invoked by uid 55); 29 Nov 2019 22:04:52 -0000 From: "vmakarov at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2 Date: Fri, 29 Nov 2019 22:04: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: 10.0 X-Bugzilla-Keywords: ra, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: vmakarov 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: 10.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: 2019-11/txt/msg03684.txt.bz2 Content-length: 519 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92283 --- Comment #27 from Vladimir Makarov --- Author: vmakarov Date: Fri Nov 29 22:04:21 2019 New Revision: 278865 URL: https://gcc.gnu.org/viewcvs?rev=3D278865&root=3Dgcc&view=3Drev Log: 2019-11-29 Vladimir Makarov PR rtl-optimization/92283 * lra.c (lra): Update reg notes after inheritance sub-pass and before constraint sub-pass. Modified: trunk/gcc/ChangeLog trunk/gcc/lra.c >>From gcc-bugs-return-661891-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Nov 30 00:01:53 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 95320 invoked by alias); 30 Nov 2019 00:01:53 -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 95256 invoked by uid 48); 30 Nov 2019 00:01:49 -0000 From: "vincent-gcc at vinc17 dot net" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/66773] sign-compare warning for == and != are pretty useless Date: Sat, 30 Nov 2019 00:01: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: 4.7.2 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: vincent-gcc at vinc17 dot net 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: 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: 2019-11/txt/msg03685.txt.bz2 Content-length: 691 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D66773 --- Comment #22 from Vincent Lef=C3=A8vre -= -- (In reply to Segher Boessenkool from comment #21) > If, as I said, the user uses explicit casts, that's not good. Much better > already is to use implicit casts, as I said; There's no such thing as implicit casts. Casts are always explicit. > and much better than that is > to fix the problems at the root (use proper types everywhere), as I said. This will not necessarily solve the problem, because the size and/or the signedness of a type may be unknown (the signedness can be detected with a macro, but there's no way to change the sign of a type). >>From gcc-bugs-return-661892-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Nov 30 00:58:10 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 127806 invoked by alias); 30 Nov 2019 00:58:09 -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 121470 invoked by uid 48); 30 Nov 2019 00:58:06 -0000 From: "marcpawl at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/92735] New: unused member variable causes code to compile for member to function for undefined function Date: Sat, 30 Nov 2019 00:58: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: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: marcpawl 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: 2019-11/txt/msg03686.txt.bz2 Content-length: 1644 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92735 Bug ID: 92735 Summary: unused member variable causes code to compile for member to function for undefined function Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: marcpawl at gmail dot com Target Milestone: --- Marc Pawlowsky Thu, Nov 28, 8:25 PM (23 hours ago) to gcc-bugzilla-account-request https://godbolt.org/z/SFZmZJ In clang you get=20 no member names 'hello' in 'Bad' which is the expected result. In all GCC versions using --std=3Dc++17 from 5.2 onwards the code compiles. #include #include struct Foo { virtual void hello(int) =3D 0; }; struct Bar : public Foo { void hello(int) override {}; }; struct Bad { }; template struct is_Foo { using hello_fn_t =3D void (T::*)(int); constexpr static void (T::*hello)(int) =3D &T::hello; static constexpr bool value=3Dtrue; }; template auto say(T& t) -> std::enable_if_t::value, void>{ //U u; // Line 22 //t.hello(4); // Line 23 puts("hello\n"); } int main() { //Bar b;; //Foo& f =3D b; //say(b); //say(f); Bad bad; say(bad); } If you change say to template > void say(T& t) { U u; // Line 22 //t.hello(4); // Line 23 } you get the same errors in clang, but no errors in gcc. =3D=3D=20 on a related not I sent to clang bug report where if value is not static the code will compile. >>From gcc-bugs-return-661893-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Nov 30 03:57:26 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 58452 invoked by alias); 30 Nov 2019 03:57:26 -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 58412 invoked by uid 48); 30 Nov 2019 03:57:21 -0000 From: "egallager at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/92688] including introduce the name index to global namespace scope Date: Sat, 30 Nov 2019 03:57: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: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: egallager at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: DUPLICATE 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: 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: 2019-11/txt/msg03687.txt.bz2 Content-length: 548 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92688 Eric Gallager changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |egallager at gcc dot gnu.o= rg --- Comment #9 from Eric Gallager --- (In reply to Andrew Pinski from comment #2) > Plus GCC does not have a POSIX option. This has come up in a few other bugs; I'll find their numbers later... >>From gcc-bugs-return-661894-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Nov 30 04:02:39 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 70915 invoked by alias); 30 Nov 2019 04:02:39 -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 70847 invoked by uid 48); 30 Nov 2019 04:02:34 -0000 From: "egallager at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug preprocessor/92696] #pragma GCC diagnostic ... interferes with if/else Date: Sat, 30 Nov 2019 04:02:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: preprocessor X-Bugzilla-Version: 9.2.1 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: egallager at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: INVALID 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: 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: 2019-11/txt/msg03688.txt.bz2 Content-length: 829 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92696 Eric Gallager changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |egallager at gcc dot gnu.o= rg --- Comment #6 from Eric Gallager --- (In reply to Andrew Pinski from comment #3) > (In reply to Andrew Pinski from comment #2) > > Also #pragma are considered statements. There is another issue like th= is > > but instead using _Pragma . >=20 > I should say some Pragmas are considered statements. >=20 > See PR 90400 Which shows the similar issue but with _Pragma. In this cas= e, > these Pragmas are considered statements. also some of the other bugs related to it, too >>From gcc-bugs-return-661895-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Nov 30 04:07:41 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 75380 invoked by alias); 30 Nov 2019 04:07: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 75325 invoked by uid 48); 30 Nov 2019 04:07:36 -0000 From: "egallager at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/92700] wrong "unintialized" warning with std::optional Date: Sat, 30 Nov 2019 04:07: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: 9.1.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: egallager 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: 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: 2019-11/txt/msg03689.txt.bz2 Content-length: 646 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92700 Eric Gallager changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |egallager at gcc dot gnu.o= rg --- Comment #2 from Eric Gallager --- (In reply to Richard Biener from comment #1) > We at least do have other PRs complaining about std::optional I think 2 of the Martins were working on a patch to split off warnings like this into a separate -Wmaybe-uninitialized-aggregates to handle this >>From gcc-bugs-return-661896-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Nov 30 04:47:16 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 115297 invoked by alias); 30 Nov 2019 04:47: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 115149 invoked by uid 48); 30 Nov 2019 04:47:11 -0000 From: "egallager at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/70196] inconsistent constness of inequality of weak symbol addresses Date: Sat, 30 Nov 2019 04:47: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: 6.0 X-Bugzilla-Keywords: accepts-invalid X-Bugzilla-Severity: minor X-Bugzilla-Who: egallager 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: --- 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: 2019-11/txt/msg03690.txt.bz2 Content-length: 432 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D70196 --- Comment #5 from Eric Gallager --- (In reply to Nathan Sidwell from comment #4) > ordering comparison of pointers is only well-defined when the two pointers > point into the same object (including one-past-the-end). [expr.ref]/4 >=20 Right, there's a warning from -Wextra for that, there's a bug to split it o= ff into its own warning, too... >>From gcc-bugs-return-661897-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Nov 30 04:48:40 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 121359 invoked by alias); 30 Nov 2019 04:48: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 116868 invoked by uid 48); 30 Nov 2019 04:48:30 -0000 From: "egallager at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/90647] Warn on returning a lambda with captured local variables Date: Sat, 30 Nov 2019 04:48: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: 10.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: egallager 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: 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: 2019-11/txt/msg03691.txt.bz2 Content-length: 449 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D90647 --- Comment #1 from Eric Gallager --- (In reply to Antony Polukhin from comment #0) > Consider the example: >=20 > auto test(int s) { > return [&s] { return s; }; > } >=20 >=20 > `s` is a local variable, so we return a lambda that has a dangling refere= nce. >=20 > It would be nice to have a warning for such cases. Under -Wreturn-local-addr, or a new flag? >>From gcc-bugs-return-661898-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Nov 30 05:55:16 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 77945 invoked by alias); 30 Nov 2019 05:55: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 77915 invoked by uid 48); 30 Nov 2019 05:55:12 -0000 From: "chinoune.mehdi at hotmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/92736] New: Error when using a variable from a module in a submodule and its parent module. Date: Sat, 30 Nov 2019 05:55:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 9.2.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: chinoune.mehdi at hotmail 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: 2019-11/txt/msg03692.txt.bz2 Content-length: 2134 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92736 Bug ID: 92736 Summary: Error when using a variable from a module in a submodule and its parent module. Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: chinoune.mehdi at hotmail dot com Target Milestone: --- gfortran recently start to reject this code : module m1 implicit none integer, parameter :: i =3D 10 end module m1 module m2 use m1, only : i implicit none interface module subroutine sb1() end subroutine sb1 end interface end module m2 submodule(m2) s1 use m1, only : i implicit none contains module subroutine sb1 print*,"hello" end subroutine sb1 end submodule s1 gfortran-9 -c file.f90 15 | submodule(m2) s1=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20 | 1=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 16 | use m1, only : i=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20 | 2=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20 Error: Symbol =E2=80=98i=E2=80=99 at (1) conflicts with the symbol at (2) The error message is not clear! I can compile it using gfortran 8.3.0 and 9.2.0, but it fails with 9.2.1 and 10.0 I think this is where it started failing : https://gcc.gnu.org/viewcvs/gcc?view=3Drevision&revision=3D274609 https://gcc.gnu.org/viewcvs/gcc?view=3Drevision&revision=3D274608 >>From gcc-bugs-return-661899-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Nov 30 06:46:11 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 96765 invoked by alias); 30 Nov 2019 06:46: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 96721 invoked by uid 48); 30 Nov 2019 06:46:06 -0000 From: "rrrlasse at hotmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/92731] Data race on exception object thrown from std::future Date: Sat, 30 Nov 2019 06:46: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: 8.3.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rrrlasse at hotmail 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: 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: 2019-11/txt/msg03693.txt.bz2 Content-length: 1249 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92731 --- Comment #4 from Lasse Reinhold --- Some simplifications, and also tried with atomics instead of mutexes, to no avail: #include #include #include #include std::function job; std::atomic has_job{ false }; int main() { std::thread t =3D std::thread([]() { for (;;) { if (has_job.load(std::memory_order_acquire)) { job(); has_job.store(false, std::memory_order_release); } } }); for (int c =3D 0; ; c++) { if (!has_job.load(std::memory_order_acquire)) { try { std::packaged_task packaged_task([]() { throw 1234;= }); std::future task_future =3D packaged_task.get_future(= ); job =3D [&]() { std::packaged_task tmp(std::move(packaged_task= )); tmp(); }; has_job.store(true, std::memory_order_release); task_future.get(); } catch (const int& e) { assert(e =3D=3D 1234); } } } } >>From gcc-bugs-return-661900-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Nov 30 06:58:58 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 103889 invoked by alias); 30 Nov 2019 06:58: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 103848 invoked by uid 48); 30 Nov 2019 06:58:54 -0000 From: "daniel.marjamaki at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/66773] sign-compare warning for == and != are pretty useless Date: Sat, 30 Nov 2019 06:58: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: 4.7.2 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: daniel.marjamaki 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: 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: 2019-11/txt/msg03694.txt.bz2 Content-length: 1126 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D66773 --- Comment #23 from Daniel Marjam=C3=A4ki --- > If the user expects C to provide tests for "mathematically different", the user has some learning to do. I believe most users can appreciate this. But few users fully understand the integer conversions. I think it's dangerous. :-( > If, as I said, the user uses explicit casts, that's not good. Much better already is to use implicit casts, as I said; and much better than that is to fix the problems at the root (use proper types everywhere), as I said. You are de-facto advocating explicit casts because that is how everybody fi= xes these. The advice to use proper types is good, in my opinion everybody tries to do that. However as far as I see it's impossible in practice to never mix sign= ed and unsigned types in real projects. > There is no simple fix, so GCC cannot give good guidance. Then people just blindly use explicit casts.. and I dislike that. > Oh, and don't try to insult me please, I'm much too dumb for that. I apologize! I do not want to insult people. >>From gcc-bugs-return-661901-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Nov 30 08:04:26 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 32419 invoked by alias); 30 Nov 2019 08:04:26 -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 32376 invoked by uid 48); 30 Nov 2019 08:04:22 -0000 From: "antoshkka at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/90647] Warn on returning a lambda with captured local variables Date: Sat, 30 Nov 2019 08:04: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: 10.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: antoshkka 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: 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: 2019-11/txt/msg03695.txt.bz2 Content-length: 160 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D90647 --- Comment #2 from Antony Polukhin --- -Wreturn-local-addr looks good to me >>From gcc-bugs-return-661902-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Nov 30 09:25:48 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 62919 invoked by alias); 30 Nov 2019 09:25:48 -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 62744 invoked by uid 48); 30 Nov 2019 09:25:43 -0000 From: "iains at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug bootstrap/92719] MacOS 10.15 Catalina build fails Date: Sat, 30 Nov 2019 09:25:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: bootstrap X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: build X-Bugzilla-Severity: normal X-Bugzilla-Who: iains at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: WORKSFORME X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution 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: 2019-11/txt/msg03696.txt.bz2 Content-length: 682 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92719 Iain Sandoe changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #2 from Iain Sandoe --- With configuration options as suggested, bootstrap completes (and jit build= ).=20 However, there are a significant number of issues with jit testing (but tha= t's a separate issue). Test results here: https://gcc.gnu.org/ml/gcc-testresults/2019-11/msg01649.html >>From gcc-bugs-return-661903-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Nov 30 09:25:48 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 62984 invoked by alias); 30 Nov 2019 09:25:48 -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 62810 invoked by uid 48); 30 Nov 2019 09:25:45 -0000 From: "iains at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/90835] Incompatibilities with macOS 10.15 headers Date: Sat, 30 Nov 2019 09:25:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: dep_changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: meta-bug X-Bugzilla-Severity: normal X-Bugzilla-Who: iains 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: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution 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: 2019-11/txt/msg03697.txt.bz2 Content-length: 463 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D90835 Bug 90835 depends on bug 92719, which changed state. Bug 92719 Summary: MacOS 10.15 Catalina build fails https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92719 What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME >>From gcc-bugs-return-661904-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Nov 30 10:53:00 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 7365 invoked by alias); 30 Nov 2019 10:53: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 7269 invoked by uid 48); 30 Nov 2019 10:52:56 -0000 From: "egallager at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/90647] Warn on returning a lambda with captured local variables Date: Sat, 30 Nov 2019 10:53: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: 10.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: egallager 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: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on blocked everconfirmed 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: 2019-11/txt/msg03698.txt.bz2 Content-length: 1186 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D90647 Eric Gallager changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2019-11-30 Blocks|87403 |90556, 54367 Ever confirmed|0 |1 --- Comment #3 from Eric Gallager --- (In reply to Antony Polukhin from comment #2) > -Wreturn-local-addr looks good to me Hm, I suddenly got the idea that there was another bug under the -Wreturn-local-addr meta-bug that this might be a dup of, but after checkin= g, it doesn't look like it after all... confirmed as a separate bug for now, I guess. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D54367 [Bug 54367] [meta-bug] lambda expressions https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D87403 [Bug 87403] [Meta-bug] Issues that suggest a new warning https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D90556 [Bug 90556] [meta-bug] bogus/missing -Wreturn-local-addr >>From gcc-bugs-return-661905-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Nov 30 10:54:56 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 8993 invoked by alias); 30 Nov 2019 10:54:56 -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 8920 invoked by uid 48); 30 Nov 2019 10:54:52 -0000 From: "egallager at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/70196] inconsistent constness of inequality of weak symbol addresses Date: Sat, 30 Nov 2019 10:54: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: 6.0 X-Bugzilla-Keywords: accepts-invalid X-Bugzilla-Severity: minor X-Bugzilla-Who: egallager 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: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: see_also 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: 2019-11/txt/msg03699.txt.bz2 Content-length: 853 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D70196 Eric Gallager changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=3D81453 --- Comment #6 from Eric Gallager --- (In reply to Eric Gallager from comment #5) > (In reply to Nathan Sidwell from comment #4) > > ordering comparison of pointers is only well-defined when the two point= ers > > point into the same object (including one-past-the-end). [expr.ref]/4 > >=20 >=20 > Right, there's a warning from -Wextra for that, there's a bug to split it > off into its own warning, too... ...right, bug 81453 >>From gcc-bugs-return-661906-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Nov 30 11:07:33 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 19406 invoked by alias); 30 Nov 2019 11:07:33 -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 19318 invoked by uid 48); 30 Nov 2019 11:07:29 -0000 From: "egallager at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/92652] function call to lambda expression that return true does not satisfy the constraint in requires-clause if using return type deduction Date: Sat, 30 Nov 2019 11:07: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: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: egallager 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: cc blocked 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: 2019-11/txt/msg03700.txt.bz2 Content-length: 727 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92652 Eric Gallager changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |egallager at gcc dot gnu.o= rg Blocks| |54367 --- Comment #1 from Eric Gallager --- is this a "concepts" thing? (I don't know C++ very well; I mostly just tria= ge bugs, and the "requires" and "constraint" terms remind me of some "concepts" bugs...) Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D54367 [Bug 54367] [meta-bug] lambda expressions >>From gcc-bugs-return-661907-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Nov 30 11:36:13 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 107811 invoked by alias); 30 Nov 2019 11:36:13 -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 107754 invoked by uid 48); 30 Nov 2019 11:36:09 -0000 From: "lutztonineubert at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/92695] P1064R0 - virtual constexpr fails if object taken from array Date: Sat, 30 Nov 2019 11:36: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: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: lutztonineubert at gmail dot com X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jakub 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: 2019-11/txt/msg03701.txt.bz2 Content-length: 196 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92695 --- Comment #11 from Toni Neubert --- I tested all patches and it works as expected. Thank you very much! >>From gcc-bugs-return-661908-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Nov 30 12:06:38 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 9372 invoked by alias); 30 Nov 2019 12:06: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 Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 9234 invoked by uid 48); 30 Nov 2019 12:06:33 -0000 From: "mjr19 at cam dot ac.uk" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/92698] Unnecessary copy in overlapping array assignment Date: Sat, 30 Nov 2019 12:06:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 9.2.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: mjr19 at cam dot ac.uk 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: 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: 2019-11/txt/msg03702.txt.bz2 Content-length: 1439 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92698 --- Comment #2 from mjr19 at cam dot ac.uk --- Thomas is quite correct that I had failed to mark the array as contiguous, = at which point the double copy is more reasonable (although memcpy will also expect its arguments to be contiguous). He also correctly points out that a(n:n+len-1) =3D a(n+1:n+len) will optimise to memmove if a is known to be contiguous. However, I still think there is scope for further improvement. a(n:n+len-1) =3D a(n+offset:n+offset+len-1) never seems to optimise, whether or not a is contiguous, presumably because= the sign of offset is unknown. However, as memmove copes with either sign of of= fset (or offset=3D0), concerns about the value of offset seem unnecessary. Also, I suspect that arrays in Fortran are often contiguous, even when this= is not explicitly stated, so introducing a special case for contiguous arrays = at high optimisation levels may be beneficial. The explicit "contiguous" attri= bute was introduced only in F2008 (and does not require packing and unpacking by= the caller if the caller's array is already contiguous). I expect a lot of code= has not progressed further than F2003. The example I offered was not real code. The real code in which this arose = was a Fortran implementation of Timsort in which the assignment was just one pa= rt of a subroutine, albeit a significant part in terms of execution time. >>From gcc-bugs-return-661909-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Nov 30 13:01:29 2019 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 94183 invoked by alias); 30 Nov 2019 13:01:28 -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 93740 invoked by uid 48); 30 Nov 2019 13:01:13 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/92723] ICE in expand_shift_1, at expmed.c:2635 Date: Sat, 30 Nov 2019 13:01:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 9.2.1 X-Bugzilla-Keywords: ice-on-valid-code, needs-reduction X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub 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: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on cc everconfirmed 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: 2019-11/txt/msg03703.txt.bz2 Content-length: 4308 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92723 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2019-11-30 CC| |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Reduced (-std=3Dc++17 -O3): template struct d; template struct d { typedef e g; }; template struct ac { typedef typename d::g g; }; template using af =3D typename ac::g; template using ah =3D ae; struct aj { template void al(h *, ak... an) { h(an...); } }; template using ao =3D aj; template class allocator : public ao {}; template struct ap; template struct ap> { using aq =3D allocator; template static void al(aq ar, h am, ak... an) { ar.al(am, an...); } }; struct as { as(allocator); }; template struct at { allocator av; }; template struct ax { struct ay : as { ay(aw ar) : as(ar) {} }; template ax(aw ar, ak... an) : az(ar) { ap::al(ar, ba(), an...); } e *ba(); ay az; }; struct bb { template bb(e *, at ar, ak... an) { ax(ar.av, an...); } }; template struct au { using bc =3D e; template au(aw bd, ak... an) : be(ba, bd, an...) {} bc *ba; bb be; }; template struct bf : au { template bf(aw bd, ak... an) : au(bd, an...) {} template friend bf bh(const aw &, ak &&...); }; template bf bh(const aw &, ak &&... an) { bf(at{}, an...); } template void bi(ak... an) { bh(allocator(), an...); } template constexpr bool bj =3D false; class j; struct bk { j *operator->(); }; struct bn : public bk { bn(decltype(nullptr)); }; class br; template using bp =3D br; template bq bs(bu); template bt *bx(); using bv =3D struct bw { template void by() { int bz; cb::ca(bz); } }; struct cf { using cc =3D int; }; struct cd { char k; void ce(); }; struct br : public cd { int &operator[](long l) { int *cj =3D reinterpret_cast(k); return cj[l]; } }; struct m { using cc =3D int; }; template constexpr bool n =3D false; struct j { using cg =3D int; using q =3D bp; q o(); } ch; template bool cn(ci f) { ((bs(ch) ? f(*bs(ch)) : false) || ...); return false; } template struct p { using cl =3D int; static void co(bp a, int b, bp c) { a.ce(); for (long i; i; ++i) c[i] =3D ck::apply(a[i], b); } }; template