[Bug target/94437] Internal compiler error in avr-g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94437 Giles Atkinson changed: What|Removed |Added Attachment #48158|0 |1 is obsolete|| --- Comment #7 from Giles Atkinson --- Created attachment 48167 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48167&action=edit Source code Seek redemption for grave sin. (Restore LGPL comment)
[Bug fortran/94030] [8/9/10 Regression] ICE equivalence of an integer and an element of an array of size n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94030 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:514bd32c5273b1b6c3438016faf96ffdd45639ca commit r9-8440-g514bd32c5273b1b6c3438016faf96ffdd45639ca Author: Mark Eggleston Date: Thu Apr 2 08:26:34 2020 +0100 fortran: ICE equivalence with an element of an array PR94030 Deferred size arrays can not be used in equivalance statements. gcc/fortran/ChangeLog: Backport from master 2020-04-02 Mark Eggleston PR fortran/94030 * resolve.c (resolve_equivalence): Correct formatting around the label "identical_types". Instead of using gfc_resolve_array_spec use is_non_constants_shape_array to determine whether the array can be used in a in an equivalence statement. gcc/testsuite/ChangeLog: Backport from master 2020-04-02 Mark Eggleston PR fortran/94030 * gfortran.dg/pr94030_1.f90 * gfortran.dg/pr94030_2.f90
[Bug target/94364] 505.mcf_r is 8% faster when compiled with -mprefer-vector-width=128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94364 --- Comment #3 from Richard Biener --- (In reply to Martin Jambor from comment #2) > (In reply to Richard Biener from comment #1) > > Huh, looks like this is the (patched by us) memory copying done in > > spec_qsort? > > Yes > > > I wonder if you can re-measure with our patching undone but then with > > -fno-strict-aliasing (though I think that only was required with LTO). > > > > The difference indeed goes away :-/ The current code we're > benchmarking (when not using LTO) is slower in both cases :-/ :/ What is the diff we are using? IIRC spec_qsort contains special casing for standard integer type sizes and my original patch simply removed all that premature optimization and instead always uses the char copying loop (which seems to be vectorized then). Maybe we can resort to apply -fno-strict-aliasing just to the qsort CU? It wasn't intended to introduce big differences compared to official runs... > > How large are the objects sorted in mcf? > > It's always pointers, 8 bytes. OK, that would explain it then.
[Bug fortran/94030] [8/9/10 Regression] ICE equivalence of an integer and an element of an array of size n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94030 --- Comment #7 from CVS Commits --- The releases/gcc-8 branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:26191cec3421a157f4bafa7760cfd1bc4f90f0e5 commit r8-10157-g26191cec3421a157f4bafa7760cfd1bc4f90f0e5 Author: Mark Eggleston Date: Thu Apr 2 08:32:05 2020 +0100 fortran: ICE equivalence with an element of an array PR94030 Deferred size arrays can not be used in equivalance statements. gcc/fortran/ChangeLog: Backport from master 2020-04-02 Mark Eggleston PR fortran/94030 * resolve.c (resolve_equivalence): Correct formatting around the label "identical_types". Instead of using gfc_resolve_array_spec use is_non_constants_shape_array to determine whether the array can be used in a in an equivalence statement. gcc/testsuite/ChangeLog: Backport from master 2020-04-02 Mark Eggleston PR fortran/94030 * gfortran.dg/pr94030_1.f90 * gfortran.dg/pr94030_2.f90
[Bug c++/94453] New: [10 Regression] ICE in make_decl_rtl since r10-3591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94453
Bug ID: 94453
Summary: [10 Regression] ICE in make_decl_rtl since r10-3591
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
Since r10-3591-gb830c28b56fdc3f4b4555200278218b4b49022d2 the following testcase
ICEs with -O2 -std=c++17:
./cc1plus -quiet -O2 -std=c++17 rh1819335.ii
during RTL pass: expand
rh1819335.ii: In static member function ‘static ar t::bf(const
s&, ad ...) [with ar = void; h = b(G)::; ad = {}]’:
rh1819335.ii:103:29: internal compiler error: in make_decl_rtl, at
varasm.c:1346
103 | auto q = [=] { exclude->di(p, data->cg().cw()); };
| ~~~^~~~
0x1a98085 make_decl_rtl(tree_node*)
../../gcc/varasm.c:1342
0x1044655 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:10085
0x103c4e3 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../gcc/expr.c:8353
0xe424f1 expand_expr
../../gcc/expr.h:282
0xe55ad7 store_one_arg
../../gcc/calls.c:5973
0xe50238 expand_call(tree_node*, rtx_def*, int)
../../gcc/calls.c:4476
template struct c { static constexpr int d = b; };
template using e = c;
template struct g;
template struct g {
typedef decltype(0) i;
};
template struct k : g::d, c::d, ad...> {};
template using ag = f;
struct r { c j; using i = decltype(j); };
template constexpr bool ak = r::i ::d;
template void ao(an ap, al... aq) {
ap(aq...);
}
template ag> at(as au, al... aq) {
using av = k;
using aw = typename av::i;
ao(au, aq...);
}
struct s {
void *ay();
template f ay() { return *static_cast(ay()); }
};
template class az;
template class bb {
protected:
static h *bc(s bd) { return bd.ay(); }
};
template class t;
template
struct t : bb {
static ar bf(const s &bg, ad... aq) {
auto bh = bb::bc(bg);
at(*bh, aq...);
}
};
template struct az {
template using bj = f;
template , void>, typename = bj>
az(h);
using bk = ar (*)(const s &, ad...);
bk bl;
};
template
template
az::az(h) { bl = t::bf; }
template struct G {
template G(bp);
bo operator->() const;
};
namespace bq {
struct H { template bs *bt(); };
struct I { template I(bz); };
template using cb = I;
class u : cb { using cc = cb; using cc::cc; };
template struct J { bs cg(); };
}
template using ci = az;
template struct ck { using cl = cj; constexpr ck(cl) {}
};
template constexpr auto l(cl d) { return ck(d); }
template constexpr auto operator|(cl a, cl) {
auto cm = l(a);
return cm;
}
namespace cn {
struct v { bq::H br(); };
}
namespace cp {
struct cq {
enum cr { cs, ct };
using cv = ck;
const int &cw() const;
};
}
namespace cn {
namespace cx {
auto cy() {}
}
struct w {
void da(ci);
};
}
using db = cn::w;
G dc(int, bq::u, int);
namespace de {
int m;
}
using cr = cp::cq;
using cv = cp::cq::cv;
using df = const int &;
using dg = df (cp::cq::*)() const;
struct x { void di(cv, int); };
G dj(int, G, ci, cv, dg);
void dk(int, G, cv, G, ci, ci);
void b(G box) {
int dm, content = 0;
using dn = bq::J;
auto data = box->br().bt();
auto n = [](cp::cq) {};
constexpr auto p = cr::cs | cr::ct;
auto o = dc(content, cn::cx::cy, de::m);
auto exclude = dj(content, data, n, p, &cp::cq::cw);
auto q = [=] { exclude->di(p, data->cg().cw()); };
o->da([=] { dk(dm, box, p, data, n, q); });
}
[Bug c++/94453] [10 Regression] ICE in make_decl_rtl since r10-3591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94453 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |10.0 CC||jason at gcc dot gnu.org Keywords||ice-on-valid-code
[Bug tree-optimization/94443] [10 Regression] 510.parest_r and 526.blender_r ICE: verify_ssa failed since r10-7491-gbd0f22a8d5caea8905f38ff1fafce31c1b7d33ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94443
--- Comment #6 from rguenther at suse dot de ---
On Thu, 2 Apr 2020, linkw at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94443
>
> --- Comment #4 from Kewen Lin ---
> This case has one conversion insn generated after bit_field_ref, the patch
> introduces one stupid mistake to use gsi_insert_before instead of
> gsi_insert_seq_before, it leads to miss the conversion insn. The below patch
> makes it work. It also polishes copy related code a bit although not really
> necessary to make this case pass.
>
> diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
> index c9b6534..4c2c9f7 100644
> --- a/gcc/tree-vect-loop.c
> +++ b/gcc/tree-vect-loop.c
> @@ -8050,7 +8050,7 @@ vectorizable_live_operation (stmt_vec_info stmt_info,
>if (stmts)
> {
>gimple_stmt_iterator exit_gsi = gsi_after_labels (exit_bb);
> - gsi_insert_before (&exit_gsi, stmts, GSI_CONTINUE_LINKING);
> + gsi_insert_seq_before (&exit_gsi, stmts, GSI_SAME_STMT);
>
>/* Remove existing phi from lhs and create one copy from new_tree. */
>tree lhs_phi = NULL_TREE;
> @@ -8060,10 +8060,10 @@ vectorizable_live_operation (stmt_vec_info stmt_info,
> gimple *phi = gsi_stmt (gsi);
> if ((gimple_phi_arg_def (phi, 0) == lhs))
> {
> - remove_phi_node (&gsi, false);
> lhs_phi = gimple_phi_result (phi);
> gimple *copy = gimple_build_assign (lhs_phi, new_tree);
> - gsi_insert_after (&exit_gsi, copy, GSI_CONTINUE_LINKING);
> + gsi_insert_after (&exit_gsi, copy, GSI_NEW_STMT);
this should also use gsi_insert_before, otherwise if the first stmt
after labels has a use of lhs_phi then SSA will be corrupt.
> + remove_phi_node (&gsi, false);
I prefer to have the PHI removed before you re-use its LHS.
OK with those changes.
> break;
> }
> }
>
>
[Bug tree-optimization/94443] [10 Regression] 510.parest_r and 526.blender_r ICE: verify_ssa failed since r10-7491-gbd0f22a8d5caea8905f38ff1fafce31c1b7d33ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94443
--- Comment #7 from Kewen Lin ---
Yes, thanks Richi! I had the same update locally but didn't update here. The
latest whole patch is
diff --git a/gcc/testsuite/gcc.dg/vect/pr94443.c
b/gcc/testsuite/gcc.dg/vect/pr94443.c
new file mode 100644
index 000..f8cbaf1
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/pr94443.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-march=znver2" { target { x86_64-*-* i?86-*-* } }
} */
+
+/* Check it to be compiled successfully without any ICE. */
+
+int a;
+unsigned *b;
+
+void foo()
+{
+ for (unsigned i; i <= a; ++i, ++b)
+;
+}
diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index c9b6534..b621f89 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -8050,7 +8050,7 @@ vectorizable_live_operation (stmt_vec_info stmt_info,
if (stmts)
{
gimple_stmt_iterator exit_gsi = gsi_after_labels (exit_bb);
- gsi_insert_before (&exit_gsi, stmts, GSI_CONTINUE_LINKING);
+ gsi_insert_seq_before (&exit_gsi, stmts, GSI_SAME_STMT);
/* Remove existing phi from lhs and create one copy from new_tree. */
tree lhs_phi = NULL_TREE;
@@ -8060,10 +8060,10 @@ vectorizable_live_operation (stmt_vec_info stmt_info,
gimple *phi = gsi_stmt (gsi);
if ((gimple_phi_arg_def (phi, 0) == lhs))
{
- remove_phi_node (&gsi, false);
lhs_phi = gimple_phi_result (phi);
gimple *copy = gimple_build_assign (lhs_phi, new_tree);
- gsi_insert_after (&exit_gsi, copy, GSI_CONTINUE_LINKING);
+ gsi_insert_before (&exit_gsi, copy, GSI_SAME_STMT);
+ remove_phi_node (&gsi, false);
break;
}
}
Still waiting for regression testing result.
[Bug fortran/93498] [9/10 Regression] ICE in gfc_resolve_findloc, at fortran/iresolve.c:1844 since r9-3688-g01ce9e31a02c8039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93498 --- Comment #8 from CVS Commits --- The releases/gcc-9 branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:b6e546912555c9b9b27bdce516e98546f4cd3d25 commit r9-8441-gb6e546912555c9b9b27bdce516e98546f4cd3d25 Author: Mark Eggleston Date: Thu Apr 2 08:42:41 2020 +0100 fortran : ICE in gfc_resolve_findloc PR93498 ICE occurs when findloc is used with character arguments of different kinds. If the character kinds are different reject the code. Original patch provided by Steven G. Kargl . gcc/fortran/ChangeLog: Backport from master Steven G. Kargl PR fortran/93498 * check.c (gfc_check_findloc): If the kinds of the arguments differ goto label "incompat". gcc/testsuite/ChangeLog: Backport from master 2020-04-02 Mark Eggleston PR fortran/93498 * gfortran.dg/pr93498_1.f90: New test. * gfortran.dg/pr93498_2.f90: New test.
[Bug fortran/94030] [8/9/10 Regression] ICE equivalence of an integer and an element of an array of size n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94030 markeggleston at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from markeggleston at gcc dot gnu.org --- Commits for master and backports: r10-7507-gbf1f6d8819ade074271df718f01fd3a5a9dc1b82 r9-8440-g514bd32c5273b1b6c3438016faf96ffdd45639ca r8-10157-g26191cec3421a157f4bafa7760cfd1bc4f90f0e5
[Bug tree-optimization/94443] [10 Regression] 510.parest_r and 526.blender_r ICE: verify_ssa failed since r10-7491-gbd0f22a8d5caea8905f38ff1fafce31c1b7d33ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94443 --- Comment #8 from Kewen Lin --- > > > + remove_phi_node (&gsi, false); > > I prefer to have the PHI removed before you re-use its LHS. > Oops, missed this, will move it back when posting to email list.
[Bug fortran/93498] [9/10 Regression] ICE in gfc_resolve_findloc, at fortran/iresolve.c:1844 since r9-3688-g01ce9e31a02c8039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93498 markeggleston at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED CC||markeggleston at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #9 from markeggleston at gcc dot gnu.org --- Committed to master and backported: r10-7508-g2c54eab5a302c6da015bb39b1a81f6799e45a650 r9-8441-gb6e546912555c9b9b27bdce516e98546f4cd3d25
[Bug debug/94450] lto abstract variable emitted as concrete decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94450 Richard Biener changed: What|Removed |Added Last reconfirmed||2020-04-02 Keywords||lto CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- I guess the more correct DWARF would be to have the 13d DIE include DW_AT_declaration? Then we could also stop the "abuse" of DW_AT_abstract_origin and instead have to use DW_AT_specification. But I'm not sure whether DW_AT_specification allows cross CU references (technically yes but practically) especially since there's explicit wording that DW_AT_specification cannot refer to type unit entities. Note I originally saw all early debug as abstract (but we're not consistently emitting DW_AT_inline to all early function DIEs either) but that concept doesn't apply to globals. As you said the DW_TAG_imported_unit serve no useful purpose (I originally thought that it would provide proper name-lookup scopes but that works correct in other ways). And I'm fine to simply drop those (also given consumers seem to handle references to CUs not explicitely imported just fine). That could be done for GCC 10 already, I fear the rest needs more testing? Btw, thanks for sanity checking the LTO DWARF.
[Bug target/94452] I386 ABI: How to determine the alignment of struct or union determined when passes them on stack？
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94452 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-04-02 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- I see gx aligned to 64 bytes (as I expected). Can you be more specific as to what target you tested?
[Bug target/94452] I386 ABI: How to determine the alignment of struct or union determined when passes them on stack？
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94452 --- Comment #2 from ChenLiu --- (In reply to Richard Biener from comment #1) > I see gx aligned to 64 bytes (as I expected). Can you be more specific as > to what target you tested? I tested on i386 target. I think you may misunderstand what I mean. The gx will align to 4 byte when passing it on stack. I think this should belong to calling conventions.
[Bug lto/91027] [10 regression] SEGV in hash_table::find_slot_with_hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91027 --- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #17 from Iain Buclaw --- > The commit for it is here. > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=98eb7b2ed249537d12004f2c58583140ac25d666 I just noticed that I had a previous workaround of yours for the SEGV still in my tree. Once I'd removed that, the failures were gone. Sorry for the noise.
[Bug lto/91027] [10 regression] SEGV in hash_table::find_slot_with_hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91027 Rainer Orth changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #19 from Rainer Orth --- Fixed indeed.
[Bug target/94452] I386 ABI: How to determine the alignment of struct or union determined when passes them on stack？
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94452 --- Comment #3 from ChenLiu --- (In reply to Richard Biener from comment #1) > I see gx aligned to 64 bytes (as I expected). Can you be more specific as > to what target you tested? The gcc version I use is 7.3.0 and only one option was used: -m32.
[Bug target/94452] I386 ABI: How to determine the alignment arguments on the stack of struct or union for argument passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94452 Richard Biener changed: What|Removed |Added Summary|I386 ABI: How to determine |I386 ABI: How to determine |the alignment of struct or |the alignment arguments on |union determined when |the stack of struct or |passes them on stack？ |union for argument passing Status|WAITING |UNCONFIRMED Ever confirmed|1 |0 --- Comment #4 from Richard Biener --- (In reply to ChenLiu from comment #2) > (In reply to Richard Biener from comment #1) > > I see gx aligned to 64 bytes (as I expected). Can you be more specific as > > to what target you tested? > > I tested on i386 target. I think you may misunderstand what I mean. The gx > will align to 4 byte when passing it on stack. I think this should belong to > calling conventions. Ah, OK. IIRC the psABI does not factor in over/under alignment but only size and kind of (sub-)objects so eventually extra copy-in/out is required to have the callee see arguments of the desired alignment. HJ can probably clarify. Note bugzilla isn't really for this kind of questions, there's a psABI mailing list somewhere.
[Bug target/89148] [AVR] Merge plugin to place C++ vtables in flash memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89148 --- Comment #2 from Georg-Johann Lay --- Some remarks: 1. There are AVR devices that don't support named address spaces. You will run into ICEs with this approach. You'll have to disable it for respective avr families. 2. The patch sets non-generic address-spaces for objects / types used in the C++ front-end, and that front-end does not support named address-spaces. How is it ensured that all transformations that take place in the C++ front-end handle ASes correctly / consistently? 3. In the case there are problems, the user should be able to switch the feature off by a command-line option. This option requires documentation, in particular it's not an optimization option because it changes the ABI. 4. The plugin must be built / installed. So I'd expect some extensions to the build system like t-avr?
[Bug fortran/93522] [10 Regression] ICE in gfc_release_symbol, at fortran/symbol.c:3121 since r10-2912-g70570ec192745095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93522 --- Comment #2 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:224efaf7e1e9240b64602ea81a255cb43e4dcb0c commit r10-7510-g224efaf7e1e9240b64602ea81a255cb43e4dcb0c Author: Tobias Burnus Date: Thu Apr 2 11:16:17 2020 +0200 [Fortran] Fix error cleanup of select rank (PR93522) PR fortran/93522 * match.c (gfc_match_select_rank): Fix error cleanup. PR fortran/93522 * gfortran.dg/select_rank_4.f90: New.
[Bug target/94452] I386 ABI: How to determine the alignment arguments on the stack of struct or union for argument passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94452 --- Comment #5 from ChenLiu --- (In reply to Richard Biener from comment #4) > (In reply to ChenLiu from comment #2) > > (In reply to Richard Biener from comment #1) > > > I see gx aligned to 64 bytes (as I expected). Can you be more specific as > > > to what target you tested? > > > > I tested on i386 target. I think you may misunderstand what I mean. The gx > > will align to 4 byte when passing it on stack. I think this should belong to > > calling conventions. > > Ah, OK. IIRC the psABI does not factor in over/under alignment but only > size and kind of (sub-)objects so eventually extra copy-in/out is required > to have the callee see arguments of the desired alignment. > > HJ can probably clarify. > > Note bugzilla isn't really for this kind of questions, there's a psABI > mailing list somewhere. Thanks for your help.
[Bug tree-optimization/94443] [10 Regression] 510.parest_r and 526.blender_r ICE: verify_ssa failed since r10-7491-gbd0f22a8d5caea8905f38ff1fafce31c1b7d33ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94443 Martin Liška changed: What|Removed |Added CC||meissner at gcc dot gnu.org --- Comment #9 from Martin Liška --- *** Bug 94451 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/94451] [10 Regression] April 1st 2020 GCC does not compile spec 2017 gcc_r benchmark with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94451 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Resolution|--- |DUPLICATE Status|ASSIGNED|RESOLVED --- Comment #5 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 94443 ***
[Bug fortran/93581] [9/10 Regression] ICE in gfc_get_dataptr_offset, at fortran/trans-array.c:6951
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93581 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #7 from Tobias Burnus --- Patch was submitted at https://gcc.gnu.org/pipermail/fortran/2020-March/054050.html And committed as r10-7081-g9de42a8e995451cb13dceb3970ae23ff88240bff [As far as I could see, it was not yet backported to GCC 9.] commit 9de42a8e995451cb13dceb3970ae23ff88240bff Author: Paul Thomas Date: Sun Mar 8 18:52:35 2020 + Patch and ChangeLogs for PR93581 +2020-03-08 Paul Thomas + + PR fortran/93581 + * resolve.c (gfc_resolve_ref): Modify array refs to be elements + if the ref chain ends in INQUIRY_LEN. + * trans-array.c (gfc_get_dataptr_offset): Provide the offsets + for INQUIRY_RE and INQUIRY_IM. + +2020-03-08 Paul Thomas + + PR fortran/93581 + * gfortran.dg/inquiry_type_ref_6.f90 : New test. +
[Bug fortran/93833] [8/9/10 Regression] ICE in trans_array_constructor, at fortran/trans-array.c:2566
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93833 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #7 from Tobias Burnus --- Patch was submitted at https://gcc.gnu.org/pipermail/fortran/2020-March/054072.html but the new mailing had stripped off the 'text/x-patch' MIME type back then.
[Bug fortran/93522] [10 Regression] ICE in gfc_release_symbol, at fortran/symbol.c:3121 since r10-2912-g70570ec192745095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93522 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||burnus at gcc dot gnu.org --- Comment #3 from Tobias Burnus --- FIXED – thanks for the report!
[Bug target/94317] gcc/config/arm/arm_mve.h:13907: strange assignment ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94317 --- Comment #9 from CVS Commits --- The master branch has been updated by Kyrylo Tkachov : https://gcc.gnu.org/g:ff825b8158394a01a43359efd91d0b6b8c4fa21b commit r10-7512-gff825b8158394a01a43359efd91d0b6b8c4fa21b Author: Srinath Parvathaneni Date: Thu Apr 2 10:23:47 2020 +0100 [ARM]: Fix for MVE ACLE intrinsics with writeback (PR94317). Following MVE ACLE intrinsics have an issue with writeback to the base address. vldrdq_gather_base_wb_s64, vldrdq_gather_base_wb_u64, vldrdq_gather_base_wb_z_s64, vldrdq_gather_base_wb_z_u64, vldrwq_gather_base_wb_s32, vldrwq_gather_base_wb_u32, vldrwq_gather_base_wb_z_s32, vldrwq_gather_base_wb_z_u32, vldrwq_gather_base_wb_f32, vldrwq_gather_base_wb_z_f32. This patch fixes the bug reported in PR94317 by adding separate builtin calls to update the result and writeback to base address for the above intrinsics. 2020-04-02 Srinath Parvathaneni PR target/94317 * config/arm/arm-builtins.c (LDRGBWBXU_QUALIFIERS): Define. (LDRGBWBXU_Z_QUALIFIERS): Likewise. * config/arm/arm_mve.h (__arm_vldrdq_gather_base_wb_s64): Modify intrinsic defintion by adding a new builtin call to writeback into base address. (__arm_vldrdq_gather_base_wb_u64): Likewise. (__arm_vldrdq_gather_base_wb_z_s64): Likewise. (__arm_vldrdq_gather_base_wb_z_u64): Likewise. (__arm_vldrwq_gather_base_wb_s32): Likewise. (__arm_vldrwq_gather_base_wb_u32): Likewise. (__arm_vldrwq_gather_base_wb_z_s32): Likewise. (__arm_vldrwq_gather_base_wb_z_u32): Likewise. (__arm_vldrwq_gather_base_wb_f32): Likewise. (__arm_vldrwq_gather_base_wb_z_f32): Likewise. * config/arm/arm_mve_builtins.def (vldrwq_gather_base_wb_z_u): Modify builtin's qualifier. (vldrdq_gather_base_wb_z_u): Likewise. (vldrwq_gather_base_wb_u): Likewise. (vldrdq_gather_base_wb_u): Likewise. (vldrwq_gather_base_wb_z_s): Likewise. (vldrwq_gather_base_wb_z_f): Likewise. (vldrdq_gather_base_wb_z_s): Likewise. (vldrwq_gather_base_wb_s): Likewise. (vldrwq_gather_base_wb_f): Likewise. (vldrdq_gather_base_wb_s): Likewise. (vldrwq_gather_base_nowb_z_u): Define builtin. (vldrdq_gather_base_nowb_z_u): Likewise. (vldrwq_gather_base_nowb_u): Likewise. (vldrdq_gather_base_nowb_u): Likewise. (vldrwq_gather_base_nowb_z_s): Likewise. (vldrwq_gather_base_nowb_z_f): Likewise. (vldrdq_gather_base_nowb_z_s): Likewise. (vldrwq_gather_base_nowb_s): Likewise. (vldrwq_gather_base_nowb_f): Likewise. (vldrdq_gather_base_nowb_s): Likewise. * config/arm/mve.md (mve_vldrwq_gather_base_nowb_v4si): Define RTL pattern. (mve_vldrwq_gather_base_wb_v4si): Modify RTL pattern. (mve_vldrwq_gather_base_nowb_z_v4si): Define RTL pattern. (mve_vldrwq_gather_base_wb_z_v4si): Modify RTL pattern. (mve_vldrwq_gather_base_wb_fv4sf): Modify RTL pattern. (mve_vldrwq_gather_base_nowb_fv4sf): Define RTL pattern. (mve_vldrwq_gather_base_wb_z_fv4sf): Modify RTL pattern. (mve_vldrwq_gather_base_nowb_z_fv4sf): Define RTL pattern. (mve_vldrdq_gather_base_nowb_v4di): Define RTL pattern. (mve_vldrdq_gather_base_wb_v4di): Modify RTL pattern. (mve_vldrdq_gather_base_nowb_z_v4di): Define RTL pattern. (mve_vldrdq_gather_base_wb_z_v4di): Modify RTL pattern. gcc/testsuite/ChangeLog: 2020-04-02 Srinath Parvathaneni PR target/94317 * gcc.target/arm/mve/intrinsics/vldrdq_gather_base_wb_s64.c: Modify. * gcc.target/arm/mve/intrinsics/vldrdq_gather_base_wb_u64.c: Likewise. * gcc.target/arm/mve/intrinsics/vldrdq_gather_base_wb_z_s64.c: Likewise. * gcc.target/arm/mve/intrinsics/vldrdq_gather_base_wb_z_u64.c: Likewise. * gcc.target/arm/mve/intrinsics/vldrwq_gather_base_wb_f32.c: Likewise. * gcc.target/arm/mve/intrinsics/vldrwq_gather_base_wb_s32.c: Likewise. * gcc.target/arm/mve/intrinsics/vldrwq_gather_base_wb_u32.c: Likewise. * gcc.target/arm/mve/intrinsics/vldrwq_gather_base_wb_z_f32.c: Likewise. * gcc.target/arm/mve/intrinsics/vldrwq_gather_base_wb_z_s32.c: Likewise. * gcc.target/arm/mve/intrinsics/vldrwq_gather_base_wb_z_u32.c: Likewise.
[Bug target/94445] gcc.target/arm/cmse/cmse-15.c fails for cortex-m33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94445 avieira at gcc dot gnu.org changed: What|Removed |Added CC||avieira at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-04-02 --- Comment #1 from avieira at gcc dot gnu.org --- Hi Christophe, This looks to me like an issue of not building distinct types for the ns_foo_t and s_bar_t function types. When I first wrote this code I tested for this and it was working, so I am wondering whether changes have been made in the way we create types in the c-frontend. I am trying to find out how all this works again, its been a while...
[Bug c++/94453] [10 Regression] ICE in make_decl_rtl since r10-3591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94453 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-04-02 Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed.
[Bug target/94445] gcc.target/arm/cmse/cmse-15.c fails for cortex-m33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94445 --- Comment #2 from avieira at gcc dot gnu.org --- start_decl seems to be doing the right thing, investigation continues...
[Bug debug/94450] lto abstract variable emitted as concrete decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94450
--- Comment #2 from Richard Biener ---
So the current situation is similar to that of
static inline int foo(int i)
{
static int j;
j = i + 1;
return j;
}
int bar(int i)
{
return foo(i);
}
int baz(int i)
{
return foo(i);
}
here we get
<1><2d>: Abbrev Number: 2 (DW_TAG_subprogram)
<2e> DW_AT_name: foo
<32> DW_AT_decl_file : 1
<33> DW_AT_decl_line : 1
<34> DW_AT_prototyped : 1
<34> DW_AT_type: <0x50>
<38> DW_AT_inline : 3(declared as inline and inlined)
<39> DW_AT_sibling : <0x50>
...
<2><46>: Abbrev Number: 4 (DW_TAG_variable)
<47> DW_AT_name: j
<49> DW_AT_decl_file : 1
<4a> DW_AT_decl_line : 3
<4b> DW_AT_type: <0x50>
...
<1><57>: Abbrev Number: 6 (DW_TAG_subprogram)
<58> DW_AT_external: 1
<58> DW_AT_name: bar
...
<2><83>: Abbrev Number: 8 (DW_TAG_inlined_subroutine)
<84> DW_AT_abstract_origin: <0x2d>
<88> DW_AT_low_pc : 0x0
<90> DW_AT_high_pc : 0x9
<98> DW_AT_call_file : 1
<99> DW_AT_call_line : 10
<3><9a>: Abbrev Number: 9 (DW_TAG_formal_parameter)
<9b> DW_AT_abstract_origin: <0x3d>
<9f> DW_AT_location: 1 byte block: 55 (DW_OP_reg5 (rdi))
<3>: Abbrev Number: 10 (DW_TAG_lexical_block)
DW_AT_low_pc : 0x0
DW_AT_high_pc : 0x9
<4>: Abbrev Number: 11 (DW_TAG_variable)
DW_AT_abstract_origin: <0x46>
DW_AT_location: 9 byte block: 3 0 0 0 0 0 0 0 0 (DW_OP_addr: 0)
...
<1>: Abbrev Number: 12 (DW_TAG_subprogram)
DW_AT_external: 1
DW_AT_name: baz
...
<2>: Abbrev Number: 8 (DW_TAG_inlined_subroutine)
DW_AT_abstract_origin: <0x2d>
DW_AT_low_pc : 0x10
DW_AT_high_pc : 0x9
<101> DW_AT_call_file : 1
<102> DW_AT_call_line : 15
<3><103>: Abbrev Number: 9 (DW_TAG_formal_parameter)
<104> DW_AT_abstract_origin: <0x3d>
<108> DW_AT_location: 1 byte block: 55(DW_OP_reg5 (rdi))
<3><10a>: Abbrev Number: 10 (DW_TAG_lexical_block)
<10b> DW_AT_low_pc : 0x10
<113> DW_AT_high_pc : 0x9
<4><11b>: Abbrev Number: 11 (DW_TAG_variable)
<11c> DW_AT_abstract_origin: <0x46>
<120> DW_AT_location: 9 byte block: 3 0 0 0 0 0 0 0 0
(DW_OP_addr: 0)
which also means at least two (in the DW_TAG_inlined_subroutine instances)
concrete variables named 'j'. Not sure if the <46> DIE is a concrete
variable - DWARF doesn't have linkage attributes and the containing
subroutine DIE is marked with DW_AT_inline.
Note we're not emitting a concrete instance of the function which would
contain the "main" instance of 'j'. Not sure what the DWARF for a
standalone concrete instantiation of 'j' would look like.
So current LTO is modeled after this, the early debug contains abstract
instances only (also for non-functions, thus global variables), albeit
not marked as such in all cases. The LTRANS debug contains all concrete
(and inline) instances.
[Bug debug/94450] lto abstract variable emitted as concrete decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94450
--- Comment #3 from Richard Biener ---
(In reply to Richard Biener from comment #2)
> So the current situation is similar to that of
Modifying the testcase to C99
inline int foo(int i)
{
static int j;
j = i + 1;
return j;
}
int bar(int i)
{
return foo(i);
}
int baz(int i)
{
return foo(i);
}
extern int foo(int i);
[...]
> Note we're not emitting a concrete instance of the function which would
> contain the "main" instance of 'j'. Not sure what the DWARF for a
> standalone concrete instantiation of 'j' would look like.
The concrete instance is emitted:
<1><57>: Abbrev Number: 6 (DW_TAG_subprogram)
<58> DW_AT_abstract_origin: <0x2d>
<5c> DW_AT_low_pc : 0x0
<64> DW_AT_high_pc : 0xa
<6c> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
<6e> DW_AT_GNU_all_call_sites: 1
<6e> DW_AT_sibling : <0x89>
<2><72>: Abbrev Number: 7 (DW_TAG_formal_parameter)
<73> DW_AT_abstract_origin: <0x3d>
<77> DW_AT_location: 1 byte block: 55 (DW_OP_reg5 (rdi))
<2><79>: Abbrev Number: 8 (DW_TAG_variable)
<7a> DW_AT_abstract_origin: <0x46>
<7e> DW_AT_location: 9 byte block: 3 0 0 0 0 0 0 0 0 (DW_OP_addr: 0)
so here's another copy of the variable.
I guess for function local variables gdb isn't fooled to think it has
two copies? And the bogus copy is not because of the abstract origin
link but because of the unit import but could be brought in by other
means of making gdb read the DWARF of it?
[Bug tree-optimization/94451] [10 Regression] April 1st 2020 GCC does not compile spec 2017 gcc_r benchmark with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94451 Kewen Lin changed: What|Removed |Added Resolution|DUPLICATE |FIXED --- Comment #6 from Kewen Lin --- Reproduced and verified with the proposed fix in pr94443, sorry for the trouble.
[Bug debug/94450] lto abstract variable emitted as concrete decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94450 --- Comment #4 from Richard Biener --- Created attachment 48168 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48168&action=edit patch to drop DW_TAG_imported_unit DIEs I'm testing this patch. Does it help?
[Bug target/94435] [9/10 Regression] ICE in extract_insn, at recog.c:2294
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94435 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:66e327517b10a19690a470c8dccfa363ba061022 commit r10-7513-g66e327517b10a19690a470c8dccfa363ba061022 Author: Jakub Jelinek Date: Thu Apr 2 12:54:47 2020 +0200 aarch64: Fix ICE due to aarch64_gen_compare_reg_maybe_ze [PR94435] The following testcase ICEs, because aarch64_gen_compare_reg_maybe_ze emits invalid RTL. For y_mode [QH]Imode it expects y to be of that mode (or CONST_INT that fits into that mode) and x being SImode; for non-CONST_INT y it zero extends y into SImode and compares that against x, for CONST_INT y it zero extends y into SImode. The problem is that when the zero extended constant isn't usable directly, it forces it into a REG, but with y_mode mode, and then compares against y. That is wrong, because it should force it into a SImode REG and compare that way. 2020-04-02 Jakub Jelinek PR target/94435 * config/aarch64/aarch64.c (aarch64_gen_compare_reg_maybe_ze): For y_mode E_[QH]Imode and y being a CONST_INT, change y_mode to SImode. * gcc.target/aarch64/pr94435.c: New test.
[Bug target/94435] [9/10 Regression] ICE in extract_insn, at recog.c:2294
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94435 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:df562b12d90699c20923f91df48eed08ebcb572e commit r10-7514-gdf562b12d90699c20923f91df48eed08ebcb572e Author: Jakub Jelinek Date: Thu Apr 2 12:57:11 2020 +0200 aarch64: Fix ICE due to aarch64_gen_compare_reg_maybe_ze [PR94435] The following testcase ICEs, because aarch64_gen_compare_reg_maybe_ze emits invalid RTL. For y_mode [QH]Imode it expects y to be of that mode (or CONST_INT that fits into that mode) and x being SImode; for non-CONST_INT y it zero extends y into SImode and compares that against x, for CONST_INT y it zero extends y into SImode. The problem is that when the zero extended constant isn't usable directly, it forces it into a REG, but with y_mode mode, and then compares against y. That is wrong, because it should force it into a SImode REG and compare that way. 2020-04-02 Jakub Jelinek PR target/94435 * config/aarch64/aarch64.c (aarch64_gen_compare_reg_maybe_ze): For y_mode E_[QH]Imode and y being a CONST_INT, change y_mode to SImode. * gcc.target/aarch64/pr94435.c: New test.
[Bug target/94435] [9/10 Regression] ICE in extract_insn, at recog.c:2294
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94435 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:be64fc4cab7facee309447302b6ee7616dfe60b4 commit r9-8442-gbe64fc4cab7facee309447302b6ee7616dfe60b4 Author: Jakub Jelinek Date: Thu Apr 2 12:54:47 2020 +0200 aarch64: Fix ICE due to aarch64_gen_compare_reg_maybe_ze [PR94435] The following testcase ICEs, because aarch64_gen_compare_reg_maybe_ze emits invalid RTL. For y_mode [QH]Imode it expects y to be of that mode (or CONST_INT that fits into that mode) and x being SImode; for non-CONST_INT y it zero extends y into SImode and compares that against x, for CONST_INT y it zero extends y into SImode. The problem is that when the zero extended constant isn't usable directly, it forces it into a REG, but with y_mode mode, and then compares against y. That is wrong, because it should force it into a SImode REG and compare that way. 2020-04-02 Jakub Jelinek PR target/94435 * config/aarch64/aarch64.c (aarch64_gen_compare_reg_maybe_ze): For y_mode E_[QH]Imode and y being a CONST_INT, change y_mode to SImode. * gcc.target/aarch64/pr94435.c: New test.
[Bug target/94435] [9/10 Regression] ICE in extract_insn, at recog.c:2294
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94435 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed. Will need to be backported to 8 once -moutline-atomics is backported there.
[Bug lto/94249] [10 regression] Many -flto -fuse-linker-plugin tests FAIL: could not add symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94249 --- Comment #21 from Martin Liška --- (In reply to Khem Raj from comment #20) > (In reply to CVS Commits from comment #18) > > The master branch has been updated by Martin Liska : > > > > https://gcc.gnu.org/g:142d68f50b48309f48e34fc1d9d6dbbeecfde684 > > > > commit r10-7492-g142d68f50b48309f48e34fc1d9d6dbbeecfde684 > > Author: Martin Liska > > Date: Wed Apr 1 09:37:37 2020 +0200 > > > > Fix typo in a macro usage. > > > > PR lto/94249 > > * plugin-api.h: Fix a typo. > > > this patch seems to be causing gcc ICE on ARM when compiling lz4 sources in > kernel, lz4, vlc almost identical ICE is seen > > attached is the test case please compile it with -O3 > > during GIMPLE pass: vect > lz4.c: In function 'LZ4_compress_fast_extState': > lz4.c:1180:5: internal compiler error: Segmentation fault > 1180 | int LZ4_compress_fast_extState(void* state, const char* source, > char* dest, int inputSize, int maxOutputSize, int acceleration) > | ^~ > Please submit a full bug report, You pointed to a bad bug, you wanted to point to PR94443?
[Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94359 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org Host|powerpc64*-linux-gnu|powerpc64*-linux-gnu, ||sparc-sun-solaris2.11 Target|powerpc64*-linux-gnu|powerpc64*-linux-gnu, ||sparc-sun-solaris2.11 Build|powerpc64*-linux-gnu|powerpc64*-linux-gnu, ||sparc-sun-solaris2.11 --- Comment #7 from Rainer Orth --- I'm seeing the same failure on Solaris/SPARC (32 and 64-bit).
[Bug target/94445] gcc.target/arm/cmse/cmse-15.c fails for cortex-m33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94445 --- Comment #3 from Christophe Lyon --- I also checked that arm_handle_cmse_nonsecure_call correctly duplicates the type.
[Bug c++/94453] [10 Regression] ICE in make_decl_rtl since r10-3591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94453
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
--- Comment #2 from ensadc at mailnesia dot com ---
void *ay();
template f ay() { return *static_cast(ay()); }
template
void bf() {
ay()();
}
struct az {
template
az(h);
using bk = void (*)();
bk bl;
};
template
az::az(h) { bl = bf; }
struct A {};
void da(az);
void di(A, int);
void dk(A, az, az);
void b() {
int data = 0;
auto n = [] {};
constexpr auto p = A{};
auto q = [=] { di(p, data); };
da([=] { dk(p, n, q); });
}
[Bug debug/94439] [10 Regression] gcc: error: gcc/testsuite/gcc.dg/torture/builtin-complex-1.c: ‘-fcompare-debug’ failure since r10-3499-g0ce77f463d1d150e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94439 Jakub Jelinek changed: What|Removed |Added CC||aoliva at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- I'm afraid scheduler -fcompare-debug issues are something I need to give up on.
[Bug target/94364] 505.mcf_r is 8% faster when compiled with -mprefer-vector-width=128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94364 --- Comment #4 from Martin Liška --- Created attachment 48169 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48169&action=edit qsort patch I'm sending spec_qsort patch we use. I'm going to prepare a patch that will revert this and add -fno-strict-aliasing attribute to the function.
[Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94359 --- Comment #8 from Iain Sandoe --- (In reply to Rainer Orth from comment #7) > I'm seeing the same failure on Solaris/SPARC (32 and 64-bit). Do you have any info on why the tail-call fails there? (e.g. is it not possible to make an indirect tail-call in the ABI, as seems to be the case for powerpc64 & AIX). At present, having discussed with a couple of other folks, my plan (for stage 4) is to produce a target hook to allow targets to opt out. For next stage 1, since the caller and the callee are both under our control and it is known that the callee *must* be another coroutine 'actor' function it might be possible to work around specific target constraints.
[Bug target/94445] gcc.target/arm/cmse/cmse-15.c fails for cortex-m33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94445 --- Comment #4 from avieira at gcc dot gnu.org --- Yeah... So far I have checked that 'gimplify_call_expr' creates the right gimple, and up until 'gimplify_modify_expr' I can verify it does by using gimple_call_fntype . Though at expansion time, the 'gimple_call_fntype (stmt)' of '_5 = s_bar_p_2(D) (); [tail call]' now has the attribute ... So it must go wrong somewhere between gimplification and expansion, but that's a big window and dump files won't help us :(
[Bug target/94445] gcc.target/arm/cmse/cmse-15.c fails for cortex-m33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94445 --- Comment #5 from avieira at gcc dot gnu.org --- Yeah... So far I have checked that 'gimplify_call_expr' creates the right gimple, and up until 'gimplify_modify_expr' I can verify it does by using gimple_call_fntype . Though at expansion time, the 'gimple_call_fntype (stmt)' of '_5 = s_bar_p_2(D) (); [tail call]' now has the attribute ... So it must go wrong somewhere between gimplification and expansion, but that's a big window and dump files won't help us :(
[Bug rtl-optimization/93264] [10 Regression] ICE in cfg_layout_redirect_edge_and_branch_force, at cfgrtl.c:4522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93264 --- Comment #7 from Richard Biener --- So let's try to address this in cfgloop.c - we're likely facing the situation of header: ... if (...) goto latch1; latch2: goto header; latch1: // in cold section goto header; where latch disambiguation via merge_latch_egdes tries to build header: ... if (...) goto latch1; latch2: goto latch3; latch1: // in cold section goto latch3; latch3: // somewhere goto header; but somehow we end up redirecting a jump that was formerly crossing to non-crossing. Looking at the backtrace it must be entry edges that are being redirected but the whole setup should be so that the crossing state of a branch is never changed. Unfortunately I can't reproduce on todays trunk, will try rewiding backwards to the reporting time to have a closer look.
[Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94359 Rainer Orth changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #9 from Rainer Orth --- (In reply to Iain Sandoe from comment #8) > (In reply to Rainer Orth from comment #7) > > I'm seeing the same failure on Solaris/SPARC (32 and 64-bit). > > Do you have any info on why the tail-call fails there? > (e.g. is it not possible to make an indirect tail-call in the ABI, as seems > to be the case for powerpc64 & AIX). No. I guess Eric (Cc'ed) is in a better position to answer that.
[Bug target/94452] I386 ABI: How to determine the alignment arguments on the stack of struct or union for argument passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94452 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #6 from H.J. Lu --- (In reply to ChenLiu from comment #5) > (In reply to Richard Biener from comment #4) > > (In reply to ChenLiu from comment #2) > > > (In reply to Richard Biener from comment #1) > > > > I see gx aligned to 64 bytes (as I expected). Can you be more specific > > > > as > > > > to what target you tested? > > > > > > I tested on i386 target. I think you may misunderstand what I mean. The gx > > > will align to 4 byte when passing it on stack. I think this should belong > > > to > > > calling conventions. > > > > Ah, OK. IIRC the psABI does not factor in over/under alignment but only > > size and kind of (sub-)objects so eventually extra copy-in/out is required > > to have the callee see arguments of the desired alignment. > > > > HJ can probably clarify. > > > > Note bugzilla isn't really for this kind of questions, there's a psABI > > mailing list somewhere. > > Thanks for your help. Please raise this question at https://groups.google.com/forum/#!forum/ia32-abi
[Bug target/94364] 505.mcf_r is 8% faster when compiled with -mprefer-vector-width=128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94364
--- Comment #5 from Martin Liška ---
With something like:
diff --git a/benchspec/CPU/505.mcf_r/src/spec_qsort/spec_qsort.c
b/benchspec/CPU/505.mcf_r/src/spec_qsort/spec_qsort.c
index 05cad501..ad79ddae 100755
--- a/benchspec/CPU/505.mcf_r/src/spec_qsort/spec_qsort.c
+++ b/benchspec/CPU/505.mcf_r/src/spec_qsort/spec_qsort.c
@@ -112,6 +112,7 @@ med3(char *a, char *b, char *c, cmp_t *cmp)
}
void
+__attribute__((optimize("-fno-strict-aliasing")))
spec_qsort(void *a, size_t n, size_t es, cmp_t *cmp)
{
char *pa, *pb, *pc, *pd, *pl, *pm, *pn;
diff --git a/benchspec/CPU/505.mcf_r/src/spec_qsort/spec_qsort.h
b/benchspec/CPU/505.mcf_r/src/spec_qsort/spec_qsort.h
index 0519f867..c25a1159 100755
--- a/benchspec/CPU/505.mcf_r/src/spec_qsort/spec_qsort.h
+++ b/benchspec/CPU/505.mcf_r/src/spec_qsort/spec_qsort.h
@@ -6,5 +6,7 @@
#ifdef __cplusplus
extern "C"
#endif
-void spec_qsort(void *array, size_t nitems, size_t size, int (*cmp)(const
void*,const void*));
+void
+__attribute__((optimize("-fno-strict-aliasing")))
+spec_qsort(void *array, size_t nitems, size_t size, int (*cmp)(const
void*,const void*));
#endif
and -Ofast -march=znver2 I get:
21.95% mcf_r_peak.gcc7 mcf_r_peak.gcc7-m64 [.] cost_compare
19.95% mcf_r_peak.gcc7 mcf_r_peak.gcc7-m64 [.] spec_qsort
19.63% mcf_r_peak.gcc7 mcf_r_peak.gcc7-m64 [.] primal_bea_mpp
14.20% mcf_r_peak.gcc7 mcf_r_peak.gcc7-m64 [.] replace_weaker_arc
9.17% mcf_r_peak.gcc7 mcf_r_peak.gcc7-m64 [.] arc_compare
8.47% mcf_r_peak.gcc7 mcf_r_peak.gcc7-m64 [.] price_out_impl
1.37% mcf_r_peak.gcc7 mcf_r_peak.gcc7-m64 [.] update_tree
0.97% mcf_r_peak.gcc7 mcf_r_peak.gcc7-m64 [.] switch_arcs.constprop.0
0.83% mcf_r_peak.gcc7 mcf_r_peak.gcc7-m64 [.] suspend_impl
0.69% mcf_r_peak.gcc7 mcf_r_peak.gcc7-m64 [.] primal_iminus
[Bug rtl-optimization/93264] [10 Regression] ICE in cfg_layout_redirect_edge_and_branch_force, at cfgrtl.c:4522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93264 --- Comment #8 from Jakub Jelinek --- (In reply to Richard Biener from comment #7) > Unfortunately I can't reproduce on todays trunk, will try rewiding backwards > to the reporting time to have a closer look. Strange, I can (tried r10-7514). ./cc1 -quiet -nostdinc -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions -fmodulo-sched -freorder-blocks-and-partition pr71550.c x86_64-linux -> aarch64-linux cross with installed cross-binutils for the target.
[Bug rtl-optimization/93264] [10 Regression] ICE in cfg_layout_redirect_edge_and_branch_force, at cfgrtl.c:4522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93264
--- Comment #9 from Richard Biener ---
Pilot error.
loop->header is in the cold partition, both latch sources are as well,
the loop entry source is in the hot partition. We're correctly
redirecting that from hot -> cold to hot -> cold state so
if (e->flags & EDGE_CROSSING
&& BB_PARTITION (e->src) == BB_PARTITION (dest)
&& simplejump_p (BB_END (src)))
{
doesn't apply anyways so we run into
edge
try_redirect_by_replacing_jump (edge e, basic_block target, bool in_cfglayout)
{
...
/* If we are partitioning hot/cold basic blocks, we don't want to
mess up unconditional or indirect jumps that cross between hot
and cold sections.
Basic block partitioning may result in some jumps that appear to
be optimizable (or blocks that appear to be mergeable), but which really
must be left untouched (they are required to make it safely across
partition boundaries). See the comments at the top of
bb-reorder.c:partition_hot_cold_basic_blocks for complete details. */
if (BB_PARTITION (src) != BB_PARTITION (target))
return NULL;
where the referenced comment says
IMPORTANT NOTE: This optimization causes some messy interactions
with the cfg cleanup optimizations; those optimizations want to
merge blocks wherever possible, and to collapse indirect jump
sequences (change "A jumps to B jumps to C" directly into "A jumps
to C"). Those optimizations can undo the jump fixes that
partitioning is required to make (see above), in order to ensure
that jumps attempting to cross section boundaries are really able
to cover whatever distance the jump requires (on many architectures
conditional or unconditional jumps are not able to reach all of
memory). Therefore tests have to be inserted into each such
optimization to make sure that it does not undo stuff necessary to
cross partition boundaries. This would be much less of a problem
if we could perform this optimization later in the compilation, but
unfortunately the fact that we may need to create indirect jumps
(through registers) requires that this optimization be performed
before register allocation.
but any such fixup jumps would appear inside the original section
(and not crossing). So preserving the crossing state should be a
good enough and better check?
diff --git a/gcc/cfgrtl.c b/gcc/cfgrtl.c
index fb551e3efc0..f2783b1d7ed 100644
--- a/gcc/cfgrtl.c
+++ b/gcc/cfgrtl.c
@@ -1046,7 +1046,7 @@ try_redirect_by_replacing_jump (edge e, basic_block
target, bool in_cfglayout)
partition boundaries). See the comments at the top of
bb-reorder.c:partition_hot_cold_basic_blocks for complete details. */
- if (BB_PARTITION (src) != BB_PARTITION (target))
+ if (BB_PARTITION (e->dest) != BB_PARTITION (target))
return NULL;
/* We can replace or remove a complex jump only when we have exactly
covers the testcase but will inhibit redirects allowed previously
when e->src is hot, e->dest was cold and target is now hot. But that
should be covered by the special-case using simplejump_p.
Ah, OK, here the jump is an indirect one, so not simple. And we'd
need to replace it with an indirect one for partitioning correctness
which we are not able to do here.
For the testcase at hand we could use sth else than make_forwarder_block,
like manually create a new BB, redirect all latches to it and then
create a new edge to the old header from it. The redirects/creations
would be all in the same partition. But then there may be the case
of a latch edge being crossing (a very cold latch in a hot loop) and
we'd face the very same issue.
Currently loop analysis thinks it can always make loops only have a single
latch so "failure" isn't an option here.
So we need to teach cfgrtl.c to redirect forming a similar instruction
as it was there before (create another indirect jump, but after reload
this needs a register - we don't know whether the jump target reg is
live). Ugh.
On the testcase itself
diff --git a/gcc/modulo-sched.c b/gcc/modulo-sched.c
index 77254b31b42..66260fa34f1 100644
--- a/gcc/modulo-sched.c
+++ b/gcc/modulo-sched.c
@@ -1347,8 +1347,7 @@ sms_schedule (void)
edge latch_edge;
HOST_WIDE_INT trip_count, max_trip_count;
- loop_optimizer_init (LOOPS_HAVE_PREHEADERS
- | LOOPS_HAVE_RECORDED_EXITS);
+ loop_optimizer_init (AVOID_CFG_MODIFICATIONS);
if (number_of_loops (cfun) <= 1)
{
loop_optimizer_finalize ();
works.
[Bug c++/94454] New: ICE 'canonical types differ for identical types'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454 Bug ID: 94454 Summary: ICE 'canonical types differ for identical types' Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: iains at gcc dot gnu.org Target Milestone: --- This a bug reported by Eric Niebler when building the ranges-v3 code on Darwin19, however it's not a Darwin-specific problem. This is a very slippery bug to pin down (possibly a dup of 90301, but unknown at present) The failure on a given platform seems to depend on the compiler build. I have now seen fails on x86-64-linux-gnu, powerpc64-linux-gnu, *darwin*. Some compiler builds fail almost consistently on a given platform, but a later build could easily pass every time. Often the fail is ≈ 1 time in 5 attempts. tried: --with-checking=yes,gcac --param ggc-min-expand=0 --param ggc-min-heapsize=0 Neither altered the repeatability. Jonathan did a run under valgrind which was also inconclusive. I've tried (manually) a fairly large number of permutation of options etc. without any pattern emerging. At present a hunch is that it's maybe an uninitialised var, or perhaps something that depends on the order in which things get initialised. ** Trying to reduce on x86-64-linux-gnu and x86-64-darwin16 (but going very slowly). /home/iains/range-v3/include/meta/meta.hpp:1216:11: internal compiler error: canonical types differ for identical types ‘std::integral_constant >’ and ‘std::integral_constant >’ 1216 | using if_c = _t, Args...>>; | ^~~~ 0x1054ba4b comptypes(tree_node*, tree_node*, int) ../../src/gcc/cp/typeck.c:1519 0x1053679f cp_tree_equal(tree_node*, tree_node*) ../../src/gcc/cp/tree.c:3940 0x10536523 cp_tree_equal(tree_node*, tree_node*) ../../src/gcc/cp/tree.c:3933 0x1043318f template_args_equal(tree_node*, tree_node*, bool) ../../src/gcc/cp/pt.c:9043 0x10432e13 template_args_equal(tree_node*, tree_node*, bool) ../../src/gcc/cp/pt.c:8985 0x10432e13 comp_template_args(tree_node*, tree_node*, tree_node**, tree_node**, bool) ../../src/gcc/cp/pt.c:9072 0x10432e13 comp_template_args(tree_node*, tree_node*, tree_node**, tree_node**, bool) ../../src/gcc/cp/pt.c:9052 0x104463bf spec_hasher::equal(spec_entry*, spec_entry*) ../../src/gcc/cp/pt.c:1703 0x104c577f hash_table::find_with_hash(spec_entry* const&, unsigned int) ../../src/gcc/hash-table.h:917 0x1049545b lookup_template_class_1 ../../src/gcc/cp/pt.c:9680 0x10499da3 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*, int, int) ../../src/gcc/cp/pt.c:10020 0x10499da3 tsubst_aggr_type ../../src/gcc/cp/pt.c:13301 0x1048e023 tsubst_template_args(tree_node*, tree_node*, int, tree_node*) ../../src/gcc/cp/pt.c:13092 0x1048e66b tsubst_argument_pack(tree_node*, tree_node*, int, tree_node*) ../../src/gcc/cp/pt.c:13040 0x1048e0f3 tsubst_template_args(tree_node*, tree_node*, int, tree_node*) ../../src/gcc/cp/pt.c:13090 0x10499d4f tsubst_aggr_type ../../src/gcc/cp/pt.c:13295 0x1048e023 tsubst_template_args(tree_node*, tree_node*, int, tree_node*) ../../src/gcc/cp/pt.c:13092 0x1048965b tsubst(tree_node*, tree_node*, int, tree_node*) ../../src/gcc/cp/pt.c:14946 0x10479c0b tsubst_decl ../../src/gcc/cp/pt.c:14377 0x1049a5e3 instantiate_template_1 ../../src/gcc/cp/pt.c:20588 Please submit a full bug report,
[Bug debug/94450] lto abstract variable emitted as concrete decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94450 --- Comment #5 from Tom de Vries --- (In reply to Richard Biener from comment #1) > I guess the more correct DWARF would be to have the 13d DIE include > DW_AT_declaration? Well, currently the debug info contains two concrete symbols, one with and one without location information. The things that makes the latter symbol concrete are both the fact that it's contained in a CU (as opposed to in a PU), as well as that it's imported into another CU (in fact, one could make an argument that in fact three concrete symbols are present, but let's not go there). So, if we'd mark the one without location information as declaration we'd still have two concrete symbols. It could be pedantically argued that tagging the symbol as declaration is incorrect because there's in fact no declaration in the source that it corresponds to. That could be fixed by marking the declaration with DW_AT_artificial == 1 (and perhaps marking the def with DW_AT_artificial == 0 in order to make sure the artificial setting is not inherited, in case we go the DW_AT_specification route). Btw, the dwarf5 standard lists DW_AT_artificial as applicable to DW_TAG_variable, and the dwarf4 standard doesn't. I'm not sure yet whether that reflects improved documentation or an actual change. But indeed, marking it as declaration would make the situation resemble more non-lto code (for the case where the source has indeed both a decl and def). I wonder even if the DW_AT_artificial marking itself (irrespective of a possible DW_AT_declaration) is used or could be used in gdb to fix PR gdb/25760. I'll have to mock up a gdb testsuite dwarf assembly test-case resembling the test-case and experiment a bit to see what works, and whether gdb needs changes. Anyway, the point I was trying to make is that the easiest way to make decls abstract (rather than adding stuff to the decl itself), is by making the decl not a top-level member of CU, in other words: declare it in a PU, and don't import it into another CU. > Then we could also stop the "abuse" of > DW_AT_abstract_origin > and instead have to use DW_AT_specification. But I'm not sure whether > DW_AT_specification allows cross CU references (technically yes but > practically) especially since there's explicit wording that > DW_AT_specification > cannot refer to type unit entities. > Using DW_AT_specification sounds cleaner, agreed. > Note I originally saw all early debug as abstract (but we're not consistently > emitting DW_AT_inline to all early function DIEs either) but that concept > doesn't apply to globals. > > As you said the DW_TAG_imported_unit serve no useful purpose (I originally > thought that it would provide proper name-lookup scopes but that works > correct in other ways). And I'm fine to simply drop those (also given > consumers seem to handle references to CUs not explicitely imported just > fine). That could be done for GCC 10 already, I fear the rest needs more > testing? > Yeah, I think the part of dropping the imports should be safe, and the rest should be decided once we have more info from playing with the above-mentioned mockup example. > Btw, thanks for sanity checking the LTO DWARF. Sure. I'm working on trying to improve gdb speed for lto executables, and in order to test gdb patches I need to regression test in lto mode, where I do run into regressions, which need to be analyzed, and that's how I'm running into this sort of issues.
[Bug c++/94454] ICE 'canonical types differ for identical types'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454 Iain Sandoe changed: What|Removed |Added Last reconfirmed||2020-04-02 Keywords||ice-on-valid-code Target Milestone|--- |10.0 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Known to fail||10.0
[Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #39 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:2c0fa3ecf70d199af18785702e9e0548fd3ab793
commit r10-7515-g2c0fa3ecf70d199af18785702e9e0548fd3ab793
Author: Jakub Jelinek
Date: Thu Apr 2 14:28:14 2020 +0200
cselib: Reuse VALUEs on sp adjustments [PR92264]
As discussed in the PR, if !ACCUMULATE_OUTGOING_ARGS on large functions we
can have hundreds of thousands of stack pointer adjustments and cselib
creates a new VALUE after each sp adjustment, which form extremely deep
VALUE chains, which is very harmful e.g. for find_base_term.
E.g. if we have
sp -= 4
sp -= 4
sp += 4
sp += 4
sp -= 4
sp += 4
that means 7 VALUEs, one for the sp at beginning (val1), than val2 = val1 -
4, then val3 = val2 - 4, then val4 = val3 + 4, then val5 = val4 + 4, then
val6 = val5 - 4, then val7 = val6 + 4.
This patch tweaks cselib, so that it is smarter about sp adjustments.
When cselib_lookup (stack_pointer_rtx, Pmode, 1, VOIDmode) and we know
nothing about sp yet (this happens at the start of the function, for
non-var-tracking also after cselib_reset_table and for var-tracking after
processing fp_setter insn where we forget about former sp values because
that is now hfp related while everything after it is sp related), we
look it up normally, but in addition to what we have been doing before
we mark the VALUE as SP_DERIVED_VALUE_P. Further lookups of sp + offset
are then special cased, so that it is canonicalized to that
SP_DERIVED_VALUE_P VALUE + CONST_INT (if possible). So, for the above,
we get val1 with SP_DERIVED_VALUE_P set, then val2 = val1 - 4, val3 = val1
-
8 (note, no longer val2 - 4!), then we get val2 again, val1 again, val2
again, val1 again.
In the find_base_term visited_vals.length () > 100 find_base_term
statistics during combined x86_64-linux and i686-linux bootstrap+regtest
cycle, without the patch I see:
find_base_term > 100
returning NULL returning non-NULL
32-bit compilations 4229178 407
64-bit compilations 217523 0
with largest visited_vals.length () when returning non-NULL being 206.
With the patch the same numbers are:
32-bit compilations 1249588 135
64-bit compilations 35100
with largest visited_vals.length () when returning non-NULL being 173.
This shows significant reduction of the deep VALUE chains.
On powerpc64{,le}-linux, these stats didn't change at all, we have
10080
for all of -m32, -m64 and little-endian -m64, just the
gcc.dg/pr85180.c and gcc.dg/pr87985.c testcases which are unrelated to sp.
My earlier version of the patch, which contained just the rtl.h and
cselib.c
changes, regressed some tests:
gcc.dg/guality/{pr36728-{1,3},pr68860-{1,2}}.c
gcc.target/i386/{pr88416,sse-{13,23,24,25,26}}.c
The problem with the former tests was worse debug info, where with -m32
where arg7 was passed in a stack slot we though a push later on might have
invalidated it, when it couldn't. This is something I've solved with the
var-tracking.c (vt_initialize) changes. In those problematic functions, we
create a cfa_base VALUE (argp) and want to record that at the start of
the function the argp VALUE is sp + off and also record that current sp
VALUE is argp's VALUE - off. The second permanent equivalence didn't make
it after the patch though, because cselib_add_permanent_equiv will
cselib_lookup the value of the expression it wants to add as the
equivalence
and if it is the same VALUE as we are calling it on, it doesn't do
anything;
and due to the cselib changes for sp based accesses that is exactly what
happened. By reversing the order of the cselib_add_permanent_equiv calls
we
get both equivalences though and thus are able to canonicalize the sp based
accesses in var-tracking to the cfa_base value + offset.
The i386 FAILs were all ICEs, where we had pushf instruction pushing flags
and then pop pseudo reading that value again. With the cselib changes,
cselib during RTL DSE is able to see through the sp adjustment and wanted
to replace_read what was done pushf, by moving the flags register into a
pseudo and replace the memory read in the pop with that pseudo. That is
wrong for two reasons: one is that the backend doesn't have an instruction
to move the flags hard register into some other register, but replace_read
has been validating just the mem -> pseudo replacement and not the insns
emitted by copy_to_mode_reg. And the second issue is that it is obviously
wrong to replace a stack pop which contains stack post-increment by a copy
of pseudo into destination. dse.c
[Bug rtl-optimization/93264] [10 Regression] ICE in cfg_layout_redirect_edge_and_branch_force, at cfgrtl.c:4522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93264 --- Comment #10 from Richard Biener --- Makes me wonder if hot/cold splitting should use a special jump instruction for crossing jumps which we could fixup/split very late so we see (parallel (set reg (label_ref ..)) (set pc (reg)) (clobber reg)) or something like that. That is, make sure the crossing jump, if indirect, has the destination computation easily accessible and replaceable.
[Bug target/94445] gcc.target/arm/cmse/cmse-15.c fails for cortex-m33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94445 --- Comment #6 from avieira at gcc dot gnu.org --- I have also identified that this only goes wrong in O2 or higher. And it happens sometime between tailcall optimization pass 1 and 2. But there's loads of passes in between.
[Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264 --- Comment #40 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:86c924113208f58fdda24078c9cc9285ee8000cd commit r10-7516-g86c924113208f58fdda24078c9cc9285ee8000cd Author: Jakub Jelinek Date: Thu Apr 2 14:34:42 2020 +0200 params: Decrease -param=max-find-base-term-values= default [PR92264] For the PR in question, my proposal would be to also lower -param=max-find-base-term-values= default from 2000 to 200 after this, at least in the above 4 bootstraps/regtests there is nothing that would ever result in find_base_term returning non-NULL with more than 200 VALUEs being processed. 2020-04-02 Jakub Jelinek PR rtl-optimization/92264 * params.opt (-param=max-find-base-term-values=): Decrease default from 2000 to 200.
[Bug c++/94454] ICE 'canonical types differ for identical types'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454 --- Comment #1 from Iain Sandoe --- there's a gist here: https://gist.github.com/jwakely/e131d3a268a78764458186eff02f29ec with Jonathan's valgrind session and some debug output from one case where I managed to catch the fail under a debugger.
[Bug c++/94454] ICE 'canonical types differ for identical types'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I'd suggest to tweak the compiler, so that spec_hasher::hash always returns 0, if the bug is reproduceable with that, perhaps it might be much faster to reduce it that way.
[Bug c++/94454] ICE 'canonical types differ for identical types'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454 --- Comment #3 from Jakub Jelinek --- See also PR94044 for this, including a patch to do so.
[Bug d/94455] New: no [] operator overload for type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94455
Bug ID: 94455
Summary: no [] operator overload for type
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
The following testcase is rejected by gdc (trunk, or 9.x), while accepted by
dmd 2.089 or ldc 1.18.0 or later (tried on d.godbolt.org). Though, admittedly
dmd 2.082 or ldc 1.17.0 and earlier also reject it.
import std.stdio;
import std.array;
import std.conv;
int main()
{
auto w = appender!string;
// pre-allocate space for at least 10 elements (this avoids costly
reallocations)
w.reserve(10);
assert(w.capacity >= 10);
w.put('a'); // single elements
w.put("bc"); // multiple elements
// use the append syntax
w ~= 'd';
w ~= "ef";
writeln(w[]); // "abcdef"
return 0;
}
[Bug c++/94454] ICE 'canonical types differ for identical types'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454
Nathan Sidwell changed:
What|Removed |Added
CC||nathan at gcc dot gnu.org
--- Comment #4 from Nathan Sidwell ---
Oh, it is from the template specialization hash table. I suggest making that
very poor to increase collisions:
pt.c:
static hashval_t
hash_tmpl_and_args (tree tmpl, tree args)
{
hashval_t val = iterative_hash_object (DECL_UID (tmpl), 0);
return val; // INSERT THIS LINE
return iterative_hash_template_arg (args, val);
}
sorry for not realizing this earlier
[Bug tree-optimization/94456] New: ICE in aarch64/sve/pr87815.c since r10-7491
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94456 Bug ID: 94456 Summary: ICE in aarch64/sve/pr87815.c since r10-7491 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Since r10-7491, I've noticed a regression with an ICE: FAIL: gcc.target/aarch64/sve/pr87815.c -march=armv8.2-a+sve (internal compiler error) /gcc/testsuite/gcc.target/aarch64/sve/pr87815.c: In function 'f': /gcc/testsuite/gcc.target/aarch64/sve/pr87815.c:6:6: error: missing definition for SSA_NAME: _50 in statement: _31 = _50; during GIMPLE pass: vect /gcc/testsuite/gcc.target/aarch64/sve/pr87815.c:6:6: internal compiler error: verify_ssa failed 0xfe9253 verify_ssa(bool, bool) /gcc/tree-ssa.c:1208 0xc6c293 execute_function_todo /gcc/passes.c:1992 0xc6cb75 execute_todo /gcc/passes.c:2039 Please submit a full bug report, with preprocessed source if appropriate.
[Bug tree-optimization/94043] [9 Regression] ICE in superloop_at_depth, at cfgloop.c:78
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94043 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #22 from Christophe Lyon --- This caused an ICE on aarch64, see PR94456
[Bug tree-optimization/94443] [10 Regression] 510.parest_r and 526.blender_r ICE: verify_ssa failed since r10-7491-gbd0f22a8d5caea8905f38ff1fafce31c1b7d33ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94443 Kewen Lin changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #10 from Kewen Lin --- *** Bug 94456 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/94456] ICE in aarch64/sve/pr87815.c since r10-7491
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94456 Kewen Lin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||linkw at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Kewen Lin --- Thanks for reporting, should be duplicated as the symptom. *** This bug has been marked as a duplicate of bug 94443 ***
[Bug lto/94249] [10 regression] Many -flto -fuse-linker-plugin tests FAIL: could not add symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94249 --- Comment #22 from Khem Raj --- yes you are right
[Bug tree-optimization/94443] [10 Regression] 510.parest_r and 526.blender_r ICE: verify_ssa failed since r10-7491-gbd0f22a8d5caea8905f38ff1fafce31c1b7d33ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94443 Khem Raj changed: What|Removed |Added CC||raj.khem at gmail dot com --- Comment #11 from Khem Raj --- this patch seems to be causing gcc ICE on ARM when compiling lz4 sources in kernel, lz4, vlc almost identical ICE is seen attached is the test case please compile it with -O3 during GIMPLE pass: vect lz4.c: In function 'LZ4_compress_fast_extState': lz4.c:1180:5: internal compiler error: Segmentation fault 1180 | int LZ4_compress_fast_extState(void* state, const char* source, char* dest, int inputSize, int maxOutputSize, int acceleration) | ^~ Please submit a full bug report,
[Bug tree-optimization/94443] [10 Regression] 510.parest_r and 526.blender_r ICE: verify_ssa failed since r10-7491-gbd0f22a8d5caea8905f38ff1fafce31c1b7d33ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94443 --- Comment #12 from Khem Raj --- Created attachment 48170 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48170&action=edit testcase
[Bug rtl-optimization/92989] [10 Regression] The mips-mti-linux-gnu fails to build after r276327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92989 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- On #c6 it can't be reproduced with mipsisa64-elf gcc, asit has different size_t etc. than the preprocessed source. I can reproduce with cross to mips-mti-linux, with -quiet -nostdinc locale-inst.ii -std=c++11 -mips16 -O2. The ICE is in: 1643for (i = FIRST_PSEUDO_REGISTER; i < max_regno; i++) 1644 if (lra_reg_info[i].nrefs != 0 1645 && reg_renumber[i] >= 0 1646 && overlaps_hard_reg_set_p (lra_reg_info[i].conflict_hard_regs, 1647 PSEUDO_REGNO_MODE (i), reg_renumber[i])) 1648gcc_unreachable (); Richard, could you please have a look again?
[Bug rtl-optimization/93264] [10 Regression] ICE in cfg_layout_redirect_edge_and_branch_force, at cfgrtl.c:4522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93264
--- Comment #11 from Roman Zhuykov ---
(In reply to Richard Biener from comment #9)
Thank you, I'm glad to see new ideas and some discussion.
> On the testcase itself
>
> diff --git a/gcc/modulo-sched.c b/gcc/modulo-sched.c
> index 77254b31b42..66260fa34f1 100644
> --- a/gcc/modulo-sched.c
> +++ b/gcc/modulo-sched.c
> @@ -1347,8 +1347,7 @@ sms_schedule (void)
>edge latch_edge;
>HOST_WIDE_INT trip_count, max_trip_count;
>
> - loop_optimizer_init (LOOPS_HAVE_PREHEADERS
> - | LOOPS_HAVE_RECORDED_EXITS);
> + loop_optimizer_init (AVOID_CFG_MODIFICATIONS);
>if (number_of_loops (cfun) <= 1)
> {
>loop_optimizer_finalize ();
>
> works.
Unfortunately, this brokes the whole SMS workflow. See e.g. loop_canon_p
function and a call to single_exit inside. I've actually tried only improved
(with all my patches) master version and only few examples, but with
AVOID_CFG_MODIFICATIONS some of them bailout with "SMS loop many exits" instead
of succesfully passing analysis and transformation phases with "SMS succeeded".
[Bug ipa/94445] gcc.target/arm/cmse/cmse-15.c fails for cortex-m33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94445 Martin Liška changed: What|Removed |Added Component|target |ipa Target Milestone|--- |10.0 Assignee|clyon at gcc dot gnu.org |marxin at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #7 from Martin Liška --- It's ICF issue and I've got a patch for it.
[Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264 --- Comment #41 from Martin Liška --- The current master does: $ time gfortran module_configure.fppized.f90 -c -march=znver2 -std=legacy -fconvert=big-endian -fno-openmp -Ofast -march=znver2 -g ... real2m21.190s user2m20.487s sys 0m0.647s
[Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264 --- Comment #42 from Jakub Jelinek --- Is that good enough to mark this PR as resolved? In #c0 you said before Richard's change it took ~200s, which is more than 2m21s, though it is unclear if those 141s are with checking compiler or not.
[Bug tree-optimization/94443] [10 Regression] 510.parest_r and 526.blender_r ICE: verify_ssa failed since r10-7491-gbd0f22a8d5caea8905f38ff1fafce31c1b7d33ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94443 --- Comment #13 from Kewen Lin --- (In reply to Khem Raj from comment #11) > this patch seems to be causing gcc ICE on ARM when compiling lz4 sources in > kernel, lz4, vlc almost identical ICE is seen > > attached is the test case please compile it with -O3 > > during GIMPLE pass: vect > lz4.c: In function 'LZ4_compress_fast_extState': > lz4.c:1180:5: internal compiler error: Segmentation fault > 1180 | int LZ4_compress_fast_extState(void* state, const char* source, > char* dest, int inputSize, int maxOutputSize, int acceleration) > | ^~ > Please submit a full bug report, Same symptom: for SSA_NAME: _1689 in statement: op_1747 = _1689; during GIMPLE pass: vect lz4.c:1180:5: internal compiler error: verify_ssa failed 0x100d0ab verify_ssa(bool, bool) Verified it can be fixed with posted patch in gcc-patch ML: https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543137.html
[Bug d/94455] no [] operator overload for type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94455 --- Comment #1 from Iain Buclaw --- Not compiler, but a missing library feature that was introduced in a more recent version than what is bundled with gdc. It could be backported for convenience, but if it can wait until after gcc-10, then I hope to this time round sync with all master branches in upstream dlang, and this pr will resolve itself with no further action. That is assuming there's nothing blocking on introducing the necessary makefile changes to support a self-hosted D front-end.
[Bug target/94364] 505.mcf_r is 8% faster when compiled with -mprefer-vector-width=128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94364 Martin Jambor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #6 from Martin Jambor --- OK, I'm going to close this given that this problem is specific to our mcf patch which we decided to change and the issue cannot easily be avoided in the compiler.
[Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264 --- Comment #43 from Martin Liška --- (In reply to Jakub Jelinek from comment #42) > Is that good enough to mark this PR as resolved? In #c0 you said before > Richard's change it took ~200s, which is more than 2m21s, though it is > unclear if those 141s are with checking compiler or not. These 140 are with default checking for current master which is checking enabled. That said, I would close this.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 94364, which changed state. Bug 94364 Summary: 505.mcf_r is 8% faster when compiled with -mprefer-vector-width=128 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94364 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 94364, which changed state. Bug 94364 Summary: 505.mcf_r is 8% faster when compiled with -mprefer-vector-width=128 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94364 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX
[Bug tree-optimization/94401] [10 Regression] pr92420.c fails on aarch64 since r10-7415
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94401 --- Comment #6 from CVS Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:81ce375d1fdd99f9d93b00f4895eab74c3d8b54a commit r10-7519-g81ce375d1fdd99f9d93b00f4895eab74c3d8b54a Author: Kewen Lin Date: Thu Apr 2 08:48:03 2020 -0500 Fix PR94401 by considering reverse overrun The commit r10-7415 brings scalar type consideration to eliminate epilogue peeling for gaps, but it exposed one problem that the current handling doesn't consider the memory access type VMAT_CONTIGUOUS_REVERSE, for which the overrun happens on low address side. This patch is to make the code take care of it by updating the offset and construction element order accordingly. Bootstrapped/regtested on powerpc64le-linux-gnu P8 and aarch64-linux-gnu. 2020-04-02 Kewen Lin gcc/ChangeLog PR tree-optimization/94401 * tree-vect-loop.c (vectorizable_load): Handle VMAT_CONTIGUOUS_REVERSE access type when loading halves of vector to avoid peeling for gaps.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 92264, which changed state. Bug 92264 Summary: [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #44 from Jakub Jelinek --- Fixed then.
[Bug tree-optimization/94401] [10 Regression] pr92420.c fails on aarch64 since r10-7415
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94401 Kewen Lin changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Kewen Lin --- Should be fixed now.
[Bug debug/94450] lto abstract variable emitted as concrete decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94450 --- Comment #6 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:54af95767e887d63dc332731738e642536d87a48 commit r10-7521-g54af95767e887d63dc332731738e642536d87a48 Author: Richard Biener Date: Thu Apr 2 16:45:28 2020 +0200 debug/94450 - remove DW_TAG_imported_unit generated in LTRANS units This removes the DW_TAG_imported_unit we generate for each referenced early debug unit in LTRANS units. They are more harmful than they do good and the semantics can be read in a way making it even wrong. 2020-04-02 Richard Biener PR debug/94450 * dwarf2out.c (dwarf2out_early_finish): Remove code emitting DW_TAG_imported_unit.
[Bug debug/94450] lto abstract variable emitted as concrete decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94450 --- Comment #7 from Richard Biener --- The DW_TAG_imported_unit are now gone for GCC 10. So can we consider this fixed?
[Bug middle-end/94206] Wrong optimization: memset of n-bit integer types (from bit-fields) is truncated to n bits (instead of sizeof)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94206 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Richard Biener : https://gcc.gnu.org/g:4b1087f8dc7505997dc475b554b5b86a06c78d69 commit r9-8443-g4b1087f8dc7505997dc475b554b5b86a06c78d69 Author: Richard Biener Date: Wed Mar 18 13:11:30 2020 +0100 middle-end/94206 fix memset folding to avoid types with padding This makes sure that the store a memset is folded to uses a type covering all bits. 2020-03-18 Richard Biener PR middle-end/94206 * gimple-fold.c (gimple_fold_builtin_memset): Avoid using partial int modes or not mode-precision integer types for the store. * gcc.dg/torture/pr94206.c: New testcase.
[Bug target/94103] Wrong optimization: reading value of a variable changes its representation for optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94103 --- Comment #17 from CVS Commits --- The releases/gcc-9 branch has been updated by Richard Biener : https://gcc.gnu.org/g:4b0b6303dde0c32d936926de45b54cfe508fa677 commit r9-8444-g4b0b6303dde0c32d936926de45b54cfe508fa677 Author: Richard Biener Date: Thu Mar 12 14:18:35 2020 +0100 tree-optimization/94103 avoid CSE of loads with padding VN currently replaces a load of a 16 byte entity 128 bits of precision (TImode) with the result of a load of a 16 byte entity with 80 bits of mode precision (XFmode). That will go downhill since if the padding bits are not actually filled with memory contents those bits are missing. 2020-03-12 Richard Biener PR tree-optimization/94103 * tree-ssa-sccvn.c (visit_reference_op_load): Avoid type punning when the mode precision is not sufficient. * gcc.target/i386/pr94103.c: New testcase.
[Bug c/94392] [10 Regression] Infinite loops are optimized away for C99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94392 --- Comment #6 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:75efe9cb1f8938a713ce540dc3b27bc2afcd3fae commit r10-7522-g75efe9cb1f8938a713ce540dc3b27bc2afcd3fae Author: Richard Biener Date: Thu Apr 2 10:46:20 2020 +0200 c/94392 - only enable -ffinite-loops for C++ This does away with enabling -ffinite-loops at -O2+ for all languages and instead enables it selectively for C++ only. It also makes -ffinite-loops loop-private at CFG construction time fixing correctness issues with inlining. 2020-04-02 Richard Biener PR c/94392 * c-opts.c (c_common_post_options): Enable -ffinite-loops for -O2 and C++11 or newer. * common.opt (ffinite-loops): Initialize to zero. * opts.c (default_options_table): Remove OPT_ffinite_loops entry. * cfgloop.h (loop::finite_p): New member. * cfgloopmanip.c (copy_loop_info): Copy finite_p. * ipa-icf-gimple.c (func_checker::compare_loops): Compare finite_p. * lto-streamer-in.c (input_cfg): Stream finite_p. * lto-streamer-out.c (output_cfg): Likewise. * tree-cfg.c (replace_loop_annotate): Initialize finite_p from flag_finite_loops at CFG build time. * tree-ssa-loop-niter.c (finite_loop_p): Check the loops finite_p flag instead of flag_finite_loops. * doc/invoke.texi (ffinite-loops): Adjust documentation of default setting. * gcc.dg/torture/pr94392.c: New testcase.
[Bug c/94392] [10 Regression] Infinite loops are optimized away for C99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94392 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Richard Biener --- Fixed.
[Bug c++/94457] New: using ~VariableName in trailing return type deduction does not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94457
Bug ID: 94457
Summary: using ~VariableName in trailing return type deduction
does not compile
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: peter_foelsche at mentor dot com
Target Milestone: ---
Created attachment 48171
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48171&action=edit
test source code
using ~std::declval() instead works fine -- use -D__WORKS__
-- use -std=c++11
g++ ~/test.cpp -std=c++11:
/home/pfoelsch/test.cpp: In function 'int main(int, char**)':
/home/pfoelsch/test.cpp:22:34: error: no match for call to '(bit_not) (test)'
{ const auto s = bit_not()(test());
^
/home/pfoelsch/test.cpp:12:7: note: candidate: template decltype (~
_r) bit_not::operator()(const T&) const
auto operator()(const T&_r) const -> decltype(~ _r)
^
/home/pfoelsch/test.cpp:12:7: note: template argument deduction/substitution
failed:
/home/pfoelsch/test.cpp: In substitution of 'template decltype (~ _r)
bit_not::operator()(const T&) const [with T = test]':
/home/pfoelsch/test.cpp:22:34: required from here
/home/pfoelsch/test.cpp:12:7: error: '_r' was not declared in this scope
orw-ams-ms7 /scratch/pfoelsch/SYMPHONY/linux_x86_64/release : g++ --version -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/wv/for_all/ams/free/GNU/devenv_g5/develop_v1.2/x86_64/2.6.32-431.el6.x86_64/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper
g++ (GCC) 5.3.0
Copyright (C) 2015 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.
Target: x86_64-unknown-linux-gnu
Configured with: /local/tmp/gcc-5.3.0_binutils-2.31.1/src/gcc-5.3.0/configure
--with-local-prefix=/u/ams --disable-nls
--prefix=/local/tmp/gcc-5.3.0_binutils-2.31.1/distrib/x86_64/2.6.32-431.el6.x86_64
--enable-languages=c,c++,fortran --with-gnu-as
--with-as=/local/tmp/gcc-5.3.0_binutils-2.31.1/distrib/x86_64/2.6.32-431.el6.x86_64/bin/as
--with-gnu-ld
--with-ld=/local/tmp/gcc-5.3.0_binutils-2.31.1/distrib/x86_64/2.6.32-431.el6.x86_64/bin/ld
Thread model: posix
gcc version 5.3.0 (GCC)
COLLECT_GCC_OPTIONS='--version' '-v' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
/wv/for_all/ams/free/GNU/devenv_g5/develop_v1.2/x86_64/2.6.32-431.el6.x86_64/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/cc1
-quiet -v -iprefix
/wv/for_all/ams/free/GNU/devenv_g5/develop_v1.2/x86_64/2.6.32-431.el6.x86_64/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.3.0/
help-dummy -quiet -dumpbase help-dummy -mtune=generic -march=x86-64 -auxbase
help-dummy -version --version -o /tmp/cc0dabSv.s
GNU C11 (GCC) version 5.3.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.3.0, GMP version 6.1.0, MPFR version 3.1.3,
MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='--version' '-v' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
/wv/for_all/ams/free/GNU/devenv_g5/develop_v1.2/x86_64/2.6.32-431.el6.x86_64/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../x86_64-unknown-linux-gnu/bin/as
-v --64 --version -o /tmp/ccbi2PlA.o /tmp/cc0dabSv.s
GNU assembler version 2.31.1 (x86_64-unknown-linux-gnu) using BFD version (GNU
Binutils) 2.31.1
GNU assembler (GNU Binutils) 2.31.1
Copyright (C) 2018 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-unknown-linux-gnu'.
COMPILER_PATH=/wv/for_all/ams/free/GNU/devenv_g5/develop_v1.2/x86_64/2.6.32-431.el6.x86_64/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/:/wv/for_all/ams/free/GNU/devenv_g5/develop_v1.2/x86_64/2.6.32-431.el6.x86_64/bin/../libexec/gcc/:/wv/for_all/ams/free/GNU/devenv_g5/develop_v1.2/x86_64/2.6.32-431.el6.x86_64/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../x86_64-unknown-linux-gnu/bin/
LIBRARY_PATH=/wv/for_all/ams/free/GNU/devenv_g5/develop_v1.2/x86_64/2.6.32-431.el6.x86_64/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.3.0/:/wv/for_all/ams/free/GNU/devenv_g5/develop_v1.2/x86_64/2.6.32-431.el6.x86_64/bin/../lib/gcc/:/wv/for_all/ams/free/GNU/devenv_g5/develop_v1.2/x86_64/2.6.32-431.el6.x86_64/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/wv/for_all/ams/free/GNU/devenv_g5/develop_v1.2/x86_64/2.6.32-431.el6.x86_64/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../x86_64-unknown-linux-gnu/lib/:/wv/for_all/ams/free/GNU/devenv_g5/develop_v1.2/x86_64/2.6.32-431.el6.x86_64/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../:/lib/:/usr/lib
[Bug c++/94457] using ~VariableName in trailing return type deduction does not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94457 --- Comment #1 from Peter Foelsche --- g++ 7.4 works fine
[Bug target/94438] [8/9/10 Regression] ICE: verify_gimple failed: position plus size exceeds size of referenced object in 'bit_field_ref' with -mavx512vbmi -mavx512vl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94438 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 48172 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48172&action=edit gcc10-pr94438.patch Untested fix. It seems completely wrong to try to use int masks for V*TImode, the hook correctly only supports V*[SD]Imode if not -mavx512bw, but with -mavx512bw it just doesn't check elem_size at all.
[Bug c++/94034] [10 Regression] Broken diagnostic: 'result_decl' not supported by dump_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94034 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug c++/94457] using ~VariableName in trailing return type deduction does not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94457 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #2 from Marek Polacek --- g++ 5 is not supported anymore and all the supported versions work as expected, so closing.
[Bug analyzer/94458] New: -Wanalyzer-malloc-leak false positive when returning a heap-allocated struct by value holding a heap-allocated pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94458
Bug ID: 94458
Summary: -Wanalyzer-malloc-leak false positive when returning a
heap-allocated struct by value holding a
heap-allocated pointer
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: simon.marchi at polymtl dot ca
Target Milestone: ---
Variation of [1], where the returned struct is heap-allocated, rather than
returned by value.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94378
Source:
#include
struct ret
{
int **array;
};
struct ret *allocate_stuff(void)
{
struct ret *ret;
ret = calloc(1, sizeof (struct ret));
if (!ret) {
abort();
}
ret->array = calloc (10, sizeof(int *));
if (!ret->array) {
abort();
}
return ret;
}
Analyzer report:
$ /opt/gcc/git/bin/gcc a.c -g3 -O0 -fanalyzer -c -Wall -Werror
a.c: In function ‘allocate_stuff’:
a.c:18:10: error: leak of ‘’ [CWE-401] [-Werror=analyzer-malloc-leak]
18 | if (!ret->array) {
| ~~~^~~
‘allocate_stuff’: events 1-7
|
| 13 | if (!ret) {
| | ^
| | |
| | (1) following ‘false’ branch (when ‘ret’ is non-NULL)...
|..
| 17 | ret->array = calloc (10, sizeof(int *));
| | ~~
| | |
| | (2) ...to here
| | (3) allocated here
| 18 | if (!ret->array) {
| | ~ ~~
| | ||
| | |(7) ‘’ leaks here; was allocated at (3)
| | (4) assuming ‘’ is non-NULL
| | (5) following ‘false’ branch...
|..
| 22 | return ret;
| | ~~~
| | |
| | (6) ...to here
|
cc1: all warnings being treated as errors
$ /opt/gcc/git/bin/gcc --version
gcc (GCC) 10.0.1 20200401 (experimental)
The analyzer says the memory allocated at (3) is leaked, but it is in fact
pointed by the returned struct.
