[Bug tree-optimization/109491] [13 Regression] Segfault in tree-ssa-sccvn.cc:expressions_equal_p()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491 --- Comment #5 from pthaugen at gcc dot gnu.org --- (In reply to Peter Bergner from comment #4) > > Can you git bisect this to find the offending commit? Yes, I was going to start that.

[Bug tree-optimization/109491] [13 Regression] Segfault in tree-ssa-sccvn.cc:expressions_equal_p()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491 --- Comment #1 from pthaugen at gcc dot gnu.org --- Note this only happens on a BE system, compiles fine on LE.

[Bug tree-optimization/109491] New: Segfault in tree-ssa-sccvn.cc:expressions_equal_p()

Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: pthaugen at gcc dot gnu.org CC: bergner at gcc dot gnu.org, segher at kernel dot crashing.org Target Milestone: --- Host: powerpc64 Target: powerpc64

[Bug testsuite/99685] gcc.target/powerpc/divkc3-1.c and mulkc3-1.c fail for 32 bits

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99685 pthaugen at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #7 from

[Bug testsuite/99685] gcc.target/powerpc/divkc3-1.c and mulkc3-1.c fail for 32 bits

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99685 pthaugen at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

[Bug target/105485] New: ICE: Segmentation fault in pcrel-opt.md:get_insn_name()

Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pthaugen at gcc dot gnu.org Target Milestone: --- Host: powerpc64le-linux-gnu Target: powerpc64le-linux-gnu Build: powerpc64le-linux-gnu pthaugen@pike

[Bug testsuite/100407] New test cases attr-retain-*.c fail after their introduction in r11-7284

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100407 pthaugen at gcc dot gnu.org changed: What|Removed |Added CC||pthaugen at gcc dot

[Bug rtl-optimization/68212] Loop unroller breaks basic block frequencies

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68212 --- Comment #9 from pthaugen at gcc dot gnu.org --- The problem can be seen in the loop2_unroll dump: pthaugen@pike:~/temp/pr68212$ grep "Invalid sum of" simple.c.272r.loop2_unroll ;; Invalid sum of incoming counts 285685646 (estimat

[Bug rtl-optimization/68212] Loop unroller breaks basic block frequencies

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68212 pthaugen at gcc dot gnu.org changed: What|Removed |Added CC||guojiufu at gcc dot gnu.org

[Bug target/65010] ppc backend generates unnecessary signed extension

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65010 pthaugen at gcc dot gnu.org changed: What|Removed |Added CC||pthaugen at gcc dot gnu.org

[Bug rtl-optimization/98782] [11/12 Regression] Bad interaction between IPA frequences and IRA resulting in spills due to changes in BB frequencies

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782 --- Comment #34 from pthaugen at gcc dot gnu.org --- (In reply to pthaugen from comment #33) > > I tried the patch on a Power9 system. Execution time went from 371 seconds > to 291. Which I should have included is in line, or even

[Bug rtl-optimization/98782] [11/12 Regression] Bad interaction between IPA frequences and IRA resulting in spills due to changes in BB frequencies

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782 --- Comment #33 from pthaugen at gcc dot gnu.org --- (In reply to rsand...@gcc.gnu.org from comment #32) > Created attachment 52102 [details] > Alternative patch > > This patch is a squash of several ira tweaks that together recov

[Bug ipa/103734] IPA-CP opportunity for imagick in SPECCPU 2017

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103734 pthaugen at gcc dot gnu.org changed: What|Removed |Added CC||pthaugen at gcc dot

[Bug target/103743] PPC: Inefficient equality compare for large 64-bit constants having only 16-bit relevant bits in high part

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103743 --- Comment #2 from pthaugen at gcc dot gnu.org --- (In reply to Peter Bergner from comment #1) > Pat, does the patch from Alan you're working to get committed help with this > test case? No, it just loads the constant slightly dif

[Bug rtl-optimization/98782] [11/12 Regression] Bad interaction between IPA frequences and IRA resulting in spills due to changes in BB frequencies

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782 --- Comment #21 from pthaugen at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #20) > With g:r12-5872-gf157c5362b4844f7676cae2aba81a4cf75bd68d5 we should no > longer need -fno-inline-functions-called-once Yes, I see th

