[Bug target/104868] [12 Regression] powerpc: Compiling libgfortran with -flto failing with GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104868 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #11 from Jakub Jelinek --- Assuming this is fixed, if not, please reopen.
[Bug target/104868] [12 Regression] powerpc: Compiling libgfortran with -flto failing with GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104868 --- Comment #10 from CVS Commits --- The master branch has been updated by Michael Meissner : https://gcc.gnu.org/g:3cb27b85a7b977958d53e1a29596ba211d21dde2 commit r12-7620-g3cb27b85a7b977958d53e1a29596ba211d21dde2 Author: Michael Meissner Date: Fri Mar 11 19:47:09 2022 -0500 Fix DImode to TImode sign extend issue PR target/104868 had had an issue where my code that updated the DImode to TImode sign extension for power10 failed. In looking at the failure message, the reason is when extendditi2 tries to split the insn, it generates an insn that does not satisfy its constraints: (set (reg:V2DI 65 1) (vec_duplicate:V2DI (reg:DI 0))) The reason is vsx_splat_v2di does not allow GPR register 0 when the will be generating a mtvsrdd instruction. In the definition of the mtvsrdd instruction, if the RA register is 0, it means clear the upper 64 bits of the vector instead of moving register GPR 0 to those bits. When I wrote the extendditi2 pattern, I forgot that mtvsrdd had that behavior so I used a 'r' constraint instead of 'b'. In the rare case where the value is in GPR register 0, this split will fail. This patch uses the right constraint for extendditi2. 2022-03-11 Michael Meissner gcc/ PR target/104868 * config/rs6000/vsx.md (extendditi2): Use a 'b' constraint when moving from a GPR register to an Altivec register.
[Bug target/104868] [12 Regression] powerpc: Compiling libgfortran with -flto failing with GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104868 --- Comment #9 from Matheus Castanho --- That one works. Thanks!
[Bug target/104868] [12 Regression] powerpc: Compiling libgfortran with -flto failing with GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104868 --- Comment #8 from Michael Meissner --- Matheus, try the patch I just attached to the PR that I posted to the gcc-patches mailing list.
[Bug target/104868] [12 Regression] powerpc: Compiling libgfortran with -flto failing with GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104868 Michael Meissner changed: What|Removed |Added CC||meissner at gcc dot gnu.org --- Comment #7 from Michael Meissner --- Created attachment 52610 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52610&action=edit Patch to fix extendidti2 constraint on power10
[Bug target/104868] [12 Regression] powerpc: Compiling libgfortran with -flto failing with GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104868 --- Comment #6 from Matheus Castanho --- I can still reproduce the issue after applying the patch in previous comment.
[Bug target/104868] [12 Regression] powerpc: Compiling libgfortran with -flto failing with GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104868 Segher Boessenkool changed: What|Removed |Added Attachment #52601|0 |1 is obsolete|| --- Comment #5 from Segher Boessenkool --- Created attachment 52604 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52604&action=edit proposed patch Okay, this then? It completely disables handling anything that maps to ppc or ppc64 directly, and leaves those to the mercy of the older code.
[Bug target/104868] [12 Regression] powerpc: Compiling libgfortran with -flto failing with GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104868 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Summary|powerpc: Compiling |[12 Regression] powerpc: |libgfortran with -flto |Compiling libgfortran with |failing with GCC 12 |-flto failing with GCC 12 Component|lto |target Keywords||ice-on-valid-code, lto
