RWC workaround: Use __builtin_trap for ancient Clang
#5458
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
zacklj89
approved these changes
May 8, 2025
|
I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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_trapintrinsic that I used in #5433 was only added in Clang 19.As a workaround, we can use the
__builtin_trapintrinsic, 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_enumintrinsic that was added by #5358. There are actually two workarounds here: DevCom-10870354 "MSVC and EDG should provide the__is_scoped_enumintrinsic 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.