Crash on systemz with named address space

[ubizjak]

Following testcase:

#define AS __attribute__((address_space(3)))

int AS m;

int *foo(void)
{
  return (int *)&m;
}

crashes when compiled with clang -O2 -S with the following backtrace:

Stack dump:
0.      Program arguments: /usr/bin/clang --target=systemz-linux -O2 -S -fcolor-diagnostics -o as.s as.c
1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'Function Pass Manager' on module 'as.c'.
4.      Running pass 'SystemZ DAG->DAG Pattern Instruction Selection' on function '@foo'
 #0 0x00007fe111017b7a llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/lib64/libLLVM.so.19.1+0x217b7a)
 #1 0x00007fe111014b24 llvm::sys::RunSignalHandlers() (/lib64/libLLVM.so.19.1+0x214b24)
 #2 0x00007fe110f33472 (/lib64/libLLVM.so.19.1+0x133472)
 #3 0x00007fe110f3341f llvm::CrashRecoveryContext::HandleExit(int) (/lib64/libLLVM.so.19.1+0x13341f)
 #4 0x00007fe11101093f (/lib64/libLLVM.so.19.1+0x21093f)
 #5 0x000055ea3ea3feae (/usr/bin/clang+0xbeae)
 #6 0x00007fe110f47f80 llvm::report_fatal_error(llvm::Twine const&, bool) (/lib64/libLLVM.so.19.1+0x147f80)
 #7 0x00007fe111a98edf llvm::SelectionDAGISel::CannotYetSelect(llvm::SDNode*) (/lib64/libLLVM.so.19.1+0xc98edf)
 #8 0x00007fe111a97eb6 llvm::SelectionDAGISel::SelectCodeCommon(llvm::SDNode*, unsigned char const*, unsigned int) (/lib64/libLLVM.so.19.1+0xc97eb6)
 #9 0x00007fe11473a1b1 (/lib64/libLLVM.so.19.1+0x393a1b1)
#10 0x00007fe111a8d7dc llvm::SelectionDAGISel::DoInstructionSelection() (/lib64/libLLVM.so.19.1+0xc8d7dc)
#11 0x00007fe111a8ca85 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/lib64/libLLVM.so.19.1+0xc8ca85)
#12 0x00007fe111a8b81f llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/lib64/libLLVM.so.19.1+0xc8b81f)
#13 0x00007fe111a88b0f llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/lib64/libLLVM.so.19.1+0xc88b0f)
#14 0x00007fe114738c59 (/lib64/libLLVM.so.19.1+0x3938c59)
#15 0x00007fe111a86b5e llvm::SelectionDAGISelLegacy::runOnMachineFunction(llvm::MachineFunction&) (/lib64/libLLVM.so.19.1+0xc86b5e)
#16 0x00007fe1114e5f48 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/lib64/libLLVM.so.19.1+0x6e5f48)
#17 0x00007fe1111bf590 llvm::FPPassManager::runOnFunction(llvm::Function&) (/lib64/libLLVM.so.19.1+0x3bf590)
#18 0x00007fe1111c78c3 llvm::FPPassManager::runOnModule(llvm::Module&) (/lib64/libLLVM.so.19.1+0x3c78c3)
#19 0x00007fe1111bfe22 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/lib64/libLLVM.so.19.1+0x3bfe22)
#20 0x00007fe11a28dbf0 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCntPtr<llvm::vfs::FileSystem>, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream>>, clang::BackendConsumer*) (/lib64/libclang-cpp.so.19.1+0x188dbf0)
#21 0x00007fe11a6ff0d9 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/lib64/libclang-cpp.so.19.1+0x1cff0d9)
#22 0x00007fe118bf5579 clang::ParseAST(clang::Sema&, bool, bool) (/lib64/libclang-cpp.so.19.1+0x1f5579)
#23 0x00007fe11b42a06b clang::FrontendAction::Execute() (/lib64/libclang-cpp.so.19.1+0x2a2a06b)
#24 0x00007fe11b386514 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/lib64/libclang-cpp.so.19.1+0x2986514)
#25 0x00007fe11b4b57bd clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/lib64/libclang-cpp.so.19.1+0x2ab57bd)
#26 0x000055ea3ea3f516 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/usr/bin/clang+0xb516)
#27 0x000055ea3ea3b7b7 (/usr/bin/clang+0x77b7)
#28 0x00007fe11af580fd (/lib64/libclang-cpp.so.19.1+0x25580fd)
#29 0x00007fe110f33400 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) (/lib64/libLLVM.so.19.1+0x133400)
#30 0x00007fe11af57975 clang::driver::CC1Command::Execute(llvm::ArrayRef<std::optional<llvm::StringRef>>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>*, bool*) const (/lib64/libclang-cpp.so.19.1+0x2557975)
#31 0x00007fe11af127cd clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&, bool) const (/lib64/libclang-cpp.so.19.1+0x25127cd)
#32 0x00007fe11af12b37 clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&, bool) const (/lib64/libclang-cpp.so.19.1+0x2512b37)
#33 0x00007fe11af35c1b clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&) (/lib64/libclang-cpp.so.19.1+0x2535c1b)
#34 0x000055ea3ea3ab7c clang_main(int, char**, llvm::ToolContext const&) (/usr/bin/clang+0x6b7c)
#35 0x000055ea3ea4b8a8 main (/usr/bin/clang+0x178a8)
#36 0x00007fe11080f248 __libc_start_call_main (/lib64/libc.so.6+0x3248)
#37 0x00007fe11080f30b __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x330b)
#38 0x000055ea3ea389f5 _start (/usr/bin/clang+0x49f5)
clang: error: clang frontend command failed with exit code 70 (use -v to see invocation)
clang version 19.1.5 (Fedora 19.1.5-1.fc41)
Target: systemz-unknown-linux
Thread model: posix
InstalledDir: /usr/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/as-b5786d.c
clang: note: diagnostic msg: /tmp/as-b5786d.sh
clang: note: diagnostic msg: 

