Bug 53604 - ld reports errors using lto after upgrading from gcc-4.6.2 to gcc-4.7.0
Summary: ld reports errors using lto after upgrading from gcc-4.6.2 to gcc-4.7.0
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: lto (show other bugs)
Version: 4.7.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: lto
Depends on: 53572
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-07 15:10 UTC by Paul Scruby
Modified: 2020-01-18 03:03 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2017-03-17 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Scruby 2012-06-07 15:10:16 UTC
I recently tried to upgrade from gcc-4.6.2 to gcc-4.7.0.  I have been using the lto with gcc-4.6.2 and binutils-2.22 for a while with no problems.

However, since I upgraded to gcc-4.7.0 ld is getting "hidden symbol isn't defined" errors, something like this when I try to link with my static libraries and a boost shared object:

  $  /opt/gcc-4.7.0/bin/g++ -o /home/pauls/repos/build/bin/my_app -static-libstdc++ -m64 -march=corei7 -Wl,-rpath,/opt/boost-1.44/lib -L/opt/boost-1.44/lib -flto -O3 -fuse-linker-plugin -L/home/pauls/repos/build/lib /home/pauls/repos/build/obj/my_app.o -lmy_lib -lboost_regex -ldl -lrt
  `_ZThn16_N5boost16exception_detail10clone_implINS0_19error_info_injectorISt11logic_errorEEED1Ev' referenced in section `.data.rel.ro' of /tmp/cc0n7i0I.ltrans12.ltrans.o: defined in discarded section `.gnu.linkonce.t._ZN5boost16exception_detail10clone_implINS0_19error_info_injectorISt11logic_errorEEED5Ev' of /home/pauls/repos/build/obj/my_app.o (symbol from plugin)
  /opt/gcc-4.7.0/lib/gcc/x86_64-fedora-linux/4.7.0/../../../../x86_64-fedora-linux/bin/ld: /home/pauls/repos/build/bin/my_app: hidden symbol `.LTHUNK11.6239' isn't defined

binutils 2.22 was pre-installed into:
  $ /opt/gcc-4.7.0

gcc4.7.0 was build with:
  $ export PATH=/opt/gcc-4.7.0/bin/:$PATH
  $ ../configure --prefix=/opt/gcc-4.7.0 --build=x86_64-fedora-linux --with-system-zlib --enable-plugin --enable-bootstrap --enable-shared --enable-threads=posix --enable-languages=c,c++ --disable-checking --disable-libunwind-exceptions

I tried upgrading to binutils-2.22.52 to see if was an issue with ld that had recently been patched, but I got the same error.  

I also tried upgrading from boost-1.44 to boost-1.49 to see if it was an issue with boost exception code, but I also got the same error.

Thanks,

Paul
Comment 1 H.J. Lu 2012-06-07 15:50:56 UTC
I think it is a dup for PR 53572.  Can you try patch at

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53572#c3
Comment 2 Paul Scruby 2012-06-07 17:14:13 UTC
The 4.7.0 code is different so the patch didn't work:
  'struct varpool_node' has no member named 'symbol'

I'm not familiar with the gcc internals so I'm not sure what I need to add to 4.7.0 to fix this?

If this is the function in question, what do I need to add to fix this problem?

static inline bool
varpool_can_remove_if_no_refs (struct varpool_node *node)
{
  return (!node->force_output && !node->used_from_other_partition
	  && (flag_toplevel_reorder || DECL_COMDAT (node->decl)
	      || DECL_ARTIFICIAL (node->decl))
  	  && (DECL_COMDAT (node->decl) || !node->externally_visible));
}

Thanks,

Paul
Comment 3 Yuri Gribov 2012-06-11 17:04:42 UTC
Paul,

I changed to 

  static inline bool
  varpool_can_remove_if_no_refs (struct varpool_node *node)
  {
    return (!node->force_output && !node->used_from_other_partition
            && (flag_toplevel_reorder || DECL_COMDAT (node->decl)
                || DECL_ARTIFICIAL (node->decl))
            && ((DECL_COMDAT (node->decl) && !varpool_used_from_object_file_p (node)) || !node->externally_visible));
  }

and it helped.
Comment 4 Richard Biener 2012-06-12 10:42:15 UTC
dup

*** This bug has been marked as a duplicate of bug 53572 ***
Comment 5 Paul Scruby 2012-06-13 11:56:53 UTC
Thanks Yuri.  I swapped out this function with yours but ld was still unable to link.  I'm trying linking to my own libraries statically using the lto and the boost shared libraries.  Linking to one of the other seems to be fine.

I'm not sure if this is the same bug as bug 53572 (gcc4.7.1) or a different one.  If you can point me in the direction of a gcc4.7.1 release, I'm happy to test my build to see if this problem has now been resolved.

Thanks again,

Paul
Comment 6 Yuri Gribov 2012-06-13 12:30:27 UTC
Paul,

I used April version of Linaro gcc toolchain so you may want to give it a try. If it still doesn't work you'll probably need to attach a repro code here.
Comment 7 Jonathan Wakely 2012-06-13 14:28:54 UTC
4.7.1 is due out Real Soon Now, the release candidate can be found on any GNU mirror: ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/snapshots/4.7.1-RC-20120606/
Comment 8 Paul Scruby 2012-06-13 14:34:38 UTC
Cheers Jon, I'll try this afternoon...
Comment 9 Paul Scruby 2012-06-13 16:44:12 UTC
Unfortunately I still have this linking issue with gcc-4.7.1-RC-20120606 and binutils-2.22 so I don't think it's a dup for PR 53572.

I'll try to make a standalone project tomorrow which demonstrates this problem and attachment it to this report to see if someone else can reproduce it.  It might not be a bug, I might just need to change the arguments that I'm passing to link my app.

Thanks again,

Paul
Comment 10 Paul Scruby 2012-06-14 08:16:28 UTC
I released that I needed to add Yuri's patch to gcc-4.7.1.RC-20120606 as it had not made it into the trunk.  However, this still made no difference and I still had the same linking problem.  I'll try to hack together a standalone example today that I can attach to the report to see if someone can reproduce it.
Comment 11 Paul Scruby 2012-06-14 11:46:32 UTC
I've written half a dozen test harnesses this morning to tried to recreate this bug unsuccessfully.  My team writes very low-latency code so they do quite a lot of 'abusive' (but legal) partial specialization tricks force some optimizations and branch predications on certain paths.  I suspect that some of this nastiness is creating bloat which is not playing ball in LTO land.

Unfortunately, these lto bugs are really hard to recreate and I have to finish some work on other projects, but I will try to pick this up and get implement this test harness when I get a chance.  For the time being we'll stick with gcc-4.6.2 which is working really nicely for us...

Thanks for all your help,

Paul
Comment 12 Paul Scruby 2012-09-06 13:03:17 UTC
I just tried Matt Hargett's patch from Bug53572 with gcc4.7.1 and it still has not fixed the problem we're having.  I'll continue test these issues in our codebase with new versions of gcc as they're released.  If I get some more time which I don't have at the moment, I'll try to replicate it with a standalone example.

Thanks,

Paul
Comment 13 Martin Sebor 2017-03-17 23:32:13 UTC
This report has been unconfirmed for nearly 5 years and GCC 4.7 is no longer maintained.  Does the problem persist with a maintained compiler (GCC 4.8 or newer) or can it be resolved?
Comment 14 Andrew Pinski 2020-01-18 03:03:01 UTC
(In reply to Martin Sebor from comment #13)
Add over 2.5 years so closing as invalid.