public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug lto/61526] New: relocation R_X86_64_PC32 in shared object with static and extern
@ 2014-06-16 14:48 khimov at altell dot ru
  2014-06-17  9:00 ` [Bug lto/61526] " rguenth at gcc dot gnu.org
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: khimov at altell dot ru @ 2014-06-16 14:48 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 61526
           Summary: relocation R_X86_64_PC32 in shared object with static
                    and extern
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: khimov at altell dot ru

Created attachment 32947
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32947&action=edit
two source files and workaround patch

Compiling Quagga 0.99.22.4 with GCC 4.9.0 (compiler bootstrapped to
cross-compile from x86_64 Debian GNU/Linux to x86_64 uClibc system) with LTO
enabled fails:

| x86_64-altell-linux-uclibc-libtool: link: ccache
x86_64-altell-linux-uclibc-gcc -march=x86-64 -mtune=generic
--sysroot=/home/rik/neo-1.5/tmp/sysroots/x86_64-altell-linux-uclibc -shared 
-fPIC -DPIC  .libs/network.o .libs/pid_output.o .libs/getopt.o .libs/getopt1.o
.libs/daemon.o .libs/checksum.o .libs/vector.o .libs/linklist.o .libs/vty.o
.libs/command.o .libs/sockunion.o .libs/prefix.o .libs/thread.o .libs/if.o
.libs/memory.o .libs/buffer.o .libs/table.o .libs/hash.o .libs/filter.o
.libs/routemap.o .libs/distribute.o .libs/stream.o .libs/str.o .libs/log.o
.libs/plist.o .libs/zclient.o .libs/sockopt.o .libs/smux.o .libs/agentx.o
.libs/snmp.o .libs/md5.o .libs/if_rmap.o .libs/keychain.o .libs/privs.o
.libs/sigevent.o .libs/pqueue.o .libs/jhash.o .libs/memtypes.o
.libs/workqueue.o   -lcrypt
-L/home/rik/neo-1.5/tmp/sysroots/x86_64-altell-linux-uclibc/usr/lib
/home/rik/neo-1.5/tmp/sysroots/x86_64-altell-linux-uclibc/usr/lib/libnetsnmpmibs.so
-ldl
/home/rik/neo-1.5/tmp/sysroots/x86_64-altell-linux-uclibc/usr/lib/libnetsnmpagent.so
/home/rik/neo-1.5/tmp/sysroots/x86_64-altell-linux-uclibc/usr/lib/libnetsnmp.so
-lcrypto -lm -lpthread -lrt  -march=x86-64 -mtune=generic
--sysroot=/home/rik/neo-1.5/tmp/sysroots/x86_64-altell-linux-uclibc -O2 -flto
-O2 -flto -Wl,-O1 -Wl,--hash-style=gnu -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-O1
-Wl,--hash-style=gnu -Wl,-z -Wl,relro -Wl,-z -Wl,now -flto   -Wl,-soname
-Wl,libzebra.so.0 -o .libs/libzebra.so.0.0.0
|
/home/rik/neo-1.5/tmp/sysroots/x86_64-altell-linux-uclibc/usr/lib/libnetsnmp.so:
warning: gethostbyaddr is obsolescent, use getaddrinfo() instead.
|
/home/rik/neo-1.5/tmp/sysroots/x86_64-altell-linux-uclibc/usr/lib/libnetsnmp.so:
warning: gethostbyname is obsolescent, use getnameinfo() instead.
|
/home/rik/neo-1.5/tmp/sysroots/x86_64-linux/usr/libexec/x86_64-altell-linux-uclibc/gcc/x86_64-altell-linux-uclibc/4.9.0/ld:
/tmp/ccYjxIMj.ltrans1.ltrans.o: relocation R_X86_64_PC32 against undefined
symbol `master' can not be used when making a shared object; recompile with
-fPIC
|
/home/rik/neo-1.5/tmp/sysroots/x86_64-linux/usr/libexec/x86_64-altell-linux-uclibc/gcc/x86_64-altell-linux-uclibc/4.9.0/ld:
final link failed: Bad value


