[codegen]Ensure __builtin_trap() has an unreachable by oontvoo · Pull Request #197789 · llvm/llvm-project

oontvoo · 2026-05-14T19:39:48Z

  void test2() {
    __builtin_trap();
}

Previously, this would generate this:

; Function Attrs: mustprogress noinline nounwind optnone uwtable
define dso_local void @test2()() #2 !dbg !14 {
  call void @llvm.trap(), !dbg !15
  ret void, !dbg !16
}

Now we'll have unreachable after the trap

; Function Attrs: noinline nounwind optnone uwtable
define dso_local void @test2() #0 {
  call void @llvm.trap()
  unreachable
}

llvmorg-github-actions · 2026-05-14T19:40:52Z

@llvm/pr-subscribers-backend-amdgpu
@llvm/pr-subscribers-clang-codegen

@llvm/pr-subscribers-clang

Author: Vy Nguyen (oontvoo)

Changes

  void test2() {
    __builtin_trap();
}

Previously, this would generate this:

; Function Attrs: mustprogress noinline nounwind optnone uwtable
define dso_local void @<!-- -->test2()() #<!-- -->2 !dbg !14 {
  call void @<!-- -->llvm.trap(), !dbg !15
  ret void, !dbg !16
}

Now we'll have unreachable after the trap

; Function Attrs: noinline nounwind optnone uwtable
define dso_local void @<!-- -->test2() #<!-- -->0 {
  call void @<!-- -->llvm.trap()
  unreachable
}

Full diff: https://github.com/llvm/llvm-project/pull/197789.diff

1 Files Affected:

(modified) clang/lib/CodeGen/CGBuiltin.cpp (+6)

diff --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index 20f99f489c55f..678985ebb55e1 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -4022,6 +4022,12 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl GD, unsigned BuiltinID,
   }
   case Builtin::BI__builtin_trap:
     EmitTrapCall(Intrinsic::trap);
+    if (Builder.GetInsertBlock()) {
+      Builder.CreateUnreachable();
+      // Dummy block for the ret void - it'll be clened up
+      llvm::BasicBlock *DeadBB = createBasicBlock("dead.trap");
+      EmitBlock(DeadBB);
+    }
     return RValue::get(nullptr);
   case Builtin::BI__builtin_verbose_trap: {
     llvm::DILocation *TrapLocation = Builder.getCurrentDebugLocation();

github-actions · 2026-05-14T20:10:45Z

🐧 Linux x64 Test Results

120661 tests passed
4895 tests skipped

✅ The build succeeded and all tests passed.

github-actions · 2026-05-14T20:10:46Z

🪟 Windows x64 Test Results

57400 tests passed
2749 tests skipped

✅ The build succeeded and all tests passed.

efriedma-quic · 2026-05-14T20:57:50Z

I guess we can do this... but what's the benefit?

InakiVA · 2026-05-14T21:26:30Z

I guess we can do this... but what's the benefit?

We are currently relying on the optimization pipeline to deduce that whenever a trap function is called there will be an unreachable following it. We already know from the get-go that after a trap comes an unreachable, so it would be nice to know this information when optimizations are disabled for analysis sake.

oontvoo · 2026-05-15T00:59:56Z

I guess we can do this... but what's the benefit?

At -O0 (ie., debug build, with dead code elimination disabled), this could help keeping the binary small because all the stuff that physically follow the trap can be safely dropped (unreachable and ClearInsertionPoint() ensure that)

efriedma-quic

That doesn't really seem like much of a benefit, but the cost is also pretty small, so fine, I guess.

Regression tests are still failing.

efriedma-quic · 2026-05-16T20:23:47Z

 }

 // CHECK-LABEL: define dso_local void @"?call_var_args@@YAXXZ"()
+// FIXME all of these are after the trap so they should be gone.


I don't think this is something we plan to fix... not sure the FIXME is useful.

efriedma-quic · 2026-05-16T20:24:39Z

-// CHECK: call void @llvm.debugtrap() #[[ATTR0]]
-// CHECK: call void @llvm.trap() #[[ATTR0]]
-// CHECK: call void  @_ZN1AD1Ev(ptr {{.*}}) #[[ATTR1]]
+// CHECK: call void @llvm.trap() #[[ATTR8:[0-9]+]]