[Bug rtl-optimization/98782] [11/12 Regression] Bad interaction between IPA frequences and IRA resulting in spills due to changes in BB frequencies

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782 --- Comment #19 from pthaugen at gcc dot gnu.org --- I tried -fno-inline-functions-called-once and the patches on a Power9 system. Following are the run times and spill counts (grep -c Spilling exchange2.fppized.f90.298r.ira). Interesting

[Bug target/102783] [powerpc] FPSCR manipulations cannot be relied upon

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102783 pthaugen at gcc dot gnu.org changed: What|Removed |Added CC||pthaugen at gcc dot

[Bug ipa/96825] [11 Regression] Commit r11-2645 degrades CPU2017 548.exchange2_r by 35%

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96825 --- Comment #6 from pthaugen at gcc dot gnu.org --- (In reply to Richard Biener from comment #4) > I believe there have been improvements recently - can you re-assess the > magnitude of the problem? The corresponding ARM PR got re-ta

[Bug target/99133] Power10 xxspltiw, xxspltidp, xxsplti32dx instructions need to be marked as prefixed

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99133 pthaugen at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status

[Bug target/99133] Power10 xxspltiw, xxspltidp, xxsplti32dx instructions need to be marked as prefixed

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99133 pthaugen at gcc dot gnu.org changed: What|Removed |Added CC||pthaugen at gcc dot gnu.org

[Bug other/96825] New: Commit r11-2645 degrades CPU2017 548.exchange2_r by 35%

Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: pthaugen at gcc dot gnu.org CC: bergner at gcc dot gnu.org, hubicka at gcc dot gnu.org, segher at gcc dot gnu.org, seurer at gcc dot gnu.org

[Bug tree-optimization/50439] gfortran infinite loop with -floop-interchange

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50439 pthaugen at gcc dot gnu.org changed: What|Removed |Added CC||pthaugen at gcc dot gnu.org

[Bug lto/92600] New: ICE: lto1: internal compiler error: symtab_node::verify failed, building 523.xalancbmk_r with -flto -fno-inline

Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: pthaugen at gcc dot gnu.org CC: dje at gcc dot gnu.org, marxin at gcc dot gnu.org

