[Bug target/87064] [9 regression] libgomp.oacc-fortran/reduction-3.f90 fails starting with r263751

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87064 --- Comment #21 from Bill Schmidt --- We should probably disable the _v4sf_scalar one for LE also, as this seems to be doing a similar trick for V4SF.

[Bug target/87064] [9 regression] libgomp.oacc-fortran/reduction-3.f90 fails starting with r263751

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87064 --- Comment #20 from Bill Schmidt --- Oh, sorry, I missed that in all the commentary. I had looked at the code and seen the "obvious" problem in the expansion, and noted you had suggested that also. Should have read further. I think that's

[Bug target/87064] [9 regression] libgomp.oacc-fortran/reduction-3.f90 fails starting with r263751

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87064 --- Comment #17 from Bill Schmidt --- Actually I *think* the *vsx_reduc__v4sf_scalar code is probably okay. This is all being done with insns that should leave the reduction result in the right-hand element of the register (element 3 for BE, as

[Bug target/87064] [9 regression] libgomp.oacc-fortran/reduction-3.f90 fails starting with r263751

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87064 --- Comment #16 from Bill Schmidt --- (In reply to Jakub Jelinek from comment #13) > So, both the following patches should fix it IMHO, but no idea which one if > any is right. > With > --- gcc/config/rs6000/vsx.md.jj 2019-01-01

[Bug target/88877] rs6000 emits signed extension for unsigned int type(__floatunsidf).

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877 Bill Schmidt changed: What|Removed |Added CC||wschmidt at gcc dot gnu.org --- Comment

[Bug target/88877] rs6000 emits signed extension for unsigned int type(__floatunsidf).

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877 --- Comment #4 from Bill Schmidt --- "Values shorter than 32 bits are sign-extended or zero-extended, depending on whether they are signed or unsigned." Source:

[Bug tree-optimization/88767] 'unroll and jam' not optimizing some loops

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88767 --- Comment #7 from Bill Schmidt --- (In reply to Michael Matz from comment #3) > I don't see anything to improve either (as far as unroll-and-jam is > concerned). > It's quite possible that cunrolli is harming more than helping in this case, >

[Bug tree-optimization/88767] 'unroll and jam' not optimizing some loops

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88767 --- Comment #6 from Bill Schmidt --- Yes, we don't want to encourage disabling cunrolli by hand for production use. This test case is interesting because it shows a tension between complete unrolling of inner loops and classical HPC loop

[Bug tree-optimization/88767] 'unroll and jam' not optimizing some loops

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88767 --- Comment #5 from Bill Schmidt --- From the original reporter: Partially unrolling the outermost loop in the innermost loop body enables data reuse for array A (see source) thereby improving the mem-ops/compute ratio and providing the

[Bug tree-optimization/88767] 'unroll and jam' not optimizing some loops

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88767 Bill Schmidt changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever confirmed|1

[Bug tree-optimization/86020] [8/9 Regression] Performance regression in Eigen geometry.cpp test starting with r248334

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86020 --- Comment #7 from Bill Schmidt --- Thanks! I've asked our performance team to re-measure with this change.

[Bug libgomp/87064] [9 regression] libgomp.oacc-fortran/reduction-3.f90 fails starting with r263751

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87064 --- Comment #10 from Bill Schmidt --- Yes. See, for example, https://gcc.gnu.org/ml/gcc-testresults/2018-12/msg02508.html.

[Bug libgomp/87064] [9 regression] libgomp.oacc-fortran/reduction-3.f90 fails starting with r263751

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87064 Bill Schmidt changed: What|Removed |Added Status|WAITING |NEW

[Bug target/88497] Improve Accumulation in Auto-Vectorized Code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88497 --- Comment #6 from Bill Schmidt --- Reassociation width should be 4 for this case per the target hook. Kelvin, you can experiment with rs6000_reassociation_width to see if larger values give you what you expect.

[Bug middle-end/88497] Improve Accumulation in Auto-Vectorized Code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88497 --- Comment #4 from Bill Schmidt --- Yes, reassociation sounds like the right place to look at this.

[Bug testsuite/85326] `make check` fails with `--disable-bootstrap` and `--enable-languages=c`

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85326 --- Comment #11 from Bill Schmidt --- Nothing further from the Power side...