This breaks what this is supposed to be testing.

Please split the call to __builtin_trap() into a separate function.

ojhunt

Rather than special casing these I feel like we should have at least EmitTrapCall() automatically plant the unreachable if the requested intrinsic is a no return/no throw (and attach the various no throw, etc flags if they do need to be set directly on the call).

That would also catch the verbose traps, etc.

Honestly if we're doing this in debug builds I'd almost just have EmitCall plant a trap + unreachable after noreturn functions.

oontvoo · 2026-06-03T16:26:07Z

Rather than special casing these I feel like we should have at least EmitTrapCall() automatically plant the unreachable if the requested intrinsic is a no return/no throw (and attach the various no throw, etc flags if they do need to be set directly on the call).

That would also catch the verbose traps, etc.

Honestly if we're doing this in debug builds I'd almost just have EmitCall plant a trap + unreachable after noreturn functions.

Done

github-actions · 2026-06-03T17:09:02Z

✅ With the latest revision this PR passed the C/C++ code formatter.

oontvoo · 2026-06-25T18:11:47Z

@ojhunt I've made the requested change. Please have another look. Thank you.

ojhunt

Just a minor renaming - I'm really surprised that there is not a single "builtin_trap" test case anywhere.

I think it would be worth it to add one, with different targets - thoughts are:

-O0 vs -O1 (I think you get a debug? trap in some cases - it would be good to find such path and ensure that it does not get the unreachable, non-returning, etc attributes)
Something like wasm (maybe?), or some other platform where trap is implemented as exceptions or something other than a hardware trap

oontvoo · 2026-06-26T00:35:26Z

Just a minor renaming - I'm really surprised that there is not a single "builtin_trap" test case anywhere.

I think it would be worth it to add one, with different targets - thoughts are:

-O0 vs -O1 (I think you get a debug? trap in some cases - it would be good to find such path and ensure that it does not get the unreachable, non-returning, etc attributes)

Something like wasm (maybe?), or some other platform where trap is implemented as exceptions or something other than a hardware trap

done

oontvoo · 2026-07-01T01:03:30Z

@ojhunt HI, ping?

oontvoo · 2026-07-14T19:32:41Z

@ojhunt @efriedma-quic @jyknight Hi, friendly ping again?
Does anyone have any objection to this?

efriedma-quic

LGTM

(already addressed the feedbacks)

@test2

``` void test2() { __builtin_trap(); } ``` Previously, this would generate this: ``` ; Function Attrs: mustprogress noinline nounwind optnone uwtable define dso_local void @test2()() llvm#2 !dbg !14 { call void @llvm.trap(), !dbg !15 ret void, !dbg !16 } ``` Now we'll have `unreachable` after the trap ``` ; Function Attrs: noinline nounwind optnone uwtable define dso_local void @test2() #0 { call void @llvm.trap() unreachable } ```

rupprecht · 2026-07-15T20:49:42Z

This is causing test failures in some build modes (I think release build modes hide it) for the attr-cpuspecific tests. ubsan explains it:

$ clang -cc1 -emit-llvm -o /dev/null clang/test/CodeGen/attr-cpuspecific.c
clang/lib/CodeGen/CGStmt.cpp:662:12: runtime error: member call on null pointer of type 'llvm::Function'
    #0 0x5633c492a531 in clang::CodeGen::CodeGenFunction::EmitBlock(llvm::BasicBlock*, bool) clang/lib/CodeGen/CGStmt.cpp:662:12
    #1 0x5633c479a5a4 in clang::CodeGen::CodeGenFunction::EmitTrapCall(unsigned int) clang/lib/CodeGen/CGExpr.cpp:4645:5
    #2 0x5633c4be52ac in clang::CodeGen::CodeGenFunction::EmitX86MultiVersionResolver(llvm::Function*, llvm::ArrayRef<clang::CodeGen::CodeGenFunction::FMVResolverOption>) clang/lib/CodeGen/CodeGenFunction.cpp:3350:30
    #3 0x5633c4be4d01 in clang::CodeGen::CodeGenFunction::EmitMultiVersionResolver(llvm::Function*, llvm::ArrayRef<clang::CodeGen::CodeGenFunction::FMVResolverOption>) clang/lib/CodeGen/CodeGenFunction.cpp:3076:5
    #4 0x5633c4c14f4b in clang::CodeGen::CodeGenModule::emitCPUDispatchDefinition(clang::GlobalDecl) clang/lib/CodeGen/CodeGenModule.cpp:5295:7
    #5 0x5633c4c12482 in clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) clang/lib/CodeGen/CodeGenModule.cpp:4608:12
    #6 0x5633c4c0b018 in clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) clang/lib/CodeGen/CodeGenModule.cpp:7929:5
    #7 0x5633c4dc7946 in (anonymous namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) clang/lib/CodeGen/ModuleBuilder.cpp:201:18
    #8 0x5633c470dd5b in clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) clang/lib/CodeGen/CodeGenAction.cpp:179:8
    #9 0x5633c5b3eb28 in clang::ParseAST(clang::Sema&, bool, bool) clang/lib/Parse/ParseAST.cpp:174:31
    #10 0x5633c5a273b3 in clang::ASTFrontendAction::ExecuteAction() clang/lib/Frontend/FrontendAction.cpp:1464:3
    #11 0x5633c4714128 in clang::CodeGenAction::ExecuteAction() clang/lib/CodeGen/CodeGenAction.cpp:1166:30
    #12 0x5633c5a269c9 in clang::FrontendAction::Execute() clang/lib/Frontend/FrontendAction.cpp:1344:3
    #13 0x5633c59a47ec in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) clang/lib/Frontend/CompilerInstance.cpp:1033:33
    #14 0x5633c470d1b9 in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:319:25
    #15 0x5633c46fb388 in cc1_main(llvm::ArrayRef<char const*>, char const*, void*) clang/tools/driver/cc1_main.cpp:296:13

w/o ubsan:

Stack dump:
0.      Program arguments: clang -cc1 -emit-llvm -o /dev/null clang/test/CodeGen/attr-cpuspecific.c
1.      clang/test/CodeGen/attr-cpuspecific.c:64:1 <Spelling=clang/test/CodeGen/attr-cpuspecific.c:8:17>: current parser token '__attribute__'
2.      clang/test/CodeGen/attr-cpuspecific.c:44:6: LLVM IR generation of declaration 'SingleVersion'

Similar for attr-cpuspecific.cpp and attr-cpuspecific-outoflinedefs.cpp

HLSL added a bunch of diagnostics for entry functions that messed with the matrix test, see here: #184892 The solution is to just mark the test as a library triple. Builtin-trap stopped translating in classic codegen, so the call after it is now missing (and there is an unreachable after it),w hich actually better matches our behavior see: #197789 This patch fixes both tests.

HLSL added a bunch of diagnostics for entry functions that messed with the matrix test, see here: llvm/llvm-project#184892 The solution is to just mark the test as a library triple. Builtin-trap stopped translating in classic codegen, so the call after it is now missing (and there is an unreachable after it),w hich actually better matches our behavior see: llvm/llvm-project#197789 This patch fixes both tests.

@test2

``` void test2() { __builtin_trap(); } ``` Previously, this would generate this: ``` ; Function Attrs: mustprogress noinline nounwind optnone uwtable define dso_local void @test2()() #2 !dbg !14 { call void @llvm.trap(), !dbg !15 ret void, !dbg !16 } ``` Now we'll have `unreachable` after the trap ``` ; Function Attrs: noinline nounwind optnone uwtable define dso_local void @test2() #0 { call void @llvm.trap() unreachable } ```

HLSL added a bunch of diagnostics for entry functions that messed with the matrix test, see here: llvm#184892 The solution is to just mark the test as a library triple. Builtin-trap stopped translating in classic codegen, so the call after it is now missing (and there is an unreachable after it),w hich actually better matches our behavior see: llvm#197789 This patch fixes both tests.

erichkeane · 2026-07-15T23:26:53Z

This is causing test failures in some build modes (I think release build modes hide it) for the attr-cpuspecific tests. ubsan explains it:

