[Bug target/72827] [7 Regression] gnat bootstrap broken on powerpc64le-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827 --- Comment #11 from Bill Schmidt --- (In reply to Eric Botcazou from comment #8) > > I'm afraid I don't know anything about Ada and how its runtime works; it > > looks like system.secondary_stack.ss_release is called automatically somehow > >

[Bug target/72827] [7 Regression] gnat bootstrap broken on powerpc64le-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827 --- Comment #7 from Bill Schmidt --- It does look possible that this is an LRA issue. Here's the code right before failure: 100dae08: f8 95 22 39 addir9,r2,-27144 100dae0c: 01 00 40 39 li r10,1 100dae10: 00

[Bug target/72827] [7 Regression] gnat bootstrap broken on powerpc64le-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827 --- Comment #6 from Bill Schmidt --- Backtrace info (svn r239837): Program received signal SIGSEGV, Segmentation fault. system.secondary_stack.ss_release (m=...) at ../rts/s-secsta.adb:479 479 To_Stack_Ptr (M.Sstk).Top := M.Sptr;

[Bug target/72827] [7 Regression] gnat bootstrap broken on powerpc64le-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827 --- Comment #2 from Bill Schmidt --- See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77405 which appears to be very similar (slight difference in the error message).

[Bug target/72827] [7 Regression] gnat bootstrap broken on powerpc64le-linux-gnu

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