[Bug rtl-optimization/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 pthaugen at gcc dot gnu.org changed: What|Removed |Added CC||pthaugen at gcc dot gnu.org

[Bug target/84369] test case gcc.dg/sms-10.c fails on power9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84369 --- Comment #7 from pthaugen at gcc dot gnu.org --- Author: pthaugen Date: Fri Apr 19 17:14:57 2019 New Revision: 270461 URL: https://gcc.gnu.org/viewcvs?rev=270461=gcc=rev Log: Backport from mainline: 2019-04-16 Pat Haugen

[Bug target/84369] test case gcc.dg/sms-10.c fails on power9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84369 --- Comment #5 from pthaugen at gcc dot gnu.org --- Author: pthaugen Date: Tue Apr 16 15:58:02 2019 New Revision: 270394 URL: https://gcc.gnu.org/viewcvs?rev=270394=gcc=rev Log: PR target/84369 * config/rs6000/power9.md: Add

[Bug rtl-optimization/89154] 5% degradation of CPU2006 473.astar starting with r266305

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89154 --- Comment #3 from Pat Haugen --- (In reply to Segher Boessenkool from comment #1) > The new version needs to save r4 because it reuses the reg for storing r7+r8. > And we still don't wrap CR separately, sigh. Yes, and similar for r3 since

[Bug tree-optimization/89154] New: 5% degradation of CPU2006 473.astar starting with r266305

Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: pthaugen at gcc dot gnu.org CC: dje at gcc dot gnu.org, rguenth at gcc dot gnu.org, segher at gcc dot gnu.org, wschmidt at gcc dot gnu.org Target

[Bug ipa/85103] [8/9 Regression] Performance regressions on SPEC with r257582

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103 --- Comment #21 from Pat Haugen --- > Knowing what inline decision matters for VPR, I can try to fix it too. Gathering some perf data, the hot functions for various revisions are as follows. All other functions report < 0.5% of execution time.

[Bug ipa/85103] [8/9 Regression] Performance regressions on SPEC with r257582

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103 --- Comment #19 from Pat Haugen --- (In reply to Jan Hubicka from comment #18) > which makes it to be inlined. Does it solve the perofmrance problem for both > benchmarks? Looking at our nightly spec runs, the bzip2 degradation has indeed been

[Bug ipa/85103] [8/9 Regression] Performance regressions on SPEC with r257582

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103 --- Comment #16 from Pat Haugen --- > > Do you observe the same slowdown if you restore either of the params to > the value before the r257582 change? > --param max-inline-insns-auto=40 results in the same degradation. --param

[Bug gcov-profile/77698] Unrolled loop not considered hot after profiling

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77698 --- Comment #7 from Pat Haugen --- I also see the loop now being aligned when I apply your patch. srdi 10,10,2 mtctr 10 .p2align 4,,15 .L6: ld 9,0(11) ld 8,0(4)

[Bug gcov-profile/77698] Unrolled loop not considered hot after profiling

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77698 Pat Haugen changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED

[Bug rtl-optimization/86892] New: RTL CSE commoning trivial constants across call and/or too early

Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: pthaugen at gcc dot gnu.org CC: dje at gcc dot gnu.org, jakub at gcc dot gnu.org, rsandifo at gcc dot gnu.org, segher at gcc dot gnu.org

[Bug target/86612] __strdup problem on power 9

||pthaugen at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Pat Haugen --- Was really a library difference, with newer glibc no longer declaring __strdup. Fixed.

[Bug target/86612] __strdup problem on power 9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86612 --- Comment #2 from Pat Haugen --- Author: pthaugen Date: Thu Jul 26 20:47:37 2018 New Revision: 263021 URL: https://gcc.gnu.org/viewcvs?rev=263021=gcc=rev Log: PR target/86612 * gcc.target/powerpc/pr58673-2.c: Call strdup.

[Bug target/86612] __strdup problem on power 9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86612 --- Comment #1 from Pat Haugen --- Author: pthaugen Date: Thu Jul 26 20:41:25 2018 New Revision: 263020 URL: https://gcc.gnu.org/viewcvs?rev=263020=gcc=rev Log: PR target/86612 * gcc.target/powerpc/pr58673-2.c: Call strdup.

[Bug tree-optimization/86489] ICE in gimple_phi_arg starting with r261682 when building 531.deepsjeng_r with FDO + LTO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86489 Pat Haugen changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug tree-optimization/86489] ICE in gimple_phi_arg starting with r261682 when building 531.deepsjeng_r with FDO + LTO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86489 --- Comment #5 from Pat Haugen --- (In reply to kugan from comment #3) > index f6fa2f7..fbdf838 100644 > --- a/gcc/tree-ssa-loop-niter.c > +++ b/gcc/tree-ssa-loop-niter.c > @@ -2555,6 +2555,7 @@ number_of_iterations_popcount (loop_p loop, edge

[Bug tree-optimization/86489] New: ICE in gimple_phi_arg starting with r261682 when building 531.deepsjeng_r with FDO + LTO

Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: pthaugen at gcc dot gnu.org CC: dje at gcc dot gnu.org, kugan at gcc dot gnu.org, segher at gcc dot gnu.org, wschmidt

[Bug tree-optimization/85698] [8/9 Regression] CPU2017 525.x264_r fails starting with r257581

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85698 --- Comment #13 from Pat Haugen --- Author: pthaugen Date: Mon May 21 16:41:09 2018 New Revision: 260477 URL: https://gcc.gnu.org/viewcvs?rev=260477=gcc=rev Log: PR target/85698 * gcc.target/powerpc/vec-setup-be-long.c: Remove

[Bug tree-optimization/85698] [8/9 Regression] CPU2017 525.x264_r fails starting with r257581

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85698 --- Comment #12 from Pat Haugen --- Author: pthaugen Date: Mon May 21 16:34:44 2018 New Revision: 260476 URL: https://gcc.gnu.org/viewcvs?rev=260476=gcc=rev Log: PR target/85698 * config/rs6000/rs6000.c

[Bug tree-optimization/85698] [8/9 Regression] CPU2017 525.x264_r fails starting with r257581

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85698 --- Comment #11 from Pat Haugen --- Author: pthaugen Date: Mon May 21 16:23:20 2018 New Revision: 260475 URL: https://gcc.gnu.org/viewcvs?rev=260475=gcc=rev Log: PR target/85698 * config/rs6000/rs6000.c

