https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113204
--- Comment #9 from Sam James ---
(In reply to Xi Ruoyao from comment #5)
> I've hit a similar ICE testing libbacktrace with LTO bootstrapped GCC on
> LoongArch:
I hit this today too.
Unfortunately, it seems that libbacktrace gets relinked (an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113204
--- Comment #8 from Sam James ---
(For my own benefit for future reference: I ran go build -work -v -x, then went
into the work dir it made, then ran /usr/lib/go/pkg/tool/linux_amd64/link -v
..., then started pulling out the bits it ran manually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113204
--- Comment #7 from Sam James ---
With some finagling:
```
/tmp/go-PR113204 $ ./run.sh
+ gcc -o test -Wl,--export-dynamic-symbol=_cgo_panic
-Wl,--export-dynamic-symbol=_cgo_topofstack
-Wl,--export-dynamic-symbol=crosscall2 -Wl,--export-dynamic-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113204
--- Comment #6 from Sam James ---
I managed to run the test manually in `/usr/lib/go/src/cmd/link` with `go test
cgo_test.go -x -v` and made writeTempFile dump the name/contents.
At least now I can reproduce with just one command outside of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113204
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
Keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113204
--- Comment #4 from Richard Biener ---
it's really odd, I don't see how it could fail. The only suspicious bit is
int file_order1 = n1->lto_file_data ? n1->lto_file_data->order : -1;
int file_order2 = n2->lto_file_data ? n2->lto_file_data-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113204
Andrew Pinski changed:
What|Removed |Added
Summary|[14 Regression] lto1: |lto1: error: qsort
|e