[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 86424, which changed state. Bug 86424 Summary: Milc is slower on PowerPC using -ffast-math than without using -ffast-math https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86424 What|Removed

[Bug target/86424] Milc is slower on PowerPC using -ffast-math than without using -ffast-math

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86424 Bill Schmidt changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug target/86423] Omnetpp is slower on PowerPC using -ffast-math than not using -ffast-math

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86423 Bill Schmidt changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[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 86423, which changed state. Bug 86423 Summary: Omnetpp is slower on PowerPC using -ffast-math than not using -ffast-math https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86423 What|Removed

[Bug target/87949] PowerPC saves CR registers across calls

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87949 --- Comment #4 from Bill Schmidt --- Seems like a potential opportunity for shrink-wrap separate on the CRs. I'm not sure whether that's implemented yet.

[Bug tree-optimization/87473] [7/8/9 Regression] ICE in create_add_on_incoming_edge, at gimple-ssa-strength-reduction.c:2344

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87473 --- Comment #9 from Bill Schmidt --- Author: wschmidt Date: Fri Oct 26 19:38:45 2018 New Revision: 265547 URL: https://gcc.gnu.org/viewcvs?rev=265547=gcc=rev Log: [gcc] 2018-10-26 Bill Schmidt Backport from mainline

[Bug tree-optimization/87473] [7/8/9 Regression] ICE in create_add_on_incoming_edge, at gimple-ssa-strength-reduction.c:2344

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87473 --- Comment #8 from Bill Schmidt --- Author: wschmidt Date: Fri Oct 26 18:50:51 2018 New Revision: 265543 URL: https://gcc.gnu.org/viewcvs?rev=265543=gcc=rev Log: [gcc] 2018-10-26 Bill Schmidt Backport from mainline

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103 --- Comment #12 from Bill Schmidt --- Does this qualify as a P2 bug? This is a serious degradation not only on P7 but also P8 and P9.

[Bug tree-optimization/87473] [7/8/9 Regression] ICE in create_add_on_incoming_edge, at gimple-ssa-strength-reduction.c:2344

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87473 --- Comment #7 from Bill Schmidt --- Fixed for trunk. Backports coming next week.

[Bug tree-optimization/87473] [7/8/9 Regression] ICE in create_add_on_incoming_edge, at gimple-ssa-strength-reduction.c:2344

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87473 --- Comment #6 from Bill Schmidt --- Author: wschmidt Date: Fri Oct 19 18:28:11 2018 New Revision: 265319 URL: https://gcc.gnu.org/viewcvs?rev=265319=gcc=rev Log: [gcc] 2018-10-19 Bill Schmidt PR tree-optimization/87473 *

[Bug tree-optimization/87473] [7/8/9 Regression] ICE in create_add_on_incoming_edge, at gimple-ssa-strength-reduction.c:2344

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87473 --- Comment #5 from Bill Schmidt --- Introduced by 136t.loopinit, still around at 172t.slsr: [local count: 14598063]: # qz_1 = PHI # jl_22 = PHI _8 = (unsigned int) jl_22; _13 = _8 * _15; qz_11 = (int) _13; Looking through

[Bug tree-optimization/87473] [7/8/9 Regression] ICE in create_add_on_incoming_edge, at gimple-ssa-strength-reduction.c:2344

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87473 --- Comment #4 from Bill Schmidt --- I have a patch under test now. This is not related, but I noticed that the problem would not have been exposed except for the code coming in to the SLSR patch containing a degenerate PHI with only one

[Bug target/86592] [9 regression] gcc.target/powerpc/p8-vec-xl-xst-v2.c fails starting with r261510

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86592 Bill Schmidt changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug tree-optimization/87473] [7/8/9 Regression] ICE in create_add_on_incoming_edge, at gimple-ssa-strength-reduction.c:2344

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87473 --- Comment #3 from Bill Schmidt --- Reproduces on trunk for powerpc64le-linux-gnu also.

[Bug tree-optimization/87473] [7/8/9 Regression] ICE in create_add_on_incoming_edge, at gimple-ssa-strength-reduction.c:2344

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87473 Bill Schmidt changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot gnu.org

[Bug c++/87289] jdk11 plinux compiled with gcc 7.3 doesn't work with NativeImageBuffer

, ||wschmidt at gcc dot gnu.org --- Comment #1 from Bill Schmidt --- Please see https://gcc.gnu.org/bugs/ for how to submit a bug report. Specifically, we need "the preprocessed file (*.i*) that triggers the bug, generated by adding -save-temps to the com