[Bug tree-optimization/85698] [8/9 Regression] CPU2017 525.x264_r fails starting with r257581

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85698 Pat Haugen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug tree-optimization/85698] [8/9 Regression] CPU2017 525.x264_r fails starting with r257581

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85698 --- Comment #9 from Pat Haugen --- Author: pthaugen Date: Thu May 17 16:19:16 2018 New Revision: 260329 URL: https://gcc.gnu.org/viewcvs?rev=260329=gcc=rev Log: PR target/85698 * config/rs6000/rs6000.c

[Bug tree-optimization/85698] [8/9 Regression] CPU2017 525.x264_r fails starting with r257581

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85698 --- Comment #7 from Pat Haugen --- So the problem is that we're generating a stxvw4x insn to write to memory, which corrupts the contents due to both endian behavior and element size (since we're dealing with halfword/uint16_t elements). Value

[Bug tree-optimization/85698] [8/9 Regression] CPU2017 525.x264_r fails starting with r257581

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85698 --- Comment #6 from Pat Haugen --- (In reply to Richard Biener from comment #4) > I can see what the patch does to this testcase on x86_64 - it enables BB > vectorization of the first two loops after runrolling. I don't see anything >

[Bug tree-optimization/85698] [8/9 Regression] CPU2017 525.x264_r fails starting with r257581

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85698 --- Comment #5 from Pat Haugen --- (In reply to Richard Biener from comment #4) > > Can you claify whether test, ref or train inputs fail for you? I tried > AVX256, AVX128 and plain old SSE sofar without any issue but ref takes some > time...

[Bug tree-optimization/85698] [8/9 Regression] CPU2017 525.x264_r fails starting with r257581

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85698 --- Comment #3 from Pat Haugen --- (In reply to Richard Biener from comment #2) > > Can you help me with isolating this to a single function inside that file? > Maybe try sticking __attribute__((optimize("no-tree-vectorize"))) on some >

[Bug tree-optimization/85698] CPU2017 525.x264_r fails starting with r257581

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85698 --- Comment #1 from Pat Haugen --- Looks like benchmark fails when x264_src/common/dct.c is compiled with r257581.

[Bug tree-optimization/85698] New: CPU2017 525.x264_r fails starting with r257581

: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: pthaugen at gcc dot gnu.org CC: rguenth at gcc dot gnu.org, segher at kernel dot crashing.org, wschmidt at gcc dot gnu.org Target Milestone: --- Host: powerpc64le

[Bug c++/85600] [9 Regression] CPU2006 471.omnetpp fails starting with r259771

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85600 Pat Haugen changed: What|Removed |Added Known to work||8.0 Summary|CPU2006 471.omnetpp

[Bug c++/85600] CPU2006 471.omnetpp fails starting with r259771

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85600 --- Comment #2 from Pat Haugen --- (In reply to Andrew Pinski from comment #1) > Does adding -fno-lifetime-dse help? This could be a bug in the omnetpp > sources ... Nope, still fails. 471.omnetpp: copy 0 non-zero return code (exit code=1,

[Bug c++/85600] New: CPU2006 471.omnetpp fails starting with r259771

++ Assignee: unassigned at gcc dot gnu.org Reporter: pthaugen at gcc dot gnu.org Target Milestone: --- Benchmark is failing at runtime, emitting following message at the end before exiting with rc=1. ** Event #0 T=0.000 ( 0.00s) Messages: created: 77472 ** Event

[Bug tree-optimization/84737] [8 Regression] 20% degradation in CPU2000 172.mgrid starting with r256888

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84737 --- Comment #20 from Pat Haugen --- (In reply to Richard Biener from comment #18) > Fixed (hopefully). Yes, mgrid performance is back. Thanks.

[Bug tree-optimization/84737] [8 Regression] 20% degradation in CPU2000 172.mgrid starting with r256888

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84737 Pat Haugen changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #15

[Bug tree-optimization/84737] [8 Regression] 20% degradation in CPU2000 172.mgrid starting with r256888

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84737 --- Comment #14 from Pat Haugen --- Created attachment 43928 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43928=edit r256888 pcom dump So the difference appears to be occurring in predictive commoning. In the ipa-cp clone,

