[Bug ipa/92538] Proposal for IPA init() constant propagation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92538 Richard Biener changed: What|Removed |Added Keywords||missed-optimization --- Comment #2 from Richard Biener --- Note that the mailing list is a better place to post patches and seek feedback.
[Bug c++/92542] [10 Regression] ICE with class template argument deduction following typo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92542 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0
[Bug c++/92539] [8/9/10 Regression] -Warray-bounds false positive (loop unroll?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92539 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.4
[Bug bootstrap/92540] [10 regression] r278218 breaks bootstrap on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92540 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0
[Bug libstdc++/92546] [10 Regression] Large increase in preprocessed file sizes in C++2a mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92546 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0
[Bug bootstrap/92540] [10 regression] r278218 breaks bootstrap on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92540 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-11-18 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/92549] Use x86 xchg instruction more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92549 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target||x86_64-*-*, i?86-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-18 Component|rtl-optimization|target Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Since there's no way encode this in RTL this must be done in some peephole2? IIRC (parallel (set (reg:SI 1) (reg:SI 2)) (set (reg:SI 2) (reg:SI 1))) doesn't work like PHI nodes (all "reads" happen first, then the "writes"), even though it would be nice to eventually represent it that way?
[Bug target/92549] Use x86 xchg instruction more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92549 Richard Biener changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #2 from Richard Biener --- But it looks like x86 has exactly patterns like this - but in this case I guess combine won't ever try this because hardregs are invovled (not sure if it ever tries to "simplify" the three-set into the parallel two-set variant)
[Bug c++/92552] [10 Regression] internal compiler error: in lazily_declare_fn, at cp/method.c:3045 with -fconcepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92552 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0
[Bug ipa/92550] [10 Regression] FAIL: gcc.dg/ipa/ipa-sra-8.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92550 Richard Biener changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |10.0 Summary|FAIL: |[10 Regression] FAIL: |gcc.dg/ipa/ipa-sra-8.c |gcc.dg/ipa/ipa-sra-8.c |execution test |execution test --- Comment #1 from Richard Biener --- I suppose all these bugs are regressions (new FAILs)? If so can you please mark them so from the start? If they are not new testcases and GCC 9 works can you also set a known-to-work?
[Bug tree-optimization/92554] [10 Regression] ICE in vect_create_epilog_for_reduction, at tree-vect-loop.c:4325
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92554 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-11-18 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |10.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Mine.
[Bug tree-optimization/92555] [10 Regression] ICE in exact_div, at poly-int.h:2162
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92555 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org Target Milestone|--- |10.0
[Bug ipa/92528] [10 Regression] ICE in ipa_get_parm_lattices since r278219
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92528 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Richard Biener --- The testcase wasn't added, still fixed.
[Bug tree-optimization/71761] missing tailcall optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71761
Konstantin Kharlamov changed:
What|Removed |Added
CC||Hi-Angel at yandex dot ru
--- Comment #4 from Konstantin Kharlamov ---
(In reply to Marc Glisse from comment #3)
> For clang, this seems based on size: up to size 16 they get jmp, starting
> from 17 they get a call.
>
> For gcc, we give up on anything more complicated than a "register":
>
> /* If the LHS of our call is not just a simple register, we can't
> transform this into a tail or sibling call. This situation happens,
> in (e.g.) "*p = foo()" where foo returns a struct. In this case
> we won't have a temporary here, but we need to carry out the side
> effect anyway, so tailcall is impossible.
>
> ??? In some situations (when the struct is returned in memory via
> invisible argument) we could deal with this, e.g. by passing 'p'
> itself as that argument to foo, but it's too early to do this here,
> and expand_call() will not handle it anyway. If it ever can, then
> we need to revisit this here, to allow that situation. */
> if (ass_var && !is_gimple_reg (ass_var))
> return;
>
> The ??? comment is exactly your case.
So this means, if I dump GIMPLE, I should see something wrong, right? When I do
this, given a file named test.cpp and I use `-fdump-tree-all`, the whole GIMPLE
I see in file `test.cpp.231t.optimized` is this:
;; Function g (_Z1gv, funcdef_no=0, decl_uid=2305, cgraph_uid=1,
symbol_order=0)
g ()
{
[local count: 1073741824]:
# DEBUG BEGIN_STMT
= f (); [return slot optimization] [tail call]
return ;
}
;; Function main (main, funcdef_no=1, decl_uid=2341, cgraph_uid=2,
symbol_order=1) (executed once)
main ()
{
struct token D.2343;
[local count: 1073741824]:
# DEBUG BEGIN_STMT
# DEBUG INLINE_ENTRY g
# DEBUG BEGIN_STMT
D.2343 = f (); [return slot optimization]
D.2343 ={v} {CLOBBER};
return 0;
}
What should I see? Should there be a `goto f` inside `g()` function, or what?
[Bug target/92545] avr: support ATmega devices from the 0-series
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92545 --- Comment #4 from Georg-Johann Lay --- Author: gjl Date: Mon Nov 18 08:19:08 2019 New Revision: 278389 URL: https://gcc.gnu.org/viewcvs?rev=278389&root=gcc&view=rev Log: PR target/92545 * config/avr/gen-avr-mmcu-specs.c (print_mcu) [link_pm_base_address]: Symbol name is __RODATA_PM_OFFSET__. Modified: trunk/gcc/config/avr/gen-avr-mmcu-specs.c
[Bug libgomp/81886] Means to determine at runtime foffload targets specified at compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81886 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org Blocks||67300 --- Comment #7 from Tobias Burnus --- For reference, the OG9 branch uses the following commit. commit 789c1d022a871eb06ab08bbb63dcb89006361d93 Author: Julian Brown Date: Thu Feb 28 08:53:54 2019 -0800 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67300 [Bug 67300] -foffload* undocumented
[Bug tree-optimization/71761] missing tailcall optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71761
--- Comment #5 from Marc Glisse ---
The case "struct token { int i; };" was fixed in gcc-7.
>= f (); [return slot optimization] [tail call]
That's all you should see at this point, it is later that it gives up.
[Bug c++/84965] ICE: unexpected expression '__alignof__ (({...}))' of kind alignof_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84965 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška --- Yes, fixed on trunk with r269923.
[Bug ipa/92508] [10 Regression] ICE in do_estimate_edge_time, at ipa-inline-analysis.c:223 since r278159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92508 --- Comment #9 from Martin Liška --- I would like to push this issue as it breaks current lto-bootstrap-lean and I can't do periodic testing in openSUSE..
[Bug inline-asm/84966] ICE verify_gimple failed (verify_gimple_in_cfg())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84966 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška --- Yes, it's fixed since r258741.
[Bug c++/84974] [8 Regression] ICE: Segmentation fault (ovl_first()/location_of())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84974 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Martin Liška --- Yes, fixed on trunk with r261802.
[Bug tree-optimization/92555] [10 Regression] ICE in exact_div, at poly-int.h:2162
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92555 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-11-18 CC||marxin at gcc dot gnu.org Known to work||9.2.0 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||10.0 --- Comment #1 from Martin Liška --- Confirmed, started with r275972.
[Bug tree-optimization/92557] New: [10 Regression] ICE in omp_clause_aligned_alignment, at omp-low.c:4090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92557
Bug ID: 92557
Summary: [10 Regression] ICE in omp_clause_aligned_alignment,
at omp-low.c:4090
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: powerpc-*-linux-gnu
gcc-10.0.0-alpha20191117 snapshot (r278376) ICEs when compiling the following
testcase reduced from gcc/testsuite/c-c++-common/gomp/simd3.c w/ -maltivec
-fopenmp:
void
g5 (void)
{
int fo;
double *aa;
#pragma omp simd aligned (aa)
for (fo = 0; fo < 1; ++fo)
aa = (void *) 0;
}
% powerpc-e300c3-linux-gnu-gcc-10.0.0-alpha20191117 -maltivec -fopenmp -c
w40ahmzx.c
during GIMPLE pass: omplower
w40ahmzx.c: In function 'g5':
w40ahmzx.c:7:9: internal compiler error: in omp_clause_aligned_alignment, at
omp-low.c:4090
7 | #pragma omp simd aligned (aa)
| ^~~
0x646a3b omp_clause_aligned_alignment
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191117/work/gcc-10-20191117/gcc/omp-low.c:4090
0x646a3b omp_clause_aligned_alignment
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191117/work/gcc-10-20191117/gcc/omp-low.c:4059
0xcc83f8 lower_rec_input_clauses
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191117/work/gcc-10-20191117/gcc/omp-low.c:4533
0xccfd8f lower_omp_for
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191117/work/gcc-10-20191117/gcc/omp-low.c:10539
0xcbd4ab lower_omp_1
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191117/work/gcc-10-20191117/gcc/omp-low.c:12797
0xcbd4ab lower_omp
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191117/work/gcc-10-20191117/gcc/omp-low.c:12989
0xcbd632 lower_omp_1
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191117/work/gcc-10-20191117/gcc/omp-low.c:12781
0xcbd632 lower_omp
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191117/work/gcc-10-20191117/gcc/omp-low.c:12989
0xcc31f9 execute_lower_omp
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191117/work/gcc-10-20191117/gcc/omp-low.c:13031
0xcc31f9 execute
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191117/work/gcc-10-20191117/gcc/omp-low.c:13079
[Bug tree-optimization/92537] [10 Regression] ICE in vect_slp_analyze_node_operations, at tree-vect-slp.c:2775
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92537 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-11-18 CC||marxin at gcc dot gnu.org Known to work||9.2.0 Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Summary|[10 Regression] internal|[10 Regression] ICE in |compiler error: in |vect_slp_analyze_node_opera |vect_slp_analyze_node_opera |tions, at |tions, at |tree-vect-slp.c:2775 |tree-vect-slp.c:2775| Ever confirmed|0 |1 Known to fail||10.0 --- Comment #2 from Martin Liška --- Confirmed, started with r278246.
[Bug tree-optimization/92537] [10 Regression] ICE in vect_slp_analyze_node_operations, at tree-vect-slp.c:2775
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92537 --- Comment #3 from Martin Liška --- Created attachment 47288 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47288&action=edit Reduced test-case
[Bug middle-end/71509] Bitfield causes load hit store with larger store than load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71509 --- Comment #10 from Xiong Hu XS Luo --- (In reply to Andrew Pinski from comment #9) > (In reply to rguent...@suse.de from comment #8) > > On Fri, 15 Mar 2019, luoxhu at cn dot ibm.com wrote: > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71509 > > > > > > Xiong Hu XS Luo changed: > > > > > >What|Removed |Added > > > > > > CC||guojiufu at gcc dot > > > gnu.org, > > >||rguenth at gcc dot > > > gnu.org > > > > > > --- Comment #7 from Xiong Hu XS Luo --- > > > Hi Richard, trying to figure out the issue recently, but get some > > > questions > > > need your help. How is the status of the "proposed simple lowering of > > > bitfield > > > accesses on GIMPLE", please? > > > > There are finished patches in a few variants but all of them show issues > > in the testsuite, mostly around missed optimizations IIRC. It has been > > quite some time since I last looked at this but IIRC Andrew Pinski said > > he's got sth for GCC 10 so you might want to ask him. > > Yes I do, I am planing on submitting the new pass once GCC 10 has opened up. Hi Pinski, is your patch upstreamed to GCC 10 please? Thanks.
[Bug tree-optimization/92558] New: [10 Regression] Miscompare of 554.roms_r with -Ofast -march=znver2 -flto since r278289
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92558 Bug ID: 92558 Summary: [10 Regression] Miscompare of 554.roms_r with -Ofast -march=znver2 -flto since r278289 Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Blocks: 26163 Target Milestone: --- I see the following miscompare with test size: Error with '/home/marxin/Programming/cpu2017/bin/specinvoke -d /home/marxin/Programming/cpu2017/benchspec/CPU/554.roms_r/run/run_peak_test_gcc7-m64. -f compare.cmd -E -e compare.err -o compare.stdout'; no non-empty output files exist Command returned exit code 1 *** Miscompare of ocean_benchmark0.log; for details see /home/marxin/Programming/cpu2017/benchspec/CPU/554.roms_r/run/run_peak_test_gcc7-m64./ocean_benchmark0.log.mis Error: 1x554.roms_r Producing Raw Reports label: gcc7-m64 workload: test metric: SPECrate2017_fp_peak format: raw -> /home/marxin/Programming/cpu2017/result/CPU2017.023.fprate.test.rsf I'm going to isolate that more.. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug tree-optimization/92558] [10 Regression] Miscompare of 554.roms_r with -Ofast -march=znver2 -flto since r278289
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92558 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-18 Known to work||9.2.0 Target Milestone|--- |10.0 Ever confirmed|0 |1 Known to fail||10.0
[Bug ipa/92508] [10 Regression] ICE in do_estimate_edge_time, at ipa-inline-analysis.c:223 since r278159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92508 --- Comment #10 from Jan Hubicka --- > I would like to push this issue as it breaks current lto-bootstrap-lean and I > can't do periodic testing in openSUSE.. I tought this one is fixed by r278222 which eliminated the divergence in roudoff errors? Honza > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You are the assignee for the bug.
[Bug target/92462] [arm32] -ftree-pre makes a variable to be wrongly hoisted out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462 --- Comment #21 from Richard Biener --- Author: rguenth Date: Mon Nov 18 09:44:52 2019 New Revision: 278391 URL: https://gcc.gnu.org/viewcvs?rev=278391&root=gcc&view=rev Log: 2019-11-18 Richard Biener PR rtl-optimization/92462 * alias.c (find_base_term): Restrict the look through ANDs. (find_base_value): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/alias.c
[Bug ipa/92553] OpenMP offload static linking error, ICE in inline_read_section, at ipa-fnsummary.c:3332
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92553 --- Comment #1 from Jakub Jelinek --- Might be a dup of PR92357.
[Bug target/92462] [arm32] -ftree-pre makes a variable to be wrongly hoisted out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Known to work||10.0 Depends on||49330 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Known to fail|10.0|9.2.0 --- Comment #22 from Richard Biener --- Fixed on trunk. Can arm people verify? I checked the DSE dump only. Bonus if you manage to create a testcase for the testsuite failing before, passing now. The patch is simple enough to backport if it works. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330 [Bug 49330] Integer arithmetic on addresses optimised with pointer arithmetic rules
[Bug tree-optimization/92558] [10 Regression] Miscompare of 554.roms_r with -Ofast -march=znver2 -flto since r278289
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92558 Martin Liška changed: What|Removed |Added Keywords|needs-reduction | --- Comment #1 from Martin Liška --- So one doesn't need -flto, the problematic file is set_weights.fppized.f90. The difference can be seen with -fdbg-cnt=vect_slp:0,vect_loop:2, -fdbg-cnt=vect_slp:0,vect_loop:1 is fine. The problematic loop comes from: set_weights.fppized.f90:1339:0: note: LOOP VECTORIZED
[Bug tree-optimization/92557] [10 Regression] ICE in omp_clause_aligned_alignment, at omp-low.c:4090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92557 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0
[Bug tree-optimization/92558] [10 Regression] Miscompare of 554.roms_r with -Ofast -march=znver2 -flto since r278289
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92558 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Will look.
[Bug tree-optimization/92558] [10 Regression] Miscompare of 554.roms_r with -Ofast -march=znver2 -flto since r278289
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92558 --- Comment #3 from Martin Liška --- (In reply to Richard Biener from comment #2) > Will look. Thanks, there's a code snippet which is different before and after the revision. Hopefully, it can be used for a reproducer creation: $ cat set.f90 USE mod_scalars real(r16) wsum, cff DO i=1,nfast0 wsum=wsum+weight(1,i,ng) cff=cff+weight(2,i,ng) END DO DO i=1,nfast0 weight=wsum*cff END DO END
[Bug tree-optimization/92558] [10 Regression] Miscompare of 554.roms_r with -Ofast -march=znver2 -flto since r278289
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92558
--- Comment #4 from rguenther at suse dot de ---
On Mon, 18 Nov 2019, marxin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92558
>
> --- Comment #3 from Martin Liška ---
> (In reply to Richard Biener from comment #2)
> > Will look.
>
> Thanks, there's a code snippet which is different before and after the
> revision. Hopefully, it can be used for a reproducer creation:
>
> $ cat set.f90
> USE mod_scalars
> real(r16) wsum, cff
> DO i=1,nfast0
> wsum=wsum+weight(1,i,ng)
> cff=cff+weight(2,i,ng)
> END DO
> DO i=1,nfast0
> weight=wsum*cff
> END DO
> END
So this seems equivalent to
integer, parameter :: r16 = selected_real_kind(12,300) !64-bit
integer, parameter :: r8 = selected_real_kind(12,300) !64-bit
integer, parameter :: Ngrids = 1
real(r8), dimension(2,0:256,Ngrids) :: weight
real(r16) wsum, cff
DO i=1,nfast0
wsum=wsum+weight(1,i,ng)
cff=cff+weight(2,i,ng)
END DO
DO i=1,nfast0
weight=wsum*cff
END DO
END
which is not vectorized. With larger Ngrids it is (I checked my
old compiled mod_param.fppized.f90 for Ngrids), and the difference
is that we now do
# vect_wsum_18.25_129 = PHI
_130 = BIT_FIELD_REF ;
_131 = BIT_FIELD_REF ;
_132 = _130 + _131;
_133 = BIT_FIELD_REF ;
_134 = BIT_FIELD_REF ;
so reduce { wsum, cff, wsum, cff } in vector form first
but we somehow end up not using that for the scalar extracts.
Will fix.
[Bug c++/84651] internal compiler error: in pop_local_binding, at cp/name-lookup.c:2054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84651 Vegard Nossum changed: What|Removed |Added CC||vegard.nossum at oracle dot com --- Comment #3 from Vegard Nossum --- This bug seems to have been fixed in 9.x, 8.x, and 7.x, but is broken again with g++ (Compiler-Explorer-Build) 10.0.0 20191117 (experimental)
[Bug target/92462] [arm32] -ftree-pre makes a variable to be wrongly hoisted out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462 --- Comment #23 from Wilco --- (In reply to Richard Biener from comment #22) > Fixed on trunk. Can arm people verify? I checked the DSE dump only. Bonus > if you manage to create a testcase for the testsuite failing before, passing > now. > > The patch is simple enough to backport if it works. I will have a look. But only checking the low bit is still way too dangerous. Aliasing checks should be conservative and 100% accurate, not use random heuristics which hope for the best. So if we want to keep the AND code then it needs to look for a mask with all top bits set as the absolute minimum.
[Bug target/92462] [arm32] -ftree-pre makes a variable to be wrongly hoisted out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462 --- Comment #24 from rguenther at suse dot de --- On Mon, 18 Nov 2019, wilco at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462 > > --- Comment #23 from Wilco --- > (In reply to Richard Biener from comment #22) > > Fixed on trunk. Can arm people verify? I checked the DSE dump only. Bonus > > if you manage to create a testcase for the testsuite failing before, passing > > now. > > > > The patch is simple enough to backport if it works. > > I will have a look. But only checking the low bit is still way too dangerous. > Aliasing checks should be conservative and 100% accurate, not use random > heuristics which hope for the best. So if we want to keep the AND code then it > needs to look for a mask with all top bits set as the absolute minimum. Unfortunately removing the AND handling is _not_ conservatve correct in this area^Wmess.
[Bug ada/92489] [9 regression] internal error on Invalid_Value Attribute attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92489 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-18 CC||ebotcazou at gcc dot gnu.org Known to work||10.0, 8.3.0 Target Milestone|--- |9.3 Summary|GNAT Bug for Invalid_Value |[9 regression] internal |Attribute |error on Invalid_Value ||Attribute attribute Ever confirmed|0 |1 Known to fail||9.2.0 --- Comment #2 from Eric Botcazou --- Present on the 9 branch only.
[Bug ada/92489] [9 regression] internal error on Invalid_Value Attribute attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92489 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #3 from Eric Botcazou --- Investigating.
[Bug ipa/92529] [10 Regression] Wrong code with ICF since r278207
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92529 --- Comment #1 from Martin Liška --- Author: marxin Date: Mon Nov 18 11:51:05 2019 New Revision: 278395 URL: https://gcc.gnu.org/viewcvs?rev=278395&root=gcc&view=rev Log: Verify NOP_EXPR LHS type in IPA ICF. 2019-11-18 Martin Liska PR ipa/92529 * ipa-icf-gimple.c (func_checker::compare_gimple_assign): Compare LHS types of NOP_EXPR. 2019-11-18 Martin Liska PR ipa/92529 * gcc.dg/ipa/pr92529.c: New test. Added: trunk/gcc/testsuite/gcc.dg/ipa/pr92529.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-icf-gimple.c trunk/gcc/testsuite/ChangeLog
[Bug ipa/92529] [10 Regression] Wrong code with ICF since r278207
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92529 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Martin Liška --- Fixed on trunk.
[Bug tree-optimization/71761] missing tailcall optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71761 --- Comment #6 from Konstantin Kharlamov --- Thanks, okay, so, for the record: comment #3 seems no longer relevant, since the function `find_tail_calls()`, when analyzing g(), gets executed till its end. No early returns anywhere. Tested with: GCC 10.0.0 20191017, commit "a6d1006b1b2 [ARM,testsuite] Fix typo in arm_arch_v8a_ok effective target."
[Bug target/92518] [10 regression] ppc rounding tests fail after r278207
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92518 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 92529 ***
[Bug ipa/92529] [10 Regression] Wrong code with ICF since r278207
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92529 Martin Liška changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #3 from Martin Liška --- *** Bug 92518 has been marked as a duplicate of this bug. ***
[Bug target/91450] __builtin_mul_overflow(A,B,R) wrong code if product <
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91450 --- Comment #4 from Jakub Jelinek --- Yeah, the comment in expand_mul_overflow is correct: s1 * s2 -> ur t1 = (s1 & s2) < 0 ? (-(U) s1) : ((U) s1) t2 = (s1 & s2) < 0 ? (-(U) s2) : ((U) s2) res = t1 * t2 ovf = (s1 ^ s2) < 0 ? (s1 && s2) : main_ovf (true) but the implementation actually doesn't do s1 && s2 but s1 & s2, in both spots: tem = expand_binop (mode, and_optab, op0, op1, NULL_RTX, false, OPTAB_LIB_WIDEN); do_compare_rtx_and_jump (tem, const0_rtx, EQ, true, mode, NULL_RTX, NULL, done_label, profile_probability::very_likely ()); and /* One argument is negative here, the other positive. This overflows always, unless one of the arguments is 0. But if e.g. s2 is 0, (U) s1 * 0 doesn't overflow, whatever s1 is, thus we can keep do_main code oring in overflow as is. */ do_compare_rtx_and_jump (tem, const0_rtx, EQ, true, mode, NULL_RTX, NULL, do_main_label, profile_probability::very_likely ()); expand_arith_set_overflow (lhs, target); emit_label (do_main_label); goto do_main;
[Bug ipa/92508] [10 Regression] ICE in do_estimate_edge_time, at ipa-inline-analysis.c:223 since r278159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92508 Martin Liška changed: What|Removed |Added Priority|P3 |P1 --- Comment #11 from Martin Liška --- It still fails for me with the current trunk: $ ../configure --prefix=/tmp/gcc/ --disable-multilib --without-isl --disable-libsanitizer --with-build-config=bootstrap-lto-lean $ make profiledbootstrap -j123
[Bug c++/80635] std::optional and bogus -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635 --- Comment #28 from Martin Jambor --- The RFC did not receive any real negative feedback so I proposed to commit an updated patch: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01494.html
[Bug middle-end/48363] Recursion not converted into a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48363 Konstantin Kharlamov changed: What|Removed |Added CC||Hi-Angel at yandex dot ru --- Comment #4 from Konstantin Kharlamov --- I think this is solved. For gcc 9.2.0, when I build the testcase as `gcc test.c -o a -g -O2`, and then look at the assembly with `objdump -d a | vim -`, I see `main` function has just a single `callq`, which is to `printf`. So the whole code was apparently optimized and inlined into main().
[Bug tree-optimization/92558] [10 Regression] Miscompare of 554.roms_r with -Ofast -march=znver2 -flto since r278289
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92558 --- Comment #5 from Richard Biener --- Author: rguenth Date: Mon Nov 18 12:41:11 2019 New Revision: 278400 URL: https://gcc.gnu.org/viewcvs?rev=278400&root=gcc&view=rev Log: 2019-11-18 Richard Biener PR tree-optimization/92558 * tree-vect-loop.c (vect_create_epilog_for_reduction): When reducting the width of a reduction vector def update new_phis. * gcc.dg/vect/pr92558.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/pr92558.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug target/65649] gcc generates overlarge constants for microblaze-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65649 nsz at gcc dot gnu.org changed: What|Removed |Added CC||nsz at gcc dot gnu.org Target Milestone|--- |10.0
[Bug libgcc/91737] On Alpine Linux (libmusl) a statically linked C++ program which throws the first exception in two threads at the same time can busy spin on shutdown after main().
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91737 nsz at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |10.0 --- Comment #6 from nsz at gcc dot gnu.org --- fixed in r278399 for gcc-10
[Bug ipa/92525] [10 Regression] ICE in ipa_icf::sem_function::equals at ipa-icf.c:810 since r278207
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92525 --- Comment #1 from Martin Liška --- Author: marxin Date: Mon Nov 18 13:04:57 2019 New Revision: 278405 URL: https://gcc.gnu.org/viewcvs?rev=278405&root=gcc&view=rev Log: Unset m_checker in sem_function::init. 2019-11-18 Martin Liska PR ipa/92525 * ipa-icf.c (sem_function::init): Unset m_checker at the end of the function. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-icf.c
[Bug ipa/92508] [10 Regression] ICE in do_estimate_edge_time, at ipa-inline-analysis.c:223 since r278159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92508 --- Comment #12 from Jan Hubicka --- > It still fails for me with the current trunk: > > $ ../configure --prefix=/tmp/gcc/ --disable-multilib --without-isl > --disable-libsanitizer --with-build-config=bootstrap-lto-lean > $ make profiledbootstrap -j123 I did profiledbootstrap thru lunch and except that I hit some -Werror issues it passed w/o problems. I will try to replicate it with your flags. You may look how much the values differ if it looks like another roundoff or something else. The test should disable itself for profiled functions since for IPA count we subtract the time spent in inline clones from the main function which is prone to roundoff errors so one can't test time to match precisely. Honza
[Bug c++/92559] New: Returning std∷map breaks tail-recursion optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92559
Bug ID: 92559
Summary: Returning std∷map breaks tail-recursion optimization
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
The following code, exploiting tail-recursion, does not get optimized into a
loop with -O3 option, so it crashes if you try to run it.
#include
using MyMap = std::map;
MyMap foo(MyMap m) {
if (m[0] == 0)
return m;
else {
m[0] -= 1;
return foo(m);
}
}
int main() {
MyMap m = {{0, 99}};
foo(m);
}
While debugging GCC, I found that `find_tail_calls()` function quits at this
code¹:
/* If the statement references memory or volatile operands, fail. */
if (gimple_references_memory_p (stmt)
|| gimple_has_volatile_ops (stmt))
return;
1:
https://github.com/gcc-mirror/gcc/blob/38f05dc5db9241d3de8041a683972f086edce561/gcc/tree-tailcall.c#L464
I haven't found any duplicates of this so far.
[Bug ipa/92508] [10 Regression] ICE in do_estimate_edge_time, at ipa-inline-analysis.c:223 since r278159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92508 --- Comment #13 from Martin Liška --- (In reply to Jan Hubicka from comment #12) > > It still fails for me with the current trunk: > > > > $ ../configure --prefix=/tmp/gcc/ --disable-multilib --without-isl > > --disable-libsanitizer --with-build-config=bootstrap-lto-lean > > $ make profiledbootstrap -j123 > > I did profiledbootstrap thru lunch and except that I hit some -Werror > issues it passed w/o problems. I will try to replicate it with your > flags. You may look how much the values differ if it looks like another > roundoff or something else. Did you use bootstrap-lto-lean (and not bootstrap-lto)? > The test should disable itself for profiled functions since for IPA > count we subtract the time spent in inline clones from the main function > which is prone to roundoff errors so one can't test time to match > precisely. > > Honza
[Bug bootstrap/92540] [10 regression] r278218 breaks bootstrap on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92540
--- Comment #1 from Martin Liška ---
I've reduced the test-case which started to fail with the commit:
$ cat riscv.cc
enum machine_mode {};
enum rtx_code { SUBREG, PLUS };
bool fn1(int);
int fn2(machine_mode);
struct A {
int offset;
};
machine_mode a;
rtx_code b;
bool c, d;
bool fn3(A *p1) {
switch (b) {
case SUBREG:
d = fn2(a);
return d;
case PLUS:
c = fn2(a);
return c && fn1(p1->offset);
}
return true;
}
void fn4() {
A e;
fn3(&e);
}
$ g++ -O2 riscv.cc -Werror=maybe-uninitialized -c
riscv.cc: In function ‘void fn4()’:
riscv.cc:18:20: error: ‘e.A::offset’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
18 | return c && fn1(p1->offset);
| ~~~^~~~
cc1plus: some warnings being treated as errors
Which is a valid warning if I'm correct.
For the bootstrap, I would recommend to set addr to zero. Let me prepare a
patch.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 92558, which changed state. Bug 92558 Summary: [10 Regression] Miscompare of 554.roms_r with -Ofast -march=znver2 -flto since r278289 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92558 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/92558] [10 Regression] Miscompare of 554.roms_r with -Ofast -march=znver2 -flto since r278289
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92558 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Fixed.
[Bug middle-end/91450] __builtin_mul_overflow(A,B,R) wrong code if product <
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91450 Jakub Jelinek changed: What|Removed |Added Component|target |middle-end Target Milestone|--- |8.4
[Bug other/92366] new test case gcc.dg/vect/bb-slp-41.c fails with its introduction in r277784
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92366 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #6 from Rainer Orth --- Created attachment 47289 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47289&action=edit 32-bit sparc-sun-solaris2.11 bb-slp-40.c.162t.slp1 Even after Richard's patch, the bb-slp-40.c failure remains on SPARC (32 and 64-bit): FAIL: gcc.dg/vect/bb-slp-40.c -flto -ffat-lto-objects scan-tree-dump slp1 "vectorizing stmts using SLP" FAIL: gcc.dg/vect/bb-slp-40.c scan-tree-dump slp1 "vectorizing stmts using SLP" Dump attached.
[Bug tree-optimization/92555] [10 Regression] ICE in exact_div, at poly-int.h:2162
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92555 --- Comment #2 from Richard Biener --- t.c:8:9: note: === vect_update_vf_for_slp === t.c:8:9: note: Loop contains only SLP stmts t.c:8:9: note: Updating vectorization factor to 8. that's not true. There is the inner loop induction that is live. t.c:8:9: note: init: phi relevant? x8_15 = PHI t.c:8:9: note: vec_stmt_relevant_p: used out of loop. t.c:8:9: note: vec_stmt_relevant_p: stmt live but not relevant. t.c:8:9: note: mark relevant 1, live 1: x8_15 = PHI ... t.c:8:9: note: worklist: examine stmt: x8_15 = PHI t.c:8:9: note: vect_is_simple_use: operand x8_23 = PHI <0(4), x8_18(10)>, type of def: induction t.c:8:9: note: inner-loop def-stmt defining outer-loop stmt. t.c:8:9: note: mark relevant 2, live 0: x8_23 = PHI <0(4), x8_18(10)> t.c:8:9: note: worklist: examine stmt: x8_23 = PHI <0(4), x8_18(10)> t.c:8:9: note: vect_is_simple_use: operand 0, type of def: constant t.c:8:9: note: vect_is_simple_use: operand x8_23 + 2, type of def: internal t.c:8:9: note: induction value on backedge. I have a fix (I think).
[Bug ipa/92525] [10 Regression] ICE in ipa_icf::sem_function::equals at ipa-icf.c:810 since r278207
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92525 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Martin Liška --- Fixed on trunk.
[Bug middle-end/91450] __builtin_mul_overflow(A,B,R) wrong code if product <
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91450 --- Comment #5 from Jakub Jelinek --- Created attachment 47290 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47290&action=edit gcc10-pr91450.patch Untested fix.
[Bug c++/92560] New: ICE using decltype(x < y) when that operator uses operator<=>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92560
Bug ID: 92560
Summary: ICE using decltype(x < y) when that operator uses
operator<=>
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Target Milestone: ---
#include
struct X
{
friend std::strong_ordering operator<=>(X, X);
} x;
using T = decltype(x < x);
Compiled with -std=gnu++2a:
less-ice.cc:8:24: internal compiler error: in build_over_call, at
cp/call.c:8835
8 | using T = decltype(x < x);
|^
0x5be807 build_over_call
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:8829
0x8672d6 build_new_method_call_1
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:10193
0x8672d6 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:10268
0x867ed9 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:9706
0x861b7a build_temp
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:7044
0x861b7a convert_like_real
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:7584
0x86346b build_over_call
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:8671
0x8692e9 build_new_op_1
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:6224
0x86987f build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node**, int)
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:6490
0x8695e4 build_new_op_1
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:6311
0x86987f build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node**, int)
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:6490
0xa38a66 build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node**, int)
/home/jwakely/src/gcc/gcc/gcc/cp/typeck.c:4221
0x9693ad cp_parser_binary_expression
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:9645
0x96a199 cp_parser_assignment_expression
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:9780
0x96a4bf cp_parser_expression
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:9948
0x98a745 cp_parser_decltype_expr
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:14727
0x98a745 cp_parser_decltype
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:14800
0x987c37 cp_parser_simple_type_specifier
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:17866
0x9761cd cp_parser_type_specifier
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:17642
0x98cc88 cp_parser_type_specifier_seq
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:22189
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/92516] [10 Regression] ICE in vect_schedule_slp_instance, at tree-vect-slp.c:4095 since r278246
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92516 --- Comment #9 from Richard Biener --- Author: rguenth Date: Mon Nov 18 14:07:11 2019 New Revision: 278406 URL: https://gcc.gnu.org/viewcvs?rev=278406&root=gcc&view=rev Log: 2019-11-18 Richard Biener PR tree-optimization/92516 * tree-vect-slp.c (vect_analyze_slp_instance): Add bst_map argument, hoist bst_map creation/destruction to ... (vect_analyze_slp): ... here, forming a true graph with SLP instances being the entries. (vect_detect_hybrid_slp_stmts): Remove wrapper. (vect_detect_hybrid_slp): Use one visited set for all graph entries. (vect_slp_analyze_node_operations): Simplify visited/lvisited to hash-sets of slp_tree. (vect_slp_analyze_operations): Likewise. (vect_bb_slp_scalar_cost): Remove wrapper. (vect_bb_vectorization_profitable_p): Use one visited set for all graph entries. (vect_schedule_slp_instance): Elide bst_map use. (vect_schedule_slp): Likewise. * g++.dg/vect/slp-pr92516.cc: New testcase. 2019-11-18 Richard Biener * tree-vect-slp.c (vect_analyze_slp_instance): When a CTOR was vectorized with just external refs fail. * gcc.dg/vect/vect-ctor-1.c: New testcase. Added: trunk/gcc/testsuite/g++.dg/vect/slp-pr92516.cc trunk/gcc/testsuite/gcc.dg/vect/vect-ctor-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-slp.c
[Bug c++/92551] accepts invalid code in function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92551 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-11-18 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- (In reply to Darrell Wright from comment #0) > I accidently produced this invalid code and it worked as intended until I > tested further. However, the integer_sequence should never have been deduced > https://gcc.godbolt.org/z/hp4crn > > This will return 20, but should be an error Why? It looks deducable to me.
[Bug tree-optimization/92516] [10 Regression] ICE in vect_schedule_slp_instance, at tree-vect-slp.c:4095 since r278246
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92516 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Richard Biener --- Fixed.
[Bug ipa/92561] New: [10 Regression] Regressions starting with r278016
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92561 Bug ID: 92561 Summary: [10 Regression] Regressions starting with r278016 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- Since r278016 I'm seeing on i686-linux (and x86_64-linux with -m32): +FAIL: g++.dg/ipa/pr61654.C -std=gnu++11 (internal compiler error) +FAIL: g++.dg/ipa/pr61654.C -std=gnu++11 (test for excess errors) +FAIL: g++.dg/ipa/pr61654.C -std=gnu++14 (internal compiler error) +FAIL: g++.dg/ipa/pr61654.C -std=gnu++14 (test for excess errors) +FAIL: g++.dg/ipa/pr61654.C -std=gnu++17 (internal compiler error) +FAIL: g++.dg/ipa/pr61654.C -std=gnu++17 (test for excess errors) +FAIL: g++.dg/ipa/pr61654.C -std=gnu++2a (internal compiler error) +FAIL: g++.dg/ipa/pr61654.C -std=gnu++2a (test for excess errors) +FAIL: g++.dg/ipa/pr61654.C -std=gnu++98 (internal compiler error) +FAIL: g++.dg/ipa/pr61654.C -std=gnu++98 (test for excess errors) +FAIL: g++.dg/ipa/pr63814.C -std=gnu++11 (internal compiler error) +FAIL: g++.dg/ipa/pr63814.C -std=gnu++11 (test for excess errors) +UNRESOLVED: g++.dg/ipa/pr63814.C -std=gnu++11 compilation failed to produce executable +FAIL: g++.dg/ipa/pr63814.C -std=gnu++14 (internal compiler error) +FAIL: g++.dg/ipa/pr63814.C -std=gnu++14 (test for excess errors) +UNRESOLVED: g++.dg/ipa/pr63814.C -std=gnu++14 compilation failed to produce executable +FAIL: g++.dg/ipa/pr63814.C -std=gnu++17 (internal compiler error) +FAIL: g++.dg/ipa/pr63814.C -std=gnu++17 (test for excess errors) +UNRESOLVED: g++.dg/ipa/pr63814.C -std=gnu++17 compilation failed to produce executable +FAIL: g++.dg/ipa/pr63814.C -std=gnu++2a (internal compiler error) +FAIL: g++.dg/ipa/pr63814.C -std=gnu++2a (test for excess errors) +UNRESOLVED: g++.dg/ipa/pr63814.C -std=gnu++2a compilation failed to produce executable +FAIL: g++.dg/ipa/pr63814.C -std=gnu++98 (internal compiler error) +FAIL: g++.dg/ipa/pr63814.C -std=gnu++98 (test for excess errors) +UNRESOLVED: g++.dg/ipa/pr63814.C -std=gnu++98 compilation failed to produce executable +FAIL: g++.dg/other/pr87916.C -std=gnu++11 (internal compiler error) +FAIL: g++.dg/other/pr87916.C -std=gnu++11 (test for excess errors) +FAIL: g++.dg/other/pr87916.C -std=gnu++14 (internal compiler error) +FAIL: g++.dg/other/pr87916.C -std=gnu++14 (test for excess errors) +FAIL: g++.dg/other/pr87916.C -std=gnu++17 (internal compiler error) +FAIL: g++.dg/other/pr87916.C -std=gnu++17 (test for excess errors) +FAIL: g++.dg/other/pr87916.C -std=gnu++2a (internal compiler error) +FAIL: g++.dg/other/pr87916.C -std=gnu++2a (test for excess errors) +FAIL: g++.dg/other/pr87916.C -std=gnu++98 (internal compiler error) +FAIL: g++.dg/other/pr87916.C -std=gnu++98 (test for excess errors) E.g. the first one shows: FAIL: g++.dg/ipa/pr63814.C -std=gnu++98 (internal compiler error) FAIL: g++.dg/ipa/pr63814.C -std=gnu++98 (test for excess errors) Excess errors: during IPA pass: cp /home/jakub/src/gcc/gcc/testsuite/g++.dg/ipa/pr63814.C:29:1: internal compiler error: Segmentation fault 0x8c688da crash_signal ../../gcc/toplev.c:329 0x85621f7 same_node_or_its_all_contexts_clone_p ../../gcc/ipa-cp.c:3530 0x85621f7 cgraph_edge_brings_value_p ../../gcc/ipa-cp.c:3545 0x9530c4b get_info_about_necessary_edges ../../gcc/ipa-cp.c:3654 0x9530c4b decide_about_value ../../gcc/ipa-cp.c:4801 0x95332dc decide_whether_version_node ../../gcc/ipa-cp.c:4888 0x95332dc ipcp_decision_stage ../../gcc/ipa-cp.c:5051 0x95332dc ipcp_driver ../../gcc/ipa-cp.c:5228 0x95332dc execute ../../gcc/ipa-cp.c:5319
[Bug ipa/92561] [10 Regression] Regressions starting with r278016
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92561 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-18 CC||hubicka at gcc dot gnu.org Target Milestone|--- |10.0 Ever confirmed|0 |1
[Bug libstdc++/92546] [10 Regression] Large increase in preprocessed file sizes in C++2a mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92546 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-18 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- and would also benefit from moving remove and remove_if to : include/std/deque:# include // For remove and remove_if include/std/string:# include // For remove and remove_if include/std/vector:# include // For remove and remove_if
[Bug c++/92552] [10 Regression] internal compiler error: in lazily_declare_fn, at cp/method.c:3045 with -fconcepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92552 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-18 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Started with r274534.
[Bug tree-optimization/92554] [10 Regression] ICE in vect_create_epilog_for_reduction, at tree-vect-loop.c:4325
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92554 --- Comment #2 from Richard Biener --- Testing patch.
[Bug tree-optimization/92557] [10 Regression] ICE in omp_clause_aligned_alignment, at omp-low.c:4090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92557 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-18 CC||jakub at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r278236.
[Bug tree-optimization/92557] [10 Regression] ICE in omp_clause_aligned_alignment, at omp-low.c:4090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92557 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 47291 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47291&action=edit gcc10-pr92557.patch I'd go with this fix. The problem is that with just -maltivec, V2DImode is present, but not supported, so the vector type created for V2DImode actually has TYPE_MODE_RAW V2DImode, but TYPE_MODE TImode.
[Bug tree-optimization/92557] [10 Regression] ICE in omp_clause_aligned_alignment, at omp-low.c:4090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92557 --- Comment #3 from rsandifo at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #2) > Created attachment 47291 [details] > gcc10-pr92557.patch > > I'd go with this fix. > The problem is that with just -maltivec, V2DImode is present, but not > supported, so the vector type created for V2DImode actually has > TYPE_MODE_RAW V2DImode, but TYPE_MODE TImode. But if the target doesn't support V2DImode, then I don't think it should be returning V2DImode from preferred_simd_mode. It's hardly preferred in that case :-)
[Bug tree-optimization/92557] [10 Regression] ICE in omp_clause_aligned_alignment, at omp-low.c:4090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92557 Jakub Jelinek changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- It is certainly weird, sure.
[Bug ipa/92528] [10 Regression] ICE in ipa_get_parm_lattices since r278219
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92528 --- Comment #11 from Martin Jambor --- Author: jamborm Date: Mon Nov 18 15:50:06 2019 New Revision: 278415 URL: https://gcc.gnu.org/viewcvs?rev=278415&root=gcc&view=rev Log: Add testcase for already fixed PR ipa/92528 2019-11-18 Martin Jambor PR ipa/92528 * g++.dg/ipa/pr92528.C: New test. Added: trunk/gcc/testsuite/g++.dg/ipa/pr92528.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/81159] New warning idea: -Wself-move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81159 --- Comment #7 from Marek Polacek --- (In reply to Eric Gallager from comment #6) > (In reply to Marek Polacek from comment #3) > > Ok, this shouldn't be too hard. I guess I could implement it for GCC 10. > > last chance to get it in before stage 1 closes... I was working on C++20 features which are more important. So this will have to wait until the next stage 1.
[Bug c++/91962] [10 Regression] ice in build_target_expr, at cp/tree.c:488
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91962
--- Comment #7 from Marek Polacek ---
Author: mpolacek
Date: Mon Nov 18 16:39:24 2019
New Revision: 278416
URL: https://gcc.gnu.org/viewcvs?rev=278416&root=gcc&view=rev
Log:
PR c++/91962 - ICE with reference binding and qualification conversion.
When fixing c++/91889 (r276251) I was assuming that we couldn't have a ck_qual
under a ck_ref_bind, and I was introducing it in the patch and so this
+ if (next_conversion (convs)->kind == ck_qual)
+ {
+ gcc_assert (same_type_p (TREE_TYPE (expr),
+next_conversion (convs)->type));
+ /* Strip the cast created by the ck_qual; cp_build_addr_expr
+ below expects an lvalue. */
+ STRIP_NOPS (expr);
+ }
in convert_like_real was supposed to handle it. But that assumption was wrong
as this test shows; here we have "(int *)f" where f is of type long int, and
we're converting it to "const int *const &", so we have both ck_ref_bind and
ck_qual. That means that the new STRIP_NOPS strips an expression it shouldn't
have, and that then breaks when creating a TARGET_EXPR. So we want to limit
the stripping to the new case only. This I do by checking need_temporary_p,
which will be 0 in the new case. Yes, we can set need_temporary_p when
binding a reference directly, but then we won't have a qualification
conversion. It is possible to have a bit-field, convert it to a pointer,
and then convert that pointer to a more-qualified pointer, but in that case
we're not dealing with an lvalue, so gl_kind is 0, so we won't enter this
block in reference_binding:
1747 if ((related_p || compatible_p) && gl_kind)
* call.c (convert_like_real) : Check
need_temporary_p.
* g++.dg/cpp0x/ref-bind7.C: New test.
Added:
trunk/gcc/testsuite/g++.dg/cpp0x/ref-bind7.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog
[Bug c++/91962] [10 Regression] ice in build_target_expr, at cp/tree.c:488
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91962 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Marek Polacek --- Fixed.
[Bug ipa/92508] [10 Regression] ICE in do_estimate_edge_time, at ipa-inline-analysis.c:223 since r278159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92508
--- Comment #14 from Jan Hubicka ---
> Did you use bootstrap-lto-lean (and not bootstrap-lto)?
OK, I finally managed to reproduce and debug this.
It is triggered by fact that bootstrap-lean is not training objc and
other frontends which is probably not a good idea (at least from the
objc developer POV).
What happens is that we link trained libbacked with the untrained objc
FE code and ICF then produces alias from objc FE function to trained
funtion and the sanity check mistakely check count of alias instead of
its ultimate target.
I am testing:
Index: ipa-inline-analysis.c
===
--- ipa-inline-analysis.c (revision 278390)
+++ ipa-inline-analysis.c (working copy)
@@ -211,7 +211,7 @@ do_estimate_edge_time (struct cgraph_edg
nonspec_time = e->entry.nonspec_time;
hints = e->entry.hints;
if (flag_checking
- && !edge->callee->count.ipa_p ())
+ && !callee->count.ipa_p ())
{
sreal chk_time, chk_nonspec_time;
int chk_size, chk_min_size;
[Bug c++/92562] New: Allow [[maybe_unused]] in class member declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92562
Bug ID: 92562
Summary: Allow [[maybe_unused]] in class member declaration
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
The following snippet is accepted by clang but reject by gcc (any version I
tested: 8, 9, and trunk):
class A
{
// Maybe unused to silence clang error: private field '_i' is not used
[-Werror,-Wunused-private-field]
int _i [[maybe_unused]];
};
It happens that this [[maybe_unused]] attribute may be needed in some cases to
silence the clang-specific warning -Wunused-private-field, in the strange cases
where you actually want to keep the unused member rather than removing it. An
alternative would be of course to use gcc pragma diagnostics, but still it
would be cool if gcc would accept [[maybe_unused]] on class member
declarations.
Today, gcc issues:
:4:27: error: 'maybe_unused' attribute ignored [-Werror=attributes]
4 | int _i [[maybe_unused]];
| ^
cc1plus: all warnings being treated as errors
Compiler returned: 1
Cheers,
Romain
[Bug tree-optimization/92557] [10 Regression] ICE in omp_clause_aligned_alignment, at omp-low.c:4090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92557 --- Comment #5 from Segher Boessenkool --- We always have many modes we cannot put in registers at all. This is normal. And yeah, what Richard says in c#3. Why do we do that? Is that a target bug?
[Bug target/92549] Use x86 xchg instruction more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92549 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 47292 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47292&action=edit gcc10-pr92549.patch Yeah, there are *swap patterns, but they are unlikely to trigger, because before RA usually there is no swap between pseudos, but simply different pseudos, and only during RA we get to a need of a swap. This patch handles it in peephole2. The big question is if it should be done always (as in the patch), or only at -Os or on selected modern CPUs + maybe generic tuning, where xchg with register operands just uses normal register renaming and is 0.5 or worst case 1 cycles.
[Bug tree-optimization/92557] [10 Regression] ICE in omp_clause_aligned_alignment, at omp-low.c:4090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92557 --- Comment #6 from Jakub Jelinek --- I think it doesn't hurt to punt instead of ICEing in the generic code, but as Richard said, if it is not a target bug, it is at least a very strange choice, how can a mode like V2DImode be preferred simd mode for DImode when it is not supported with -maltivec -mno-vsx? I think it should just return word_mode in that case.
[Bug target/92462] [arm32] -ftree-pre makes a variable to be wrongly hoisted out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
--- Comment #25 from Aleksei Voitylov ---
(In reply to Richard Biener from comment #22)
> Fixed on trunk. Can arm people verify? I checked the DSE dump only. Bonus
> if you manage to create a testcase for the testsuite failing before, passing
> now.
>
> The patch is simple enough to backport if it works.
Unfortunately it still fails for arm32. Here is the relevant piece of rtl dump
for dse1:
**scanning insn=21
mem: (plus:SI (reg/f:SI 125)
(reg/v:SI 118 [ offset ]))
after canon_rtx address: (plus:SI (plus:SI (reg/f:SI 102 sfp)
(reg/v:SI 118 [ offset ]))
(const_int -8 [0xfff8]))
after cselib_expand address: (plus:SI (minus:SI (reg/f:SI 102 sfp)
(reg:SI 116 [ _10 ]))
(const:SI (plus:SI (symbol_ref:SI ("*.LANCHOR0") [flags 0x182])
(const_int -8 [0xfff8]
after canon_rtx address: (plus:SI (minus:SI (reg/f:SI 102 sfp)
(reg:SI 116 [ _10 ]))
(const:SI (plus:SI (symbol_ref:SI ("*.LANCHOR0") [flags 0x182])
(const_int -8 [0xfff8]
varying cselib base=11:2037069969 offset = 0
processing cselib store [0..1)
mems_found = 1, cannot_delete = false
**scanning insn=22
mem: (plus:SI (reg/f:SI 102 sfp)
(const_int -8 [0xfff8]))
after canon_rtx address: (plus:SI (reg/f:SI 102 sfp)
(const_int -8 [0xfff8]))
gid=1 offset=-8
processing const load gid=1[-8..-4)
trying to replace SImode load in insn 22 from SImode store in insn 16
deferring rescan insn with uid = 22.
deferring rescan insn with uid = 90.
-- replaced the loaded MEM with (reg 135)
[Bug target/92549] Use x86 xchg instruction more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92549 --- Comment #4 from Jakub Jelinek --- E.g. Agner Fog has in the tables for Atom mov r,r 1uops, latency 1, rec. throughput 1/2, while for xchg r,r 3uops, latency 6, rec. throughput 6. It doesn't look beneficial speed wise then. Though, even say on Skylake-X the tables say mov r32,r32 is 1uops, latency 0-1, rec. thr. 0.25, while xchg r,r is 3uops, latency 2, rec. thr. 1.
[Bug c++/92563] New: trunk/gcc/cp/error.c:1988: useless parameter ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92563
Bug ID: 92563
Summary: trunk/gcc/cp/error.c:1988: useless parameter ?
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
trunk/gcc/cp/error.c:1988:2: style: Assignment of function parameter has no
effect outside the function. [uselessAssignmentArg]
Source code is
static void
dump_call_expr_args (cxx_pretty_printer *pp, tree t, int flags, bool skipfirst)
{
tree arg;
call_expr_arg_iterator iter;
pp_cxx_left_paren (pp);
FOR_EACH_CALL_EXPR_ARG (arg, iter, t)
{
if (skipfirst)
skipfirst = false;
else
{
dump_expr (pp, arg, flags | TFF_EXPR_IN_PARENS);
if (more_call_expr_args_p (&iter))
pp_separate_with_comma (pp);
}
}
pp_cxx_right_paren (pp);
}
I can't see much point in parameter skipfirst. Suggest remove.
[Bug ipa/92561] [10 Regression] Regressions starting with r278016
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92561 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #1 from Arseny Solokha --- Must be a duplicate of PR92476?
[Bug target/92549] Use x86 xchg instruction more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92549 --- Comment #5 from Jakub Jelinek --- Further info on the topic: https://stackoverflow.com/questions/45766444/why-is-xchg-reg-reg-a-3-micro-op-instruction-on-modern-intel-architectures
[Bug ipa/92561] [10 Regression] Regressions starting with r278016
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92561 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jakub Jelinek --- Dup. *** This bug has been marked as a duplicate of bug 92476 ***
[Bug ipa/92476] [10 regression] SEGV in cgraph_edge_brings_value_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92476 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- *** Bug 92561 has been marked as a duplicate of this bug. ***
[Bug libgcc/92565] New: trunk/libgcc/config/libbid/bid_internal.h: 2 * useless assignments ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92565 Bug ID: 92565 Summary: trunk/libgcc/config/libbid/bid_internal.h: 2 * useless assignments ? Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- trunk/libgcc/config/libbid/bid_internal.h:1543:3: style: Assignment of function parameter has no effect outside the function. [uselessAssignmentArg] Source code is expon = 0; There is no later use of expon, so suggest remove it or use it. trunk/libgcc/config/libbid/bid_internal.h:1679:3: style: Assignment of function parameter has no effect outside the function. [uselessAssignmentArg] Duplicate.
[Bug go/92564] New: libgo regression in runtime test resulting in SIGSEGV on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92564 Bug ID: 92564 Summary: libgo regression in runtime test resulting in SIGSEGV on ppc64le Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: boger at gcc dot gnu.org CC: cmang at google dot com, seurer at us dot ibm.com Target Milestone: --- When running the runtime test on ppc64le from trunk, a SIGSEV results. This happens consistently now, but we have been unable to identify the commit where this was introduced because it was intermittent when it started. On one machine it fails on r276474. The failing output: [signal SIGSEGV: segmentation violation code=0x2 addr=0x7c2d2cb3 pc=0x100af074] runtime stack: runtime.dopanic_m /home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest48232/test/panic.go:1181 runtime.fatalthrow /home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest48232/test/panic.go:1047 runtime.throw /home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest48232/test/panic.go:1018 runtime.sigpanic /home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest48232/test/signal_unix.go:337 runtime.sighandler /home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest48232/test/signal_sighandler.go:100 runtime.sigtrampgo /home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest48232/test/signal_unix.go:314 runtime.sigtramp ../../../src/libgo/runtime/go-signal.c:86 :0 runtime.scanstackblock /home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest48232/test/mgcmark.go:1059 doscanstack1 ../../../src/libgo/runtime/stack.c:91 runtime.doscanstack ../../../src/libgo/runtime/stack.c:38 runtime.scanstack /home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest48232/test/mgcmark.go:653 runtime.scang /home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest48232/test/proc.go:914 runtime.markroot..func1 /home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest48232/test/mgcmark.go:206 runtime.systemstack /home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest48232/test/stubs.go:60 runtime.markroot /home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest48232/test/mgcmark.go:187 runtime.gcDrain /home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest48232/test/mgcmark.go:764 runtime.gcBgMarkWorker..func2 /home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest48232/test/mgc.go:1906 runtime.systemstack..func1 /home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest48232/test/stubs.go:63 runtime_mstart ../../../src/libgo/runtime/proc.c:593 goroutine 102 [GC worker (idle)]: runtime.mcall ../../../src/libgo/runtime/proc.c:343 runtime.systemstack /home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest48232/test/stubs.go:66 runtime.gcBgMarkWorker /home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest48232/test/mgc.go:1893 runtime.kickoff /home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest48232/test/proc.go:1213 created by runtime.gcBgMarkStartWorkers /home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest48232/test/mgc.go:1785 +0xc8 goroutine 1 [chan receive (scan)]: runtime.mcall ../../../src/libgo/runtime/proc.c:343 runtime.gopark /home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest48232/test/proc.go:339 runtime.goparkunlock /home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest48232/test/proc.go:345 runtime.chanrecv /home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest48232/test/chan.go:546 runtime.chanrecv1 /home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest48232/test/chan.go:423 testing.T.Run ../../../src/libgo/go/testing/testing.go:961 testing.runTests..func1 ../../../src/libgo/go/testing/testing.go:1202 testing.tRunner ../../../src/libgo/go/testing/testing.go:909 testing.runTests ../../../src/libgo/go/testing/testing.go:1200 testing.M.Run ../../../src/libgo/go/testing/testing.go:1117 runtime_test.TestMain /home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest48232/test/crash_test.go:28 main.main /home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest48232/test/_testmain.go:515 runtime.main /home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest48232/test/proc.go:235 goroutine 2 [force gc (idle)]: runtime.mcall ../../../src/libgo/runtime/proc.c:343 runtime.gopark /home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest48232/test/proc.go:339 runtime.goparkunlock /home/boger/gccgo.work/trunk/bld/powerpc64le-
[Bug c++/92551] accepts invalid code in function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92551 --- Comment #2 from Darrell Wright --- The Args... is in a non deduced context because it isn't at the end. http://eel.is/c++draft/temp.deduct#type-5.7 With that, I think only trailing packs can be defaulted to empty http://eel.is/c++draft/temp.arg.explicit#4 In the bad code above, the args looks like it is being treated as an empty pack, but I am not sure the standard allows for that.
[Bug c++/92563] trunk/gcc/cp/error.c:1988: useless parameter ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92563 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- It has no effect outside the function, but that's ok here and it's preferable to creating a new local var.
[Bug target/92566] New: rs6000_preferred_simd_mode isn't very good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92566 Bug ID: 92566 Summary: rs6000_preferred_simd_mode isn't very good Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: segher at gcc dot gnu.org Target Milestone: --- As mentioned in PR92557, at least we shouldn't return V2DImode for the vector mode for DImode, if we do not actually support that.
