Skip to content

Crash with unsigned _BitInt(1) global variable #62207

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

Closed
ostannard opened this issue Apr 18, 2023 · 6 comments
Closed

Crash with unsigned _BitInt(1) global variable #62207

ostannard opened this issue Apr 18, 2023 · 6 comments
Labels
c23 clang:codegen IR generation bugs: mangling, exceptions, etc. confirmed Verified by a second party crash-on-valid

Comments

@ostannard
Copy link
Collaborator

ostannard commented Apr 18, 2023

This code causes an assertion failure in Clang CodeGen for all targets (I've tested x86_64, Arm and AArch64:

unsigned _BitInt(1) a = 0;
$ /work/llvm/build/bin/clang -c test.c
clang: /work/llvm/llvm-project/llvm/lib/IR/Constants.cpp:2118: static llvm::Constant* llvm::ConstantExpr::getZExt(llvm::Constant*, llvm::Type*, bool): Assertion `C->getType()->getScalarSizeInBits() < Ty->getScalarSizeInBits()&& "SrcTy must be smaller than DestTy for ZExt!"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.      Program arguments: /work/llvm/build/bin/clang -c test.c
1.      <eof> parser at end of file
2.      test.c:1:21: LLVM IR generation of declaration 'a'
3.      test.c:1:21: Generating code for declaration 'a'
 #0 0x0000558258e8805f llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/work/llvm/build/bin/clang+0x7f8505f)
 #1 0x0000558258e85d9c llvm::sys::CleanupOnSignal(unsigned long) (/work/llvm/build/bin/clang+0x7f82d9c)
 #2 0x0000558258dc9ca8 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
 #3 0x00007f1066290420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
 #4 0x00007f1065d2d00b raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
 #5 0x00007f1065d0c859 abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:81:7
 #6 0x00007f1065d0c729 get_sysdep_segment_value /build/glibc-SzIz7B/glibc-2.31/intl/loadmsgcat.c:509:8
 #7 0x00007f1065d0c729 _nl_load_domain /build/glibc-SzIz7B/glibc-2.31/intl/loadmsgcat.c:970:34
 #8 0x00007f1065d1dfd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6)
 #9 0x00005582586a1245 llvm::ConstantExpr::getZExt(llvm::Constant*, llvm::Type*, bool) (/work/llvm/build/bin/clang+0x779e245)
#10 0x00005582592b8897 clang::CodeGen::ConstantEmitter::emitForMemory(clang::CodeGen::CodeGenModule&, llvm::Constant*, clang::QualType) (/work/llvm/build/bin/clang+0x83b5897)
#11 0x00005582592c19dc clang::CodeGen::ConstantEmitter::tryEmitPrivateForVarInit(clang::VarDecl const&) (/work/llvm/build/bin/clang+0x83be9dc)
#12 0x00005582592c1dc9 clang::CodeGen::ConstantEmitter::tryEmitForInitializer(clang::VarDecl const&) (/work/llvm/build/bin/clang+0x83bedc9)
#13 0x00005582591c48bd clang::CodeGen::CodeGenModule::EmitGlobalVarDefinition(clang::VarDecl const*, bool) (/work/llvm/build/bin/clang+0x82c18bd)
#14 0x00005582591e8cd1 clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl, llvm::GlobalValue*) (/work/llvm/build/bin/clang+0x82e5cd1)
#15 0x00005582591e9938 clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) (/work/llvm/build/bin/clang+0x82e6938)
#16 0x00005582591f27c4 clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) (.part.0) CodeGenModule.cpp:0:0
#17 0x0000558259c7cc69 (anonymous namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) ModuleBuilder.cpp:0:0
#18 0x0000558259c6f890 clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) CodeGenAction.cpp:0:0
#19 0x000055825b5e4d64 clang::ParseAST(clang::Sema&, bool, bool) (/work/llvm/build/bin/clang+0xa6e1d64)
#20 0x0000558259c7a868 clang::CodeGenAction::ExecuteAction() (/work/llvm/build/bin/clang+0x8d77868)
#21 0x0000558259b4fd09 clang::FrontendAction::Execute() (/work/llvm/build/bin/clang+0x8c4cd09)
#22 0x0000558259ad1c76 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/work/llvm/build/bin/clang+0x8bcec76)
#23 0x0000558259c419f7 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/work/llvm/build/bin/clang+0x8d3e9f7)
#24 0x00005582563367c6 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/work/llvm/build/bin/clang+0x54337c6)
#25 0x0000558256331e5a ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&, llvm::ToolContext const&) driver.cpp:0:0
#26 0x00005582599392bd void llvm::function_ref<void ()>::callback_fn<clang::driver::CC1Command::Execute(llvm::ArrayRef<std::optional<llvm::StringRef>>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>*, bool*) const::'lambda'()>(long) Job.cpp:0:0
#27 0x0000558258dca190 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) (/work/llvm/build/bin/clang+0x7ec7190)
#28 0x0000558259939b7f clang::driver::CC1Command::Execute(llvm::ArrayRef<std::optional<llvm::StringRef>>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>*, bool*) const (.part.0) Job.cpp:0:0
#29 0x00005582598fde1c clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&, bool) const (/work/llvm/build/bin/clang+0x89fae1c)
#30 0x00005582598fe8bd clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&, bool) const (/work/llvm/build/bin/clang+0x89fb8bd)
#31 0x000055825990679d clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&) (/work/llvm/build/bin/clang+0x8a0379d)
#32 0x00005582563344e0 clang_main(int, char**, llvm::ToolContext const&) (/work/llvm/build/bin/clang+0x54314e0)
#33 0x0000558256344715 main (/work/llvm/build/bin/clang+0x5441715)
#34 0x00007f1065d0e083 __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:342:3
#35 0x000055825632cb6e _start (/work/llvm/build/bin/clang+0x5429b6e)
clang: error: clang frontend command failed with exit code 134 (use -v to see invocation)
clang version 17.0.0 ([email protected]:llvm/llvm-project.git 626b7e5dd249f569203e024141c1a2a0f618df9c)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /work/llvm/build/bin
clang: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/test-adcc14.c
clang: note: diagnostic msg: /tmp/test-adcc14.sh
clang: note: diagnostic msg: 

********************
@ostannard ostannard added clang:codegen IR generation bugs: mangling, exceptions, etc. crash Prefer [crash-on-valid] or [crash-on-invalid] labels Apr 18, 2023
@llvmbot
Copy link
Member

llvmbot commented Apr 18, 2023

@llvm/issue-subscribers-clang-codegen

@tbaederr
Copy link
Contributor

The values when the assertion fails are:

(lldb) p C->getType()->getScalarSizeInBits()
(unsigned int) $0 = 1
(lldb) p Ty->getScalarSizeInBits()
(unsigned int) $1 = 1

@shafik
Copy link
Collaborator

shafik commented Apr 19, 2023

I am guessing this code:

  // Zero-extend bool.
  if (C->getType()->isIntegerTy(1)) {
    llvm::Type *boolTy = CGM.getTypes().ConvertTypeForMem(destType);
    return llvm::ConstantExpr::getZExt(C, boolTy);
  }

Needs to handle _BitInt specifically but not sure CC @AaronBallman

@AaronBallman AaronBallman added c23 confirmed Verified by a second party crash-on-valid labels Apr 20, 2023
@llvmbot
Copy link
Member

llvmbot commented Apr 20, 2023

@llvm/issue-subscribers-c2x

@Fznamznon
Copy link
Contributor

Usually _Bool looks like i1 in the IR and it is zero-extended before loading and storing into memory. However _BitInt(1) is not _Bool, it just fell into the same code path due to the same bit size. It seems right now approach is to manipulate with BitInt(N) with the same size without extending (except bitfield case), so ConvertTypeForMem returns the type with unmodified size and hence the assertion. Here is the patch avoiding that unnecessary attempt to extend - https://reviews.llvm.org/D149436 and it fixes the assertion, though what concerns me is issues like #62032 where inconsistent loads and stores produce an issue and the potential solution could be always zero-extend to the closest power-of-two size before storing/loading into memory, though that feels like breaking the whole idea of _BitInt but I'm not sure.
cc @AaronBallman @erichkeane

@erichkeane
Copy link
Collaborator

Right, we don't want to extend the bit-ints unless necessary for ABI reasons, so normal loads/stores shouldn't expand them.

@EugeneZelenko EugeneZelenko removed the crash Prefer [crash-on-valid] or [crash-on-invalid] label Apr 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c23 clang:codegen IR generation bugs: mangling, exceptions, etc. confirmed Verified by a second party crash-on-valid
Projects
None yet
Development

No branches or pull requests

8 participants