[Bug ipa/85103] [8 Regression] Performance regressions on SPEC with r257582

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103 --- Comment #7 from Pat Haugen --- Created attachment 43901 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43901=edit inline dump Prior attachment was r257581 dump. This is r257582 dump.

[Bug ipa/85103] [8 Regression] Performance regressions on SPEC with r257582

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103 --- Comment #6 from Pat Haugen --- Created attachment 43900 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43900=edit inline dump

[Bug ipa/85103] [8 Regression] Performance regressions on SPEC with r257582

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103 --- Comment #5 from Pat Haugen --- A little more detail. 48t.fnsplit splits mainGtU() into 2 functions: mainGtU(): which contains a few early exit tests and then a call to mainGtU.part.0() mainGtU.part.0(): contains the remainder of mainGtU(),

[Bug ipa/85103] [8 Regression] Performance regressions on SPEC with r257582

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103 --- Comment #3 from Pat Haugen --- (In reply to Jan Hubicka from comment #1) > Pat, can you try to figure out what value of min-speedup is neeed to recover > from this regression? Using r257582, either of the following options restores the

[Bug ipa/85103] [8 Regression] Performance regressions on SPEC with r257582

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103 --- Comment #2 from Pat Haugen --- (In reply to Pat Haugen from comment #0) > > Very initial look at profile of bzip2 shows degradation is contained to > mainSort(), which showed a 54% increase in run cycles. Appears one of the > calls to

[Bug middle-end/83665] [8 regression] Big code size regression and some code quality improvement at Jan 2 2018

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83665 --- Comment #18 from Pat Haugen --- (In reply to Richard Biener from comment #17) > Pat, please open a new bug for the regression caused by the fix. Done, pr85103.

[Bug ipa/85103] New: Performance regressions on SPEC with r257582

Assignee: unassigned at gcc dot gnu.org Reporter: pthaugen at gcc dot gnu.org CC: dje at gcc dot gnu.org, hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org, segher at kernel dot crashing.org, wschmidt at gcc dot gnu.org

[Bug middle-end/83665] [8 regression] Big code size regression and some code quality improvement at Jan 2 2018

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83665 Pat Haugen changed: What|Removed |Added CC||pthaugen at gcc dot gnu.org --- Comment

[Bug target/83497] [8 Regression] CPU2000 172.mgrid starts failing with r254730

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83497 Pat Haugen changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|---

[Bug tree-optimization/84737] [8 Regression] 20% degradation in CPU2000 172.mgrid starting with r256888

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84737 --- Comment #10 from Pat Haugen --- (In reply to Pat Haugen from comment #9) > (pr83497, which I'm still digging on). Ignoring output miscompare and just > timing the two versions built with -fno-tree-vectorize, I see that the > performance is

[Bug tree-optimization/84737] [8 Regression] 20% degradation in CPU2000 172.mgrid starting with r256888

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84737 --- Comment #9 from Pat Haugen --- (In reply to Martin Jambor from comment #7) > Do I understand it correctly that you suspect that the new IPA-CP > clone that is created from r256888 on is harmful? In that case, you > want to test that by

[Bug tree-optimization/84737] [8 Regression] 20% degradation in CPU2000 172.mgrid starting with r256888

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84737 --- Comment #5 from Pat Haugen --- Created attachment 43601 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43601=edit ipa-cp dump (r256887) (In reply to Martin Liška from comment #4) > Thank you, may I please ask you for the IPA CP dump

[Bug tree-optimization/84737] [8 Regression] 20% degradation in CPU2000 172.mgrid starting with r256888

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84737 --- Comment #3 from Pat Haugen --- (In reply to Martin Liška from comment #1) > Isn't that dup of 84149? Can you please tweak --param ipa-cp-eval-threshold > to value to 200, 300, 400? Can you please attach -fdump-ipa-cp-details file? I tried

[Bug tree-optimization/84737] [8 Regression] 20% degradation in CPU2000 172.mgrid starting with r256888

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84737 --- Comment #2 from Pat Haugen --- Created attachment 43589 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43589=edit ipa-cp dump

[Bug ipa/84737] New: 20% degradation in CPU2000 172.mgrid starting with r256888

Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: pthaugen at gcc dot gnu.org CC: dje at gcc dot gnu.org, marxin at gcc dot gnu.org, segher at gcc dot gnu.org, wschmidt at gcc dot gnu.org Target Milestone

