Skip to content

RWC workaround: Use __builtin_trap for ancient Clang #5458

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

StephanTLavavej
Copy link
Member

Once again, we need to add a workaround for the Taichi project in our Real World Code test suite, which is using an ancient version of Clang that we don't generally support (Clang 14). It turns out that the __builtin_verbose_trap intrinsic that I used in #5433 was only added in Clang 19.

As a workaround, we can use the __builtin_trap intrinsic, which has been supported since the Age of Legends.

(At some point, if this keeps causing headaches, I'll throw up my hands and declare that we can't keep quasi-supporting this scenario anymore. But for now, adding a couple of lines isn't too intrusive, and it may also help with our quasi-support of the Clang-based Intel compiler.)

Additionally, I am expanding our TRANSITION comment for the __is_scoped_enum intrinsic that was added by #5358. There are actually two workarounds here: DevCom-10870354 "MSVC and EDG should provide the __is_scoped_enum intrinsic to improve throughput" and VSO-2397560 "[RWC][prod/fe][Regression] Taichi build failed with error G444FFF0D: overloaded 'operator()' cannot be a static member function" (which was originally filed for our usage of the static function call operator, but is reasonable to cite for all ancient-Clang workarounds for Taichi). Usually when we say "TRANSITION, bug-number, explain-reason", we're explaining what the bug-number is about, but this comment was citing one workaround with bug-number and another workaround with explain-reason.

@StephanTLavavej StephanTLavavej added the enhancement Something can be improved label May 1, 2025
@StephanTLavavej StephanTLavavej requested a review from a team as a code owner May 1, 2025 22:32
@github-project-automation github-project-automation bot moved this to Initial Review in STL Code Reviews May 1, 2025
@StephanTLavavej StephanTLavavej moved this from Initial Review to Final Review in STL Code Reviews May 1, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Something can be improved
Projects
Status: Final Review
Development

Successfully merging this pull request may close these issues.

1 participant