Turns out that the problem can be reproduced with just two objects, vty.o and
zclient.o, preprocessed sources attached. Compiling with:

$ x86_64-altell-linux-uclibc-gcc -fno-strict-aliasing -pipe -O2
-fomit-frame-pointer -frename-registers -flto -c vty.prepr.c  -fPIC -DPIC -o
vty.o
$ x86_64-altell-linux-uclibc-gcc -fno-strict-aliasing -pipe -O2
-fomit-frame-pointer -frename-registers -flto -c zclient.prepr.c  -fPIC -DPIC
-o zclient.o
$ x86_64-altell-linux-uclibc-gcc -shared  -fPIC -DPIC  vty.o zclient.o -O2
-flto -o lib.so

gives the same result:

/home/rik/neo-1.5/tmp/sysroots/x86_64-linux/usr/libexec/x86_64-altell-linux-uclibc/gcc/x86_64-altell-linux-uclibc/4.9.0/ld:
/tmp/cc3LxvY0.ltrans1.ltrans.o: relocation R_X86_64_PC32 against undefined
symbol `master.lto_priv.3' can not be used when making a shared object;
recompile with -fPIC
/home/rik/neo-1.5/tmp/sysroots/x86_64-linux/usr/libexec/x86_64-altell-linux-uclibc/gcc/x86_64-altell-linux-uclibc/4.9.0/ld:
final link failed: Bad value
collect2: error: ld returned 1 exit status

Compiling with -flto-partition=none solves the problem as does my current
workaround patch to rename static variable in vty.o (attached, although the
patch is for original Quagga package).


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug lto/61526] relocation R_X86_64_PC32 in shared object with static and extern
  2014-06-16 14:48 [Bug lto/61526] New: relocation R_X86_64_PC32 in shared object with static and extern khimov at altell dot ru
@ 2014-06-17  9:00 ` rguenth at gcc dot gnu.org
  2014-06-17  9:28 ` khimov at altell dot ru
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-06-17  9:00 UTC (permalink / raw)
  To: gcc-bugs

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think this is a duplicate of PR61012.  That is, works on the branch head for
me.
Reduced testcase that fails with 4.9.0:

static void *master;
void *foo () { return master; }

---

extern void *master;
void *bar () { return master; }

and using -flto-partition=1to1 at link.

*** This bug has been marked as a duplicate of bug 61012 ***


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug lto/61526] relocation R_X86_64_PC32 in shared object with static and extern
  2014-06-16 14:48 [Bug lto/61526] New: relocation R_X86_64_PC32 in shared object with static and extern khimov at altell dot ru
  2014-06-17  9:00 ` [Bug lto/61526] " rguenth at gcc dot gnu.org
