<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Issue</th>
<td>
<a href=https://github.com/llvm/llvm-project/issues/72398>72398</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>
Builtins-sparc-sunos:: divtc3_test.c XPASSes on Solaris/sparc
</td>
</tr>
<tr>
<th>Labels</th>
<td>
compiler-rt,
compiler-rt:builtins
</td>
</tr>
<tr>
<th>Assignees</th>
<td>
arichardson
</td>
</tr>
<tr>
<th>Reporter</th>
<td>
rorth
</td>
</tr>
</table>
<pre>
As originally reported in [[builtins] Guard the divtc3_test.c test with CRT_HAS_TF_MODE](https://github.com/llvm/llvm-project/pull/71876), that patch 77d75dc9be5c4bb1d9986a475e1c661718067c6a caused `Builtins-sparc-sunos:: divtc3_test.c` to `XPASS` on Solaris/sparc, breaking the [Solaris/sparcv9 buildbot](https://lab.llvm.org/buildbot/#/builders/72/builds/263).
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:
- In LLVM 17, the 32-bit test `XFAIL`s: it does compile, but died with `SIGBUS` at runtime, as originally reported in Bug 42493/Issue #41838. The 32-bit `divtc3.c.o` contains a definition of `__divtc3`
- On `main`, the test now `XPASS`es. Before the culprit patch, the test would fail to compile (missing definitions of `Qcomplex` and `tf_float`), which was hidden by the `XFAIL`. After the culprit patch, compilation wasn't attempted, resulting in a `XPASS`. 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 always `true`, which seems totallly wrong if the symbol is missing from `libclang_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.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJyUVk2P2zgS_TX0pdCCRFmSdfDB7l4nDSRINt1Z7M2gxLLECUUaJGWP__2gKNn9MUkwc7Ehiqp69V7VI4X3qjOIa1ZsGefCqbYXTnprGOeseFiIMfTWrZ11oV80Vl7WGw_WqU4ZofUFHB6tCyhBGaAYxbYZlQ7KeFY8wIdROAmhR5DqFNp8H9CHpAX6g7MKPdx_e95_3Dztn3f7z18e_sOKB8ZXfQhHz_IN4zvGd50K_dgkrR0Y32l9uv7dHZ39A9vA-O44as34rspWVcl4zfg9hF4EOIrQ9lBVsipkWzdYtMumyWRdr0qxrArM2rLMqmyVllVbCmjF6FECK9PtXMSdPwrX3vnR2Ago37ythJUpBEtf_P_r5umJHq2BJ6uFU57xXfyc4DQOxQ9lukgGK7bvtpxqIN5kY8PPKNCiSajkxLqO8d1tK73MrwvoKFzFr8_0xMuc8Tph6QNLN9Pvkx0QlDmhD6oTQVkDygQbgR2E0qPDmTxnhyNJS2_aUR-dujLaixNCg2je6P_o_YjAeF5ldZW9SfrcI3hBiWmPB3E86gsxl_O7RgV4-rr5dk88xaYQBoSUirAJDa0djlq19ESExHh38Gjg06f_fYasmtTGa6jYWyTIbvP4iZUpsQgqgLToYyylMSoyBpAK5ZSSlenT44ft9yihCOBGE9QQN4pfNvx27GDJlzVJcCt-ma3yVQLPL4hYmU5Nk7SJpfitNUEo40GAxIMysVKwB9q53097WZleS_1i6MUglKHFudpYprHn172HPgHY4sFGCd-J9ubDsx21jHKTCDMrwPhqUN5Tm77g8jOw_0Yd8M9IkIlTEg77g7YiRFhx6s69ans4Cw-9khINNJep41_0SAA2h4Du5wgnKFNbnoU3jFcBRAgYW5F2OPQjzWZHCojX5ScA341WP_B1Z_yNfOLsJoCx4C9DY7Wn4lWCCS39VpR347S1oSckc8orNa_UYmWqVePCvhf-dZx7UB6EPouLj2S6Eef1iUWPOHgINghNjXd2lmo-RN4m0BTgKtjB2WFO1Wphur0LSfPGxRJBHL3G_jhNxURyj_oIqEKPjrgIvR27HowNNI5xbOFgJ9V-Y168nsyDtl3Tx5bzIBxOmdxoJu3mIfPT5zR2gnz8_laUMBc4Wu9Vo6_W8bYA6Eb0_gZssAOaOXlsc3Ghd2c6hRRxCQ4He0LGd1J5QVHfdScBu00JueLozC9q7hwZoOgE1RI7ugApLv7FxqKFKkOQWjtEaA4P6Fw8CMhylZ9cMwH4aM94QjePqUPiKxYw0DjPvjmjuzHbWjm7tUFyagsNgpAOvUeZLOQ6l3VeiwWusypN06KuS77o12KV4iHl2OChLKqqaiQ2VS4Psk3FMqvlQq15yvMsy4psWfAlT7BYYZHyOl-tBC-5ZMsUB6H07VhaRITriuf1aqFFg9rPl4rZXdydC3Sp4Pfv1vLN7cow3TncOh7vzdh5tky18sG_pAkqaFz_0_MZojeg_8mpvBidXv_rm8akQzxn83r1VwAAAP__RswHpw">