[Bug target/92051] New: Many aarch64 SVE tests fail with ICE (expected integer_cst, have poly_int_cst in to_wide)

Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sje at gcc dot gnu.org Target Milestone: --- I am seeing several hundred aarch64 sve tests fail with an ICE since Oct 8, 2019. One such failure is gcc.target

[Bug tree-optimization/90836] Missing popcount pattern matching

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90836 --- Comment #4 from Steve Ellcey --- Author: sje Date: Tue Oct 8 21:53:03 2019 New Revision: 276722 URL: https://gcc.gnu.org/viewcvs?rev=276722=gcc=rev Log: 2019-10-08 Dmitrij Pochepko PR tree-optimization/90836 *

[Bug tree-optimization/90836] Missing popcount pattern matching

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90836 --- Comment #3 from Steve Ellcey --- Author: sje Date: Tue Oct 8 21:50:05 2019 New Revision: 276721 URL: https://gcc.gnu.org/viewcvs?rev=276721=gcc=rev Log: 2019-10-08 Dmitrij Pochepko PR tree-optimization/90836 *

[Bug middle-end/91983] New: g++.dg/tree-ssa/pr61034.C regression

Assignee: unassigned at gcc dot gnu.org Reporter: sje at gcc dot gnu.org Target Milestone: --- The g++.dg/tree-ssa/pr61034.C test has been failing since around Sept 15, 2019. Looking at gcc-testresults it looks like is failing on aarch64, x86, power, and probably more. FAIL: g

[Bug target/91982] New: gcc.target/aarch64/sve/clastb_*.c tests failing with segfault

Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sje at gcc dot gnu.org Target Milestone: --- Target: aarch64 A number of gcc.target/aarch64/sve/clastb_* tests (1-8) are failing with segfaults. This seems to have started

[Bug c++/91889] [10 Regression] error: call of overloaded ‘to_value_ptr(B*&)’ is ambiguous

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91889 --- Comment #10 from Steve Ellcey --- (In reply to Marek Polacek from comment #9) > I'll raise it with CWG; suspending until then. Not sure if it matters but there seem to be 8 instances of this problem in Boost (get_color, get_left, get_next,

[Bug c++/91889] New: Boost does not build with top-of-tree GCC

++ Assignee: unassigned at gcc dot gnu.org Reporter: sje at gcc dot gnu.org Target Milestone: --- A recent g++ change broke the boost build. It is dying with many (many) errors like this: ./boost/intrusive/list.hpp:1448:7: required from here ./boost/intrusive/detail

[Bug tree-optimization/91885] New: ICE when compiling SPEC 2017 blender benchmark with -O3 -fprofile-generate

: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sje at gcc dot gnu.org Target Milestone: --- When compiling the SPEC 2017 526.blender_r benchmark for peak, the compilation that tries to generate profile