@ 2014-06-17  9:28 ` khimov at altell dot ru
  2014-07-21 16:00 ` sandra at codesourcery dot com
  2014-07-21 16:17 ` ubizjak at gmail dot com
  3 siblings, 0 replies; 5+ messages in thread
From: khimov at altell dot ru @ 2014-06-17  9:28 UTC (permalink / raw)
  To: gcc-bugs

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

Roman Khimov <khimov at altell dot ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #2 from Roman Khimov <khimov at altell dot ru> ---
Just tried the fix for PR61012 and indeed, it solves the problem. Thanks.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug lto/61526] relocation R_X86_64_PC32 in shared object with static and extern
  2014-06-16 14:48 [Bug lto/61526] New: relocation R_X86_64_PC32 in shared object with static and extern khimov at altell dot ru
  2014-06-17  9:00 ` [Bug lto/61526] " rguenth at gcc dot gnu.org
  2014-06-17  9:28 ` khimov at altell dot ru
@ 2014-07-21 16:00 ` sandra at codesourcery dot com
  2014-07-21 16:17 ` ubizjak at gmail dot com
  3 siblings, 0 replies; 5+ messages in thread
From: sandra at codesourcery dot com @ 2014-07-21 16:00 UTC (permalink / raw)
  To: gcc-bugs

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

Sandra Loosemore <sandra at codesourcery dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sandra at codesourcery dot com

--- Comment #3 from Sandra Loosemore <sandra at codesourcery dot com> ---
The testcase added for this bug in GCC 4.9.1 is failing with a link error on an
arm-none-eabi target that doesn't support -shared.  Should it be restricted to
linux targets?


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug lto/61526] relocation R_X86_64_PC32 in shared object with static and extern
  2014-06-16 14:48 [Bug lto/61526] New: relocation R_X86_64_PC32 in shared object with static and extern khimov at altell dot ru
                   ` (2 preceding siblings ...)
  2014-07-21 16:00 ` sandra at codesourcery dot com
@ 2014-07-21 16:17 ` ubizjak at gmail dot com
  3 siblings, 0 replies; 5+ messages in thread
From: ubizjak at gmail dot com @ 2014-07-21 16:17 UTC (permalink / raw)
  To: gcc-bugs

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 9096 bytes --]

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

--- Comment #4 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Sandra Loosemore from comment #3)
> The testcase added for this bug in GCC 4.9.1 is failing with a link error on
> an arm-none-eabi target that doesn't support -shared.  Should it be
> restricted to linux targets?

Probably the best way is to add check_effective_target_shared to
lib/target-supports.exp (similar to existing c_e_t_static) procedure and use it
through the testsuite.
>From gcc-bugs-return-456873-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 21 17:33:09 2014
Return-Path: <gcc-bugs-return-456873-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 2330 invoked by alias); 21 Jul 2014 17:33:08 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 2194 invoked by uid 48); 21 Jul 2014 17:33:01 -0000
From: "coleb at eyesopen dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/61872] New: Assigning to "long double" causes memset to be improperly elided
Date: Mon, 21 Jul 2014 17:33:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.8.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: coleb at eyesopen dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created
Message-ID: <bug-61872-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-07/txt/msg01464.txt.bz2
Content-length: 6683

https://gcc.gnu.org/bugzilla/show_bug.cgi?ida872

            Bug ID: 61872
           Summary: Assigning to "long double" causes memset to be
                    improperly elided
           Product: gcc
           Version: 4.8.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: coleb at eyesopen dot com

Created attachment 33169
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id3169&actioníit
Intermediate file generated by the compiler for the above test case

The following code zeros out memory being used as a "long double" in order to
be able to memcmp the memory later. However, assigning to the long double later
causes the optimizer to omit the preceding memset of zero.

The following code boils this down to a simple test case:


#include <assert.h>
#include <string.h>
#include <iomanip>
#include <iostream>

void Dump( const void * mem, size_t n )
{
  const unsigned char * p = reinterpret_cast< const unsigned char *>( mem );
  for ( size_t i = 0; i < n; i++ )
  {
    std::cout << std::hex << std::setw(2) << std::setfill( std::cout.widen('0')
) << int(p[i]) << " ";
  }
  std::cout << std::endl;
}

int main()
{
  long double a;
  memset(&a, '\0', sizeof(long double));
  //Dump(&a, sizeof(long double)); // Uncomment me to make the test pass
  a = 1.0;

  long double b;
    memset(&b, '\0', sizeof(long double));
  //Dump(&b, sizeof(long double)); // Uncomment me to make the test pass
  b = 1.0;

  std::cout << memcmp(&a, &b, sizeof(long double)) << std::endl;

  Dump(&a, sizeof(long double));
  Dump(&b, sizeof(long double));

  assert(memcmp(&a, &b, sizeof(long double)) == 0);
}


