[Bug tree-optimization/99029] memory leak in IPA pure-const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99029 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-02-10 --- Comment #1 from Richard Biener --- Mine.
[Bug tree-optimization/98950] jump threading memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98950 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Richard Biener --- I will have a second look.
[Bug ipa/99003] memory leak in IPA ICF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99003 --- Comment #2 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:d44f56f2b2d4f0a827ba6f08aebc715786225c6f commit r11-7163-gd44f56f2b2d4f0a827ba6f08aebc715786225c6f Author: Martin Liska Date: Tue Feb 9 09:57:04 2021 +0100 ICF: fix memory leak gcc/ChangeLog: PR ipa/99003 * ipa-icf.c (sem_item::add_reference): Fix memory leak when a reference exists.
[Bug tree-optimization/99002] [11 Regression] memory leak in if-to-switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99002 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:5da5d8a02c6799e60970fef72ee8c1c3d033a5e5 commit r11-7164-g5da5d8a02c6799e60970fef72ee8c1c3d033a5e5 Author: Martin Liska Date: Tue Feb 9 09:50:04 2021 +0100 if-to-switch: fix a memory leak gcc/ChangeLog: PR tree-optimization/99002 * gimple-if-to-switch.cc (find_conditions): Fix memory leak in the function.
[Bug ipa/99003] memory leak in IPA ICF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99003 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška --- Fixed on master.
[Bug tree-optimization/99002] [11 Regression] memory leak in if-to-switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99002 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Martin Liška --- Fixed on master.
[Bug bootstrap/78251] config/gettext.m4 and config/iconv.m4 contaminate CPPFLAGS (can lead to build failures when libunwind-headers from MacPorts is active)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78251 Eric Gallager changed: What|Removed |Added CC||casner at acm dot org --- Comment #13 from Eric Gallager --- Stephen Casner and Nick Alcock discussed what I think is this issue on the bug-gettext mailing list: https://lists.gnu.org/archive/html/bug-gettext/2021-02/msg0.html
[Bug tree-optimization/99002] [11 Regression] memory leak in if-to-switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99002 Martin Liška changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #5 from Martin Liška --- (In reply to Richard Biener from comment #2) > Another one: > > ==17557== Memcheck, a memory error detector > ==17557== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. > ==17557== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info > ==17557== Command: ./cc1 -quiet -fdiagnostics-plain-output -O3 -o > ssa-dom-thread-1.s > /home/rguenther/src/gcc3/gcc/testsuite/gcc.dg/torture/pr63464.c > ==17557== > ==17557== > ==17557== HEAP SUMMARY: > ==17557== in use at exit: 1,890,206 bytes in 2,855 blocks > ==17557== total heap usage: 86,712 allocs, 83,857 frees, 16,547,876 bytes > allocated > ==17557== > ==17557== 448 bytes in 8 blocks are definitely lost in loss record 674 of 760 > ==17557==at 0x4C2E94F: operator new(unsigned long) (in > /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > ==17557==by 0x24FF041: if_chain::is_beneficial() > (gimple-if-to-switch.cc:207) > ==17557==by 0x250052F: (anonymous > namespace)::pass_if_to_switch::execute(function*) > (gimple-if-to-switch.cc:545) > ==17557==by 0x12E7FEA: execute_one_pass(opt_pass*) (passes.c:2572) > ==17557==by 0x12E8321: execute_pass_list_1(opt_pass*) (passes.c:2661) > ==17557==by 0x12E8352: execute_pass_list_1(opt_pass*) (passes.c:2662) > ==17557==by 0x12E83AA: execute_pass_list(function*, opt_pass*) > (passes.c:2672) > ==17557==by 0x12E62DF: do_per_function_toporder(void (*)(function*, > void*), void*) (passes.c:1774) > ==17557==by 0x12E8FDA: execute_ipa_pass_list(opt_pass*) (passes.c:3006) > ==17557==by 0xCFC9EE: ipa_passes() (cgraphunit.c:2157) > ==17557==by 0xCFCE24: symbol_table::compile() (cgraphunit.c:2292) > ==17557==by 0xCFD391: symbol_table::finalize_compilation_unit() > (cgraphunit.c:2540) I've got a patch for this on.
[Bug tree-optimization/98950] jump threading memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98950
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot
gnu.org
--- Comment #5 from Richard Biener ---
So the issue seems we have a recorded path of length 1 which isn't handled but
also not rejected in the generic thread_through_all_blocks machinery which
makes it not deleted by the actual threading.
Freeing of paths is a bit awkward scattered through the code rather than
being done when releasing the vector of paths.
$12 = {e = 24)>, type = EDGE_NO_COPY_SRC_BLOCK}
is the path we end up with. The path is originally registered with length
two but adjusted via
#0 vec::block_remove (
this=0x3a6b900 = {...}, ix=0, len=1)
at /home/rguenther/src/gcc2/gcc/vec.h:1136
#1 0x018235fb in vec::block_remove
(Python Exception There is no member or method named
m_vecpfx.:
this=0x3a6cea0, ix=0, len=1) at /home/rguenther/src/gcc2/gcc/vec.h:2029
#2 0x0181f68e in adjust_paths_after_duplication (curr_path_num=0)
at /home/rguenther/src/gcc2/gcc/tree-ssa-threadupdate.c:2292
#3 0x0181fe27 in duplicate_thread_path (
entry= 30)>,
exit= 20)>, region=0x3ace140, n_region=2,
current_path_no=0)
at /home/rguenther/src/gcc2/gcc/tree-ssa-threadupdate.c:2462
#4 0x01820243 in thread_through_all_blocks (
may_peel_loop_headers=true)
at /home/rguenther/src/gcc2/gcc/tree-ssa-threadupdate.c:2594
to this degenerate state.
I'm lost as to how this all should work. The releasing of paths all around
the transform code rather than simply at the end of thread_through_all_blocks
where we do
paths.release ();
(but appearantly rely on it being empty) makes things awkward to fix for me.
Jeff?
[Bug analyzer/99042] Another false -Wanalyzer-malloc-leak on code path involving unknown function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99042 --- Comment #2 from Antonio Chirizzi --- Hi David, just curious of what you mean with "unknown function". Is it something that has not been declared or is not known to the compiler up to that point? Thanks, -Antonio
[Bug target/99025] [11 Regression] ICE Segmentation fault since r11-6351-g12ae2bc70846a2be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99025 --- Comment #2 from Uroš Bizjak --- Comment on attachment 50154 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50154 gcc11-pr99025.patch >2021-02-09 Jakub Jelinek >+ if (SUBREG_P (operands[1])) >+operands[1] = force_reg (V2SFmode, operands[1]); There is no need to check for SUBREG, force_reg has early exit in case operand is already a register.
[Bug tree-optimization/99026] memleak in switch-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99026 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-02-10 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Mine.
[Bug fortran/99036] [11 Regression] ICE in gfc_current_interface_head, at fortran/interface.c:4699
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99036 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||pault at gcc dot gnu.org --- Comment #2 from Martin Liška --- Just for the record, started with r11-6832-geaf883710c0039ec.
[Bug tree-optimization/99024] memory leak in vect_analyze_loop_form
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99024 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:d997565c41a8a5783bf076437208f38d8ea39ced commit r11-7165-gd997565c41a8a5783bf076437208f38d8ea39ced Author: Richard Biener Date: Wed Feb 10 09:06:26 2021 +0100 tree-optimization/99024 - fix leak in loop vect analysis When we analyzed a loop as epilogue but later in peeling decide we're not going to use it then in the DTOR we clear the original loops ->aux which causes us to leak the main loop vinfo. Fixed by only clearing aux if it is associated with the vinfo we're destroying. 2021-02-10 Richard Biener PR tree-optimization/99024 * tree-vect-loop.c (_loop_vec_info::~_loop_vec_info): Only clear loop->aux if it is associated with the destroyed loop_vinfo.
[Bug tree-optimization/99024] memory leak in vect_analyze_loop_form
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99024 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Richard Biener --- Fixed.
[Bug tree-optimization/99029] memory leak in IPA pure-const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99029 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:9eb7669cc040882992dee3621ebacf4f0311e8a0 commit r11-7166-g9eb7669cc040882992dee3621ebacf4f0311e8a0 Author: Richard Biener Date: Wed Feb 10 09:13:01 2021 +0100 ipa/99029 - fix memory leak in propagate_malloc This makes sure to release the vec<> of callees. 2021-02-10 Richard Biener PR ipa/99029 * ipa-pure-const.c (propagate_malloc): Use an auto_vec<> for callees.
[Bug tree-optimization/99029] memory leak in IPA pure-const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99029 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug rtl-optimization/99054] memory leak in thread_prologue_and_epilogue_insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99054 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-02-10 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Richard Biener --- Mine.
[Bug target/99037] Invalid representation of vector zero in aarch64-simd.md
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99037 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot gnu.org CC||ktkachov at gcc dot gnu.org --- Comment #1 from ktkachov at gcc dot gnu.org --- Got a patch to fix it for GCC 12.
[Bug rtl-optimization/98692] Unitialized Values reported only with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692 --- Comment #17 from Mark Wielaard --- Thanks for the step-by-step explanation of the assembly instructions and calling conventions. (In reply to Segher Boessenkool from comment #16) > (In reply to Mark Wielaard from comment #13) > > ==25741== Use of uninitialised value of size 8 > > ==25741==at 0x1504: main (pr9862.C:16) > > r4 is argv here > >0x14f0 <+16>:ld r3,0(r4) > r3 = argv[0]; > >0x14f4 <+20>:mr r31,r4 > r31 = argv; // because we need it after the call, save it in a non-volatile > reg > >0x14f8 <+24>:std r0,16(r1) > >0x14fc <+28>:stdur1,-48(r1) > >0x1500 <+32>:bl 0x16b4 > The call; after this we have to load argv[0] again, the called function might > have changed it. > >0x1504 <+36>:ld r3,0(r31) > r3 = argv[0]; > > So it is funny that the exact same insn four insns earlier (in the program > text) > worked fine, but this one fails. The different (according to valgrind) is that r4 has a defined value, while it believes r31 has an undefined value after the isVariable call. > The ABI says (taken from the ELFv1 ABI, the ELFv2 doc is not nice for > copy/paste): > > > Here is a sample implementation of _savegpr0_N and _restgpr0_N. > > _savegpr0_14: std r14,-144(r1) > _savegpr0_15: std r15,-136(r1) > _savegpr0_16: std r16,-128(r1) > _savegpr0_17: std r17,-120(r1) > _savegpr0_18: std r18,-112(r1) > _savegpr0_19: std r19,-104(r1) > _savegpr0_20: std r20,-96(r1) > _savegpr0_21: std r21,-88(r1) > _savegpr0_22: std r22,-80(r1) > _savegpr0_23: std r23,-72(r1) > _savegpr0_24: std r24,-64(r1) > _savegpr0_25: std r25,-56(r1) > _savegpr0_26: std r26,-48(r1) > _savegpr0_27: std r27,-40(r1) > _savegpr0_28: std r28,-32(r1) > _savegpr0_29: std r29,-24(r1) > _savegpr0_30: std r30,-16(r1) > _savegpr0_31: std r31,-8(r1) > std r0, 16(r1) > blr > _restgpr0_14: ld r14,-144(r1) > _restgpr0_15: ld r15,-136(r1) > _restgpr0_16: ld r16,-128(r1) > _restgpr0_17: ld r17,-120(r1) > _restgpr0_18: ld r18,-112(r1) > _restgpr0_19: ld r19,-104(r1) > _restgpr0_20: ld r20,-96(r1) > _restgpr0_21: ld r21,-88(r1) > _restgpr0_22: ld r22,-80(r1) > _restgpr0_23: ld r23,-72(r1) > _restgpr0_24: ld r24,-64(r1) > _restgpr0_25: ld r25,-56(r1) > _restgpr0_26: ld r26,-48(r1) > _restgpr0_27: ld r27,-40(r1) > _restgpr0_28: ld r28,-32(r1) > _restgpr0_29: ld r0, 16(r1) > ld r29,-24(r1) > mtlr r0 > ld r30,-16(r1) > ld r31,-8(r1) > blr > _restgpr0_30: ld r30,-16(r1) > _restgpr0_31: ld r0, 16(r1) > ld r31,-8(r1) > mtlr r0 > blr > > So this is one function with many entry points you could say. Maybe that is > what confused valgrind? So for some reason valgrind doesn't believe the stack value for -8(r1) is valid when r31 is restored. What seems to confuse valgrind is: 0x16c0 <+20>:bl 0x1820 <_savegpr0_25> 0x16c4 <+24>:stdur1,-128(r1) [...] 0x1720 <+116>: addir1,r1,128 0x1724 <+120>: b 0x1844 <_restgpr0_25> It looks like it interprets those stack pointer moves as invalidating the values stored on the stack.
[Bug middle-end/99007] [11 Regression] ICE in dominated_by_p, at dominance.c:1124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99007 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:bd0e37f68a3aed944df4eb739a0734bb87153749 commit r11-7167-gbd0e37f68a3aed944df4eb739a0734bb87153749 Author: Jakub Jelinek Date: Wed Feb 10 10:34:58 2021 +0100 openmp: Temporarily disable into_ssa when gimplifying OpenMP reduction clauses [PR99007] gimplify_scan_omp_clauses was already calling gimplify_expr with false as last argument to make sure it is not an SSA_NAME, but as the testcases show, that is not enough, SSA_NAME temporaries created during that gimplification can be reused too and we can't allow SSA_NAMEs to be used across OpenMP region boundaries, as we can only firstprivatize decls. Fixed by temporarily disabling into_ssa. 2021-02-10 Jakub Jelinek PR middle-end/99007 * gimplify.c (gimplify_scan_omp_clauses): For MEM_REF on reductions, temporarily disable gimplify_ctxp->into_ssa around gimplify_expr calls. * g++.dg/gomp/pr99007.C: New test. * gcc.dg/gomp/pr99007-1.c: New test. * gcc.dg/gomp/pr99007-2.c: New test. * gcc.dg/gomp/pr99007-3.c: New test.
[Bug c/99055] New: memory leak in warn_parm_array_mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99055 Bug ID: 99055 Summary: memory leak in warn_parm_array_mismatch Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- ==23200== Memcheck, a memory error detector ==23200== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==23200== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==23200== Command: ./cc1 -quiet -fdiagnostics-plain-output -O3 -o ssa-dom-thread-2.s /home/rguenther/src/gcc3/gcc/testsuite/gcc.c-torture/compile/pr77754-5.c ==23200== ==23200== ==23200== HEAP SUMMARY: ==23200== in use at exit: 1,860,863 bytes in 2,692 blocks ==23200== total heap usage: 26,486 allocs, 23,794 frees, 6,321,282 bytes allocated ==23200== ==23200== 7 bytes in 1 blocks are definitely lost in loss record 1 of 675 ==23200==at 0x4C2E2DF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==23200==by 0x28ECBF6: xmalloc (xmalloc.c:147) ==23200==by 0x28ECD6F: xstrdup (xstrdup.c:34) ==23200==by 0x15EF359: print_generic_expr_to_str(tree_node*) (tree-pretty-print.c:179) ==23200==by 0xBD992D: warn_parm_array_mismatch(unsigned int, tree_node*, tree_node*) (c-warn.c:3589) ==23200==by 0xA4089D: start_function(c_declspecs*, c_declarator*, tree_node*) (c-decl.c:9601) ==23200==by 0xAAD6A4: c_parser_declaration_or_fndef(c_parser*, bool, bool, bool, bool, bool, tree_node**, vec, bool, tree_node*, oacc_routine_data*, bool*) (c-parser.c:2440) ==23200==by 0xAABE71: c_parser_external_declaration(c_parser*) (c-parser.c:1777) ==23200==by 0xAAB98D: c_parser_translation_unit(c_parser*) (c-parser.c:1650) ==23200==by 0xAEBF10: c_parse_file() (c-parser.c:21990) ==23200==by 0xB89212: c_common_parse_file() (c-opts.c:1218) ==23200==by 0x148FCD3: compile_file() (toplev.c:457)
[Bug target/99025] [11 Regression] ICE Segmentation fault since r11-6351-g12ae2bc70846a2be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99025 --- Comment #3 from Jakub Jelinek --- (In reply to Uroš Bizjak from comment #2) > Comment on attachment 50154 [details] > gcc11-pr99025.patch > > >2021-02-09 Jakub Jelinek > > >+ if (SUBREG_P (operands[1])) > >+operands[1] = force_reg (V2SFmode, operands[1]); > > There is no need to check for SUBREG, force_reg has early exit in case > operand is already a register. I know, I've just misread nonimmediate_operand as nonmemory_operand and thought I need to let immediates get through to simplify_gen_subreg. The predicates are register_operand (so REG or SUBREG) or nonimmediate_operand (so REG, SUBREG or MEM and in that case this is used in !MEM_P paths) and so you're right force_reg can be called unconditionally.
[Bug fortran/99043] Inconsistent behavior when calling rank(ptr) for assumed-rank null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99043
Tobias Burnus changed:
What|Removed |Added
Last reconfirmed||2021-02-10
CC||burnus at gcc dot gnu.org
Keywords||wrong-code
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from Tobias Burnus ---
Confirmed, gfortran (-fdump-tree-original) adds an additional 'a->' assignment:
void rank_of_pointer_level1 (struct array15_real(kind=4) & a)
{
...
if ((real(kind=4)[0:] *) ((struct array15_real(kind=4) *) a)->data == 0B)
{
((struct array15_real(kind=4) *) a)->dtype
= {.elem_len=4, .rank=-1, .type=3};
}
rank_of_pointer_level2 ((struct array15_real(kind=4) *) a);
[Bug rtl-optimization/99054] memory leak in thread_prologue_and_epilogue_insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99054 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:72932511053596091ad291539022b51d9f2ba418 commit r11-7168-g72932511053596091ad291539022b51d9f2ba418 Author: Richard Biener Date: Wed Feb 10 10:17:15 2021 +0100 rtl-optimization/99054 - fix leak in fixup_partitions This fixes a leak of the vector retured by find_partition_fixes by turning it into an auto_vec. 2021-02-10 Richard Biener PR rtl-optimization/99054 * cfgrtl.c (rtl-optimization/99054): Return an auto_vec. (fixup_partitions): Adjust. (rtl_verify_edges): Likewise.
[Bug ipa/99034] [10/11 Regression] ICE in emit_to_new_bb_before, at except.c:932
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99034 Martin Liška changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Martin Liška --- I'll take a look.
[Bug ipa/97346] IPA reference reference_vars_to_consider leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97346 --- Comment #4 from Richard Biener --- So like the following? Note the leak is the allcoation from ipa_init being not released when we do the vec_alloc in ipa_reference_write_optimization_summary (maybe this function wants to use its own private vector?!) diff --git a/gcc/ipa-reference.c b/gcc/ipa-reference.c index 2ea2a6d5327..328fa8f732c 100644 --- a/gcc/ipa-reference.c +++ b/gcc/ipa-reference.c @@ -966,8 +966,7 @@ propagate (void) ipa_ref_var_info_summaries = NULL; } - if (dump_file) -vec_free (reference_vars_to_consider); + vec_free (reference_vars_to_consider); reference_vars_to_consider = NULL; return remove_p ? TODO_remove_functions : 0; } @@ -1059,7 +1058,7 @@ ipa_reference_write_optimization_summary (void) auto_bitmap ltrans_statics; int i; - vec_alloc (reference_vars_to_consider, ipa_reference_vars_uids); + vec_truncate (reference_vars_to_consider, 0); reference_vars_to_consider->safe_grow (ipa_reference_vars_uids, true); /* See what variables we are interested in. */ @@ -1117,7 +1116,8 @@ ipa_reference_write_optimization_summary (void) } } lto_destroy_simple_output_block (ob); - delete reference_vars_to_consider; + vec_free (reference_vars_to_consider); + reference_vars_to_consider = NULL; } /* Deserialize the ipa info for lto. */
[Bug ipa/97346] IPA reference reference_vars_to_consider leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97346 --- Comment #5 from Richard Biener --- (In reply to Richard Biener from comment #4) > So like the following? Note the leak is the allcoation from ipa_init > being not released when we do the vec_alloc in > ipa_reference_write_optimization_summary (maybe this function wants to > use its own private vector?!) > > diff --git a/gcc/ipa-reference.c b/gcc/ipa-reference.c > index 2ea2a6d5327..328fa8f732c 100644 > --- a/gcc/ipa-reference.c > +++ b/gcc/ipa-reference.c > @@ -966,8 +966,7 @@ propagate (void) >ipa_ref_var_info_summaries = NULL; > } > > - if (dump_file) > -vec_free (reference_vars_to_consider); > + vec_free (reference_vars_to_consider); >reference_vars_to_consider = NULL; >return remove_p ? TODO_remove_functions : 0; > } > @@ -1059,7 +1058,7 @@ ipa_reference_write_optimization_summary (void) >auto_bitmap ltrans_statics; >int i; > > - vec_alloc (reference_vars_to_consider, ipa_reference_vars_uids); > + vec_truncate (reference_vars_to_consider, 0); vec_safe_truncate >reference_vars_to_consider->safe_grow (ipa_reference_vars_uids, true); > >/* See what variables we are interested in. */ > @@ -1117,7 +1116,8 @@ ipa_reference_write_optimization_summary (void) > } >} >lto_destroy_simple_output_block (ob); > - delete reference_vars_to_consider; > + vec_free (reference_vars_to_consider); > + reference_vars_to_consider = NULL; > } > > /* Deserialize the ipa info for lto. */
[Bug libstdc++/98985] libstdc++: filesystem::rename not overwriting files on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98985 --- Comment #2 from m.heinzler at heinzler dot de --- (In reply to Jonathan Wakely from comment #1) > I'll fix it by using MoveFileExW in posix::rename instead. > > MoveFileExW seems to have some weird differences from POSIX rename when the > source or destination name is a directory. Yes, after taking another look that seems much better suited there. I don't know about all the differences but as the currently used Microsoft implementation of rename is also far from POSIX compliant I'd guess this is a project for another day :). At least I have not stumbled upon any issues related to that yet. Thank you!
[Bug ipa/97346] IPA reference reference_vars_to_consider leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97346 --- Comment #6 from Richard Biener --- I'm testing the following which fixes the leak(s) diff --git a/gcc/ipa-reference.c b/gcc/ipa-reference.c index 2ea2a6d5327..a6b79fb9381 100644 --- a/gcc/ipa-reference.c +++ b/gcc/ipa-reference.c @@ -966,8 +966,7 @@ propagate (void) ipa_ref_var_info_summaries = NULL; } - if (dump_file) -vec_free (reference_vars_to_consider); + vec_free (reference_vars_to_consider); reference_vars_to_consider = NULL; return remove_p ? TODO_remove_functions : 0; } @@ -1059,6 +1058,7 @@ ipa_reference_write_optimization_summary (void) auto_bitmap ltrans_statics; int i; + vec_free (reference_vars_to_consider); vec_alloc (reference_vars_to_consider, ipa_reference_vars_uids); reference_vars_to_consider->safe_grow (ipa_reference_vars_uids, true); @@ -1117,7 +1117,8 @@ ipa_reference_write_optimization_summary (void) } } lto_destroy_simple_output_block (ob); - delete reference_vars_to_consider; + vec_free (reference_vars_to_consider); + reference_vars_to_consider = NULL; } /* Deserialize the ipa info for lto. */
[Bug rtl-optimization/99054] memory leak in thread_prologue_and_epilogue_insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99054 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug analyzer/99042] Another false -Wanalyzer-malloc-leak on code path involving unknown function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99042 --- Comment #3 from David Malcolm --- (In reply to Antonio Chirizzi from comment #2) > just curious of what you mean with "unknown function". Is it something that > has not been declared or is not known to the compiler up to that point? A function that the compiler doesn't have a definition for (typically a function declared extern, defined in a different translation unit).
[Bug preprocessor/96391] [10/11 Regression] internal compiler error: in linemap_compare_locations, at libcpp/line-map.c:1359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 --- Comment #13 from David Malcolm --- (In reply to Michael Cronenworth from comment #12) > That's the Linux GCC. You will want to see the version for MinGW: > mingw-gcc-9.2.1-6.fc32 - which does not crash so I'm not surprised you > didn't crash. Thanks. > > Michael: is that the mock configuration that's failing for you, or are you > > using a different one? > > Try: mock --rebuild mingw-wine-gecko-2.47.1-2.fc32.src.rpm -N -r > fedora-33-i386 Thanks; however with that command line it fails for me very early in the build with: 0:03.33 Generating /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1/configure using autoconf 0:03.34 autoconf: configure.in: No such file or directory 0:03.34 gmake: *** [client.mk:323: /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1/configure] Error 1 Am I doing something wrong, or does that src.rpm need reworking? (sorry, my packaging skills are rather rusty) This is with the src.rpm downloaded from the link in comment #0: $ md5sum mingw-wine-gecko-2.47.1-2.fc32.src.rpm 82684032aabc8bd3b19923aa9452eb5e mingw-wine-gecko-2.47.1-2.fc32.src.rpm $ rpm -q mock mock-2.3-1.fc32.noarch If you supply me with a .src.rpm that manifests the compiler crash, I can try to debug it and find a simpler reproducer.
[Bug preprocessor/96391] [10/11 Regression] internal compiler error: in linemap_compare_locations, at libcpp/line-map.c:1359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 --- Comment #14 from David Malcolm --- (In reply to David Malcolm from comment #13) > $ rpm -q mock > mock-2.3-1.fc32.noarch Sorry, my bad; I had quite an old mock. I've upgraded, and the build is now progressing beyond that point.
[Bug tree-optimization/99002] [11 Regression] memory leak in if-to-switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99002 --- Comment #6 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:57d1b68d6582efec5a7ca63ea56a1cedbfe6e874 commit r11-7169-g57d1b68d6582efec5a7ca63ea56a1cedbfe6e874 Author: Martin Liska Date: Wed Feb 10 09:39:54 2021 +0100 if-to-switch: fix memory leak in case merging gcc/ChangeLog: PR tree-optimization/99002 PR tree-optimization/99026 * gimple-if-to-switch.cc (if_chain::is_beneficial): Fix memory leak when adjacent cases are merged. * tree-switch-conversion.c (switch_decision_tree::analyze_switch_statement): Use release_clusters. (make_pass_lower_switch): Remove trailing whitespace. * tree-switch-conversion.h (release_clusters): New.
[Bug tree-optimization/99026] memleak in switch-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99026 --- Comment #2 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:57d1b68d6582efec5a7ca63ea56a1cedbfe6e874 commit r11-7169-g57d1b68d6582efec5a7ca63ea56a1cedbfe6e874 Author: Martin Liska Date: Wed Feb 10 09:39:54 2021 +0100 if-to-switch: fix memory leak in case merging gcc/ChangeLog: PR tree-optimization/99002 PR tree-optimization/99026 * gimple-if-to-switch.cc (if_chain::is_beneficial): Fix memory leak when adjacent cases are merged. * tree-switch-conversion.c (switch_decision_tree::analyze_switch_statement): Use release_clusters. (make_pass_lower_switch): Remove trailing whitespace. * tree-switch-conversion.h (release_clusters): New.
[Bug rtl-optimization/98986] Try matching both orders of commutative RTX operations when there is no canonical order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98986 rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #3 from rsandifo at gcc dot gnu.org --- Yeah, I think making the canonicalisation rules go deep into the operands has scalability problems. FWIW, another similar thing I've wanted in the past is to try recognising multiple possible constants in an (and X (const_int N)) when X is known to have some bits clear. Often we try to make N contain as few bits as possible, but that can give worse results than a fuller mask. I had a WIP patch for this and binary order thing. It used a wrapper around recog (in recog.c) to apply useful-looking variations. Of course, trying multiple variations has scalability issues too, so it would need some kind of limiter.
[Bug objc++/99056] New: NIOS GCC optimizaton issue with memset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99056
Bug ID: 99056
Summary: NIOS GCC optimizaton issue with memset
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc++
Assignee: unassigned at gcc dot gnu.org
Reporter: lpacheco at ael dot com.br
Target Milestone: ---
Hi,
Performing an activity of source to object code (checking if the compiler
generated exactly what was intended, nothing more, nothing less) I detected a
failure.
Source code:
UINT32 ServiceCallingMemset(int a, size_t b)
{
UINT8 MemoryToBeSet = 0;
memset((void*)&MemoryToBeSet,a,b);
if(MemoryToBeSet == 1)
{
return 1;
}
else
{
return 0;
}
}
Object code:
4200bdc: defffe04 addi sp,sp,-8
4200be0: dfc00115 stw ra,4(sp)
4200be4: 280d883a mov r6,r5
4200be8: 200b883a mov r5,r4
4200bec: d809883a mov r4,sp
4200bf0: 420838c0 call 420838c
4200bf4: 0005883a mov r2,zero
4200bf8: dfc00117 ldw ra,4(sp)
4200bfc: dec00204 addi sp,sp,8
4200c00: f800283a ret
If you verify the output object code, the compiler optimization is removing the
"if statement" and inserting the "else statement" only ('return 0' - 'mov
r2,zero').
But this is not correct, the compiler is not evaluating correctly the possible
value for 'MemoryToBeSet'. It seems the compiler is ignoring the 'memset'
instruction.
This issue only appear when using optimization.
The compilation flags used are:
nios2-elf-g++ -T'J:\HVS\Source\INT_BSP/linker.x'
-msys-crt0='J:\HVS\Source\INT_BSP/obj/HAL/src/crt0.o' -msys-lib=hal_bsp
-LJ:\HVS\Source\INT_BSP -Wl,-Map=Src2ObjCode.map -O1 -g -Wall -fno-defer-pop
-fno-merge-constants -fno-thread-jumps -fno-loop-optimize -fno-crossjumping
-fno-if-conversion -fno-if-conversion2 -fno-delayed-branch
-fno-guess-branch-probability -fno-cprop-registers -mhw-div -mhw-mul -mhw-mulx
-mgpopt=local -o Src2ObjCode.elf obj/Default/SRC/Src2ObjCode.o
obj/Default/SRC/comm.o -lm -msys-lib=m
$ nios2-elf-g++ --version
nios2-elf-g++.exe (Altera 17.1 Build 590) 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.
[Bug rtl-optimization/98986] Try matching both orders of commutative RTX operations when there is no canonical order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98986 --- Comment #4 from rguenther at suse dot de --- On Wed, 10 Feb 2021, rsandifo at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98986 > > rsandifo at gcc dot gnu.org changed: > >What|Removed |Added > > CC||rsandifo at gcc dot gnu.org > > --- Comment #3 from rsandifo at gcc dot gnu.org > --- > Yeah, I think making the canonicalisation rules go deep into > the operands has scalability problems. > > FWIW, another similar thing I've wanted in the past is to try > recognising multiple possible constants in an (and X (const_int N)) > when X is known to have some bits clear. Often we try to make N contain > as few bits as possible, but that can give worse results than a fuller mask. > > I had a WIP patch for this and binary order thing. It used a wrapper > around recog (in recog.c) to apply useful-looking variations. > Of course, trying multiple variations has scalability issues too, > so it would need some kind of limiter. So this is where the "autogenerated" part comes in. We should have an idea what might be useful and what isn't even worth trying by looking at the machine description (which might require exposing costs in such form for this case of constants). For commutative operands maybe recog itself can be relaxed and accept the insn with the "wrong" commutation (or fix it up itself) for example. Or maybe genrecog can magically emit commutated variants (like genmatch does for :c annotated expression branches).
[Bug tree-optimization/99026] memleak in switch-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99026 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Martin Liška --- Fixed.
[Bug tree-optimization/99002] [11 Regression] memory leak in if-to-switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99002 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #7 from Martin Liška --- Fixed.
[Bug c++/99035] [9/10/11 Regression] ICE in declare_weak, at varasm.c:5930
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99035 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Jakub Jelinek --- Created attachment 50161 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50161&action=edit gcc11-pr99035.patch Untested fix.
[Bug c++/99057] New: Memory leak in cp_parser_selection_statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99057 Bug ID: 99057 Summary: Memory leak in cp_parser_selection_statement Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: jason at gcc dot gnu.org, mpolacek at gcc dot gnu.org Target Milestone: --- I see the following leak: g++ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/warn/anonymous-namespace-3.C -c -Wduplicated-cond -wrapper valgrind,--leak-check=yes ... ==30789== 240 bytes in 6 blocks are definitely lost in loss record 1,620 of 1,879 ==30789==at 0x483977F: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==30789==by 0x1DD4BEF: xrealloc (xmalloc.c:177) ==30789==by 0xAD85B1: reserve (vec.h:290) ==30789==by 0xAD85B1: reserve (vec.h:1778) ==30789==by 0xAD85B1: safe_push (vec.h:1887) ==30789==by 0xAD85B1: cp_parser_selection_statement (parser.c:12341) ==30789==by 0xAD85B1: cp_parser_statement(cp_parser*, tree_node*, bool, bool*, vec*, unsigned int*) (parser.c:11623) ==30789==by 0xAD8712: cp_parser_statement_seq_opt(cp_parser*, tree_node*) (parser.c:12112) ==30789==by 0xAD87F0: cp_parser_compound_statement(cp_parser*, tree_node*, int, bool) (parser.c:12062) ==30789==by 0xAF60BF: cp_parser_function_body (parser.c:23991) ==30789==by 0xAF60BF: cp_parser_ctor_initializer_opt_and_function_body(cp_parser*, bool) (parser.c:24042) ==30789==by 0xAF7CCA: cp_parser_function_definition_after_declarator(cp_parser*, bool) (parser.c:29945) ==30789==by 0xAF915D: cp_parser_function_definition_from_specifiers_and_declarator (parser.c:29861) ==30789==by 0xAF915D: cp_parser_init_declarator(cp_parser*, int, cp_decl_specifier_seq*, vec*, bool, bool, int, bool*, tree_node**, unsigned int*, tree_node**) (parser.c:21564) ==30789==by 0xAFF477: cp_parser_single_declaration(cp_parser*, vec*, bool, bool, bool*) (parser.c:30441) ==30789==by 0xAFF5F1: cp_parser_template_declaration_after_parameters(cp_parser*, tree_node*, bool) (parser.c:30013) ==30789==by 0xAFFE0C: cp_parser_explicit_template_declaration(cp_parser*, bool) (parser.c:30279) ==30789==by 0xB02671: cp_parser_declaration(cp_parser*, tree_node*) (parser.c:14009)
[Bug objc++/99056] NIOS GCC optimizaton issue with memset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99056 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Target||nios2 Ever confirmed|0 |1 Last reconfirmed||2021-02-10 --- Comment #1 from Richard Biener --- Note GCC 5 is no longer maintained, you should go and report the issue to Altera who provided the compiler. When I use current trunk and a simple cc1 cross to nios2-elf I get with -O2 ServiceCallingMemset: addisp, sp, -8 mov r6, r5 mov r5, r4 addir4, sp, 3 stw ra, 4(sp) stb zero, 3(sp) callmemset ldbur2, 3(sp) cmpeqi r2, r2, 1 ldw ra, 4(sp) addisp, sp, 8 ret which I'd say shows the issue is fixed?
[Bug c++/99057] Memory leak in cp_parser_selection_statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99057 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-02-10
[Bug target/95265] aarch64: suboptimal code generation for common neon intrinsic sequence involving shrn and mull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95265 ktkachov at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Known to work||11.0 Target Milestone|--- |11.0 Status|NEW |RESOLVED CC||ktkachov at gcc dot gnu.org --- Comment #2 from ktkachov at gcc dot gnu.org --- This is fixed in GCC 11. It now generates: func: smull v2.2d, v0.2s, v1.2s smull2 v1.2d, v0.4s, v1.4s shrnv0.2s, v2.2d, 12 shrn2 v0.4s, v1.2d, 12 ret
[Bug target/95958] [meta-bug] Inefficient arm_neon.h code for AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95958 Bug 95958 depends on bug 95265, which changed state. Bug 95265 Summary: aarch64: suboptimal code generation for common neon intrinsic sequence involving shrn and mull https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95265 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug objc++/99056] NIOS GCC optimizaton issue with memset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99056 --- Comment #2 from Leonardo Pacheco --- Yes, your result shows that the issue is already fixed. Thanks, will try to open bug report to Altera. Thanks.
[Bug target/82074] [aarch64] vmlsq_f32 compiled into 2 instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82074 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||ktkachov at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from ktkachov at gcc dot gnu.org --- Fixed in all currently supported versions (8.5 an higher).
[Bug target/95958] [meta-bug] Inefficient arm_neon.h code for AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95958 Bug 95958 depends on bug 82074, which changed state. Bug 82074 Summary: [aarch64] vmlsq_f32 compiled into 2 instructions https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82074 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug ipa/97346] IPA reference reference_vars_to_consider leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97346
--- Comment #7 from Jan Hubicka ---
I tested yesterday this one (which makes the lifetime bit more explicit
- during propagation it is for dumps only). Sorry for not posting it
earlier. I just wanted to double check tha tleak is gone.
diff --git a/gcc/ipa-reference.c b/gcc/ipa-reference.c
index 2ea2a6d5327..84c018ff57c 100644
--- a/gcc/ipa-reference.c
+++ b/gcc/ipa-reference.c
@@ -458,8 +458,8 @@ ipa_init (void)
ipa_init_p = true;
- vec_alloc (reference_vars_to_consider, 10);
-
+ if (dump_file)
+vec_alloc (reference_vars_to_consider, 10);
if (ipa_ref_opt_sum_summaries != NULL)
{
@@ -967,8 +967,12 @@ propagate (void)
}
if (dump_file)
-vec_free (reference_vars_to_consider);
- reference_vars_to_consider = NULL;
+{
+ vec_free (reference_vars_to_consider);
+ reference_vars_to_consider = NULL;
+}
+ else
+gcc_checking_assert (!reference_vars_to_consider);
return remove_p ? TODO_remove_functions : 0;
}
@@ -1059,6 +1063,7 @@ ipa_reference_write_optimization_summary (void)
auto_bitmap ltrans_statics;
int i;
+ gcc_checking_assert (!reference_vars_to_consider);
vec_alloc (reference_vars_to_consider, ipa_reference_vars_uids);
reference_vars_to_consider->safe_grow (ipa_reference_vars_uids, true);
@@ -1117,7 +1122,7 @@ ipa_reference_write_optimization_summary (void)
}
}
lto_destroy_simple_output_block (ob);
- delete reference_vars_to_consider;
+ vec_free (reference_vars_to_consider);
}
/* Deserialize the ipa info for lto. */
[Bug ipa/97346] IPA reference reference_vars_to_consider leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97346
--- Comment #8 from Richard Biener ---
(In reply to Jan Hubicka from comment #7)
> I tested yesterday this one (which makes the lifetime bit more explicit
> - during propagation it is for dumps only). Sorry for not posting it
> earlier. I just wanted to double check tha tleak is gone.
>
> diff --git a/gcc/ipa-reference.c b/gcc/ipa-reference.c
> index 2ea2a6d5327..84c018ff57c 100644
> --- a/gcc/ipa-reference.c
> +++ b/gcc/ipa-reference.c
> @@ -458,8 +458,8 @@ ipa_init (void)
>
>ipa_init_p = true;
>
> - vec_alloc (reference_vars_to_consider, 10);
> -
> + if (dump_file)
> +vec_alloc (reference_vars_to_consider, 10);
>
>if (ipa_ref_opt_sum_summaries != NULL)
> {
> @@ -967,8 +967,12 @@ propagate (void)
> }
>
>if (dump_file)
> -vec_free (reference_vars_to_consider);
> - reference_vars_to_consider = NULL;
> +{
> + vec_free (reference_vars_to_consider);
> + reference_vars_to_consider = NULL;
> +}
> + else
> +gcc_checking_assert (!reference_vars_to_consider);
>return remove_p ? TODO_remove_functions : 0;
> }
>
> @@ -1059,6 +1063,7 @@ ipa_reference_write_optimization_summary (void)
>auto_bitmap ltrans_statics;
>int i;
>
> + gcc_checking_assert (!reference_vars_to_consider);
>vec_alloc (reference_vars_to_consider, ipa_reference_vars_uids);
>reference_vars_to_consider->safe_grow (ipa_reference_vars_uids, true);
>
> @@ -1117,7 +1122,7 @@ ipa_reference_write_optimization_summary (void)
> }
>}
>lto_destroy_simple_output_block (ob);
> - delete reference_vars_to_consider;
> + vec_free (reference_vars_to_consider);
maybe set reference_vars_to_consider to NULL here for consistency,
otherwise also looks good to me!
> }
>
> /* Deserialize the ipa info for lto. */
[Bug target/95964] AArch64 arm_neon.h arithmetic functions lack appropriate attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95964 ktkachov at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2021-02-10 Ever confirmed|0 |1 CC||ktkachov at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #3 from ktkachov at gcc dot gnu.org --- In GCC 11 these builtins have do get a fnspec attribute and the start pointer is hoisted. But this happens only with -fno-trapping-math (part of -Ofast) because the operation can raise FP exceptions and therefore is considered to modify global state unless -fnop-trapping-math. Is that good enough for this PR or do we want more something more fine-grained?
[Bug c++/99057] Memory leak in cp_parser_selection_statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99057
--- Comment #1 from Martin Liška ---
And this one please for C FE:
$ cat wslay.i
typedef long unsigned int size_t;
typedef struct {
}
__sigset_t;
typedef int (*__compar_fn_t) (const
void *, const void *);
extern __inline __attribute__ ((__gnu_inline__)) void * bsearch (const
void *__key, const void *__base, size_t __nmemb, size_t __size, __compar_fn_t
__compar) {
size_t __l, __u, __idx;
int __comparison;
while (__l < __u) {
if (__comparison < 0) __u = __idx;
else if (__comparison > 0) __l = __idx + 1;
}
}
$ gcc wslay.i -O -Wduplicated-cond -fsyntax-only -wrapper
valgrind,--leak-check=yes
==26658== Memcheck, a memory error detector
==26658== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==26658== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==26658== Command: /home/marxin/bin/gcc/lib/gcc/x86_64-pc-linux-gnu/11.0.0/cc1
-fpreprocessed wslay.i -quiet -dumpdir a- -dumpbase wslay.i -dumpbase-ext .i
-mtune=generic -march=x86-64 -O -Wduplicated-cond -fsyntax-only -o /dev/null
==26658==
==26658==
==26658== HEAP SUMMARY:
==26658== in use at exit: 540,404 bytes in 2,250 blocks
==26658== total heap usage: 3,394 allocs, 1,144 frees, 1,156,250 bytes
allocated
==26658==
==26658== 40 bytes in 1 blocks are definitely lost in loss record 18 of 741
==26658==at 0x483977F: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26658==by 0x1ADADFF: xrealloc (xmalloc.c:177)
==26658==by 0x8B7F55: reserve (vec.h:290)
==26658==by 0x8B7F55: reserve (vec.h:1778)
==26658==by 0x8B7F55: safe_push (vec.h:1887)
==26658==by 0x8B7F55: c_parser_if_statement (c-parser.c:6499)
==26658==by 0x8B7F55: c_parser_statement_after_labels(c_parser*, bool*,
vec*) (c-parser.c:6108)
==26658==by 0x8B856A: c_parser_compound_statement_nostart(c_parser*)
(c-parser.c:5788)
==26658==by 0x8D2C6D: c_parser_compound_statement(c_parser*, unsigned int*)
(c-parser.c:5597)
==26658==by 0x8B6569: c_parser_statement_after_labels(c_parser*, bool*,
vec*) (c-parser.c:6102)
==26658==by 0x8D5993: c_parser_statement (c-parser.c:6074)
==26658==by 0x8D5993: c_parser_c99_block_statement(c_parser*, bool*,
unsigned int*) (c-parser.c:6314)
==26658==by 0x8D66E6: c_parser_while_statement(c_parser*, bool, unsigned
short, bool*) (c-parser.c:6634)
==26658==by 0x8B6C90: c_parser_statement_after_labels(c_parser*, bool*,
vec*) (c-parser.c:6114)
==26658==by 0x8B856A: c_parser_compound_statement_nostart(c_parser*)
(c-parser.c:5788)
==26658==by 0x8D2C6D: c_parser_compound_statement(c_parser*, unsigned int*)
(c-parser.c:5597)
==26658==by 0x8D441F: c_parser_declaration_or_fndef(c_parser*, bool, bool,
bool, bool, bool, tree_node**, vec, bool, tree_node*,
oacc_routine_data*, bool*) (c-parser.c:2539)
[Bug libstdc++/99058] New: Consider adding a note about std::optional ABI break to the C++17 status table
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99058 Bug ID: 99058 Summary: Consider adding a note about std::optional ABI break to the C++17 status table Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: bspencer at blackberry dot com Target Milestone: --- In this table https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2017 the row labelled "Library Fundamentals V1 TS Components: optional" says it's supported since "7.1" and references Note 1, but there's no mention of the ABI break between 7.x and 8.x. Perhaps I was misusing this table, but I interpreted "supported since 7.1" to mean that if I compile against 7.1 headers, my code will remain ABI compatible against future versions of the library _and_ other code compiled against future versions of the headers. This ABI break caught me by surprise, and even though these versions are older now, it seems worthwhile to at least mention the break in a note to help others. BTW, this particular example also happens to come up as a question in Marshall Clow's recent talk on the topic of standard library ABIs. See https://youtu.be/7RoTDjLLXJQ?t=3191 Thanks.
[Bug c++/99030] [11 Regression] ICE in finish_expr_stmt, at cp/semantics.c:776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99030 --- Comment #2 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:f8fac476b5ce4b9a37ea2b257d9da810f8c507be commit r11-7170-gf8fac476b5ce4b9a37ea2b257d9da810f8c507be Author: Nathan Sidwell Date: Wed Feb 10 05:29:39 2021 -0800 c++: generic lambdas and local-externs from outer scopes [PR 99030] Lambdas can refer to local externs from their enclosing scope. When the lambda's generic but the containing function is not a temploid, we'll never have tsubsted the declaring decl so won't have a local specialization. But in that case we can just use the decl we tsubsting directly -- it's not dependent. PR c++/99030 gcc/cp * pt.c (tsubst_copy) [VAR_DECL]: For a DECL_LOCAL_DECL_P T is the answer if there's no local specialization. gcc/testsuite/ * g++.dg/lookup/pr99030.C: New.
[Bug c++/99030] [11 Regression] ICE in finish_expr_stmt, at cp/semantics.c:776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99030 Nathan Sidwell changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Nathan Sidwell --- f8fac476b5c 2021-02-10 | c++: generic lambdas and local-externs from outer scopes [PR 99030]
[Bug c/99049] _Alignof ignores requested alignment of bit-field types in ms_struct struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99049 --- Comment #2 from Julian Orth --- MSVC returns 128 for both: https://godbolt.org/z/16Tzh7
[Bug rtl-optimization/98863] [11 Regression] WRF with LTO consumes a lot of memory in REE, FWPROP and x86 specific passes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98863 --- Comment #46 from Richard Biener --- Created attachment 50162 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50162&action=edit df-live on demand So I did the experiment to turn off DF_LIVE as permanent like we do for -O1. w/o permanent DF_LIVE: df reaching defs : 23.36 ( 7%) 0.13 ( 4%) 23.84 ( 7%) 0 ( 0%) df live regs : 45.56 ( 14%) 0.09 ( 3%) 45.61 ( 14%) 0 ( 0%) df live&initialized regs : 19.42 ( 6%) 0.11 ( 3%) 19.49 ( 6%) 0 ( 0%) TOTAL : 314.61 3.19317.93 2538M w/ permanent DF_LIVE: df reaching defs : 23.53 ( 7%) 0.01 ( 0%) 23.45 ( 7%) 0 ( 0%) df live regs : 44.95 ( 14%) 0.09 ( 3%) 45.13 ( 14%) 0 ( 0%) df live&initialized regs : 19.70 ( 6%) 0.08 ( 3%) 19.68 ( 6%) 0 ( 0%) TOTAL : 313.83 2.94316.92 2538M which doesn't seem to be much of a difference (but there's some observable times with less memory use since live consumes ~400MB in bitmaps). It should be noted that the passes that add DF_LIVE anyway (and thus on-demand at -O1) are all enabled by default at -O1. Which makes me question this design decision even more. In principle keeping DF_LIVE from invariant motion to doloop might make sense (unroll loops isn't enabled by default, but also not all targets have doloop). Maybe even starting from ifcvt1. I've attached the patch used for the experiment.
[Bug rtl-optimization/98692] Unitialized Values reported only with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692 --- Comment #18 from Mark Wielaard --- The current thinking (Julian did the thinking, I am just repeating) is that this is caused by the way the _savegpr and/or restgpr functions return using blr. PPC has two special "lets zap the red zone" (the 288 bytes below the stack pointer) cases: # define VG_STACK_REDZONE_SZB288 // number of addressable bytes below R1 // from 64-bit PowerPC ELF ABI // Supplement 1.7 guest_ppc_zap_RZ_at_blr guest is ppc64-linux==> True guest is ppc32-linux==> False guest is other ==> inapplicable guest_ppc_zap_RZ_at_bl guest is ppc64-linux==> const True guest is ppc32-linux==> const False guest is other ==> inapplicable guest_stack_redzone_size guest is ppc32-linux==> 0 guest is ppc64-linux==> 288 guest is amd64-linux==> 128 guest is other ==> inapplicable /* PPC and AMD64 GUESTS only: how many bytes below the stack pointer are validly addressible? */ Int guest_stack_redzone_size; /* PPC GUESTS only: should we zap the stack red zone at a 'blr' (function return) ? */ Bool guest_ppc_zap_RZ_at_blr; /* PPC GUESTS only: should we zap the stack red zone at a 'bl' (function call) ? Is supplied with the guest address of the target of the call since that may be significant. If NULL, is assumed equivalent to a fn which always returns False. */ Bool (*guest_ppc_zap_RZ_at_bl)(Addr); # if defined(VGP_ppc32_linux) vex_abiinfo.guest_ppc_zap_RZ_at_blr= False; vex_abiinfo.guest_ppc_zap_RZ_at_bl = NULL; # endif # if defined(VGP_ppc64be_linux) vex_abiinfo.guest_ppc_zap_RZ_at_blr= True; vex_abiinfo.guest_ppc_zap_RZ_at_bl = const_True; vex_abiinfo.host_ppc_calls_use_fndescrs= True; # endif # if defined(VGP_ppc64le_linux) vex_abiinfo.guest_ppc_zap_RZ_at_blr= True; vex_abiinfo.guest_ppc_zap_RZ_at_bl = const_True; vex_abiinfo.host_ppc_calls_use_fndescrs= False; # endif What happens on a blr function return is that, based on the guest_ppc_zap_RZ_at_blr value, the redzone is marked as containing undefined values. And indeed, with this patch: diff --git a/coregrind/m_translate.c b/coregrind/m_translate.c index 332202a91..6dd01afac 100644 --- a/coregrind/m_translate.c +++ b/coregrind/m_translate.c @@ -1709,7 +1709,7 @@ Bool VG_(translate) ( ThreadId tid, # endif # if defined(VGP_ppc64le_linux) - vex_abiinfo.guest_ppc_zap_RZ_at_blr= True; + vex_abiinfo.guest_ppc_zap_RZ_at_blr= False; vex_abiinfo.guest_ppc_zap_RZ_at_bl = const_True; vex_abiinfo.host_ppc_calls_use_fndescrs= False; # endif The warning goes away. But is that the right thing to do always? It seems to mask issues where a function is using the red zone values set by another function.
[Bug c++/99059] New: Static inline variable can't refer to itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99059
Bug ID: 99059
Summary: Static inline variable can't refer to itself
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent.hamp at higaski dot at
Target Milestone: ---
Declaring a static inline member variable and initializing it with a pointer to
itself is currently impossible. The textbook example for such code would
probably be a linked list of some sort:
struct link {
link* next{nullptr};
link* prev{nullptr};
};
struct list {
static inline link tail{&tail, &tail};
};
list l;
Making the member just static and initializing it outside of the class works,
but this kinda breaks my mental model of "static inline" as just being
syntactic sugar. Is this an actual bug or just some overlooked thing in the
standard?
[Bug c++/99057] Memory leak in cp_parser_selection_statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99057 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Marek Polacek --- -Wduplicated-cond -> mine
[Bug c++/99033] [9/10/11 Regression] ICE in tree_to_poly_int64, at tree.c:3091
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99033 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 50163 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50163&action=edit gcc11-pr99033.patch Untested fix.
[Bug rtl-optimization/98692] Unitialized Values reported only with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692 jseward at acm dot org changed: What|Removed |Added CC||jseward at acm dot org --- Comment #19 from jseward at acm dot org --- (In reply to Mark Wielaard from comment #18) (expanding marginally on Mark's comment) Currently the Memcheck ppc64be and ppc64le ports assume that the redzone (the 288 bytes below SP) is volatile across both calls and returns, and it enforces this behaviour by painting that area of memory as "undefined" for both calls and returns. But the optimisation discussed here appears to carry live data across a return (that's what a "blr" is, right?) So in effect the problem occurs because this optimisation changes the ABI semantics that Memcheck has thus far assumed. As Mark says, we can "fix" this just by disabling the zap-on-return instrumentation behaviour, but that comes at the cost of completely losing the ability to detect genuinely incorrect uses of the redzone across a return.
[Bug rtl-optimization/98692] Unitialized Values reported only with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #20 from Jakub Jelinek --- Can you disable it just for these magic entrypoints (either by name or by content)?
[Bug middle-end/99007] [8/9/10 Regression] ICE in dominated_by_p, at dominance.c:1124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99007 Jakub Jelinek changed: What|Removed |Added Target Milestone|11.0|8.5 Summary|[11 Regression] ICE in |[8/9/10 Regression] ICE in |dominated_by_p, at |dominated_by_p, at |dominance.c:1124|dominance.c:1124 --- Comment #6 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug middle-end/99007] [8/9/10 Regression] ICE in dominated_by_p, at dominance.c:1124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99007 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug rtl-optimization/98692] Unitialized Values reported only with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692 --- Comment #21 from jseward at acm dot org --- (In reply to Jakub Jelinek from comment #20) > Can you disable it just for these magic entrypoints (either by name or by > content)? In principle yes. I prefer by-content rather than by-name, in the case where all symbol names have disappeared or changed, etc. However, this would require having a reliable mechanism for detecting the entry points by inspecting their content. It would also require a certain amount of plumbing work, basically making `VexAbiInfo::guest_ppc_zap_RZ_at_blr` be a function rather than a Bool, in the same way that `VexAbiInfo::guest_ppc_zap_RZ_at_bl` already is. It might be a day or two's work to set up and test, once we had a reliable identify-by-content routine available.
[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 Richard Biener changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #83 from Richard Biener --- Meh. On trunk (GCC 11) we now have for the reduced testcase > ./f951 -quiet testcase_reduced.f90 -ffree-line-length-512 -ftime-report -O3 Time variable usr sys wall GGC ... callgraph ipa passes : 28.09 ( 8%) 0.23 ( 38%) 28.33 ( 8%) 68M ( 12%) ipa inlining heuristics: 5.13 ( 1%) 0.01 ( 2%) 5.13 ( 1%) 14M ( 3%) alias stmt walking : 7.03 ( 2%) 0.09 ( 15%) 7.15 ( 2%) 277k ( 0%) tree PTA : 26.20 ( 7%) 0.17 ( 28%) 26.39 ( 7%) 25M ( 5%) store merging : 308.60 ( 84%) 0.01 ( 2%) 308.70 ( 84%) 3858k ( 1%) TOTAL : 365.68 0.61366.42 557M so store-merging goes bollocks. I will try to dig into it a bit but I'm not very familiar with the code. GCC 10 behaves similar here but not as bad: store merging : 232.10 ( 82%) 0.02 ( 4%) 232.19 ( 82%) 3837 kB ( 1%) TOTAL : 283.51 0.45284.05 582957 kB while GCC 9 is sane: store merging : 0.04 ( 0%) 0.00 ( 0%) 0.04 ( 0%) 2700 kB ( 1%) TOTAL : 88.59 0.70 89.34 521364 kB
[Bug rtl-optimization/98692] Unitialized Values reported only with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692 --- Comment #22 from jseward at acm dot org --- Looking back at the above, it's now clearer what the problem is: # Park potentially live data in the red zone _savegpr0_14: std r14,-144(r1) _savegpr0_15: std r15,-136(r1) _savegpr0_16: std r16,-128(r1) _savegpr0_17: std r17,-120(r1) _savegpr0_18: std r18,-112(r1) _savegpr0_19: std r19,-104(r1) _savegpr0_20: std r20,-96(r1) _savegpr0_21: std r21,-88(r1) _savegpr0_22: std r22,-80(r1) _savegpr0_23: std r23,-72(r1) _savegpr0_24: std r24,-64(r1) _savegpr0_25: std r25,-56(r1) _savegpr0_26: std r26,-48(r1) _savegpr0_27: std r27,-40(r1) _savegpr0_28: std r28,-32(r1) _savegpr0_29: std r29,-24(r1) _savegpr0_30: std r30,-16(r1) _savegpr0_31: std r31,-8(r1) std r0, 16(r1) # And ka-zap! Memcheck paints -288(r1) .. -1(r1) as undefined. blr # So now they're all "unusable".
[Bug c++/95675] [8/9/10/11 Regression] internal compiler error: in build_over_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95675 Patrick Palka changed: What|Removed |Added CC||david at doublewise dot net --- Comment #7 from Patrick Palka --- *** Bug 99016 has been marked as a duplicate of this bug. ***
[Bug c++/99016] [9/10/11 Regression] Internal compiler error from decltype of binary operator when one operand is a prvalue function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99016 Patrick Palka changed: What|Removed |Added Resolution|--- |DUPLICATE CC||ppalka at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #2 from Patrick Palka --- Hmm, looks like a dup of PR95675 *** This bug has been marked as a duplicate of bug 95675 ***
[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #84 from Richard Biener --- So it's the usual (quadratic) culprit: Samples: 1M of event 'cycles:u', Event count (approx.): 1675893461671 Overhead Samples Command Shared Object Symbol 20.61%316521 f951 f951 [.] get_ref_base_and_extent 14.42%221221 f951 f951 [.] (anonymous namespace)::pass_store_merging::terminate_all_aliasing_chains 5.77% 88586 f951 f951 [.] special_function_p I'll see whether I can do some surgery.
[Bug preprocessor/96391] [10/11 Regression] internal compiler error: in linemap_compare_locations, at libcpp/line-map.c:1359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 --- Comment #15 from David Malcolm --- #0 fancy_abort (file=0x95b0ab6 "../../libcpp/line-map.c", line=1359, function=0x95b0ace "linemap_compare_locations") at ../../gcc/diagnostic.c:1778 #1 0x08fcbecf in linemap_compare_locations (set=0xf7ffb000, pre=2146782942, post=) at ../../libcpp/line-map.c:1359 #2 0x080f4378 in linemap_location_before_p (loc_b=2146782943, loc_a=2146782942, set=) at ../../gcc/../libcpp/include/line-map.h:1247 #3 min_location (locb=2146782942, loca=2146782943) at ../../gcc/cp/decl.c:10641 #4 smallest_type_location (type_quals=type_quals@entry=1, locations=locations@entry=0xc778) at ../../gcc/cp/decl.c:10673 #5 0x081024bb in grokdeclarator (declarator=0xa03c950, declspecs=0xc778, decl_context=NORMAL, initialized=0, attrlist=0xc62c) at ../../gcc/cp/decl.c:11008 #6 0x0810a109 in start_decl (declarator=0xa03c950, declspecs=0xc778, initialized=0, attributes=, prefix_attributes=0x0, pushed_scope_p=0xc68c) at ../../gcc/cp/decl.c:5226 #7 0x0818face in cp_parser_init_declarator (parser=0xec83dae0, flags=, decl_specifiers=0xc778, checks=0x0, function_definition_allowed_p=true, member_p=false, declares_class_or_enum=0, function_definition_p=0xc71c, maybe_range_for_decl=0x0, init_loc=0xc710, auto_result=0xc7fc) at ../../gcc/cp/parser.c:20776 #8 0x08172e04 in cp_parser_simple_declaration (parser=0xec83dae0, function_definition_allowed_p=, maybe_range_for_decl=0x0) at ../../gcc/cp/parser.c:13739 #9 0x08198e6a in cp_parser_declaration (parser=0xec83dae0) at ../../gcc/cp/parser.c:13438 #10 0x081998cb in cp_parser_declaration_seq_opt (parser=) at ../../gcc/cp/parser.c:13314 #11 cp_parser_linkage_specification (parser=0xec83dae0) at ../../gcc/cp/parser.c:14632 #12 0x08198ed2 in cp_parser_declaration (parser=0xec83dae0) at ../../gcc/cp/parser.c:13375 #13 0x081995b6 in cp_parser_translation_unit (parser=0xec83dae0) at ../../gcc/cp/parser.c:4734 #14 c_parse_file () at ../../gcc/cp/parser.c:44001 #15 0x0825a13c in c_common_parse_file () at ../../gcc/c-family/c-opts.c:1190 #16 0x086be8ce in compile_file () at ../../gcc/toplev.c:458 #17 0x0809227d in do_compile () at ../../gcc/toplev.c:2298 #18 toplev::main (this=0xca4e, argc=120, argv=0xcb24) at ../../gcc/toplev.c:2437 #19 0x08096231 in main (argc=120, argv=0xcb24) at ../../gcc/main.c:39 It's hitting the abort at line 1359 within linemap_compare_locations: 1350 /* So pre and post represent two tokens that are present in a 1351 same macro expansion. Let's see if the token for pre was 1352 before the token for post in that expansion. */ 1353 unsigned i0, i1; 1354 const struct line_map *map = 1355first_map_in_common (set, pre, post, &l0, &l1); 1356 1357 if (map == NULL) 1358/* This should not be possible. */ 1359abort (); where: (gdb) p /x loc_a $1 = 0x7ff54ede (gdb) p /x loc_b $2 = 0x7ff54edf (gdb) call inform (loc_a, "loc_a") In file included from /usr/i686-w64-mingw32/sys-root/mingw/include/minwindef.h:163, from /usr/i686-w64-mingw32/sys-root/mingw/include/windef.h:8, from /usr/i686-w64-mingw32/sys-root/mingw/include/windows.h:69, from /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1/widget/windows/AudioSession.cpp:7, from /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1-x86/widget/windows/Unified_cpp_widget_windows0.cpp:2: /usr/i686-w64-mingw32/sys-root/mingw/include/cfgmgr32.h: At global scope: /usr/i686-w64-mingw32/sys-root/mingw/include/cfgmgr32.h:19: note: loc_a 19 | typedef CONST VOID *PCVOID; | (gdb) call inform (loc_b, "loc_b") In file included from /usr/i686-w64-mingw32/sys-root/mingw/include/windef.h:8, from /usr/i686-w64-mingw32/sys-root/mingw/include/windows.h:69, from /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1/widget/windows/AudioSession.cpp:7, from /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1-x86/widget/windows/Unified_cpp_widget_windows0.cpp:2: /usr/i686-w64-mingw32/sys-root/mingw/include/cfgmgr32.h:19: note: loc_b 19 | typedef CONST VOID *PCVOID; |
[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #85 from Richard Biener ---
Starting new chain with statement:
D.31414 ={v} {CLOBBER};
The base object is:
&D.31414
Starting new chain with statement:
D.31415 ={v} {CLOBBER};
The base object is:
&D.31415
...
but those are all the last use of the base object so they just add up and
are never invalidated, but lengthening the m_stores_head list and thus
making terminate_all_aliasing_chains more expensive.
Jakub, were the clobbers ever supposed to _start_ a chain?
With
diff --git a/gcc/gimple-ssa-store-merging.c b/gcc/gimple-ssa-store-merging.c
index f0f4a068de5..fa9a092d544 100644
--- a/gcc/gimple-ssa-store-merging.c
+++ b/gcc/gimple-ssa-store-merging.c
@@ -5175,6 +5175,9 @@ pass_store_merging::process_store (gimple *stmt)
/* Store aliases any existing chain? */
ret |= terminate_all_aliasing_chains (NULL, stmt);
+ /* Do not start a new chain from a CLOBBER. */
+ if (gimple_clobber_p (stmt))
+return ret;
/* Start a new chain. */
class imm_store_chain_info *new_chain
= new imm_store_chain_info (m_stores_head, base_addr);
compile-time gets down to
store merging : 1.18 ( 2%) 0.00 ( 0%) 1.18 ( 2%)
3858k ( 1%)
TOTAL : 59.84 0.57 60.43
557M
I'm checking if it has any testsuite fallout.
[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #86 from Richard Biener --- OK, so clobber handling was added as a fix for PR92038
[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #87 from Jakub Jelinek --- At least for PR92038 it is important to see CLOBBERs in the chain, including the first position in there.
[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #88 from rguenther at suse dot de --- On Wed, 10 Feb 2021, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 > > --- Comment #87 from Jakub Jelinek --- > At least for PR92038 it is important to see CLOBBERs in the chain, including > the first position in there. Hmm, OK. I'll look closer tomorrow but can you try to explain why it's ever important at the first position?
[Bug preprocessor/96391] [10/11 Regression] internal compiler error: in linemap_compare_locations, at libcpp/line-map.c:1359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 --- Comment #16 from rguenther at suse dot de --- On Wed, 10 Feb 2021, dmalcolm at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 > > --- Comment #15 from David Malcolm --- > #0 fancy_abort (file=0x95b0ab6 "../../libcpp/line-map.c", line=1359, > function=0x95b0ace "linemap_compare_locations") > at ../../gcc/diagnostic.c:1778 > #1 0x08fcbecf in linemap_compare_locations (set=0xf7ffb000, pre=2146782942, > post=) at ../../libcpp/line-map.c:1359 > #2 0x080f4378 in linemap_location_before_p (loc_b=2146782943, > loc_a=2146782942, set=) > at ../../gcc/../libcpp/include/line-map.h:1247 > #3 min_location (locb=2146782942, loca=2146782943) at > ../../gcc/cp/decl.c:10641 > #4 smallest_type_location (type_quals=type_quals@entry=1, > locations=locations@entry=0xc778) at ../../gcc/cp/decl.c:10673 > #5 0x081024bb in grokdeclarator (declarator=0xa03c950, declspecs=0xc778, > decl_context=NORMAL, initialized=0, attrlist=0xc62c) > at ../../gcc/cp/decl.c:11008 > #6 0x0810a109 in start_decl (declarator=0xa03c950, declspecs=0xc778, > initialized=0, attributes=, prefix_attributes=0x0, > pushed_scope_p=0xc68c) at ../../gcc/cp/decl.c:5226 > #7 0x0818face in cp_parser_init_declarator (parser=0xec83dae0, > flags=, decl_specifiers=0xc778, checks=0x0, > function_definition_allowed_p=true, member_p=false, > declares_class_or_enum=0, function_definition_p=0xc71c, > maybe_range_for_decl=0x0, > init_loc=0xc710, auto_result=0xc7fc) at > ../../gcc/cp/parser.c:20776 > #8 0x08172e04 in cp_parser_simple_declaration (parser=0xec83dae0, > function_definition_allowed_p=, maybe_range_for_decl=0x0) > at ../../gcc/cp/parser.c:13739 > #9 0x08198e6a in cp_parser_declaration (parser=0xec83dae0) at > ../../gcc/cp/parser.c:13438 > #10 0x081998cb in cp_parser_declaration_seq_opt (parser=) at > ../../gcc/cp/parser.c:13314 > #11 cp_parser_linkage_specification (parser=0xec83dae0) at > ../../gcc/cp/parser.c:14632 > #12 0x08198ed2 in cp_parser_declaration (parser=0xec83dae0) at > ../../gcc/cp/parser.c:13375 > #13 0x081995b6 in cp_parser_translation_unit (parser=0xec83dae0) at > ../../gcc/cp/parser.c:4734 > #14 c_parse_file () at ../../gcc/cp/parser.c:44001 > #15 0x0825a13c in c_common_parse_file () at ../../gcc/c-family/c-opts.c:1190 > #16 0x086be8ce in compile_file () at ../../gcc/toplev.c:458 > #17 0x0809227d in do_compile () at ../../gcc/toplev.c:2298 > #18 toplev::main (this=0xca4e, argc=120, argv=0xcb24) at > ../../gcc/toplev.c:2437 > #19 0x08096231 in main (argc=120, argv=0xcb24) at ../../gcc/main.c:39 > > > It's hitting the abort at line 1359 within linemap_compare_locations: > > 1350 /* So pre and post represent two tokens that are present in a > 1351 same macro expansion. Let's see if the token for pre was > 1352 before the token for post in that expansion. */ > 1353 unsigned i0, i1; > 1354 const struct line_map *map = > 1355first_map_in_common (set, pre, post, &l0, &l1); > 1356 > 1357 if (map == NULL) > 1358/* This should not be possible. */ > 1359abort (); > > where: > > (gdb) p /x loc_a > $1 = 0x7ff54ede > (gdb) p /x loc_b > $2 = 0x7ff54edf > (gdb) call inform (loc_a, "loc_a") > In file included from > /usr/i686-w64-mingw32/sys-root/mingw/include/minwindef.h:163, > from /usr/i686-w64-mingw32/sys-root/mingw/include/windef.h:8, > from > /usr/i686-w64-mingw32/sys-root/mingw/include/windows.h:69, > from > /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1/widget/windows/AudioSession.cpp:7, > from > /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1-x86/widget/windows/Unified_cpp_widget_windows0.cpp:2: > /usr/i686-w64-mingw32/sys-root/mingw/include/cfgmgr32.h: At global scope: > /usr/i686-w64-mingw32/sys-root/mingw/include/cfgmgr32.h:19: note: loc_a >19 | typedef CONST VOID *PCVOID; > | > (gdb) call inform (loc_b, "loc_b") > In file included from /usr/i686-w64-mingw32/sys-root/mingw/include/windef.h:8, > from > /usr/i686-w64-mingw32/sys-root/mingw/include/windows.h:69, > from > /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1/widget/windows/AudioSession.cpp:7, > from > /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1-x86/widget/windows/Unified_cpp_widget_windows0.cpp:2: > /usr/i686-w64-mingw32/sys-root/mingw/include/cfgmgr32.h:19: note: loc_b >19 | typedef CONST VOID *PCVOID; > | > Guess you now have to trace first_map_in_common_1 where it "breaks" since visually there should be a common map.
[Bug c/99055] memory leak in warn_parm_array_mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99055 Martin Sebor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-02-10 CC||msebor at gcc dot gnu.org
[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #89 from Richard Biener ---
Fallout includes
FAIL: g++.dg/opt/store-merging-1.C scan-tree-dump store-merging "New sequence
of [12] stores to replace old one of 2 stores"
which shows
Starting new chain with statement:
s ={v} {CLOBBER};
The base object is:
&s
Recording immediate store from stmt:
s.a = 0;
Recording immediate store from stmt:
s.b = 0;
stmt causes chain termination:
foo (s);
and the CLOBBER allows us to use zeros for padding:
Store 0:
bitsize:64 bitpos:0 val:{CLOBBER}
Store 1:
bitsize:32 bitpos:0 val:0
Store 2:
bitsize:8 bitpos:32 val:0
After writing {CLOBBER} of size 64 at position 0
the merged value contains 00 00 00 00 00 00 00 00
the merged mask contains 00 00 00 00 00 00 00 00
After writing 0 of size 32 at position 0
the merged value contains 00 00 00 00 00 00 00 00
the merged mask contains 00 00 00 00 00 00 00 00
After writing 0 of size 8 at position 32
the merged value contains 00 00 00 00 00 00 00 00
the merged mask contains 00 00 00 00 00 00 00 00
Coalescing successful!
Merged into 1 stores
New sequence of 1 stores to replace old one of 2 stores
# .MEM_6 = VDEF <.MEM_5>
MEM [(void *)&s] = 0;
Merging successful!
[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #90 from Jakub Jelinek --- Because it says that the whole range is uninitialized, so the store merging code doesn't need to care about pre-existing content in any gaps between the stored values. So say when the whole var is clobbered and then the code stores to every second bitfield, we don't need to read the old content, mask it, or with the stored bits and store that, but can just put some suitable value into the gaps (0 or all ones or whatever is best). For quadratic behavior, I wonder if we just shouldn't see how many chains are we tracking currently and if we have too many (some param), terminate all of them.
[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #91 from Richard Biener --- So the other simple idea I have is to limit the number of active store groups and force-terminate in either a LRU or FIFO manner. For the testcase at hand the decls we start the chain for are all only used in full but knowing that would require some pre-analysis of the IL similar to what SRA does for example (collecting all accesses). It's then also still easy to "break" such heuristic so limiting is in the end the only (and I guess best) option.
[Bug preprocessor/96391] [10/11 Regression] internal compiler error: in linemap_compare_locations, at libcpp/line-map.c:1359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 --- Comment #17 from qinzhao at gcc dot gnu.org --- (In reply to David Malcolm from comment #15) > where: > > (gdb) call inform (loc_a, "loc_a") > In file included from > /usr/i686-w64-mingw32/sys-root/mingw/include/minwindef.h:163, > from > /usr/i686-w64-mingw32/sys-root/mingw/include/windef.h:8, > from > /usr/i686-w64-mingw32/sys-root/mingw/include/windows.h:69, > from > /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1/widget/windows/ > AudioSession.cpp:7, > from > /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1-x86/widget/windows/ > Unified_cpp_widget_windows0.cpp:2: > /usr/i686-w64-mingw32/sys-root/mingw/include/cfgmgr32.h: At global scope: > /usr/i686-w64-mingw32/sys-root/mingw/include/cfgmgr32.h:19: note: loc_a >19 | typedef CONST VOID *PCVOID; Is the above line the failing point for the testing file? there is a "CONST" qualifier. I am not sure whether it's helpful or not: we found that deleting "CONST" from the source code helped the compilation to succeed.
[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #92 from Richard Biener ---
Simple and stupid like the below works and does
store merging : 0.42 ( 1%) 0.00 ( 0%) 0.43 ( 1%)
3858k ( 1%)
TOTAL : 56.86 0.56 57.45
557M
we have a limit of 64 stores in a single chain, so the product of both limits
limit the number of alias queries done in terminate_all_aliasing_chains. I'll
polish it up tomorrow (and will refrain from trying to avoid the linear
walk here and keeping a counter or even a pointer to the last element).
diff --git a/gcc/gimple-ssa-store-merging.c b/gcc/gimple-ssa-store-merging.c
index f0f4a068de5..c6ec6b2cbce 100644
--- a/gcc/gimple-ssa-store-merging.c
+++ b/gcc/gimple-ssa-store-merging.c
@@ -5175,6 +5175,19 @@ pass_store_merging::process_store (gimple *stmt)
/* Store aliases any existing chain? */
ret |= terminate_all_aliasing_chains (NULL, stmt);
+ unsigned cnt = 0;
+ imm_store_chain_info **e = &m_stores_head;
+ while (*e)
+if (++cnt > 16)
+ {
+ if (dump_file && (dump_flags & TDF_DETAILS))
+ fprintf (dump_file, "Too many chains, terminating oldest before "
+ "starting a new chain.\n");
+ terminate_and_process_chain (*e);
+ }
+else
+ e = &(*e)->next;
+
/* Start a new chain. */
class imm_store_chain_info *new_chain
= new imm_store_chain_info (m_stores_head, base_addr);
[Bug rtl-optimization/98692] Unitialized Values reported only with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692 --- Comment #23 from Segher Boessenkool --- savegpr/restgpr are special ABI-defined functions that do not have all the same ABI calling conventions as normal functions. They indeed write into the parent's frame (red zone, in this case). Maybe you should allow this always when a function has not established a new frame? That always has to be done with a stdu 1,...(1) insn (in 64-bit; stwu in 32-bit, but the 32-bit Linux ABI has no red zone anyway) so it probably isn't too hard to detect. Only leaf functions will not establish a new frame normally (but that can happen later in the function, esp. with shrink-wrapping). Unstacking a frame is most other things that write to r1, often addi 1,1,... and sometimes ld 1,0(1) (there probably are other cases too that I am forgetting here). Maybe you should invalidate the red zone whenever r1 is changed, instead?
[Bug rtl-optimization/98692] Unitialized Values reported only with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692 --- Comment #24 from Segher Boessenkool --- I do see the problems for savegpr/restgpr with that suggestion, but maybe something in that vein can be done.
[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #93 from Jakub Jelinek --- I think I'd go for more chains by default, at least 64 or even 256, with a param and tracking on how many we have in a counter. The class has a ctor/dtor, so the increment/decrement of the counter can be done there. And I think it is doubly-linked, so tail should be prev on the head.
[Bug rtl-optimization/98986] Try matching both orders of commutative RTX operations when there is no canonical order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98986 --- Comment #5 from Segher Boessenkool --- (In reply to rsand...@gcc.gnu.org from comment #3) > FWIW, another similar thing I've wanted in the past is to try > recognising multiple possible constants in an (and X (const_int N)) > when X is known to have some bits clear. Often we try to make N contain > as few bits as possible, but that can give worse results than a fuller mask. This could be done in the target machine description, where it makes a lot more sense to do anyway, *if* nonzero_bits was generally usable there. I have Plans for that for GCC 12, but don't depend on it please :-)
[Bug preprocessor/96391] [10/11 Regression] internal compiler error: in linemap_compare_locations, at libcpp/line-map.c:1359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2021-02-10
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
--- Comment #18 from David Malcolm ---
(In reply to qinzhao from comment #17)
> (In reply to David Malcolm from comment #15)
> > /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1-x86/widget/windows/
> > Unified_cpp_widget_windows0.cpp:2:
> > /usr/i686-w64-mingw32/sys-root/mingw/include/cfgmgr32.h: At global scope:
> > /usr/i686-w64-mingw32/sys-root/mingw/include/cfgmgr32.h:19: note: loc_a
> >19 | typedef CONST VOID *PCVOID;
>
> Is the above line the failing point for the testing file?
>
> there is a "CONST" qualifier. I am not sure whether it's helpful or not: we
> found that deleting "CONST" from the source code helped the compilation to
> succeed.
Yes.
Note how there are no column numbers for the macro invocation locations.
The issue occurs when location_t > LINE_MAP_MAX_LOCATION_WITH_COLS (enough
source has been compiled that we've stopped tracking column numbers).
We have two locations that are both from macro expansions, and return the same
output from:
linemap_resolve_location (set, [...], LRK_MACRO_EXPANSION_POINT, NULL);
i.e. line 19 of cfgmgr32.h
cc1plus attempts to compare the locations of the two declarators ("const" and
"void"), decides that they are the same location, and assumes they must be from
the same macro expansion - but they're only at the same location because we're
no longer attempting to track column numbers.
Converting one of both of those "const" and "void" to non-macros ought to work
around it.
I've created a minimal reproducer and will attempt a fix.
[Bug libstdc++/88881] std::filesystem::status gives bad results on mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1 --- Comment #15 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:3df5b249b3c81e95cdcb293a388155ae5b168f9e commit r11-7174-g3df5b249b3c81e95cdcb293a388155ae5b168f9e Author: Jonathan Wakely Date: Wed Feb 10 16:51:34 2021 + libstdc++: Re-enable workaround for _wstat64 bug [PR 1] This wasn't fixed upstream for mingw-w64 so we still need the workaround. libstdc++-v3/ChangeLog: PR libstdc++/1 * src/c++17/fs_ops.cc (fs::status): Re-enable workaround.
[Bug preprocessor/96391] [10/11 Regression] internal compiler error: in linemap_compare_locations, at libcpp/line-map.c:1359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 --- Comment #19 from David Malcolm --- (In reply to David Malcolm from comment #18) > Converting one of both of those "const" and "void" to non-macros ought to "one or both", I meant to say
[Bug fortran/99060] New: [9/10/11 Regression] ICE in gfc_match_varspec, at fortran/primary.c:2411
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99060 Bug ID: 99060 Summary: [9/10/11 Regression] ICE in gfc_match_varspec, at fortran/primary.c:2411 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20200726 and 20200809 : $ cat z1.f90 program p real :: a print *, a%kind%n end $ gfortran-11-20200726 -c z1.f90 z1.f90:3:20: 3 |print *, a%kind%n |1 Error: Expected expression in PRINT statement at (1) $ gfortran-11-20210207 -c z1.f90 f951: internal compiler error: Segmentation fault 0xc093ef crash_signal ../../gcc/toplev.c:327 0x6eaa63 gfc_match_varspec(gfc_expr*, int, bool, bool) ../../gcc/fortran/primary.c:2411 0x6ec2e1 gfc_match_rvalue(gfc_expr**) ../../gcc/fortran/primary.c:3849 0x6c0c4e match_primary ../../gcc/fortran/matchexp.c:157 0x6c0c4e match_level_1 ../../gcc/fortran/matchexp.c:211 0x6c0c4e match_mult_operand ../../gcc/fortran/matchexp.c:267 0x6c0e98 match_add_operand ../../gcc/fortran/matchexp.c:356 0x6c10ec match_level_2 ../../gcc/fortran/matchexp.c:480 0x6c1242 match_level_3 ../../gcc/fortran/matchexp.c:551 0x6c1334 match_level_4 ../../gcc/fortran/matchexp.c:599 0x6c1334 match_and_operand ../../gcc/fortran/matchexp.c:693 0x6c1522 match_or_operand ../../gcc/fortran/matchexp.c:722 0x6c15f2 match_equiv_operand ../../gcc/fortran/matchexp.c:765 0x6c16c4 match_level_5 ../../gcc/fortran/matchexp.c:811 0x6c0aa1 gfc_match_expr(gfc_expr**) ../../gcc/fortran/matchexp.c:870 0x6a8a69 match_io_element ../../gcc/fortran/io.c:3661 0x6ab345 match_io_list ../../gcc/fortran/io.c:3709 0x6ab744 match_io ../../gcc/fortran/io.c:4387 0x6af1ca gfc_match_print() ../../gcc/fortran/io.c:4443 0x6db9c1 match_word ../../gcc/fortran/parse.c:65
[Bug rtl-optimization/98986] Try matching both orders of commutative RTX operations when there is no canonical order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98986 --- Comment #6 from Segher Boessenkool --- (In reply to rguent...@suse.de from comment #4) > So this is where the "autogenerated" part comes in. We should have > an idea what might be useful and what isn't even worth trying by > looking at the machine description (which might require exposing > costs in such form for this case of constants). > > For commutative operands maybe recog itself can be relaxed and > accept the insn with the "wrong" commutation (or fix it up > itself) for example. Or maybe genrecog can magically emit > commutated variants (like genmatch does for :c annotated > expression branches). We could probably derive what things in an RTL expression are commutative (even if there are many quantities in play), but only allowing the canonical forms in that is a daunting task. Something like :c could help; we already have % in RTL, but we need more general than that (examples: a+b+c and a*b+c*d should both be handled some way, since such cases (structure, not necessarily those exact ops) happen a lot in practice.
[Bug fortran/99061] New: [10/11 Regression] ICE in gfc_conv_intrinsic_atan2d, at fortran/trans-intrinsic.c:4728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99061 Bug ID: 99061 Summary: [10/11 Regression] ICE in gfc_conv_intrinsic_atan2d, at fortran/trans-intrinsic.c:4728 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20200308 and 20200412 : $ cat z1.f90 program p real(16) :: a = 1.0_16 z = atan2d(a, a) end $ gfortran-10-20200308 -c z1.f90 $ $ gfortran-11-20210207 -c z1.f90 z1.f90:3:19: 3 |z = atan2d(a, a) | 1 internal compiler error: Segmentation fault 0xc093ef crash_signal ../../gcc/toplev.c:327 0xe8528e build_call_expr_loc_array(unsigned int, tree_node*, int, tree_node**) ../../gcc/tree.c:11558 0xe8536f build_call_expr_loc(unsigned int, tree_node*, int, ...) ../../gcc/tree.c:11591 0x792bc9 gfc_conv_intrinsic_atan2d ../../gcc/fortran/trans-intrinsic.c:4728 0x792bc9 gfc_conv_intrinsic_function(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-intrinsic.c:10296 0x767aaa gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:8878 0x76a973 gfc_conv_expr_val(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:8931 0x77bbbc gfc_conv_intrinsic_function_args ../../gcc/fortran/trans-intrinsic.c:235 0x77c026 gfc_conv_intrinsic_conversion ../../gcc/fortran/trans-intrinsic.c:293 0x7930a5 gfc_conv_intrinsic_function(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-intrinsic.c:10338 0x767aaa gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:8878 0x777601 gfc_trans_assignment_1 ../../gcc/fortran/trans-expr.c:11167 0x739b67 trans_code ../../gcc/fortran/trans.c:1922 0x7602d4 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6880 0x6e6c26 translate_all_program_units ../../gcc/fortran/parse.c:6351 0x6e6c26 gfc_parse_file() ../../gcc/fortran/parse.c:6620 0x732e7f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug c++/99062] New: [10/11 Regression] ICE in tree_to_uhwi, at tree.h:4579
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99062
Bug ID: 99062
Summary: [10/11 Regression] ICE in tree_to_uhwi, at tree.h:4579
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20190512 and 20190519 :
$ cat z1.cc
enum { a = 1 << 31 };
void *f () __attribute__ ((assume_aligned (a, 4)));
$ g++-11-20210207 -c z1.cc
z1.cc:2:50: internal compiler error: in tree_to_uhwi, at tree.h:4579
2 | void *f () __attribute__ ((assume_aligned (a, 4)));
| ^
0x8835a6 tree_to_uhwi(tree_node const*)
../../gcc/tree.h:4579
0x8835a6 handle_assume_aligned_attribute
../../gcc/c-family/c-attribs.c:3565
0x823311 decl_attributes(tree_node**, tree_node*, int, tree_node*)
../../gcc/attribs.c:724
0x6e6fc7 cplus_decl_attributes(tree_node**, tree_node*, int)
../../gcc/cp/decl2.c:1596
0x6272a2 grokfndecl
../../gcc/cp/decl.c:9983
0x6d5261 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
../../gcc/cp/decl.c:13818
0x6da5f8 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc/cp/decl.c:5333
0x79bffb cp_parser_init_declarator
../../gcc/cp/parser.c:21660
0x77cf3a cp_parser_simple_declaration
../../gcc/cp/parser.c:14381
0x7a0ea5 cp_parser_declaration
../../gcc/cp/parser.c:14078
0x7a03db cp_parser_translation_unit
../../gcc/cp/parser.c:4936
0x7a03db c_parse_file()
../../gcc/cp/parser.c:45179
0x86d982 c_common_parse_file()
../../gcc/c-family/c-opts.c:1218
[Bug c++/99063] New: [9/10/11 Regression] ICE in prep_operand, at cp/call.c:5842
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99063
Bug ID: 99063
Summary: [9/10/11 Regression] ICE in prep_operand, at
cp/call.c:5842
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started with r8 (before 20180525) :
$ cat z1.cc
template
void f (a... n)
{
do; while (--n); {}
}
void g ()
{
f(3);
}
$ cat z2.cc
template
void f (a... n)
{
do; while (n--); {}
}
void g ()
{
f(1,2);
}
$ g++-11-20210207 -c z1.cc
z1.cc: In instantiation of 'void f(a ...) [with a = {int}]':
z1.cc:8:6: required from here
z1.cc:4:14: internal compiler error: Segmentation fault
4 | do; while (--n); {}
| ^~~
0xcd922f crash_signal
../../gcc/toplev.c:327
0x66567d prep_operand
../../gcc/cp/call.c:5842
0x677955 build_new_op_1
../../gcc/cp/call.c:6224
0x6786c0 build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node**, int)
../../gcc/cp/call.c:6676
0x80d982 build_x_unary_op(unsigned int, tree_code, cp_expr, int)
../../gcc/cp/typeck.c:6136
0x7b5e11 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:19737
0x7c6a67 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:19084
0x7c65f8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18411
0x7c5c17 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18475
0x7ba4f3 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:25835
0x7ba4f3 instantiate_body
../../gcc/cp/pt.c:25835
0x7bb580 instantiate_decl(tree_node*, bool, bool)
../../gcc/cp/pt.c:26124
0x7d5bab instantiate_pending_templates(int)
../../gcc/cp/pt.c:26203
0x6ecab2 c_parse_final_cleanups()
../../gcc/cp/decl2.c:4965
[Bug c/99055] memory leak in warn_parm_array_mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99055 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #1 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565139.html
[Bug driver/87758] --print-file-name= ignores -L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87758 npl at chello dot at changed: What|Removed |Added CC||npl at chello dot at --- Comment #4 from npl at chello dot at --- Is it really an excuse that it behaved like that forever? Given that -march and -sysroot (and spec files AFAIR) already affect the search paths, its not reasonable to expect -L wont work. I know that the linker is separate, but just adding the searchpath should be easy? If there is a new flag, please show in the returncode whether the library was found or not. If you want to inquire the linker, then maybe some "link-only" mode would be better, just invoking the linker with the usual flags and passing though additional commands.
[Bug analyzer/99064] New: [11 regression] ICE analyzer::print_mem_ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99064
Bug ID: 99064
Summary: [11 regression] ICE analyzer::print_mem_ref
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dimhen at gmail dot com
Target Milestone: ---
gcc version 11.0.0 20210104 (experimental) [master revision
7f2b7317566:9da1da01aec:39bd65faee3bafe2dc067e5fedb5079896551a8a] (GCC)
r11-6442 PASS
gcc version 11.0.0 20210108 (experimental) [master revision
bdcde150450:e18dcf9fcae:b407f233d7c18534fbfe8f74af7f0232498fb0c4] (GCC)
r11-6550 FAIL
gcc version 11.0.0 20210210 (experimental) [master revision
bd0e37f68a3:deed5164277:72932511053596091ad291539022b51d9f2ba418] (GCC)
r11-7168 FAIL
$ cat x.ii
template struct iterator_traits;
template struct iterator_traits<_Tp *> {
typedef _Tp &reference;
};
template struct __normal_iterator {
_Iterator _M_current;
__normal_iterator(_Iterator &__i) : _M_current(__i) {}
typename iterator_traits<_Iterator>::reference operator*() {
return *_M_current;
}
};
template struct allocator;
template struct allocator_traits;
template struct allocator_traits> {
using pointer = _Tp *;
};
struct TPkcs11Token;
struct __alloc_traits : allocator_traits> {};
struct _Vector_base {
typedef __alloc_traits::pointer pointer;
struct {
pointer _M_start;
} _M_impl;
};
struct : _Vector_base {
__normal_iterator begin() { return _M_impl._M_start; }
} list_tokens_token_list;
struct TPkcs11Token {
int *add_info;
};
void list_tokens() {
for (__normal_iterator base = list_tokens_token_list.begin();;) {
int *add_info = new int;
(*base).add_info = add_info;
}
}
// cvise'd from private codebase
$ gcc_current/bin/g++ -fpreprocessed -O2 -fanalyzer -c x.ii
during IPA pass: analyzer
x.ii:34:22: internal compiler error: Segmentation fault
34 | (*base).add_info = add_info;
| ~^~
0x12baa3f crash_signal
/home/dimhen/src/gcc_current/gcc/toplev.c:327
0xd7f150 print_mem_ref
/home/dimhen/src/gcc_current/gcc/c-family/c-pretty-print.c:2006
0xb7b035 dump_expr
/home/dimhen/src/gcc_current/gcc/cp/error.c:2367
0xb80640 expr_to_string(tree_node*)
/home/dimhen/src/gcc_current/gcc/cp/error.c:3188
0xb80d7c cp_printer
/home/dimhen/src/gcc_current/gcc/cp/error.c:4356
0x1f28c86 pp_format(pretty_printer*, text_info*)
/home/dimhen/src/gcc_current/gcc/pretty-print.c:1475
0x16533cc ana::evdesc::event_desc::formatted_print(char const*, ...) const
/home/dimhen/src/gcc_current/gcc/analyzer/pending-diagnostic.cc:64
0x1eb67a6 ana::warning_event::get_desc(bool) const
/home/dimhen/src/gcc_current/gcc/analyzer/checker-path.cc:885
0x1eb60f2 ana::checker_event::prepare_for_emission(ana::checker_path*,
ana::pending_diagnostic*, diagnostic_event_id_t)
/home/dimhen/src/gcc_current/gcc/analyzer/checker-path.cc:149
0x1ec64f3 ana::checker_path::prepare_for_emission(ana::pending_diagnostic*)
/home/dimhen/src/gcc_current/gcc/analyzer/checker-path.h:559
0x1ec64f3 ana::diagnostic_manager::emit_saved_diagnostic(ana::exploded_graph
const&, ana::saved_diagnostic const&, ana::exploded_path const&, gimple const*,
int)
/home/dimhen/src/gcc_current/gcc/analyzer/diagnostic-manager.cc:668
0x1ec8a80 ana::dedupe_winners::emit_best(ana::diagnostic_manager*,
ana::exploded_graph const&)
/home/dimhen/src/gcc_current/gcc/analyzer/diagnostic-manager.cc:569
0x1ec68c8 ana::diagnostic_manager::emit_saved_diagnostics(ana::exploded_graph
const&)
/home/dimhen/src/gcc_current/gcc/analyzer/diagnostic-manager.cc:622
0x1649d32 ana::impl_run_checkers(ana::logger*)
/home/dimhen/src/gcc_current/gcc/analyzer/engine.cc:4744
0x164aafe ana::run_checkers()
/home/dimhen/src/gcc_current/gcc/analyzer/engine.cc:4801
0x163d568 execute
/home/dimhen/src/gcc_current/gcc/analyzer/analyzer-pass.cc:87
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ gcc_current/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/home/dimhen/arch-gcc/gcc_current/bin/g++
COLLECT_LTO_WRAPPER=/home/dimhen/arch-gcc/gcc_current/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
Target: x86_64-pc-linux-gnu
Configured with: /home/dimhen/src/gcc_current/configure
--prefix=/home/dimhen/arch-gcc/gcc_current
--enable-checking=yes,df,fold,rtl,extra --enable-languages=c,c++,lto
--disable-multilib --enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl
--enable-offl