********************

If the testcase is changed to:

#define AS __attribute__((address_space(3)))

int AS m;

int *foo(void)
{
  return (int *)(unsigned long)&m;
}

then the compilation succeeds without problems.

[ubizjak]

Forgot to paste the most important part of the backtrace:

fatal error: error in backend: Cannot select: 0x55aa9a239150: i64 = addrspacecast[3 -> 0] 0x55aa9a239380
  0x55aa9a239380: i64 = SystemZISD::PCREL_WRAPPER TargetGlobalAddress:i64<ptr addrspace(3) @m> 0
    0x55aa9a239310: i64 = TargetGlobalAddress<ptr addrspace(3) @m> 0
In function: foo

[uweigand]

Linux on SystemZ doesn't support multiple address spaces. What would you expect this program to do? On GCC, the attribute is simply ignored with:

warning: ‘address_space’ attribute directive ignored [-Wattributes]

An internal error is of course not nice, but I do think this should give some sort of error ...

[ubizjak]

Linux on SystemZ doesn't support multiple address spaces. What would you expect this program to do?

With my proposed patches [1], it will be possible to tag linux __percpu address space with e.g. __attribute__((address_space(3))), so the compiler will be able to check invalid cross-namespace pointer access even for targets that do not use __seg_gs named address space qualifier. An example that works for x86, arm64, riscv64 and loongson64 is at [2]. I tried this approach with s390 crosscompiler, but triggered the reported crash.

(Please note that a couple of additional typeof()s need to be changed to TYPEOF_UNQUAL() for each target, I can provide a patch for s390 on request).

On GCC, the attribute is simply ignored with:

warning: ‘address_space’ attribute directive ignored [-Wattributes]

Yes, GCC only provides "true" named address spaces (with qualifiers). clang is a bit more flexible here, so various "other" address spaces can be defined using address_space attribute. This functionality can be used for the compiler to perform various checks on __percpu variable accesses in a generic way.

Please also note related issue #119705 (triggered on arm64 with anonymous struct) and issue #93449 (triggered on x86_64 that prevents usage of __seg_gs named address space)

An internal error is of course not nice, but I do think this should give some sort of error ...

No, I think that __attribute__((address_space)) can enable various compiler checks, even when the defined address space is a subspace of the generic address space.

[uweigand]

Sorry for the delay, but I'd still like to get back to this.

Yes, GCC only provides "true" named address spaces (with qualifiers). clang is a bit more flexible here, so various "other" address spaces can be defined using address_space attribute. This functionality can be used for the compiler to perform various checks on __percpu variable accesses in a generic way.

The fundamental question, in my mind, is still about the semantics of those "other" address spaces. The named address space support in GCC and LLVM implements ISO/IEC TR 18037 section 5.1. This states in particular:

When not specified otherwise, objects are allocated by default in a generic address space,which corresponds to the single address space of ISO/IEC 9899:1999. In addition to the generic address space, an implementation may support other, named address spaces. Objects may be allocated in these alternate address spaces, and pointers may be defined that point to objects in these address spaces. It is intended that pointers into an address space only need be large enough to support the range of addresses in that address space.

Each address space other than the generic one has a unique name in the form of an identifier. Address space names are ordinary identifiers, sharing the same name space as variables and typedef names. Any such names follow the same rules for scope as other ordinary identifiers (such as typedef names). An implementation may provide an implementation-defined set of intrinsic address spaces that are, in effect, predefined at the start of every translation unit. The names of intrinsic address spaces must be reserved identifiers (beginning with an underscore and an uppercase letter or with two underscores). An implementation may also optionally support a means for new address space names to be defined within a translation unit.

I'm assuming these "other" address spaces would be covered by this optional implementation-defined rule, so that is fine.

Address spaces may overlap in a nested fashion. For any two address spaces, either the address spaces must be disjoint, they must be equivalent, or one must be a subset of the other. Other forms of overlapping are not permitted. If an object is in address space A and A is a subset of address space B, the object is simultaneously in address space B.
An implementation must define the relationship between all pairs of address spaces. (The complete set of address spaces includes the generic address space plus any address spaces that may be defined within a translation unit, if the implementation supports such definitions within a program.) There is no requirement that named address spaces (intrinsic or otherwise) be subsets of the generic address space.

However, the implementation must define the relationship between all pairs of address spaces, and this is part that is unclear to me: what is the relationship of those "other" address space to the generic address space (and possible other named address spaces the platform supports)?

As determined by its type, every pointer points into a specific address space, either the generic address space or a named address space. A pointer into an address space can only point to locations in that address space (including any subset ddress spaces).

A non-null pointer into an address space A can be cast to a pointer into another address space B, but such a cast is undefined if the source pointer does not point to a location in B. Note that if A is a subset of B, the cast is always valid; however, if B is a subset of A, the cast is valid only if the source pointer refers to a location in B. A null pointer into one address space can be cast to a null pointer into any overlapping address space.

That relationship is critical because it defines how cross-address-space pointer casts need to be implemented. Casts may either be invalid, or else the pointer may have to be adjusted to refer to the same location using its address in the target address space.

That has to be implemented by target-specific code that understands the relationships between address spaces. So those relationships have to be defined somehow, right?