[Bug ada/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

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

[Bug target/72863] Powerpc64le: redundant swaps when using vec_vsx_ld/st

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

[Bug target/72863] Powerpc64le: redundant swaps when using vec_vsx_ld/st

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72863 --- Comment #8 from Bill Schmidt --- Author: wschmidt Date: Thu Aug 25 16:12:23 2016 New Revision: 239762 URL: https://gcc.gnu.org/viewcvs?rev=239762=gcc=rev Log: [gcc] 2016-08-25 Bill Schmidt Backport

[Bug target/72863] Powerpc64le: redundant swaps when using vec_vsx_ld/st

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72863 --- Comment #7 from Bill Schmidt --- Author: wschmidt Date: Thu Aug 25 14:24:17 2016 New Revision: 239761 URL: https://gcc.gnu.org/viewcvs?rev=239761=gcc=rev Log: [gcc] 2016-08-25 Bill Schmidt Backport

[Bug rtl-optimization/74585] powerpc64: Very poor code generation for homogeneous vector aggregates passed in registers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74585 --- Comment #14 from Bill Schmidt --- (In reply to Richard Biener from comment #13) > > You mean stores like the following? > > (insn 13 12 14 2 (set (mem/c:V4SI (plus:DI (reg/f:DI 150 virtual-stack-vars) > (const_int 112

[Bug rtl-optimization/74585] powerpc64: Very poor code generation for homogeneous vector aggregates passed in registers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74585 --- Comment #12 from Bill Schmidt --- The rest of the ugly code (once you ignore the loads/stores) is horrible choices of register allocation. Need to understand why we're not making use of the high floating-point registers; too much copying

[Bug c++/77034] [6.2RC regression] g++.dg/init/elide5.C fails on powerpc64-unknown-linux-gnu with -m32

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77034 Bill Schmidt changed: What|Removed |Added Target||powerpc64-unknown-linux-gnu

[Bug c++/77034] New: [6.2RC regression] g++.dg/init/elide5.C fails on powerpc64-unknown-linux-gnu with -m32

Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: wschmidt at gcc dot gnu.org Target Milestone: --- Testing the release candidate, I see a regression versus the 6.1 release when compiling the referenced test. From

[Bug rtl-optimization/74585] powerpc64: Very poor code generation for homogeneous vector aggregates passed in registers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74585 --- Comment #11 from Bill Schmidt --- With the original test case, -mcpu=power8 is problematic because of the use of the "swapping stores," whose RHS is a vec_select rather than a register or subreg. This prevents us from saving the RHS of the

[Bug rtl-optimization/63491] Ice in LRA with simple vector test case on power

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63491 --- Comment #16 from Bill Schmidt --- Ping...

[Bug rtl-optimization/74585] powerpc64: Very poor code generation for homogeneous vector aggregates passed in registers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74585 --- Comment #10 from Bill Schmidt --- The dse pass is responsible for removing all the unnecessary stack activity. I think that we are probably confusing it because the stores are full vector stores, but the loads are vector element loads of

[Bug rtl-optimization/74585] powerpc64: Very poor code generation for homogeneous vector aggregates passed in registers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74585 --- Comment #9 from Bill Schmidt --- We do optimize things well for the following: typedef struct { __vector double vx0; __vector double vx1; __vector double vx2; __vector double vx3; } vdoublex8_t; vdoublex8_t test_vecd8_rotate_left

[Bug rtl-optimization/74585] powerpc64: Very poor code generation for homogeneous vector aggregates passed in registers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74585 --- Comment #8 from Bill Schmidt --- FYI, adding -mcpu=power9 to the options makes it much easier to read the RTL, as it gets rid of the extra vector swaps needed for POWER8.

[Bug rtl-optimization/74585] powerpc64: Very poor code generation for homogeneous vector aggregates passed in registers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74585 Bill Schmidt changed: What|Removed |Added Component|tree-optimization |rtl-optimization Summary|SRA

[Bug tree-optimization/74585] SRA forces parameters to memory causing awful code generation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74585 --- Comment #5 from Bill Schmidt --- (In reply to Richard Biener from comment #1) > The issue is not SRA pushing things to memory - it doesn't. The issue is > that in the GIMPLE IL the parameter appears as "memory" as it is an > aggregate type.

[Bug rtl-optimization/72855] Long compile time due to integrity checking during dataflow analysis per loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72855 --- Comment #16 from Bill Schmidt --- Author: wschmidt Date: Thu Aug 11 22:20:41 2016 New Revision: 239395 URL: https://gcc.gnu.org/viewcvs?rev=239395=gcc=rev Log: 2016-08-11 Richard Biener Bill Schmidt

[Bug rtl-optimization/72855] Long compile time due to integrity checking during dataflow analysis per loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72855 --- Comment #15 from Bill Schmidt --- For your patch submission, the testing was done on powerpc64le-unknown-linux-gnu.

[Bug rtl-optimization/72855] Long compile time due to integrity checking during dataflow analysis per loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72855 --- Comment #14 from Bill Schmidt --- Oh, I should have mentioned, it passed bootstrap with no regressions, so the patch LGTM.

[Bug target/72863] Powerpc64le: redundant swaps when using vec_vsx_ld/st

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72863 --- Comment #6 from Bill Schmidt --- Author: wschmidt Date: Thu Aug 11 21:39:49 2016 New Revision: 239394 URL: https://gcc.gnu.org/viewcvs?rev=239394=gcc=rev Log: [gcc] 2016-08-11 Bill Schmidt PR

[Bug tree-optimization/74585] [5/6/7] Tree-sra forces parameters to memory causing awful code generation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74585 Bill Schmidt changed: What|Removed |Added Target||powerpc64*-*-* CC|

[Bug tree-optimization/74585] New: [5/6/7] Tree-sra forces parameters to memory causing awful code generation

: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: wschmidt at gcc dot gnu.org Target Milestone: --- For the PowerPC64 ELF V2 ABI, homogeneous aggregates of vectors (any combination of structs and arrays containing

[Bug rtl-optimization/72855] Long compile time due to integrity checking during dataflow analysis per loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72855 --- Comment #12 from Bill Schmidt --- Last night before I ran out of time, I built a debug compiler on gcc-6-branch, and flag_checking was always 0, and I didn't have the compile time issue. So it appears to be something that only occurs with a

[Bug target/72863] Powerpc64le: redundant swaps when using vec_vsx_ld/st

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72863 --- Comment #5 from Bill Schmidt --- Regstrap passes. I'll prepare the formal patch tomorrow. Thanks for the report!

[Bug target/72863] Powerpc64le: redundant swaps when using vec_vsx_ld/st

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

[Bug rtl-optimization/72855] Long compile time due to integrity checking during dataflow analysis per loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72855 --- Comment #10 from Bill Schmidt --- Some experiments on trunk: - Using Bin's patch, I see compile time reduced to ~14 minutes. - Using Richi's patch, I see compile time reduced to ~9 minutes. So both are quite helpful compared to somewhere

[Bug target/72863] Powerpc64le: redundant swaps when using vec_vsx_ld/st

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72863 --- Comment #3 from Bill Schmidt --- This is a phase ordering issue involving the expanders for the built-ins. In vsx.md: ;; Explicit load/store expanders for the builtin functions (define_expand "vsx_load_" [(set (match_operand:VSX_M 0

[Bug target/72863] Powerpc64le: redundant swaps when using vec_vsx_ld/st

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

[Bug tree-optimization/71815] SLSR misses several PHI candidate cases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71815 --- Comment #9 from Bill Schmidt --- I'm not comfortable with the results of the patch. Overall I see a slight improvement for SPECint CPU2006 and a slightly larger degradation for SPECfp CPU2006. But there are some individual slowdowns that

[Bug rtl-optimization/72855] Long compile time due to integrity checking during dataflow analysis per loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72855 --- Comment #6 from Bill Schmidt --- (In reply to amker from comment #4) > It reduces compile time for powerpc-elf on x86_64 machine from 54m to 5m. > The compiler is configured with checking. With "--enable-checking=release", > the current

[Bug rtl-optimization/72855] Long compile time due to integrity checking during dataflow analysis per loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72855 --- Comment #5 from Bill Schmidt --- (In reply to Richard Biener from comment #2) > If we have release checking enabled then we shuould hit > > static void > df_analyze_1 (void) > { > ... > #ifndef ENABLE_DF_CHECKING > if

[Bug target/72863] Powerpc64le: redundant swaps when using vec_vsx_ld/st

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72863 --- Comment #1 from Bill Schmidt --- Egad. How appalling. I'll have a look soon.

[Bug rtl-optimization/72855] New: Long compile time due to integrity checking during dataflow analysis per loop

: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: wschmidt at gcc dot gnu.org Target Milestone: --- Created attachment 39091 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39091=edit C++ file show

[Bug tree-optimization/71815] SLSR misses several PHI candidate cases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71815 --- Comment #8 from Bill Schmidt --- Created attachment 39085 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39085=edit Patch under test Attaching a patch that passes regstrap. I want to do a little benchmarking before submitting it

[Bug tree-optimization/71815] SLSR misses several PHI candidate cases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71815 --- Comment #7 from Bill Schmidt --- I have a prototype that fixes this in the obvious way and it causes both slsr-35.c and slsr-36.c to pass again without turning off code hoisting. I'll do a regstrap and then work on some benchmark testing.

[Bug tree-optimization/71815] SLSR misses several PHI candidate cases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71815 --- Comment #6 from Bill Schmidt --- Actually, it looks like a similar problem for the unknown stride case. Again there is logic that relies on single-reached-use for determining what expressions go dead. We need to factor in expressions that

[Bug tree-optimization/71815] SLSR misses several PHI candidate cases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71815 --- Comment #5 from Bill Schmidt --- I'll note that in the case where the stride is known (slsr-35.c), SLSR is making at least a somewhat rational decision based on cost not to strength-reduce the phi candidate. In this case the stride is a

[Bug rtl-optimization/69847] Spec 2006 403.gcc slows down with -mlra vs. reload on PowerPC

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69847 --- Comment #17 from Bill Schmidt --- Vlad, the patch checks out very well on powerpc64le. 403.gcc no longer degrades. We are seeing some very nice improvements from LRA over reload on a few benchmarks (435.gromacs leads the way with +9.5%).

[Bug rtl-optimization/69847] Spec 2006 403.gcc slows down with -mlra vs. reload on PowerPC

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69847 --- Comment #16 from Bill Schmidt --- Hi Vlad, I need to re-run my tests one more time because I goofed up the build on a few of them; however, I was able to verify that the degradation on 403.gcc has now gone away (I saw a slight improvement

[Bug rtl-optimization/69847] Spec 2006 403.gcc slows down with -mlra vs. reload on PowerPC

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69847 --- Comment #14 from Bill Schmidt --- Thanks, Vlad! I'll do some benchmarking with this patch in the next few days. Much obliged!

[Bug target/72747] powerpc: wrong code generated for vec_splats in cascading assignment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72747 Bill Schmidt changed: What|Removed |Added Target||powerpc64le-unknown-linux-g

[Bug target/72747] New: powerpc: wrong code generated for vec_splats in cascading assignment

Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: wschmidt at gcc dot gnu.org Target Milestone: --- A statement such as "v = vec_splats (1);" correctly initializes a vector. However, a statement such as "v[1] = v[

[Bug target/72103] ICE with gcc 7 for povray benchmark

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72103 --- Comment #8 from Bill Schmidt --- Per c#3, could we please have another bug opened to track the tragic code generation opportunity? ;)

[Bug tree-optimization/71815] SLSR misses several PHI candidate cases

||2016-07-25 Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Bill Schmidt --- Confirmed. Will have a look soon.

[Bug tree-optimization/71915] A missed opportunity for SLSR

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

[Bug target/71731] incorrect result for vectorized char rotate with -mcpu=power9

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

[Bug target/71805] incorrect code for test pr45752.c with -mcpu=power9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71805 --- Comment #7 from Bill Schmidt --- *** Bug 71731 has been marked as a duplicate of this bug. ***

[Bug target/71297] [7 regression] ICE on invalid code in altivec_resolve_overloaded_builtin (rs6000-c.c:5106) on powerpc64le-linux

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

[Bug target/71297] [7 regression] ICE on invalid code in altivec_resolve_overloaded_builtin (rs6000-c.c:5106) on powerpc64le-linux

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71297 --- Comment #3 from Bill Schmidt --- Author: wschmidt Date: Fri Jul 8 15:42:47 2016 New Revision: 238168 URL: https://gcc.gnu.org/viewcvs?rev=238168=gcc=rev Log: [gcc] 2016-07-08 Bill Schmidt PR

[Bug tree-optimization/71815] SLSR misses several PHI candidate cases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71815 --- Comment #3 from Bill Schmidt --- OK. I'm busy wrapping up some things before a vacation, but I'll plan to look into this when I get back.

[Bug tree-optimization/71815] SLSR misses several PHI candidate cases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71815 --- Comment #1 from Bill Schmidt --- Interesting. How do we enable/disable code hoisting? I don't see a documented option for this.

[Bug target/71297] [7 regression] ICE on invalid code in altivec_resolve_overloaded_builtin (rs6000-c.c:5106) on powerpc64le-linux

||2016-07-07 Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot gnu.org Summary|ICE on invalid code in |[7 regression] ICE on |altivec_resolve_overloaded_ |invalid code in |builtin (rs6000-c.c:5106

[Bug target/71201] PowerPC XXPERM instruction fails on ISA 3.0 system.

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

[Bug target/71297] ICE on invalid code in altivec_resolve_overloaded_builtin (rs6000-c.c:5106) on powerpc64le-linux

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

[Bug target/71722] incorrect code for test pr64252.c for -mcpu=power9 -mpower9-vector -ftree-vectorize -O3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71722 --- Comment #4 from Bill Schmidt --- Another possibility is all the vperm instructions, as this is little endian and we might expect to see vpermr on occasion. That's hard to tell without digging deeper.

[Bug target/71722] incorrect code for test pr64252.c for -mcpu=power9 -mpower9-vector -ftree-vectorize -O3

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

[Bug target/71294] [6/7 Regression] ICE in gen_add2_insn, at optabs.c:4442 on powerpc64le-linux

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71294 --- Comment #8 from Bill Schmidt --- Just recording that this patch was rejected on the list at https://gcc.gnu.org/ml/gcc-patches/2016-05/msg02136.html, so we still need a fix for this.

[Bug target/71648] C++ ICE on ppc64 with -m64

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

[Bug target/70957] testsuite/gcc.target/powerpc/vsx-elemrev-4.c fails on power7

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

[Bug target/70957] testsuite/gcc.target/powerpc/vsx-elemrev-4.c fails on power7

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70957 --- Comment #13 from Bill Schmidt --- Author: wschmidt Date: Fri Jun 3 13:18:25 2016 New Revision: 237067 URL: https://gcc.gnu.org/viewcvs?rev=237067=gcc=rev Log: 2016-06-03 Bill Schmidt PR target/70957

[Bug target/70957] testsuite/gcc.target/powerpc/vsx-elemrev-4.c fails on power7

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70957 --- Comment #12 from Bill Schmidt --- Author: wschmidt Date: Fri Jun 3 13:14:26 2016 New Revision: 237066 URL: https://gcc.gnu.org/viewcvs?rev=237066=gcc=rev Log: 2016-06-03 Bill Schmidt PR target/70957

[Bug target/71390] PowerPC GCC should warn if use does -mcpu=, and an old assembler was used

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

[Bug target/70957] testsuite/gcc.target/powerpc/vsx-elemrev-4.c fails on power7

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70957 --- Comment #11 from Bill Schmidt --- OK, I've traced this down to its sordid origins. The problem arises when the test case is run on a machine using an old target assembler. If the assembler doesn't support POWER8 instructions, this causes

[Bug target/70957] testsuite/gcc.target/powerpc/vsx-elemrev-4.c fails on power7

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

[Bug rtl-optimization/71309] Copying fields within a struct followed by use results in load hit store

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

[Bug tree-optimization/71050] [7 regression] test case gcc.target/powerpc/lhs-1.c fails starting with r236066

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71050 --- Comment #10 from Bill Schmidt --- Great, thanks, Pat! Let's hold off for now, as Segher is checking out some ideas.

[Bug tree-optimization/71050] [7 regression] test case gcc.target/powerpc/lhs-1.c fails starting with r236066

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71050 --- Comment #8 from Bill Schmidt --- Even this test case isn't truly horrible for real-world code (it looks nastier than it is, as stack stores tend to have minimal real cost). This is an issue only on "older" processors; it's just that a lot

[Bug tree-optimization/71050] [7 regression] test case gcc.target/powerpc/lhs-1.c fails starting with r236066

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71050 --- Comment #6 from Bill Schmidt --- Yes, I see your point -- even if you query the RTX cost of the subreg, we're just going to tell you it's one insn since the true expense doesn't show up until reload. Seems like some invention will be

[Bug middle-end/44382] Slow integer multiply

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

[Bug rtl-optimization/70825] x86_64: __atomic_compare_exchange_n() accesses stack unnecessarily

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70825 Bill Schmidt changed: What|Removed |Added Target|x86_64, aarch64 |x86_64, aarch64, powerpc64* --- Comment

[Bug tree-optimization/71050] [7 regression] test case gcc.target/powerpc/lhs-1.c fails starting with r236066

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71050 --- Comment #3 from Bill Schmidt --- Sorry, accidentally saved before finishing my thoughts. How do we "inform" the middle-end that a DI subreg of a DF is very expensive? This differs wildly by processor for us. We "can" always do the subreg,

[Bug tree-optimization/71050] [7 regression] test case gcc.target/powerpc/lhs-1.c fails starting with r236066

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71050 Bill Schmidt changed: What|Removed |Added CC||dje at gcc dot gnu.org,

[Bug middle-end/44382] Slow integer multiply

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44382 --- Comment #12 from Bill Schmidt --- I'd propose that this bug can now be closed. If nobody objects, I'll do that later this week.

[Bug target/70963] vec_cts/vec_ctf intrinsics produce wrong results for 64-bit floating point

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

[Bug target/70963] vec_cts/vec_ctf intrinsics produce wrong results for 64-bit floating point

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70963 --- Comment #9 from Bill Schmidt --- Author: wschmidt Date: Tue May 10 17:24:32 2016 New Revision: 236097 URL: https://gcc.gnu.org/viewcvs?rev=236097=gcc=rev Log: [gcc] 2016-05-10 Bill Schmidt Backport

[Bug target/70963] vec_cts/vec_ctf intrinsics produce wrong results for 64-bit floating point

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70963 --- Comment #8 from Bill Schmidt --- Author: wschmidt Date: Tue May 10 16:09:28 2016 New Revision: 236091 URL: https://gcc.gnu.org/viewcvs?rev=236091=gcc=rev Log: [gcc] 2016-05-10 Bill Schmidt Backport

[Bug target/70963] vec_cts/vec_ctf intrinsics produce wrong results for 64-bit floating point

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70963 --- Comment #7 from Bill Schmidt --- Author: wschmidt Date: Tue May 10 16:07:04 2016 New Revision: 236089 URL: https://gcc.gnu.org/viewcvs?rev=236089=gcc=rev Log: [gcc] 2016-05-10 Bill Schmidt Backport

[Bug target/70963] vec_cts/vec_ctf intrinsics produce wrong results for 64-bit floating point

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70963 --- Comment #6 from Bill Schmidt --- Author: wschmidt Date: Tue May 10 14:27:12 2016 New Revision: 236082 URL: https://gcc.gnu.org/viewcvs?rev=236082=gcc=rev Log: [gcc] 2016-05-10 Bill Schmidt PR

[Bug target/70963] vec_cts/vec_ctf intrinsics produce wrong results for 64-bit floating point

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70963 --- Comment #4 from Bill Schmidt --- OK, there is an obvious bug in the define_expand for vsx_xvcvdpsxds_scale. If the scale factor is 0, wrong code is always generated. I'll get a patch going.

[Bug target/70963] vec_cts/vec_ctf intrinsics produce wrong results for 64-bit floating point

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70963 --- Comment #3 from Bill Schmidt --- Note also that your asm constraints are wrong. You need VSX registers, not Altivec registers, so you should be using the "wa" constraint instead of the "v" constraint. This is why you get some apparently

[Bug target/70963] vec_cts/vec_ctf intrinsics produce wrong results for 64-bit floating point

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70963 --- Comment #2 from Bill Schmidt --- The xxswapd's are a bit of a red herring. These are part of the little-endian normalization code that are required with the funky lxvd2x and stxvd2x instructions. The problem appears to be the register

[Bug target/70957] testsuite/gcc.target/powerpc/vsx-elemrev-4.c fails on power7

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70957 --- Comment #8 from Bill Schmidt --- Looks like it also did not fail in the latest gcc-testresults Power7 BE run. Going to stop looking at this unless/until it shows up again.

[Bug target/70957] testsuite/gcc.target/powerpc/vsx-elemrev-4.c fails on power7

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

[Bug target/70957] testsuite/gcc.target/powerpc/vsx-elemrev-4.c fails on power7

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70957 --- Comment #6 from Bill Schmidt --- The test also passed on P7 at the time I committed the patch.

[Bug target/70957] testsuite/gcc.target/powerpc/vsx-elemrev-4.c fails on power7

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70957 --- Comment #5 from Bill Schmidt --- I applied the same patch to gcc-6-branch, and the test works correctly on a Power7 machine. Thus we appear to be exposing a recent problem introduced on trunk. I'll try to bisect this.

[Bug target/70957] testsuite/gcc.target/powerpc/vsx-elemrev-4.c fails on power7

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70957 --- Comment #4 from Bill Schmidt --- The other odd thing is that we fail only on the signed and unsigned long long cases, and all of the other variants work.

[Bug target/70957] testsuite/gcc.target/powerpc/vsx-elemrev-4.c fails on power7

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70957 --- Comment #3 from Bill Schmidt --- Configuration for the two compilers used: $GCC_SRC/configure --enable-__cxa_atexit --enable-languages=c,c++,fortran,objc,obj-c++,go --with-cpu=power7 --disable-libsanitizer

[Bug target/70957] testsuite/gcc.target/powerpc/vsx-elemrev-4.c fails on power7

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

[Bug target/70957] testsuite/gcc.target/powerpc/vsx-elemrev-4.c fails on power7

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

[Bug target/70928] Load simple float constants via VSX operations on PowerPC

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70928 --- Comment #1 from Bill Schmidt --- Short sequences for the rest of -32 to 31 are possible also. The splats can be done as follows. x even, x in [-32,-18] U [16,30]: vspltis[bhw] t, x vaddu[bhw]m y, t, t x odd, x in [17,31]:

[Bug rtl-optimization/70826] [7 regression] many test cases fail starting with r235442

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70826 --- Comment #2 from Bill Schmidt --- I don't know the register-renames code at all -- does it update debug information when it replaces registers? Sounds like gdb is getting stale results for which register represents a memory value.

[Bug target/70098] PowerPC64: eigen hits ICE following invalid register assignment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70098 --- Comment #11 from Bill Schmidt --- Author: wschmidt Date: Mon Apr 25 22:29:49 2016 New Revision: 235424 URL: https://gcc.gnu.org/viewcvs?rev=235424=gcc=rev Log: [gcc] 2016-04-25 Bill Schmidt Backport

[Bug target/70098] PowerPC64: eigen hits ICE following invalid register assignment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70098 --- Comment #10 from Bill Schmidt --- Author: wschmidt Date: Mon Apr 25 22:28:36 2016 New Revision: 235423 URL: https://gcc.gnu.org/viewcvs?rev=235423=gcc=rev Log: [gcc] 2016-04-25 Bill Schmidt Backport

[Bug target/70098] PowerPC64: eigen hits ICE following invalid register assignment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70098 Bill Schmidt changed: What|Removed |Added CC||markos at freevec dot org --- Comment #9

[Bug rtl-optimization/70761] C++ ICE on ppc64le and ppc64 with -m64

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

[Bug target/70672] New: [5] Wrong code for little endian bitfield modification

Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: wschmidt at gcc dot gnu.org CC: dje at gcc dot gnu.org, segher at gcc dot gnu.org Target Milestone: --- Target: powerpc64le-unknown-linux-gnu

<    5   6   7   8   9   10   11   12   13   14   >