[Bug middle-end/87157] [9 regression] gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c fails starting with r263981

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87157 --- Comment #7 from Bill Schmidt --- OK, that makes sense. And I verified that r263981 does indeed introduce the extra functions. Thanks for looking into it!

[Bug middle-end/87157] [9 regression] gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c fails starting with r263981

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87157 --- Comment #5 from Bill Schmidt --- So, the test case compiled with r264043 produces 3 functions: main1.part.0, main1, and main. The test case compiled with r263980 produces only 1 function (main). The loop is vectorized in both main and

[Bug middle-end/87157] [9 regression] gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c fails starting with r263981

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87157 --- Comment #4 from Bill Schmidt --- Created attachment 44649 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44649=edit vect details dump for r264043 Here's the requested dump information.

[Bug middle-end/87157] [9 regression] gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c fails starting with r263981

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87157 --- Comment #3 from Bill Schmidt --- I don't have a recently built gcc lying around, but from an earlier version, here's the command line from the testsuite log: /home/wschmidt/gcc/build/gccgit-test/gcc/xgcc

[Bug testsuite/87157] [9 regression] gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c fails starting with r263981

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87157 --- Comment #1 from Bill Schmidt --- I doubt the test cases need updating. Looks like this change had a surprising side of effect of breaking vectorization for this test on Power, which needs to be understood and fixed.

[Bug middle-end/86554] [7/8/9 Regression] Incorrect code generation with signed/unsigned comparison

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86554 --- Comment #6 from Bill Schmidt --- Anton has been able to work around the problem with a source change (this code is unnecessarily baroque anyway), so I don't think anybody is urgently awaiting a fix. If this will be fixed in your eventual

[Bug middle-end/86554] Incorrect code generation with signed/unsigned comparison

||2018-07-17 CC||wschmidt at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Bill Schmidt --- Confirmed.

[Bug target/84266] mmintrin.h intrinsic headers for PowerPC code fails on power9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84266 --- Comment #12 from Bill Schmidt --- Author: wschmidt Date: Sun Jul 15 18:04:00 2018 New Revision: 262670 URL: https://gcc.gnu.org/viewcvs?rev=262670=gcc=rev Log: [gcc] 2018-07-15 Bill Schmidt Backport from mainline

[Bug target/85894] PPC64LE alloca stack slot allocation allows memset to destroy the stack

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85894 Bill Schmidt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86367 --- Comment #8 from Bill Schmidt --- That makes sense -- we already have a NaN rather than an SNaN by the time we hit the Ealias pass.

[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86367 Bill Schmidt changed: What|Removed |Added Keywords||wrong-code Target|

[Bug target/86197] POWERPC: float128 parameter passing

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86197 --- Comment #1 from Bill Schmidt --- Note, this is restricted to powerpc64le using ELFv2 ABI.

[Bug target/86197] POWERPC: float128 parameter passing

, ||segher at gcc dot gnu.org, ||wschmidt at gcc dot gnu.org Target Milestone|--- |8.2

[Bug rtl-optimization/63281] powerpc64le creates 64 bit constants from scratch instead of loading them

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281 --- Comment #9 from Bill Schmidt --- Also reported by Donald Stence this week: The compiler produces excessive sequences to synthesize some literal constants. This contributes excess path length and potentially latency. Constants requiring only

[Bug tree-optimization/85712] [8/9 Regression] ICE in all_phi_incrs_profitable_1 at gcc/gimple-ssa-strength-reduction.c:3479

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85712 Bill Schmidt changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug tree-optimization/85712] [8/9 Regression] ICE in all_phi_incrs_profitable_1 at gcc/gimple-ssa-strength-reduction.c:3479

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85712 --- Comment #10 from Bill Schmidt --- Author: wschmidt Date: Fri Jun 1 13:00:57 2018 New Revision: 261067 URL: https://gcc.gnu.org/viewcvs?rev=261067=gcc=rev Log: 2018-06-01 Bill Schmidt PR tree-optimization/85712 Backport

[Bug tree-optimization/85712] [8/9 Regression] ICE in all_phi_incrs_profitable_1 at gcc/gimple-ssa-strength-reduction.c:3479

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85712 --- Comment #9 from Bill Schmidt --- Author: wschmidt Date: Fri Jun 1 12:57:16 2018 New Revision: 261066 URL: https://gcc.gnu.org/viewcvs?rev=261066=gcc=rev Log: 2018-06-01 Bill Schmidt PR tree-optimization/85712 Backport

