Open rorth opened 9 months ago
Thanks for the detailed analysis. It sounds like the right way forward is to drop the XFAIL for now and to fix the librthas* checks. I agree that the tests need improving...
This can be closed now?
Good question: I just ran a main
build and the test PASS
es for both sparc
and sparcv9
:
PASS: Builtins-sparc-sunos :: divtc3_test.c (130 of 87734)
PASS: Builtins-sparcv9-sunos :: divtc3_test.c (433 of 87734)
However, when I run them manually, I get
$ test/builtins/Unit/SPARCSunOSConfig/Output/divtc3_test.c.tmp
skipped
$ test/builtins/Unit/SPARCV9SunOSConfig/Output/divtc3_test.c.tmp
No errors found.
Doing nothing and just printing skipped
seems very wrong to me since it hides the actual outcome from the testsuite: the test should probably turn UNSUPPORTED
instead. However, this applies not only to this single test but to many (all?) builtin tests.
As originally reported in [builtins] Guard the divtc3_test.c test with CRT_HAS_TF_MODE, that patch 77d75dc9be5c4bb1d9986a475e1c661718067c6a caused
Builtins-sparc-sunos:: divtc3_test.c
toXPASS
on Solaris/sparc, breaking the Solaris/sparcv9 buildbot.Some investigation into the failure that prompted the culprit patch have been reported in Issue #71971.
The same issues apply to 32-bit SPARC, with an additional compliction:
XFAIL
s: it does compile, but died withSIGBUS
at runtime, as originally reported in Bug 42493/Issue #41838. The 32-bitdivtc3.c.o
contains a definition of__divtc3
main
, the test nowXPASS
es. Before the culprit patch, the test would fail to compile (missing definitions ofQcomplex
andtf_float
), which was hidden by theXFAIL
. After the culprit patch, compilation wasn't attempted, resulting in aXPASS
. Unlike LLVM 17,divtc3.c.o
now contains no symbols (i.e. no definition of__divtc3
).Both in LLVM 17 and
main
,librt_has_divtc3
, is alwaystrue
, which seems totallly wrong if the symbol is missing fromlibclang_rt.builtins-sparc.a
.It doesn't help either (though not an issue for the Solaris/sparcv9 buildbot) that the builtins tests aren't run in a runtimes build at all, missing any possible issues.
I guess for the moment the best way forward is to remove/disable the
XFAIL
in the test to turn the Solaris/sparcv9 green again after 5 days, with a prominent comment referring to this Issue. However, there are way more issues in the builtins code that need to be adressed.