Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged

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" andVSO-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.

@StephanTLavavejStephanTLavavej added the enhancementSomething can be improved labelMay 1, 2025
@StephanTLavavejStephanTLavavej requested a review froma team as acode ownerMay 1, 2025 22:32
@StephanTLavavejStephanTLavavej moved this fromInitial Review toFinal Review inSTL Code ReviewsMay 1, 2025
@StephanTLavavejStephanTLavavej moved this fromFinal Review toReady To Merge inSTL Code ReviewsMay 8, 2025
@StephanTLavavejStephanTLavavej moved this fromReady To Merge toMerging inSTL Code ReviewsMay 9, 2025
@StephanTLavavej
Copy link
MemberAuthor

I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.

StephanTLavavej added a commit to StephanTLavavej/STL that referenced this pull requestMay 9, 2025
@StephanTLavavejStephanTLavavej merged commit8cb1082 intomicrosoft:mainMay 10, 2025
39 checks passed
@github-project-automationgithub-project-automationbot moved this fromMerging toDone inSTL Code ReviewsMay 10, 2025
@StephanTLavavejStephanTLavavej deleted the admiral-ackbar branchMay 10, 2025 12:10
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@zacklj89zacklj89zacklj89 approved these changes

Assignees

No one assigned

Labels

enhancementSomething can be improved

Projects

Archived in project

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@StephanTLavavej@zacklj89

[8]ページ先頭

©2009-2025 Movatter.jp