[Bug target/79066] [7 Regression] non-PIC code generated for powerpc glibc with -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79066 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Alan Modra --- Fixed
[Bug target/79066] [7 Regression] non-PIC code generated for powerpc glibc with -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79066 --- Comment #7 from Alan Modra --- Author: amodra Date: Tue Jan 17 02:54:11 2017 New Revision: 244515 URL: https://gcc.gnu.org/viewcvs?rev=244515=gcc=rev Log: PR79066, non-PIC code generated for powerpc glibc with -fpic PR target/79066 * config/rs6000/rs6000.md (elf_high, elf_low): Disable when pic. * config/rs6000/rs6000.c (rs6000_emit_allocate_stack): Don't allow symbolic stack limit when pic. testsuite/ * gcc.target/powerpc/pr79066.c: New. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr79066.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/rs6000.md trunk/gcc/testsuite/ChangeLog
[Bug target/79066] [7 Regression] non-PIC code generated for powerpc glibc with -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79066
Alan Modra changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
--- Comment #6 from Alan Modra ---
The problem happens in lra-contraints.c:process_address_1. Search for
HAVE_lo_sum. A high/lo_sum address is correctly rejected by the rs6000 backend
as improper for V4 pic here:
*ad.inner = gen_rtx_LO_SUM (Pmode, new_reg, addr);
if (! valid_address_p (ad.mode, *ad.outer, ad.as))
{
/* Try to put lo_sum into register. */
However the code then stuffs the high/lo_sum into a reg and that of course is
seen as valid.
One possible fix that occurs to me is to disable rs6000.md:elf_high when
flag_pic.
[Bug target/79066] [7 Regression] non-PIC code generated for powerpc glibc with -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79066 --- Comment #5 from Segher Boessenkool --- -mno-lra calls rs6000_emit_move to load the address of the const mem it creates; -mlra does not. It should, but how what where.
[Bug target/79066] [7 Regression] non-PIC code generated for powerpc glibc with -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79066 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #4 from Alan Modra --- -mno-lra generates correct code
[Bug target/79066] [7 Regression] non-PIC code generated for powerpc glibc with -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79066 --- Comment #3 from Segher Boessenkool --- Confirmed. The constant is forced to mem in LRA.
[Bug target/79066] [7 Regression] non-PIC code generated for powerpc glibc with -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79066
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
--- Comment #2 from Jakub Jelinek ---
Reduced testcase:
/* { dg-do compile { target { fpic && ilp32 } } } */
/* { dg-options "-O2 -fpic" } */
/* { dg-final { dg-scan-assembler-not "@ha" } } */
/* { dg-final { dg-scan-assembler-not "@l" } } */
union U { double x; int i[2]; };
double
foo (double x)
{
union U u, v;
u.x = x;
v.i[0] = 0x7ff0;
v.i[1] = 0;
return u.x / v.x;
}
[Bug target/79066] [7 Regression] non-PIC code generated for powerpc glibc with -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79066 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-12 CC||jakub at gcc dot gnu.org, ||meissner at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- My bisection actually points to r242679 introducing this.
[Bug target/79066] [7 Regression] non-PIC code generated for powerpc glibc with -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79066 Richard Biener changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |7.0
