ICE when using libcxx

[davidtwco]

When using libcxx and a simple example (unrelated to SYCL), then the compiler will ICE. This appears to be due to the use of __global in libcxx:

llvm/libcxx/include/__locale

Line 177 in eacc876

static locale& __global();

Example

// Originally from cppreference (https://en.cppreference.com/w/cpp/container/array)
#include <string>
#include <iterator>
#include <iostream>
#include <algorithm>
#include <array>

int main()
{
    // construction uses aggregate initialization
    std::array<int, 3> a1{ {1, 2, 3} }; // double-braces required in C++11 prior to the CWG 1270 revision
                                        // (not needed in C++11 after the revision and in C++14 and beyond)
    std::array<int, 3> a2 = {1, 2, 3};  // never required after =
    std::array<std::string, 2> a3 = { std::string("a"), "b" };

    // container operations are supported
    std::sort(a1.begin(), a1.end());
    std::reverse_copy(a2.begin(), a2.end(),
                      std::ostream_iterator<int>(std::cout, " "));

    std::cout << '\n';

    // ranged for loop is supported
    for(const auto& s: a3)
        std::cout << s << ' ';
}

Stack Trace

When invoked as ./bin/clang++ -std=c++11 -stdlib=libc++ repro.cpp -o repro with a build of eacc876:

