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

File a bug report. And remember to reduce it (perhaps with DustMite).
Things on this list will just get lost.

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