Uncommenting the "Dump" function calls causing the test to pass, presumably
because the optimizer notices the zero'd out memory is now being used by Dump
before the assignment.

Note, this only occurs with -O1 or higher.

I've attached the associated .ii files from the following command:

coleb@rhel7:~> g++ -v -save-temps -O1 ./LongDoubleMemSetElided.cpp && ./a.out
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --disable-libgcj
--with-isl=/builddir/build/BUILD/gcc-4.8.2-20131106/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.2-20131106/obj-x86_64-redhat-linux/cloog-install
--with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.2 20131106 (Red Hat 4.8.2-3) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/4.8.2/cc1plus -E -quiet -v -D_GNU_SOURCE
./LongDoubleMemSetElided.cpp -mtune=generic -march=x86-64 -O1 -fpch-preprocess
-o LongDoubleMemSetElided.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/4.8.2/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../include/c++/4.8.2

/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../include/c++/4.8.2/x86_64-redhat-linux
 /usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../include/c++/4.8.2/backward
 /usr/lib/gcc/x86_64-redhat-linux/4.8.2/include
 /usr/local/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/4.8.2/cc1plus -fpreprocessed
LongDoubleMemSetElided.ii -quiet -dumpbase LongDoubleMemSetElided.cpp
-mtune=generic -march=x86-64 -auxbase LongDoubleMemSetElided -O1 -version -o
LongDoubleMemSetElided.s
GNU C++ (GCC) version 4.8.2 20131106 (Red Hat 4.8.2-3) (x86_64-redhat-linux)
    compiled by GNU C version 4.8.2 20131106 (Red Hat 4.8.2-3), GMP version
5.1.1, MPFR version 3.1.1, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand\x100 --param ggc-min-heapsize\x131072
GNU C++ (GCC) version 4.8.2 20131106 (Red Hat 4.8.2-3) (x86_64-redhat-linux)
    compiled by GNU C version 4.8.2 20131106 (Red Hat 4.8.2-3), GMP version
5.1.1, MPFR version 3.1.1, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand\x100 --param ggc-min-heapsize\x131072
Compiler executable checksum: 854a658c8d093bd199c43bf0150da7d8
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 as -v --64 -o LongDoubleMemSetElided.o LongDoubleMemSetElided.s
GNU assembler version 2.23.52.0.1 (x86_64-redhat-linux) using BFD version
version 2.23.52.0.1-12.el7 20130226
COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/4.8.2/:/usr/libexec/gcc/x86_64-redhat-linux/4.8.2/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/4.8.2/:/usr/lib/gcc/x86_64-redhat-linux/
LIBRARY_PATH=/usr/lib/gcc/x86_64-redhat-linux/4.8.2/:/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/4.8.2/collect2 --build-id --no-add-needed
--eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker
/lib64/ld-linux-x86-64.so.2
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../lib64/crt1.o
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/crtbegin.o
-L/usr/lib/gcc/x86_64-redhat-linux/4.8.2
-L/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../..
LongDoubleMemSetElided.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/crtend.o
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../lib64/crtn.o
64
00 00 00 00 00 00 00 80 ff 3f 40 00 00 00 00 00
00 00 00 00 00 00 00 80 ff 3f 00 00 00 00 00 00
a.out: ./LongDoubleMemSetElided.cpp:33: int main(): Assertion `memcmp(&a, &b,
sizeof(long double)) == 0' failed.
Aborted (core dumped)

Thank you!


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2014-07-21 16:17 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-06-16 14:48 [Bug lto/61526] New: relocation R_X86_64_PC32 in shared object with static and extern khimov at altell dot ru
2014-06-17  9:00 ` [Bug lto/61526] " rguenth at gcc dot gnu.org
2014-06-17  9:28 ` khimov at altell dot ru
2014-07-21 16:00 ` sandra at codesourcery dot com
2014-07-21 16:17 ` ubizjak at gmail dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).