clang-9: $project/llvm/include/llvm/ADT/StringSwitch.h:189: R llvm::StringSwitch<unsigned int, unsigned int>::operator unsigned int() [T = unsigned int, R = unsigned int]: Assertion `Result && "Fell off the end of a string-switch"' failed.
Stack dump:
0.      Program arguments: $project/build/bin/clang-9 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name repro.cpp -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb -resource-dir $project/build/lib/clang/9.0.0 -internal-isystem /usr/include/c++/v1 -internal-isystem /usr/local/include -internal-isystem $project/build/lib/clang/9.0.0/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c++11 -fdeprecated-macro -fdebug-compilation-dir $project/build/dtw/libcxx-repro -ferror-limit 19 -fmessage-length 0 -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /run/user/1000/repro-d15a61.o -x c++ repro.cpp -faddrsig
1.      /usr/include/c++/v1/__locale:139:20: current parser token '__global'
2.      /usr/include/c++/v1/__locale:50:1 <Spelling=/usr/include/c++/v1/__config:439:37>: parsing namespace 'std'
3.      /usr/include/c++/v1/__locale:50:1 <Spelling=/usr/include/c++/v1/__config:439:59>: parsing namespace 'std::__1'
4.      /usr/include/c++/v1/__locale:83:1: parsing struct/union/class body 'std::__1::locale'
 #0 0x0000000002ab3d19 llvm::sys::PrintStackTrace(llvm::raw_ostream&) $project/llvm/lib/Support/Unix/Signals.inc:494:11
 #1 0x0000000002ab3ec9 PrintStackTraceSignalHandler(void*) $project/llvm/lib/Support/Unix/Signals.inc:558:1
 #2 0x0000000002ab27d6 llvm::sys::RunSignalHandlers() $project/llvm/lib/Support/Signals.cpp:67:5
 #3 0x0000000002ab457b SignalHandler(int) $project/llvm/lib/Support/Unix/Signals.inc:357:1
 #4 0x00007fade03b9860 __restore_rt (/usr/lib/libpthread.so.0+0x12860)
 #5 0x00007faddfcdfbe0 raise (/usr/lib/libc.so.6+0x35be0)
 #6 0x00007faddfce0dc1 abort (/usr/lib/libc.so.6+0x36dc1)
 #7 0x00007faddfcd86e7 __assert_fail_base (/usr/lib/libc.so.6+0x2e6e7)
 #8 0x00007faddfcd8792 (/usr/lib/libc.so.6+0x2e792)
 #9 0x00000000031d5b05 llvm::StringSwitch<unsigned int, unsigned int>::operator unsigned int() $project/llvm/include/llvm/ADT/StringSwitch.h:190:23
#10 0x0000000006f20c35 getFutureCompatDiagKind(clang::IdentifierInfo const&, clang::LangOptions const&) $project/clang/lib/Lex/Preprocessor.cpp:761:5
#11 0x0000000006f20633 clang::Preprocessor::HandleIdentifier(clang::Token&) $project/clang/lib/Lex/Preprocessor.cpp:844:5
#12 0x0000000006e984c6 clang::Lexer::LexIdentifier(clang::Token&, char const*) $project/clang/lib/Lex/Lexer.cpp:1688:7
#13 0x0000000006e9dd8c clang::Lexer::LexTokenInternal(clang::Token&, bool) $project/clang/lib/Lex/Lexer.cpp:3444:5
#14 0x0000000006e9bb38 clang::Lexer::Lex(clang::Token&) $project/clang/lib/Lex/Lexer.cpp:3152:8
#15 0x0000000006f20cda clang::Preprocessor::Lex(clang::Token&) $project/clang/lib/Lex/Preprocessor.cpp:886:21
#16 0x0000000006ed103e clang::Preprocessor::CachingLex(clang::Token&) $project/clang/lib/Lex/PPCaching.cpp:65:7
#17 0x0000000006f20d19 clang::Preprocessor::Lex(clang::Token&) $project/clang/lib/Lex/Preprocessor.cpp:893:21
#18 0x0000000005713d37 clang::Parser::ConsumeToken() $project/clang/include/clang/Parse/Parser.h:453:12
#19 0x000000000573ca67 clang::Parser::ParseDeclaratorInternal(clang::Declarator&, void (clang::Parser::*)(clang::Declarator&)) $project/clang/lib/Parse/ParseDecl.cpp:5524:24
#20 0x00000000057252f8 clang::Parser::ParseDeclarator(clang::Declarator&) $project/clang/lib/Parse/ParseDecl.cpp:5387:1
#21 0x000000000575b0eb clang::Parser::ParseCXXMemberDeclaratorBeforeInitializer(clang::Declarator&, clang::VirtSpecifiers&, clang::ActionResult<clang::Expr*, true>&, clang::Parser::LateParsedAttrList&) $project/clang/lib/Parse/ParseDeclCXX.cpp:2302:5
#22 0x000000000575c85b clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier, clang::ParsedAttributes&, clang::Parser::ParsedTemplateInfo const&, clang::ParsingDeclRAIIObject*) $project/clang/lib/Parse/ParseDeclCXX.cpp:2670:7
#23 0x000000000575e891 clang::Parser::ParseCXXClassMemberDeclarationWithPragmas(clang::AccessSpecifier&, clang::Parser::ParsedAttributesWithRange&, clang::TypeSpecifierType, clang::Decl*) $project/clang/lib/Parse/ParseDeclCXX.cpp:3137:12
#24 0x0000000005759e2a clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, clang::SourceLocation, clang::Parser::ParsedAttributesWithRange&, unsigned int, clang::Decl*) $project/clang/lib/Parse/ParseDeclCXX.cpp:3317:7
#25 0x000000000575853f clang::Parser::ParseClassSpecifier(clang::tok::TokenKind, clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, bool, clang::Parser::DeclSpecContext, clang::Parser::ParsedAttributesWithRange&) $project/clang/lib/Parse/ParseDeclCXX.cpp:1954:7
#26 0x000000000573252c clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, clang::Parser::DeclSpecContext, clang::Parser::LateParsedAttrList*) $project/clang/lib/Parse/ParseDecl.cpp:3814:12
#27 0x000000000570e4fd clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec&, clang::AccessSpecifier) $project/clang/lib/Parse/Parser.cpp:1006:7
#28 0x000000000570e0f0 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*, clang::AccessSpecifier) $project/clang/lib/Parse/Parser.cpp:1111:12
#29 0x000000000570d9a0 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) $project/clang/lib/Parse/Parser.cpp:931:12
#30 0x000000000575124a clang::Parser::ParseInnerNamespace(llvm::SmallVector<clang::Parser::InnerNamespaceInfo, 4u> const&, unsigned int, clang::SourceLocation&, clang::ParsedAttributes&, clang::BalancedDelimiterTracker&) $project/clang/lib/Parse/ParseDeclCXX.cpp:246:7
#31 0x0000000005750bf4 clang::Parser::ParseNamespace(clang::DeclaratorContext, clang::SourceLocation&, clang::SourceLocation) $project/clang/lib/Parse/ParseDeclCXX.cpp:227:18
#32 0x000000000572e902 clang::Parser::ParseDeclaration(clang::DeclaratorContext, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) $project/clang/lib/Parse/ParseDecl.cpp:1747:14
#33 0x000000000570d64e clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) $project/clang/lib/Parse/Parser.cpp:885:16
#34 0x000000000575124a clang::Parser::ParseInnerNamespace(llvm::SmallVector<clang::Parser::InnerNamespaceInfo, 4u> const&, unsigned int, clang::SourceLocation&, clang::ParsedAttributes&, clang::BalancedDelimiterTracker&) $project/clang/lib/Parse/ParseDeclCXX.cpp:246:7
#35 0x0000000005750bf4 clang::Parser::ParseNamespace(clang::DeclaratorContext, clang::SourceLocation&, clang::SourceLocation) $project/clang/lib/Parse/ParseDeclCXX.cpp:227:18
#36 0x000000000572e9fd clang::Parser::ParseDeclaration(clang::DeclaratorContext, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) $project/clang/lib/Parse/ParseDecl.cpp:1753:12
#37 0x000000000570d500 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) $project/clang/lib/Parse/Parser.cpp:864:14
#38 0x000000000570bc7c clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&, bool) $project/clang/lib/Parse/Parser.cpp:682:12
#39 0x0000000005707051 clang::ParseAST(clang::Sema&, bool, bool) $project/clang/lib/Parse/ParseAST.cpp:158:16
#40 0x00000000035f0ca2 clang::ASTFrontendAction::ExecuteAction() $project/clang/lib/Frontend/FrontendAction.cpp:1037:1
#41 0x0000000003f4e05f clang::CodeGenAction::ExecuteAction() $project/clang/lib/CodeGen/CodeGenAction.cpp:1057:1
#42 0x00000000035f06c0 clang::FrontendAction::Execute() $project/clang/lib/Frontend/FrontendAction.cpp:938:7
#43 0x0000000003585970 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) $project/clang/lib/Frontend/CompilerInstance.cpp:946:7
#44 0x000000000377a164 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) $project/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:273:8
#45 0x00000000011b4e23 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) $project/clang/tools/driver/cc1_main.cpp:225:13
#46 0x00000000011a8981 ExecuteCC1Tool(llvm::ArrayRef<char const*>, llvm::StringRef) $project/clang/tools/driver/driver.cpp:309:5
#47 0x00000000011a7d11 main $project/clang/tools/driver/driver.cpp:381:5
#48 0x00007faddfcccb8e __libc_start_main (/usr/lib/libc.so.6+0x22b8e)
#49 0x00000000011a750a _start /build/glibc-2.27/csu/../sysdeps/x86_64/start.S:122:0
clang-9: error: unable to execute command: Aborted
clang-9: error: clang frontend command failed due to signal (use -v to see invocation)
clang version 9.0.0
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: $project/build/dtw/libcxx-repro/../../bin
clang-9: note: diagnostic msg: PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
clang-9: note: diagnostic msg:
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-9: note: diagnostic msg: /run/user/1000/repro-11d120.cpp
clang-9: note: diagnostic msg: /run/user/1000/repro-11d120.sh
clang-9: note: diagnostic msg:

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

[asavonic]

Although we can just rename the variable in libcxx, I wonder if we really need these __global, __local and __private aliases in SYCL. They should not be exposed to the users anyway, and for the SYCL library code we can use __attribute__((address_space(1))) syntax.

[agozillon]

I think ComputeCpp does or used to do something similar to what you suggest (perhaps for other reasons): https://developer.codeplay.com/products/computecpp/ce/api-reference/base_8h

Maybe @Ruyk or @Naghasan will be able to elaborate on it or correct me though if my assumption is wrong

[bader]

Another option is to use more OpenCL specific keywords (e.g. __opencl_global) instead of quite generic __global.
NOTE: address space are mapping is target dependent.

[Naghasan]

Although we can just rename the variable in libcxx, I wonder if we really need these __global, __local and __private aliases in SYCL. They should not be exposed to the users anyway

They need to be exposed somehow, as SYCL 1.2.1 defines interop type like global_ptr<T>::pointer, but it is up to the implementation to define the "how" as the definition is implementation defined.

I think the main problem here is that __global and co are keywords, which I believe is the root of the problem.

and for the SYCL library code we can use __attribute__((address_space(1))) syntax.

As @bader said, this sets a target address space, so its is actually different from the language address space.

I think ComputeCpp does or used to do something similar to what you suggest (perhaps for other reasons)

We expose the language address spaces as an attribute, which limits the exposure.

Another option is to use more OpenCL specific keywords (e.g. __opencl_global) instead of quite generic __global.

__global is defined by the OpenCL specs so you can't change it (e.g. https://www.khronos.org/registry/OpenCL/specs/opencl-1.2.pdf section 6.5.1). Although, does it need to a be a keyword ? Or can it be made context sensitive ?

Maybe @AnastasiaStulova has an opinion on this

[bader]

__global is defined by the OpenCL specs so you can't change it (e.g. https://www.khronos.org/registry/OpenCL/specs/opencl-1.2.pdf section 6.5.1). Although, does it need to a be a keyword ? Or can it be made context sensitive ?

We are not required to expose OpenCL address spaces using keywords defined the OpenCL spec. The option I mentioned tries to expose OpenCL concept using different keyword, although it might not solve the fundamental problem.

[AnastasiaStulova]

I think this is related to my earlier question about your overall approach to address spaces (#59 (comment))

There are obviously a multiple options available and whichever you select will affect the rest of your compilation flow I believe.

In C++ for OpenCL upstream we are using language address spaces just like we used in OpenCL C. They are enabled by both "__" prefixed spelling and without. However, it is still work in progress and it heavily relies on generic address space feature that I believe is not available in SYCL 1.2...

If you are using __attribute__((address_space(...))) in C++ code it has a lot less support at the moment and it's also being changed currently https://reviews.llvm.org/D62574. But it is fundamentally different because it is attached to a target and not to the language itself. It is therefore not intended to be portable between targets. I feel it might not be the best fit for SYCL. You might want to review RFC thread on this topic mentioned in the review.

[keryell]

In triSYCL we use __attribute__((address_space(...))) for now.