crash on `sys/wait.h` from glibc 2.17

[PHHargrove]

I am running clang-upc2c 3.9.1-1 20171002 on a Scientific Linux 7.5 system (RHEL clone, like Centos). This system uses glbc 2.17.

The following 2-line program crashes clang-upc2c:

#include <sys/wait.h>
int main(void) { return WEXITSTATUS(0); }

as show here:

$ upcc bug24a.c
upcc: error during UPC-to-C translation:
clang-upc2c: /home/upcnightly/llvm-upc/src/tools/clang-upc/lib/AST/DeclBase.cpp:1319: void clang::DeclContext::addHiddenDecl(clang::Decl*): Assertion `D->getLexicalDeclContext() == this && "Decl inserted into wrong lexical context"' failed.
gmake: *** [do-trans] Aborted (core dumped)

Since this was a debug build of clang-upc2c, here is the backtrace from the generated core:

#0  0x00007fcbeb591207 in raise () from /usr/lib64/libc.so.6
#1  0x00007fcbeb5928f8 in abort () from /usr/lib64/libc.so.6
#2  0x00007fcbeb58a026 in __assert_fail_base () from /usr/lib64/libc.so.6
#3  0x00007fcbeb58a0d2 in __assert_fail () from /usr/lib64/libc.so.6
#4  0x0000000001757461 in clang::DeclContext::addHiddenDecl (this=0x4e5c9a8, D=0x4e5bf18)
    at /home/upcnightly/llvm-upc/src/tools/clang-upc/lib/AST/DeclBase.cpp:1318
#5  0x0000000001757585 in clang::DeclContext::addDecl (this=0x4e5c9a8, D=0x4e5bf18)
    at /home/upcnightly/llvm-upc/src/tools/clang-upc/lib/AST/DeclBase.cpp:1344
#6  0x000000000041bec3 in (anonymous namespace)::RemoveUPCTransform::TransformDeclarationImpl (
    this=0x7fffbe6d2990, D=0x4e0b840, DC=0x4e28910)
    at /home/upcnightly/llvm-upc/src/tools/clang-upc/tools/upc2c/Transform.cpp:2095
#7  0x000000000041886b in (anonymous namespace)::RemoveUPCTransform::TransformDeclaration (this=0x7fffbe6d2990,
    D=0x4e0b840, DC=0x4e28910) at /home/upcnightly/llvm-upc/src/tools/clang-upc/tools/upc2c/Transform.cpp:1649
#8  0x000000000041d141 in (anonymous namespace)::RemoveUPCTransform::TransformTranslationUnitDecl (
    this=0x7fffbe6d2990, D=0x4d3d290)
    at /home/upcnightly/llvm-upc/src/tools/clang-upc/tools/upc2c/Transform.cpp:2254
#9  0x000000000041ff3b in (anonymous namespace)::RemoveUPCConsumer::HandleTranslationUnit (this=0x4d294a0,
    Context=...) at /home/upcnightly/llvm-upc/src/tools/clang-upc/tools/upc2c/Transform.cpp:2536
#10 0x0000000000990540 in clang::ParseAST (S=..., PrintStats=false, SkipFunctionBodies=false)
    at /home/upcnightly/llvm-upc/src/tools/clang-upc/lib/Parse/ParseAST.cpp:159
#11 0x000000000076df98 in clang::ASTFrontendAction::ExecuteAction (this=0x4d1cba0)
    at /home/upcnightly/llvm-upc/src/tools/clang-upc/lib/Frontend/FrontendAction.cpp:559
#12 0x000000000076da11 in clang::FrontendAction::Execute (this=0x4d1cba0)
    at /home/upcnightly/llvm-upc/src/tools/clang-upc/lib/Frontend/FrontendAction.cpp:459
#13 0x000000000071393a in clang::CompilerInstance::ExecuteAction (this=0x7fffbe6d85a0, Act=...)
    at /home/upcnightly/llvm-upc/src/tools/clang-upc/lib/Frontend/CompilerInstance.cpp:953
#14 0x0000000000660ac1 in clang::tooling::FrontendActionFactory::runInvocation (this=0x4d1cf00,
    Invocation=std::shared_ptr (empty) 0x0, Files=0x4d1b8d0, PCHContainerOps=std::shared_ptr (empty) 0x0,
    DiagConsumer=0x0) at /home/upcnightly/llvm-upc/src/tools/clang-upc/lib/Tooling/Tooling.cpp:333
#15 0x0000000000660923 in clang::tooling::ToolInvocation::runInvocation (this=0x7fffbe6d8e80,
    BinaryName=0x4d19d28 "/home/data2/upcnightly/dirac/llvm-upc/bin/clang-upc2c", Compilation=0x4d215a0,
    Invocation=std::shared_ptr (empty) 0x0, PCHContainerOps=std::shared_ptr (empty) 0x0)
    at /home/upcnightly/llvm-upc/src/tools/clang-upc/lib/Tooling/Tooling.cpp:309
#16 0x0000000000660752 in clang::tooling::ToolInvocation::run (this=0x7fffbe6d8e80)
    at /home/upcnightly/llvm-upc/src/tools/clang-upc/lib/Tooling/Tooling.cpp:294
#17 0x00000000004208fa in main (argc=45, argv=0x7fffbe6d93c8)
    at /home/upcnightly/llvm-upc/src/tools/clang-upc/tools/upc2c/Transform.cpp:2637

I wanted to provide a version of the reproducer with which one does not need to reproduce sys/wait.h from glibc 2.17. However, doing so seems to change the failure mode entirely:

{phargrov@pcp-d-9 ~}$ cat bug24b.c
int main(void) { return ((((__extension__ (((union { __typeof(0) __in; int __i; }) { .__in = (0) }).__i))) & 0xff00) >> 8); }
{phargrov@pcp-d-9 ~}$ upcc bug24b.c
upcc: error during UPC-to-C translation:
bug24b.c:1:18: error: non-void function 'user_main' should return a value [-Wreturn-type]
int main(void) { return ((((__extension__ (((union { __typeof(0) __in; int __i; }) { .__in = (0) }).__i))) & 0xff00) >> 8); }
                 ^
1 error generated.
gmake: *** [do-trans] Error 1

[PHHargrove]

Update. The macro call is not the problem. Just including the header is sufficient:

#include <sys/wait.h>

[nenadv]

Narrowed down to the lines of code that cause an assertion. Here is the simple case that does not include wait, ..

typedef union
  {
    union wait1 *__uptr;
  } __WAIT_STATUS1;

union wait1
  {
    int w_status;
#ifdef GOOD
    int __w_termsig;
#else
    struct
      {
         int __w_termsig;
      } __wait_terminated;
#endif
  };

int main (void) {}

Additional notes:

1. Struct inside the union wait1 causes the assertion

2. If you reverse the order of typedef and union declarations code compiles, no assertion (I did not verify that the code is correct.

[PHHargrove]

It appears this error (or perhaps similar on some other __extension__ in system headers) is now impacting a user of HipMer (an application of signifant current interest within the DOE):

https://groups.google.com/a/lbl.gov/d/msg/upc-users/Jmu9BtvaStw/P7BjVhhaAQAJ

[swatanabe]

AMDG

The root of the problem is that union wait1 is being processed twice. It's supposed to be handled when we reach the definition, but it gets processed earlier at union wait1 *__uptr

In Christ, Steven Watanabe

[swatanabe]

AMDG

I think this can be fixed by changing TransformTranslationUnitDecl to use TransformDecl instead of TransformDeclaration (avoiding duplicate processing) and changing TransformDecl to look up the correct DeclContext instead of assuming that they are always processed depth-first.

In Christ, Steven Watanabe