[Bug tree-optimization/85712] [8/9 Regression] ICE in all_phi_incrs_profitable_1 at gcc/gimple-ssa-strength-reduction.c:3479

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85712 --- Comment #8 from Bill Schmidt --- Author: wschmidt Date: Fri Jun 1 12:55:06 2018 New Revision: 261065 URL: https://gcc.gnu.org/viewcvs?rev=261065=gcc=rev Log: 2018-06-01 Bill Schmidt PR tree-optimization/85712 Backport

[Bug tree-optimization/86020] Performance regression in Eigen geometry.cpp test starting with r248334

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86020 Bill Schmidt changed: What|Removed |Added Keywords||missed-optimization Target|

[Bug tree-optimization/86020] Performance regression in Eigen geometry.cpp test starting with r248334

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86020 --- Comment #1 from Bill Schmidt --- Created attachment 44220 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44220=edit Source file that shows the problem

[Bug tree-optimization/86020] New: Performance regression in Eigen geometry.cpp test starting with r248333

Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: wschmidt at gcc dot gnu.org Target Milestone: --- GCC 8.1 has regressed by about 30% compared with GCC 7.3 on one of the Eigen test cases when measured on Power9

[Bug tree-optimization/85712] [8/9 Regression] ICE in all_phi_incrs_profitable_1 at gcc/gimple-ssa-strength-reduction.c:3479

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85712 --- Comment #7 from Bill Schmidt --- Patch from c#6 corrects a problem discovered when backporting to GCC 6. With the two patches, no regressions are seen in trunk, 8, 7, or 6.

[Bug tree-optimization/85712] [8/9 Regression] ICE in all_phi_incrs_profitable_1 at gcc/gimple-ssa-strength-reduction.c:3479

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85712 --- Comment #6 from Bill Schmidt --- Author: wschmidt Date: Fri May 25 19:12:16 2018 New Revision: 260772 URL: https://gcc.gnu.org/viewcvs?rev=260772=gcc=rev Log: 2018-05-25 Bill Schmidt PR

[Bug target/85894] PPC64LE alloca stack slot allocation allows memset to destroy the stack

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85894 Bill Schmidt changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug tree-optimization/85712] [8/9 Regression] ICE in all_phi_incrs_profitable_1 at gcc/gimple-ssa-strength-reduction.c:3479

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85712 Bill Schmidt changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #5 from Bill

[Bug tree-optimization/85712] [8/9 Regression] ICE in all_phi_incrs_profitable_1 at gcc/gimple-ssa-strength-reduction.c:3479

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85712 --- Comment #4 from Bill Schmidt --- Proposed patch here: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01183.html

[Bug tree-optimization/85712] [8/9 Regression] ICE in all_phi_incrs_profitable_1 at gcc/gimple-ssa-strength-reduction.c:3479

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85712 --- Comment #3 from Bill Schmidt --- There are six vulnerabilities like this in the SLSR code: replace_mult_candidate (2) replace_rhs_if_not_dup (1) replace_one_candidate (3) I'll work on a fix.

[Bug target/85216] Performance issue with PHP on ppc64 systems

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85216 --- Comment #18 from Bill Schmidt --- I asked around a bit. On x86, user-user attacks are not mitigated by default. To enable user-user mitigation: echo 2 > /sys/kernel/debug/x86/ibrs_enabled My source tells me: 8<--- Red Hat

[Bug target/85216] Performance issue with PHP on ppc64 systems

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85216 --- Comment #17 from Bill Schmidt --- OK, thanks! I'd be very interested in hearing what you discover.

[Bug target/85216] Performance issue with PHP on ppc64 systems

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85216 --- Comment #15 from Bill Schmidt --- PHP's reliance on frequent indirect branches makes it essentially the worst case for this sort of thing. When Spectre v2 CVE mitigations are in place for user code, you will see performance issues on all

[Bug target/85216] Performance issue with PHP on ppc64 systems

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85216 --- Comment #13 from Bill Schmidt --- This was prototyped and measured against the firmware fixes with indistinguishable results. So the complexity of a software solution, with its impacts on Linux distributions, was not warranted. (That is,

[Bug tree-optimization/85712] [8/9 Regression] ICE in all_phi_incrs_profitable_1 at gcc/gimple-ssa-strength-reduction.c:3479

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85712 Bill Schmidt changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot gnu.org