[Bug rtl-optimization/83530] [7/8 Regression] ICE in reset_sched_cycles_in_current_ebb, at sel-sched.c:7150

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83530 Pat Haugen changed: What|Removed |Added Summary|[8 Regression] ICE in |[7/8 Regression] ICE in

[Bug rtl-optimization/83530] [8 Regression] ICE in reset_sched_cycles_in_current_ebb, at sel-sched.c:7150

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83530 --- Comment #9 from Pat Haugen --- (In reply to Andrey Belevantsev from comment #8) > I will take a look. The ICE is within the code that models the scheduling > loop in order to get the proper insn ticks and everything for later MD >

[Bug rtl-optimization/83530] [8 Regression] ICE in reset_sched_cycles_in_current_ebb, at sel-sched.c:7150

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83530 --- Comment #7 from Pat Haugen --- Assuming this is a latent selective scheduling bug since I can reproduce with r243865 by adding -fsched-pressure --param sched-pressure-algorithm=2. Looking...

[Bug other/83497] CPU2000 172.mgrid starts failing with r254730

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83497 --- Comment #4 from Pat Haugen --- (In reply to Pat Haugen from comment #0) > mgrid started failing (output miscompare) with r254730. The following > options demonstrate the failure "-O3 -mcpu=power6 -ffast-math". Incomplete option set, -m32 is

[Bug other/83497] CPU2000 172.mgrid starts failing with r254730

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83497 --- Comment #3 from Pat Haugen --- (In reply to Richard Biener from comment #2) > > As far as I see the miscompare is -0.8 vs. 0.18 so it doesn't look like a > precision issue to me. Does it only happen for power6 / bigendian? > Yes, the

[Bug other/83497] New: CPU2000 172.mgrid starts failing with r254730

: other Assignee: unassigned at gcc dot gnu.org Reporter: pthaugen at gcc dot gnu.org CC: dje at gcc dot gnu.org, hubicka at gcc dot gnu.org, rguenth at gcc dot gnu.org, segher at gcc dot gnu.org, wschmidt at gcc dot gnu.org

[Bug lto/83201] [7/8 Regression] SPEC CPU2017 505.mcf_r produces incorrect output when built with -flto and FDO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83201 --- Comment #18 from Pat Haugen --- (In reply to Martin Liška from comment #16) > (In reply to Richard Biener from comment #15) > > SWAPINIT should end up with swaptype_long == 1 I think and swaptype_int == 1 > > for the cases in question.

[Bug lto/83201] [7/8 Regression] SPEC CPU2017 505.mcf_r produces incorrect output when built with -flto and FDO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83201 --- Comment #6 from Pat Haugen --- So I did a bisect of trunk during the GCC 7 development timeframe (r235035-r247017) and it pointed to r236878 as the point where the failure started. +++ gcc/ChangeLog (revision 236878) @@ -1,3 +1,9 @@

[Bug lto/83201] [7/8 Regression] SPEC CPU2017 505.mcf_f produces incorrect output when built with -flto and FDO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83201 --- Comment #5 from Pat Haugen --- Current FSF 6 branch works fine, so I have some bisect points. Will comment further as I find out.

[Bug tree-optimization/81303] [8 Regression] 410.bwaves regression caused by r249919

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81303 --- Comment #15 from Pat Haugen --- Just confirming that the changes have eliminated the bwaves degradation on PowerPC that started with r249919.

[Bug lto/83201] SPEC CPU2017 505.mcf_f produces incorrect output when built with -flto and FDO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83201 --- Comment #2 from Pat Haugen --- (In reply to Pat Haugen from comment #0) > > It appears to work fine with r254943. I'll start a bisect and post results. My bisect showed that r254946 was where it started failing on trunk. And yes, it fails

[Bug lto/83201] New: SPEC CPU2017 505.mcf_f produces incorrect output when built with -flto and FDO

: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: pthaugen at gcc dot gnu.org CC: dje at gcc dot gnu.org, hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org, segher at gcc dot gnu.org

[Bug tree-optimization/81953] Code sinking increases register pressure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81953 --- Comment #4 from Pat Haugen --- (In reply to Richard Biener from comment #3) > The interesting part is also why RTL scheduling doesn't rectify things > here? If you're referring to -fsched-pressure, I believe the answer is that those