$ clang -cc1 -emit-llvm -o /dev/null clang/test/CodeGen/attr-cpuspecific.c
clang/lib/CodeGen/CGStmt.cpp:662:12: runtime error: member call on null pointer of type 'llvm::Function'
    #0 0x5633c492a531 in clang::CodeGen::CodeGenFunction::EmitBlock(llvm::BasicBlock*, bool) clang/lib/CodeGen/CGStmt.cpp:662:12
    #1 0x5633c479a5a4 in clang::CodeGen::CodeGenFunction::EmitTrapCall(unsigned int) clang/lib/CodeGen/CGExpr.cpp:4645:5
    #2 0x5633c4be52ac in clang::CodeGen::CodeGenFunction::EmitX86MultiVersionResolver(llvm::Function*, llvm::ArrayRef<clang::CodeGen::CodeGenFunction::FMVResolverOption>) clang/lib/CodeGen/CodeGenFunction.cpp:3350:30
    #3 0x5633c4be4d01 in clang::CodeGen::CodeGenFunction::EmitMultiVersionResolver(llvm::Function*, llvm::ArrayRef<clang::CodeGen::CodeGenFunction::FMVResolverOption>) clang/lib/CodeGen/CodeGenFunction.cpp:3076:5
    #4 0x5633c4c14f4b in clang::CodeGen::CodeGenModule::emitCPUDispatchDefinition(clang::GlobalDecl) clang/lib/CodeGen/CodeGenModule.cpp:5295:7
    #5 0x5633c4c12482 in clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) clang/lib/CodeGen/CodeGenModule.cpp:4608:12
    #6 0x5633c4c0b018 in clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) clang/lib/CodeGen/CodeGenModule.cpp:7929:5
    #7 0x5633c4dc7946 in (anonymous namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) clang/lib/CodeGen/ModuleBuilder.cpp:201:18
    #8 0x5633c470dd5b in clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) clang/lib/CodeGen/CodeGenAction.cpp:179:8
    #9 0x5633c5b3eb28 in clang::ParseAST(clang::Sema&, bool, bool) clang/lib/Parse/ParseAST.cpp:174:31
    #10 0x5633c5a273b3 in clang::ASTFrontendAction::ExecuteAction() clang/lib/Frontend/FrontendAction.cpp:1464:3
    #11 0x5633c4714128 in clang::CodeGenAction::ExecuteAction() clang/lib/CodeGen/CodeGenAction.cpp:1166:30
    #12 0x5633c5a269c9 in clang::FrontendAction::Execute() clang/lib/Frontend/FrontendAction.cpp:1344:3
    #13 0x5633c59a47ec in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) clang/lib/Frontend/CompilerInstance.cpp:1033:33
    #14 0x5633c470d1b9 in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:319:25
    #15 0x5633c46fb388 in cc1_main(llvm::ArrayRef<char const*>, char const*, void*) clang/tools/driver/cc1_main.cpp:296:13

w/o ubsan:

Stack dump:
0.      Program arguments: clang -cc1 -emit-llvm -o /dev/null clang/test/CodeGen/attr-cpuspecific.c
1.      clang/test/CodeGen/attr-cpuspecific.c:64:1 <Spelling=clang/test/CodeGen/attr-cpuspecific.c:8:17>: current parser token '__attribute__'
2.      clang/test/CodeGen/attr-cpuspecific.c:44:6: LLVM IR generation of declaration 'SingleVersion'

Similar for attr-cpuspecific.cpp and attr-cpuspecific-outoflinedefs.cpp

Hmm... There's no reason that the resolver call CAN'T set the CurFn I think, and probably should. I'll work up a quick patch to do so, hopefully it won't have horrific impact on the cpu-specific tests.

Commit llvm#197789 manages to try to reference CurFn while generating a trap, which some of the multiversion resolvers do. This patch makes sure we set it to the resolver so we are inserting stuff into the right places. This somewhat shockingly causes no tests to fail, but it SHOULD stop the UBSan failures.

Commit #197789 manages to try to reference CurFn while generating a trap, which some of the multiversion resolvers do. This patch makes sure we set it to the resolver so we are inserting stuff into the right places. This somewhat shockingly causes no tests to fail, but it SHOULD stop the UBSan failures.

[codegen]Ensure __builtin_trap() has an unreachable

48bc3a4

oontvoo requested a review from jyknight May 14, 2026 19:39

llvmorg-github-actions Bot added clang Clang issues not falling into any other category clang:codegen IR generation bugs: mangling, exceptions, etc. labels May 14, 2026