[Bug target/85198] long long int vector mistaken as long int vector

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85198 --- Comment #5 from Bill Schmidt --- OK, I see Jakub's point now. And this whole business is a big mess -- probably too late to change in 8, but we need to clean this up.

[Bug target/85198] long long int vector mistaken as long int vector

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85198 --- Comment #4 from Bill Schmidt --- Ah, but vulli does have the wrong element type, when you get a little deeper. V2DI size unit-size align:128 warn_if_not_align:0 symtab:0 alias-set -1

[Bug target/85198] long long int vector mistaken as long int vector

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85198 Bill Schmidt changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug target/85424] The __builtin_packlongdouble function might have issues with the output overlapping the inputs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85424 Bill Schmidt changed: What|Removed |Added Target Milestone|--- |7.4

[Bug target/85080] [8 regression] gcc.dg/vect/costmodel/ppc/costmodel-pr37194.c fails starting with r248678

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85080 Bill Schmidt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug target/85080] [8 regression] gcc.dg/vect/costmodel/ppc/costmodel-pr37194.c fails starting with r248678

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85080 --- Comment #5 from Bill Schmidt --- Author: wschmidt Date: Mon Apr 16 18:18:42 2018 New Revision: 259407 URL: https://gcc.gnu.org/viewcvs?rev=259407=gcc=rev Log: [gcc/testsuite] 2018-04-16 Bill Schmidt PR

[Bug testsuite/85326] `make check` fails with `--disable-bootstrap` and `--enable-languages=c`

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85326 --- Comment #5 from Bill Schmidt --- Author: wschmidt Date: Mon Apr 16 02:00:43 2018 New Revision: 259393 URL: https://gcc.gnu.org/viewcvs?rev=259393=gcc=rev Log: [gcc/testsuite] 2018-04-15 Bill Schmidt PR

[Bug target/85080] [8 regression] gcc.dg/vect/costmodel/ppc/costmodel-pr37194.c fails starting with r248678

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85080 Bill Schmidt changed: What|Removed |Added Status|WAITING |NEW

[Bug target/85080] [8 regression] gcc.dg/vect/costmodel/ppc/costmodel-pr37194.c fails starting with r248678

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85080 --- Comment #4 from Bill Schmidt --- _Set8 wasn't supposed to be profitable before -- but this is an old test, predating reasonable unaligned storage accesses with Power8 and later. We should have vectorized both loops as soon as that came

[Bug target/85080] [8 regression] gcc.dg/vect/costmodel/ppc/costmodel-pr37194.c fails starting with r248678

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85080 --- Comment #3 from Bill Schmidt --- I'll see if I can make time to look at this one soon. I suspect the new peeling costs check from Robin just made this test invalid.

[Bug target/85216] Performance issue with PHP on ppc64 systems

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85216 --- Comment #11 from Bill Schmidt --- (In reply to Timothy Pearson from comment #10) > > It's even slow compared to P8 with mitigations applied. Do you have a link > to the hostboot commit that may have enabled the P9 mitigation, or to the >

[Bug target/83402] PPC64 implementation of ./rs6000/emmintrin.h gives out of range for _mm_slli_epi32

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83402 --- Comment #11 from Bill Schmidt --- Conclusion is that we still need a fix to emmintrin.h along the lines of Steve's original two comments. Additionally, we need to fix trunk to complain about the out of range value, rather than quietly

[Bug target/85216] Performance issue with PHP on ppc64 systems

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85216 --- Comment #9 from Bill Schmidt --- You mentioned you're on a POWER9 machine. It could be that you have firmware with Spectre mitigations applied, which will affect all indirect branches. It may be that you do not have Spectre mitigations

[Bug rtl-optimization/80791] [8 regression] test case gcc.dg/sms-1.c fail2 starting with r247885

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80791 --- Comment #18 from Bill Schmidt --- In the before case, it appears that later optimization is able to remove the i_12 add by adjusting the loop counter. After ivopts: i_12 = i_5 + 4; ivtmp.10_17 = ivtmp.10_18 + 32; Before SMS: r174 =

[Bug rtl-optimization/80791] [8 regression] test case gcc.dg/sms-1.c fail2 starting with r247885

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80791 --- Comment #17 from Bill Schmidt --- Sure. My point is that the modeling that's being done doesn't accurately predict the actual loop performance. What we need to do is figure out why.

