www.digitalmars.com         C & C++   DMDScript  

D.gnu - LTO related bugs

reply Artur Skawina <art.08.09 gmail.com> writes:
Are these interesting, ie should I file them, or is it too early, and
the basic gdc functionality has abs priority?

I think it's too early to worry about these kind of optimizations, FWIW.


Anyway, just ran into this, while trying for the very first time to
statically link a D app:

 lto1: internal compiler error: in lto_reissue_options, at lto-opts.c:418
 Please submit a full bug report,
 with preprocessed source if appropriate.
 See <https://bitbucket.org/goshawk/gdc/issues> for instructions.
 lto-wrapper: gdc returned 1 exit status
 /usr/bin/ld: lto-wrapper failed
 collect2: ld returned 1 exit status

artur
Jan 20 2012
next sibling parent Trass3r <un known.com> writes:
File a bug report. And remember to reduce it (perhaps with DustMite).
Things on this list will just get lost.
Jan 20 2012
prev sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 01/20/12 22:34, Trass3r wrote:
 File a bug report. And remember to reduce it (perhaps with DustMite).
 Things on this list will just get lost.

Reducing LTO test cases isn't always easy. :) But i have given up on the static linking in the mean time, as i couldn't get it working in a few minutes, even *w/o* LTO [1]. I don't need static executables anyway, it was just another item on a checklist that /should/ work, but building an IFUNC-less static glibc just to check seems like a bit too much work, at least for now. I'd like the non-LTO build to work before filing LTO bugs, so this has to wait until then... artur [1] /usr/bin/ld: dynamic STT_GNU_IFUNC symbol `strcmp' with pointer equality in `/usr/lib/libc.a(strcmp.o)' can not be used when making an executable; recompile with -fPIE and relink with -pie
Jan 20 2012