set no ret

b7c1970

oontvoo added 2 commits May 14, 2026 21:17

typo

d2c974b

update tests

ca1be1c

llvmorg-github-actions Bot added the backend:AMDGPU label May 15, 2026

efriedma-quic reviewed May 16, 2026

View reviewed changes

ojhunt requested changes May 20, 2026

View reviewed changes

Comment thread clang/lib/CodeGen/CGBuiltin.cpp Outdated

Comment thread clang/lib/CodeGen/CGBuiltin.cpp Outdated

oontvoo added 3 commits June 1, 2026 14:37

address review

b77cd81

updated attr-nomerge test

3d12f1f

have EmitTrapCall() automatically add the unreachable

c9f22a2

oontvoo requested a review from ojhunt June 3, 2026 16:26

make debug_trap may return

7b1f03e

clean up more test failures

d647066

oontvoo requested a review from efriedma-quic June 25, 2026 18:09

llvmorg-github-actions Bot added the clang:openmp OpenMP related changes to Clang label Jun 25, 2026

Merge branch 'main' into builtintrap

07e1d13

oontvoo added 2 commits June 25, 2026 14:52

Merge branch 'llvm:main' into builtintrap

4bbb5bf

Merge branch 'main' into builtintrap

50104d3

fix compiler-rt/test/profile/gcov-__gcov_flush-terminate.c

6eee744

ojhunt previously requested changes Jun 25, 2026

View reviewed changes

Comment thread clang/lib/CodeGen/CGBuiltin.cpp Outdated

Comment thread clang/lib/CodeGen/CGExpr.cpp Outdated

oontvoo added 2 commits June 25, 2026 20:20

rename

27bf8c6

add builtin-trap test

7338ad8

oontvoo requested a review from ojhunt June 26, 2026 00:35

Merge branch 'main' into builtintrap

c0b380f

Merge branch 'main' into builtintrap

8580c7f

oontvoo requested a review from alinas July 7, 2026 01:09

Merge branch 'main' into builtintrap

a785ecc

efriedma-quic approved these changes Jul 14, 2026

View reviewed changes

Merge branch 'main' into builtintrap

cefbe0c

oontvoo enabled auto-merge (squash) July 15, 2026 18:23

oontvoo merged commit 0f494fc into llvm:main Jul 15, 2026
11 checks passed

erichkeane mentioned this pull request Jul 15, 2026

[CIR] Fix a pair of CIR Build failures: #209896

Merged

erichkeane mentioned this pull request Jul 15, 2026

Make Multiversion Function Resolvers set CurFn #209918

Merged

oontvoo deleted the builtintrap branch July 16, 2026 14:46

Uh oh!

Conversation

oontvoo commented May 14, 2026

Uh oh!

llvmorg-github-actions Bot commented May 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented May 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🐧 Linux x64 Test Results

Uh oh!

github-actions Bot commented May 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🪟 Windows x64 Test Results

Uh oh!

efriedma-quic commented May 14, 2026

Uh oh!

InakiVA commented May 14, 2026

Uh oh!

oontvoo commented May 15, 2026

Uh oh!

efriedma-quic left a comment

Choose a reason for hiding this comment

Uh oh!

efriedma-quic May 16, 2026

Choose a reason for hiding this comment

Uh oh!

efriedma-quic May 16, 2026

Choose a reason for hiding this comment

Uh oh!

oontvoo Jun 1, 2026

Choose a reason for hiding this comment

Uh oh!

ojhunt left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

oontvoo commented Jun 3, 2026

Uh oh!

github-actions Bot commented Jun 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

oontvoo commented Jun 25, 2026

Uh oh!

ojhunt left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

oontvoo commented Jun 26, 2026

Uh oh!

oontvoo commented Jul 1, 2026

Uh oh!

oontvoo commented Jul 14, 2026

Uh oh!

efriedma-quic left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

rupprecht commented Jul 15, 2026

Uh oh!

erichkeane commented Jul 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

llvmorg-github-actions Bot commented May 14, 2026 •

edited

Loading

github-actions Bot commented May 14, 2026 •

edited

Loading

github-actions Bot commented May 14, 2026 •

edited

Loading

github-actions Bot commented Jun 3, 2026 •

edited

Loading