[Bug rtl-optimization/80791] [8 regression] test case gcc.dg/sms-1.c fail2 starting with r247885

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80791 --- Comment #15 from Bill Schmidt --- It's a bit shift, but the result is still that it is now in the loop instead of outside the loop, and the total cost of the loop has increased.

[Bug target/83964] [8 Regression] ICE in extract_insn, at recog.c:2304

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83964 --- Comment #14 from Bill Schmidt --- The functions are broken, and a release is imminent. This will be revisited in the next release, and backports considered at least for Advance Toolchain. Time and resources are finite...

[Bug target/67297] PowerPC does not support all vector interfaces from the ELFv2 1.1 ABI

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67297 Bill Schmidt changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug rtl-optimization/80791] [8 regression] test case gcc.dg/sms-1.c fail2 starting with r247885

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80791 --- Comment #13 from Bill Schmidt --- Actually it appears that the IVOPTS change results in worse code going into SMS, regardless of whether SMS can succeed on the loop. It comes down to the fact that IVOPTS formerly pulled a multiply

[Bug rtl-optimization/80791] [8 regression] test case gcc.dg/sms-1.c fail2 starting with r247885

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80791 --- Comment #12 from Bill Schmidt --- It's not clear yet what we should do with this. It looks like SMS is able to figure out that the sign-extension is not needed in the pre-r247885 code, but can't sort this out with the IVOPTS change. The

[Bug target/78263] Compile failure with AltiVec library on PPC64le and -std=c++11 flag

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78263 --- Comment #7 from Bill Schmidt --- Yes, unfortunately we did not get to this yet. Thanks.

[Bug target/84907] [8 Regression] ppc64le gromacs miscompilation since r256656

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84907 Bill Schmidt changed: What|Removed |Added CC||wschmidt at gcc dot gnu.org --- Comment

[Bug rtl-optimization/84753] GCC does not fold xxswapd followed by vperm

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84753 --- Comment #8 from Bill Schmidt --- Looks like Peter was able to help you on the binutils forum over the weekend. Thanks, Peter!

[Bug target/84760] Finish implementation of __builtin_altivec_lvx_v1ti

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84760 Bill Schmidt changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug rtl-optimization/84753] GCC does not fold xxswapd followed by vperm

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84753 Bill Schmidt changed: What|Removed |Added Target Milestone|--- |9.0

[Bug rtl-optimization/84753] GCC does not fold xxswapd followed by vperm

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84753 Bill Schmidt changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug target/84760] Finish implementation of __builtin_altivec_lvx_v1ti

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84760 --- Comment #1 from Bill Schmidt --- Hm. For this one I think I would recommend we just remove the partial implementation, provided that vec_ld already supports vector __int128.

[Bug rtl-optimization/84753] GCC does not fold xxswapd followed by vperm

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84753 --- Comment #5 from Bill Schmidt --- s/this loop/this function

[Bug rtl-optimization/84753] GCC does not fold xxswapd followed by vperm

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84753 Bill Schmidt changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID

[Bug rtl-optimization/84753] GCC does not fold xxswapd followed by vperm

||wschmidt at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Bill Schmidt --- GCC 4.8.5 is out of service. This is fixed in all in-service versions of GCC (6.4 and later).

[Bug target/81594] Optimize PowerPC vector set and store

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81594 --- Comment #2 from Bill Schmidt --- What's the status of this one?

[Bug debug/83758] ICE building gccgo on powerpc64le --with-cpu=power8

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758 --- Comment #33 from Bill Schmidt --- Does this need to be reopened for backports?

[Bug target/84266] mmintrin.h intrinsic headers for PowerPC code fails on power9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84266 --- Comment #6 from Bill Schmidt --- (In reply to Steven Munroe from comment #4) > BTW is there a P9 in the GCC compile farm yet? Sadly, not yet. We can do testing on your behalf until we can get a system out there.

[Bug target/84154] [7/8 Regression] PowerPC GCC 7 and 8 have regression in converting fp to short/char and returning it

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84154 --- Comment #5 from Bill Schmidt --- Does this still need a 7 backport?

[Bug tree-optimization/81038] [8 regression] test case g++.dg/vect/slp-pr56812.cc fails starting with r248678

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81038 Bill Schmidt changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug target/84266] mmintrin.h intrinsic headers for PowerPC code fails on power9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84266 --- Comment #2 from Bill Schmidt --- I wonder how many failures are left if that invalid cast is removed from the code? It is just wrong and unnecessary.

<    1   2   3   4   5   6   7   8   9   10   >