https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71571
--- Comment #5 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
(In reply to David B. Robins from comment #0)
> Runs of "make check-gcc-c++ RUNTESTFLAGS=--target_board=cris-sim"
> with/without the fix do not differ in passes/failures.
But that doesn't use -fpic or -fPIC, required to trig the bug. Trying "make
check-gcc-c++ RUNTESTFLAGS=--target_board=cris-sim/fpic" would hopefully
exercise the bug, but will likely also result in noise from tests where -fpic
is unwanted.
> I would like to add a
> test for this issue but am unsure as to the correct way of doing so;
> crash.ii could be used in an execute test, or is checking the output
> assembly better, or something else?
An execution test gated on PIC-enabled targets and adding "-fpic" would do it.
As a rule, better a generic test than a target-test so as coverage I'll add an
execution test, gcc/testsuite/g++.dg/torture/pr71571.C decorated with:
// { dg-do run }
// { dg-options "-fpic" { target fpic } }
see e.g. gcc/testsuite/g++.dg/torture/pr37922.C.
I'd guess the body of the test could be your crash.ii, if you don't mind.
Completely optional, but if you could verify that that actually exposes the bug
on trunk, and observe that it passes with the patch above, I can commit to
commit faster. (Please attach the final test here.)