[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222 --- Comment #17 from Steve Ellcey --- I tested Jason's patch on my Aarch64 box and it fixed the ICE. Any chance we could check that patch in so that we could build SPEC 2017 with -flto? I don't know if we want to allow this mismatch or not but

[Bug bootstrap/91825] Top-of-tree GCC does not bootstrap (uninitialized warning)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91825 --- Comment #4 from Steve Ellcey --- The original bootstrap failure is on aarch64.

[Bug bootstrap/91825] New: Top-of-tree GCC does not bootstrap (uninitialized warning)

Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: sje at gcc dot gnu.org Target Milestone: --- GCC bootstrap currently fails with this error: /home/sellcey/tot/src/gcc/gcc/expmed.c: In function ‘rtx_def* emit_store_flag_1(rtx

[Bug middle-end/91599] New: GCC does not say where warning is happening

Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: sje at gcc dot gnu.org Target Milestone: --- When compiling the following source file, GCC gives a warning. The warning notes that the declaration is on line 2 but it does not say what line the actual write

[Bug c++/89179] compiler error: in ggc_set_mark, at ggc-page.c:1532

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89179 --- Comment #17 from Steve Ellcey --- The bug I was seeing on aarch64 turns out to be PR 91404. It has now been fixed. I don't know if that patch will also fix the original bug seen on Darwin or not.

[Bug c++/89179] compiler error: in ggc_set_mark, at ggc-page.c:1532

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89179 --- Comment #16 from Steve Ellcey --- I built ggc-page.c with GCC_DEBUG_LEVEL 5 and I see: Allocating object, requested size=360, actual=360 at 0x8726c210 on 0x10549200 Freeing object, actual size=360, at 0x8726c210 on 0x10549200 But

[Bug c++/89179] compiler error: in ggc_set_mark, at ggc-page.c:1532

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89179 Steve Ellcey changed: What|Removed |Added CC||sje at gcc dot gnu.org --- Comment #14

[Bug driver/91406] New: gcc -Q -v lies about what flags are enabled

: driver Assignee: unassigned at gcc dot gnu.org Reporter: sje at gcc dot gnu.org Target Milestone: --- If you run 'gcc -Q -v x.c' and look at the 'options enabled:' list, it is not accurate. For example, on aarch64 it will show '-fprefetch-loop-arrays' which

[Bug middle-end/91242] ICE on aarch64 SVE tests - gcc.target/aarch64/sve/clastb_[146].c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91242 --- Comment #7 from Steve Ellcey --- (In reply to Martin Liška from comment #5) > (In reply to Jaydeep Chauhan from comment #4) > > Hello, > > > > With latest trunk issue is not reproducible for all three > >

[Bug fortran/91253] New: gfortran.dg/continuation_6.f fails when using latest glibc

Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: sje at gcc dot gnu.org Target Milestone: --- When testing GCC with the latest GLIBC, specifically one which creates a math-vector-fortran.h header file, the gfortran.dg/continuation_6.f

[Bug tree-optimization/83518] [8/9 Regression] Missing optimization: useless instructions should be dropped

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83518 --- Comment #21 from Steve Ellcey --- (In reply to Richard Biener from comment #20) > (In reply to Steve Ellcey from comment #19) > It should have been fixed by r273732 (checked with a cc1 cross to aarch64, > albeit on a not clean tree...) OK,

[Bug tree-optimization/83518] [8/9 Regression] Missing optimization: useless instructions should be dropped

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83518 Steve Ellcey changed: What|Removed |Added CC||sje at gcc dot gnu.org --- Comment #19

[Bug middle-end/91242] New: ICE on aarch64 SVE tests - gcc.target/aarch64/sve/clastb_[146].c

Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: sje at gcc dot gnu.org Target Milestone: --- I get ICE on these GCC tests: FAIL: gcc.target/aarch64/sve/clastb_1.c -march=armv8.2-a+sve (internal compiler error) FAIL: gcc.target

[Bug bootstrap/91176] [10 regression] AArch64 bootstrap fails since r273479

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91176 Steve Ellcey changed: What|Removed |Added CC||sje at gcc dot gnu.org --- Comment #8

[Bug bootstrap/90873] [10 regression] -Wmaybe-uninitialized warning in gcc/tree-ssa-forwprop.c breaks 32-bit bootstrap

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90873 Steve Ellcey changed: What|Removed |Added CC||sje at gcc dot gnu.org --- Comment #5

[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763 --- Comment #51 from Steve Ellcey --- Author: sje Date: Thu Apr 11 18:03:49 2019 New Revision: 270289 URL: https://gcc.gnu.org/viewcvs?rev=270289=gcc=rev Log: 2018-04-11 Steve Ellcey PR rtl-optimization/87763 *

[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763 --- Comment #50 from Steve Ellcey --- Author: sje Date: Thu Apr 11 18:02:41 2019 New Revision: 270288 URL: https://gcc.gnu.org/viewcvs?rev=270288=gcc=rev Log: 2018-04-11 Steve Ellcey PR rtl-optimization/87763 *

[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763 --- Comment #48 from Steve Ellcey --- (In reply to Richard Biener from comment #47) > What's the state of regressions left? Can we xfail the rest and defer the > bug? I submitted a patch to fix gcc.target/aarch64/lsl_asr_sbfiz.c That email is

[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763 --- Comment #46 from Steve Ellcey --- Author: sje Date: Wed Apr 10 20:29:57 2019 New Revision: 270267 URL: https://gcc.gnu.org/viewcvs?rev=270267=gcc=rev Log: 2018-04-10 Steve Ellcey PR rtl-optimization/87763 *

[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763 --- Comment #45 from Steve Ellcey --- Author: sje Date: Wed Apr 10 20:28:19 2019 New Revision: 270266 URL: https://gcc.gnu.org/viewcvs?rev=270266=gcc=rev Log: 2018-04-10 Steve Ellcey PR rtl-optimization/87763 *

[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763 --- Comment #34 from Steve Ellcey --- I submitted a patch that would fix gcc.target/aarch64/combine_bfi_1.c back in February but have not gotten any feedback on the final version of the patch despite a couple of pings. I have resubmitted the

[Bug fortran/89724] New: Fortran diagnostics give wrong line number because of math-vector-fortran.h header file

Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: sje at gcc dot gnu.org Target Milestone: --- I am seeing some Fortran regressions in my testing, but only when I build and test with the latest Glibc

[Bug target/89719] New: [9 regression] gcc.target/aarch64/spellcheck_[456].c testsuite failures

Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sje at gcc dot gnu.org Target Milestone: --- FAIL: gcc.target/aarch64/spellcheck_4.c (test for errors, line ) FAIL: gcc.target/aarch64/spellcheck_4.c (test for excess errors

[Bug target/89628] aarch64_vector_pcs does not use v24-v31 as temp regs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89628 Steve Ellcey changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314 --- Comment #24 from Steve Ellcey --- See email strings at: https://gcc.gnu.org/ml/fortran/2019-01/msg00276.html https://gcc.gnu.org/ml/fortran/2019-02/msg00057.html For more discussion.

[Bug middle-end/82479] missing popcount builtin detection

||sje at gcc dot gnu.org Known to work||9.0 Resolution|--- |FIXED --- Comment #14 from Steve Ellcey --- It looks like the fix for this is checked in. I verified that on Aarch64, when compiling bits.cpp from 531

[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314 Steve Ellcey changed: What|Removed |Added CC||sje at gcc dot gnu.org --- Comment #22

[Bug target/84201] 549.fotonik3d_r from SPEC2017 fails verification with recent Intel and AMD CPUs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84201 --- Comment #7 from Steve Ellcey --- (In reply to Richard Biener from comment #6) > If Martins bisection to power.fppized.o is correct you can bisect the loop > via the vect_loop or vect_slp debug counters (or first try with just >

[Bug target/84201] 549.fotonik3d_r from SPEC2017 fails verification with recent Intel and AMD CPUs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84201 Steve Ellcey changed: What|Removed |Added CC||sje at gcc dot gnu.org --- Comment #5

[Bug debug/87451] FAIL: gcc.dg/debug/dwarf2/inline5.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87451 --- Comment #11 from Steve Ellcey --- (In reply to Richard Biener from comment #10) > (In reply to Steve Ellcey from comment #9) > Looks like that's because of different expected comment characters, > # vs. // in your file. The pattern for the

[Bug debug/87451] FAIL: gcc.dg/debug/dwarf2/inline5.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87451 Steve Ellcey changed: What|Removed |Added CC||sje at gcc dot gnu.org --- Comment #9

[Bug target/85711] ICE in aarch64_classify_address, at config/aarch64/aarch64.c:5678

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85711 --- Comment #3 from Steve Ellcey --- Author: sje Date: Wed Jan 23 22:43:42 2019 New Revision: 268219 URL: https://gcc.gnu.org/viewcvs?rev=268219=gcc=rev Log: 2019-01-23 Bin Cheng Steve Ellcey PR target/85711 *

[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763 --- Comment #21 from Steve Ellcey --- If I look at this specific example: int f2 (int x, int y) { return (x & ~0x0ff000) | ((y & 0x0ff) << 12); } Before the combine change, I see in x.c.260r.combine: Trying 8, 9 -> 15: 8:

[Bug fortran/88912] Fortran compiler segfaults when pre-include file is not found

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88912 --- Comment #3 from Steve Ellcey --- It is quite possible I am using the option incorrectly (though that should not result in a segfault of course). Should some other flag be adding this to the command line for me?

[Bug fortran/88912] New: Fortran compiler segfaults when pre-include file is not found

Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: sje at gcc dot gnu.org Target Milestone: --- I am using the new -pre-include= option with Fortran and when the file I am trying to preinclude does not exist the compiler segfaults

[Bug fortran/88898] [Regression 9] gomp is broken by r268045

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88898 --- Comment #6 from Steve Ellcey --- Author: sje Date: Fri Jan 18 00:41:40 2019 New Revision: 268054 URL: https://gcc.gnu.org/viewcvs?rev=268054=gcc=rev Log: 2018-01-17 Steve Ellcey PR fortran/88898 *

[Bug fortran/88898] [Regression 9] gomp is broken by r268045

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88898 Steve Ellcey changed: What|Removed |Added CC||sje at gcc dot gnu.org --- Comment #4

[Bug target/85711] ICE in aarch64_classify_address, at config/aarch64/aarch64.c:5678

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85711 --- Comment #2 from Steve Ellcey --- This has been failing for quite a while now and there is apparently a fix for it. Can we get it fixed for GCC 9.0 release?

[Bug target/88682] new test case c-c++-common/pr51628-10.c fails starting with its introduction in r267313

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88682 Steve Ellcey changed: What|Removed |Added CC||sje at gcc dot gnu.org --- Comment #5

[Bug rtl-optimization/87763] [9.0 Regression] aarch64 target testcases fail after r265398

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763 --- Comment #1 from Steve Ellcey --- I looked at one of the failing tests (gcc.target/aarch64/cvtf_1.c) the code looks worse than before, generating an extra instruction in each of the routines. Here is an example from one function where there

[Bug rtl-optimization/87763] New: [9.0 Regression] aarch64 target testcases fail after r265398

Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sje at gcc dot gnu.org CC: segher at gcc dot gnu.org Target Milestone: --- The following tests fail on aarch64 after r265398 (combine: Do not combine moves from

[Bug tree-optimization/71625] missing strlen optimization on different array initialization style

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71625 --- Comment #24 from Steve Ellcey --- Author: sje Date: Fri Oct 5 15:26:40 2018 New Revision: 264874 URL: https://gcc.gnu.org/viewcvs?rev=264874=gcc=rev Log: 2018-10-05 Steve Ellcey PR tree-optimization/71625 *

[Bug testsuite/87433] [9 Regression] gcc.dg/zero_bits_compound-1.c and gcc.target/aarch64/ashltidisi.c tests fail after combine two to two instruction patch on aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87433 Steve Ellcey changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug testsuite/87433] [9 Regression] gcc.dg/zero_bits_compound-1.c and gcc.target/aarch64/ashltidisi.c tests fail after combine two to two instruction patch on aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87433 --- Comment #6 from Steve Ellcey --- Author: sje Date: Fri Sep 28 14:44:15 2018 New Revision: 264692 URL: https://gcc.gnu.org/viewcvs?rev=264692=gcc=rev Log: 2018-09-28 Steve Ellcey PR testsuite/87433 *

[Bug testsuite/87433] [9 Regression] gcc.dg/zero_bits_compound-1.c and gcc.target/aarch64/ashltidisi.c tests fail after combine two to two instruction patch on aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87433 --- Comment #5 from Steve Ellcey --- Author: sje Date: Fri Sep 28 14:41:45 2018 New Revision: 264691 URL: https://gcc.gnu.org/viewcvs?rev=264691=gcc=rev Log: 2018-09-28 Steve Ellcey PR testsuite/87433 *

[Bug tree-optimization/71625] missing strlen optimization on different array initialization style

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71625 Steve Ellcey changed: What|Removed |Added CC||sje at gcc dot gnu.org --- Comment #21

[Bug testsuite/87433] [9 Regression] gcc.dg/zero_bits_compound-1.c and gcc.target/aarch64/ashltidisi.c tests fail after combine two to two instruction patch on aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87433 --- Comment #3 from Steve Ellcey --- Based on that email string, gcc.target/aarch64/ashltidisi.c can be fixed by looking for 3 asr instructions instead of 4. That seems simple enough. The new code has two fewer instructions that the old code:

[Bug tree-optimization/61247] vectorization fails for unsigned is used for IV but casted to int before using as the index (and then casted for internal type)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61247 --- Comment #4 from Steve Ellcey --- Here is a simpler C version of the problem. On aarch64 in LP64 mode setting TYPE to int, long int, or unsigned long int allows for vectorization but using unsigned int does not get vectorized. In ILP32

[Bug middle-end/87433] New: gcc.dg/zero_bits_compound-1.c and gcc.target/aarch64/ashltidisi.c regressions on aarch64

Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: sje at gcc dot gnu.org Target Milestone: --- The tests gcc.dg/zero_bits_compound-1.c and gcc.target/aarch64/ashltidisi.c have been failing since

[Bug target/71727] -O3 -mstrict-align produces code which assumes unaligned vector accesses work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71727 Steve Ellcey changed: What|Removed |Added CC||sje at gcc dot gnu.org --- Comment #6

[Bug target/86538] GCC should define a macro to specify if LSE is enabled or not

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86538 --- Comment #2 from Steve Ellcey --- While I agree that we want users to use the __sync and atomic primitives, it still seems like it would be useful in some cases to know if the LSE operations are available and if GCC is generating code for

[Bug middle-end/86540] New: pr77445-2.c and ssa-dom-thread-7.c regressions since May 20, 2018

Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: sje at gcc dot gnu.org Target Milestone: --- According to Christophe Lyon, Martin Liska is aware of these failures and will fix them but I wanted to create a bug report

[Bug target/86538] New: GCC should define a macro to specify if LSE is enabled or not

Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sje at gcc dot gnu.org Target Milestone: --- Right now there is no predefined macro in GCC that can tell if LSE is enable or not. If you compile with -march=armv8.1-a+lse or -march

[Bug other/86153] [9 regression] test case g++.dg/pr83239.C fails starting with r261585

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86153 Steve Ellcey changed: What|Removed |Added CC||sje at gcc dot gnu.org --- Comment #4

[Bug testsuite/86016] New tests for r260978 report excess errors

||dave.pagan at oracle dot com, ||sje at gcc dot gnu.org --- Comment #2 from Steve Ellcey --- Adding David Pagen since it looks like Jeff checked this patch in for him.

[Bug target/79924] aarch64: untranslated diagnostics in aarch64_err_no_fpadvsimd

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79924 --- Comment #2 from Steve Ellcey --- Author: sje Date: Tue Jun 5 22:21:36 2018 New Revision: 261218 URL: https://gcc.gnu.org/viewcvs?rev=261218=gcc=rev Log: 2018-06-05 Steve Ellcey PR target/79924 *

[Bug target/79924] aarch64: untranslated diagnostics in aarch64_err_no_fpadvsimd

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79924 --- Comment #1 from Steve Ellcey --- Author: sje Date: Tue Jun 5 22:20:13 2018 New Revision: 261217 URL: https://gcc.gnu.org/viewcvs?rev=261217=gcc=rev Log: 2018-06-05 Steve Ellcey PR target/79924 *

[Bug target/68256] Defining TARGET_USE_CONSTANT_BLOCKS_P causes go bootstrap failure on aarch64.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68256 Steve Ellcey changed: What|Removed |Added CC||sje at gcc dot gnu.org --- Comment #11

[Bug c/84923] gcc.dg/attr-weakref-1.c failed on aarch64

||2018-04-24 CC||sje at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Steve Ellcey --- I am seeing this failure also.

[Bug tree-optimization/85483] New: Many failures on test gcc.target/aarch64/sve/vcond_1.c

Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sje at gcc dot gnu.org Target Milestone: --- I am seeing a bunch of failures in the gcc.target/aarch64/sve/vcond_1.c test on aarch64. You can see them on the test results list at: https://gcc.gnu.org

[Bug middle-end/85383] [8 regression] many ICE failures at gcc/toplev.c:325 starting with r259346

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85383 Steve Ellcey changed: What|Removed |Added CC||sje at gcc dot gnu.org --- Comment #2

[Bug middle-end/85160] New: GCC generates mvn/and instructions instead of bic on aarch64

-optimization Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: sje at gcc dot gnu.org Target Milestone: --- Target: aarch64 With this test case: int foo(int a, int b, int *c, int i, int j

[Bug tree-optimization/84114] global reassociation pass prevents fma usage, generates slower code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84114 --- Comment #9 from Steve Ellcey --- > Can you let me know if my workaround helped? If useful I could backport it > to GCC7 as well. Yes, the patch helped. I ran spec 2017 fp rate and saw a small improvement (0.7%). Most of the speed up was

[Bug target/83335] [8 regression][aarch64,ilp32] gcc.target/aarch64/asm-2.c ICEs since 255481

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83335 Steve Ellcey changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug target/83335] [8 regression][aarch64,ilp32] gcc.target/aarch64/asm-2.c ICEs since 255481

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83335 --- Comment #6 from Steve Ellcey --- Author: sje Date: Thu Feb 22 17:08:10 2018 New Revision: 257908 URL: https://gcc.gnu.org/viewcvs?rev=257908=gcc=rev Log: 2018-02-22 Steve Ellcey PR target/83335 *

[Bug target/83335] [8 regression][aarch64,ilp32] gcc.target/aarch64/asm-2.c ICEs since 255481

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83335 --- Comment #5 from Steve Ellcey --- Author: sje Date: Thu Feb 22 17:06:31 2018 New Revision: 257907 URL: https://gcc.gnu.org/viewcvs?rev=257907=gcc=rev Log: 2018-02-22 Steve Ellcey PR target/83335 *

[Bug testsuite/83983] FAIL: g++.dg/lto/pr83121 (test for LTO warnings, pr83121_0.C line 8)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83983 Steve Ellcey changed: What|Removed |Added CC||sje at gcc dot gnu.org --- Comment #3

[Bug tree-optimization/84114] global reassociation pass prevents fma usage, generates slower code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84114 --- Comment #6 from Steve Ellcey --- (In reply to Wilco from comment #5) > (In reply to Steve Ellcey from comment #4) > > While teaching the reassociation pass about fma's seems like the right > > answer would it be reasonable (and simpler) to

[Bug tree-optimization/84114] global reassociation pass prevents fma usage, generates slower code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84114 --- Comment #4 from Steve Ellcey --- While teaching the reassociation pass about fma's seems like the right answer would it be reasonable (and simpler) to do the fma pass (pass_optimize_widening_mul) before the reassociation pass (pass_reassoc)

[Bug tree-optimization/84114] New: global reassociation pass prevents fma usage, generates slower code

Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sje at gcc dot gnu.org Target Milestone: --- Created attachment 43279 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43279=edit Test case The example code co

[Bug c/65345] ICE with _Generic selection on _Atomic int

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345 Steve Ellcey changed: What|Removed |Added CC||sje at gcc dot gnu.org --- Comment #29

[Bug target/83726] [8 Regression] ICE: in final_scan_insn, at final.c:3063

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83726 --- Comment #7 from Steve Ellcey --- I tested the patch on my aarch64 box, I got three regressions: FAIL: gcc.target/aarch64/pr78733.c scan-assembler adr FAIL: gcc.target/aarch64/pr79041-2.c scan-assembler adr FAIL:

[Bug target/82066] #pragma GCC target documentation does not say it is implemented for aarch64

||sje at gcc dot gnu.org Known to work||8.0 Resolution|--- |FIXED --- Comment #4 from Steve Ellcey --- Yes, this is fixed for 8.0.

[Bug target/83726] [8 Regression] ICE: in final_scan_insn, at final.c:3063

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83726 Steve Ellcey changed: What|Removed |Added CC||sje at gcc dot gnu.org --- Comment #4

[Bug target/83285] non-atomic stores can removed with seq_cst (and store release) on AArch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83285 Steve Ellcey changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug target/83285] non-atomic stores can removed with seq_cst (and store release) on AArch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83285 Steve Ellcey changed: What|Removed |Added CC||sje at gcc dot gnu.org --- Comment #2

[Bug target/83335] [8 regression][aarch64,ilp32] gcc.target/aarch64/asm-2.c ICEs since 255481

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83335 --- Comment #3 from Steve Ellcey --- Proposed patch https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00348.html

[Bug rtl-optimization/83500] gcc.dg/tree-prof/switch-case-1.c fails on aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83500 Steve Ellcey changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|---

[Bug target/83466] Wrong TLS GD sequence for ILP32

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83466 --- Comment #4 from Steve Ellcey --- Created attachment 43027 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43027=edit Patch file being tested I am testing this patch for regressions, I have verified that it does fix the small test case.

[Bug rtl-optimization/83500] gcc.dg/tree-prof/switch-case-1.c fails on aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83500 --- Comment #3 from Steve Ellcey --- The test now passes for me.

[Bug rtl-optimization/83500] New: gcc.dg/tree-prof/switch-case-1.c fails on aarch64

Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sje at gcc dot gnu.org Target Milestone: --- This test started failing on aarch64-linux-gnu with this checkin: commit b33f4eb038b5c30bf57de6bb10f40e11481c6be6 Author: hubicka <hubicka@138bc75d-0d04-0

[Bug target/81356] __builtin_strcpy is not good for copying an empty string on aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81356 --- Comment #8 from Steve Ellcey --- Author: sje Date: Tue Nov 21 00:18:14 2017 New Revision: 254977 URL: https://gcc.gnu.org/viewcvs?rev=254977=gcc=rev Log: 2017-11-20 Steve Ellcey PR target/81356 *

[Bug target/81356] __builtin_strcpy is not good for copying an empty string on aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81356 --- Comment #7 from Steve Ellcey --- Author: sje Date: Fri Nov 17 22:44:32 2017 New Revision: 254901 URL: https://gcc.gnu.org/viewcvs?rev=254901=gcc=rev Log: 2017-11-17 Steve Ellcey PR target/81356 *

[Bug target/79868] aarch64: diagnostic "malformed target %s value" not translateable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79868 Steve Ellcey changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug tree-optimization/80925] [8 Regression] vect peeling failures

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80925 --- Comment #27 from Steve Ellcey --- (In reply to Richard Biener from comment #26) > Fixed? I see still these vect failures on aarch64: FAIL: gcc.dg/vect/pr65947-14.c execution test FAIL: gcc.dg/vect/pr65947-14.c -flto -ffat-lto-objects

[Bug target/79868] aarch64: diagnostic "malformed target %s value" not translateable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79868 --- Comment #10 from Steve Ellcey --- Author: sje Date: Thu Nov 2 21:58:05 2017 New Revision: 254360 URL: https://gcc.gnu.org/viewcvs?rev=254360=gcc=rev Log: PR target/79868 * gcc.target/aarch64/spellcheck_1.c: Update dg-error

[Bug target/79868] aarch64: diagnostic "malformed target %s value" not translateable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79868 --- Comment #9 from Steve Ellcey --- Author: sje Date: Thu Nov 2 21:56:00 2017 New Revision: 254359 URL: https://gcc.gnu.org/viewcvs?rev=254359=gcc=rev Log: PR target/79868 * config/aarch64/aarch64-c.c

[Bug rtl-optimization/82683] Combine: GCC generates bad code with -tune=thunderx2t99

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82683 --- Comment #17 from Steve Ellcey --- Yes, this fixed my SPEC problem.

[Bug rtl-optimization/82683] Combine: GCC generates bad code with -tune=thunderx2t99

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82683 --- Comment #14 from Steve Ellcey --- (In reply to Segher Boessenkool from comment #13) > I have a simpler patch. It is testing... Can you attach your patch to this defect so I can test it as well.

[Bug target/82786] New: aarch64 frame patch caused a number of target specific test failures.

Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sje at gcc dot gnu.org CC: wdijkstr at arm dot com Target Milestone: --- Target: aarch64-*-* This patch: 2017-10-26 Wilco Dijkstra <wd

[Bug rtl-optimization/82683] Combine: GCC generates bad code with -tune=thunderx2t99

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82683 --- Comment #12 from Steve Ellcey --- Created attachment 42491 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42491=edit Patch that fixes the test case Here is a possible patch. It fixes the test case and I am doing a bootstrap and make

[Bug rtl-optimization/82683] Combine: GCC generates bad code with -tune=thunderx2t99

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82683 --- Comment #11 from Steve Ellcey --- I think I see where this is going wrong but I don't know what to do about it. In try_combine, line 3288 we have i2 and i3 of: (insn 18 16 19 3 (set (reg:DI 91) (ashift:DI (reg:DI 83 [ _26 ])

  1   2   3   4   >