[Bug tree-optimization/81953] New: Code sinking results in increased use of callee saved registers

Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: pthaugen at gcc dot gnu.org CC: dje.gcc at gmail dot com, wschmidt at gcc dot gnu.org Target Milestone: --- Host: powerpc64le-unknown-linux-gnu

[Bug rtl-optimization/81340] ICE in compute_bb_dataflow, at var-tracking.c:6877

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81340 Pat Haugen changed: What|Removed |Added CC||mliska at suse dot cz --- Comment #1 from

[Bug rtl-optimization/81340] New: ICE in compute_bb_dataflow, at var-tracking.c:6877

: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: pthaugen at gcc dot gnu.org CC: dje at gcc dot gnu.org, wschmidt at gcc dot gnu.org Target Milestone: --- Host: powerpc64le-unknown-linux-gnu Target: powerpc64le

[Bug ipa/80597] [8 Regression] internal compiler error: in compute_inline_parameters, at ipa-inline-analysis.c:3126

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80597 --- Comment #16 from Pat Haugen --- (In reply to Dmitry Babokin from comment #14) > Original test case still fails with compiler switches that I've originally > reported (-fsanitize=undefined). Is your failure fixed with r248325?

[Bug rtl-optimization/79801] Disable ira.c:add_store_equivs for some targets?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79801 Pat Haugen changed: What|Removed |Added CC||pthaugen at gcc dot gnu.org --- Comment #1

[Bug ipa/80597] [8 Regression] internal compiler error: in compute_inline_parameters, at ipa-inline-analysis.c:3126

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80597 --- Comment #12 from Pat Haugen --- (In reply to Martin Liška from comment #11) > Created attachment 41375 [details] > Patch candidate v2 > > Can you please test this version? It moves e from 10^6 to 10^5. That patch works for both the

[Bug ipa/80597] [8 Regression] internal compiler error: in compute_inline_parameters, at ipa-inline-analysis.c:3126

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80597 --- Comment #9 from Pat Haugen --- (In reply to Martin Liška from comment #8) > > Can you please provide a test-case? Or can you dump the sreal values via > .to_double() ? That can be also hint for us to fix that properly. I'm trying to reduce

[Bug libfortran/80602] Reduce stack usage for blocked matmul

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80602 --- Comment #7 from Pat Haugen --- (In reply to Thomas Koenig from comment #6) > I just committed r248074 which I suspect is the same problem > (the fix for PR 80765). > > If you could just upgrade to the most recent trunk (only > need to

[Bug libfortran/80602] Reduce stack usage for blocked matmul

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80602 Pat Haugen changed: What|Removed |Added CC||pthaugen at gcc dot gnu.org --- Comment #5

[Bug ipa/80597] [8 Regression] internal compiler error: in compute_inline_parameters, at ipa-inline-analysis.c:3126

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80597 --- Comment #7 from Pat Haugen --- (In reply to Pat Haugen from comment #6) > > I just ran into the same ICE and the proposed patch fixes the problem. Unfortunately the patch introduces the same ICE on another benchmark that used to build just

[Bug ipa/80597] [8 Regression] internal compiler error: in compute_inline_parameters, at ipa-inline-analysis.c:3126

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80597 Pat Haugen changed: What|Removed |Added CC||pthaugen at gcc dot gnu.org --- Comment #6

[Bug tree-optimization/80705] Incorrect code generated for profile counter updates due to SLP+LIM

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80705 --- Comment #1 from Pat Haugen --- I should have noted that the dumps I was looking at were slp1 and lim4.

[Bug tree-optimization/80705] New: Incorrect code generated for profile counter updates due to SLP+LIM

Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: pthaugen at gcc dot gnu.org CC: dje at gcc dot gnu.org, wschmidt at gcc dot gnu.org Target Milestone: --- Host

[Bug rtl-optimization/80357] [7 Regression] ICE in model_update_limit_points_in_group, at haifa-sched.c:1982 on powerpc64le-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80357 --- Comment #7 from Pat Haugen --- (In reply to Bill Schmidt from comment #6) > That revision enabled -fsched-pressure by default, so it may have been > latent with -fsched-pressure before then. Yes, this is a latent bug in the "model"

[Bug target/80107] ICE in final_scan_insn, at final.c:2964

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80107 Pat Haugen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

  1   2   3   4   >