[Bug target/49950] New: GOT relocation for -fPIE is excessive

[Bug target/49950] New: GOT relocation for -fPIE is excessive

[jan.kratochvil at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49950

           Summary: GOT relocation for -fPIE is excessive
           Product: gcc
           Version: 4.4.7
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: jan.kratochvil@redhat.com
            Target: x86_64-unknown-linux-gnu


FAIL: gcc (GCC) 4.4.7 20110802 (prerelease)
FAIL: gcc (GCC) 4.5.4 20110802 (prerelease)
FAIL: gcc (GCC) 4.6.2 20110802 (prerelease)
FAIL: gcc (GCC) 4.7.0 20110802 (experimental)

echo 'int i; int f (void) { return i; }' | gcc -c -o 20.o -Wall -fPIE -x c -
readelf -Wr 20.o
0000000000000007  0000000800000009 R_X86_64_GOTPCREL      0000000000000004 i -
4

none:  R_X86_64_PC32     is correct
-fPIE: R_X86_64_GOTPCREL is excessive - this Bug
-fPIC: R_X86_64_GOTPCREL is correct

Jakub:
the difference between -fPIE and -fPIC is that the former assumes that you
can't override its symbols
so if it sees some symbol defined in the current source file, it knows that it
will be the definition at runtime
for -shared libraries that is not true, other shared libraries defining the
same symbol can override it, so they need more runtime relocations

[Bug target/49950] GOT relocation for -fPIE is excessive

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49950

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-08-03 09:38:11 UTC ---
But int i is a common, with -fno-common I get no GOTPCREL but what you expect.
Not sure if we need a GOTPCREL for commons or not.

[Bug target/49950] GOT relocation for -fPIE is excessive

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49950

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-08-03 16:29:48 UTC ---
default_binds_local_p_1 has:
  /* Uninitialized COMMON variable may be unified with symbols
     resolved from other modules.  */
  else if (DECL_COMMON (exp)
           && !resolved_locally
           && (DECL_INITIAL (exp) == NULL
               || DECL_INITIAL (exp) == error_mark_node))
    local_p = false;

Now, it depends on what the callers expect.  If they want to figure out if the
decl can't be interposed by other library etc., then the above lines are
unnecessary, but if it wants to find out e.g. if it can trust DECL_INITIAL or
lack thereof of the DECL etc., then the above is needed.  E.g. we use
targetm.binds_local_p to find out if anchoring should be used, for commons it
certainly shouldn't be.

[Bug target/49950] GOT relocation for -fPIE is excessive

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49950

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |5.1.0
      Known to fail|                            |4.9.4

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I see in GCC 5+:
        movl    i(%rip), %eax

[Bug target/49950] GOT relocation for -fPIE is excessive

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49950

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|UNCONFIRMED                 |RESOLVED
   Target Milestone|---                         |5.0
           Keywords|                            |missed-optimization

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed for GCC 5 by r5-5573.