My compiler crashes .... but the online godbolt one doesn't ?!

Hi,

Crazy question, but would someone kind be able to help me a little here. I have

a clang 4.0 installation on my linux laptop, which crashes when compiling this

code fragment:

template <const int& X>

constexpr auto fn1() { return X; }

template

auto fn2()

{

return ( {

static constexpr auto value = 12;

return fn1();

})();

}

auto test()

{

return fn2();

}

However, doing the same on the godbolt clang 4.0.0 compiler doesn’t crash. What

I can’t work out is why!?

The is the command I run on my machine (using a clean checkout from the clang

svn repository) and the output given (the problem seems to be a non-instantiated

VarDecl in “LocalInstantiationScope::findInstantiationOf()” if you add debug

information to the compiler code at this point):

$ ~/Toolchains/clang-4.0/bin/clang++ -std=c++1z -O2 -S -o - test.cpp -v

clang version 4.0.0 (branches/release_40)

Target: x86_64-unknown-linux-gnu

Thread model: posix

InstalledDir: /home/user/Toolchains/clang-4.0/bin

Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6

Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.3.0

Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.3.0

Candidate multilib: .;@m64

Selected multilib: .;@m64

“/home/user/Toolchains/clang-4.0/bin/clang-4.0” -cc1 -triple

x86_64-unknown-linux-gnu -S -disable-free -main-file-name test.cpp

-mrelocation-model static -mthread-model posix -fmath-errno -masm-verbose

-mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64

-momit-leaf-frame-pointer -v -dwarf-column-info -debugger-tuning=gdb

-coverage-notes-file /home/user/test/-.gcno -resource-dir

/home/user/Toolchains/clang-4.0/bin/…/lib/clang/4.0.0 -internal-isystem

/usr/lib/gcc/x86_64-linux-gnu/6.3.0/…/…/…/…/include/c++/6.3.0

-internal-isystem

/usr/lib/gcc/x86_64-linux-gnu/6.3.0/…/…/…/…/include/x86_64-linux-gnu/c++/6.3.0

-internal-isystem

/usr/lib/gcc/x86_64-linux-gnu/6.3.0/…/…/…/…/include/x86_64-linux-gnu/c++/6.3.0

-internal-isystem

/usr/lib/gcc/x86_64-linux-gnu/6.3.0/…/…/…/…/include/c++/6.3.0/backward

-internal-isystem /usr/local/include -internal-isystem

/home/user/Toolchains/clang-4.0/bin/…/lib/clang/4.0.0/include

-internal-externc-isystem /usr/include/x86_64-linux-gnu

-internal-externc-isystem /include -internal-externc-isystem /usr/include -O2

-std=c++1z -fdeprecated-macro -fdebug-compilation-dir /home/user/test

-ferror-limit 19 -fmessage-length 92 -fobjc-runtime=gcc -fcxx-exceptions

-fexceptions -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops

-vectorize-slp -o - -x c++ test.cpp

clang -cc1 version 4.0.0 based upon LLVM 4.0.0 default target

x86_64-unknown-linux-gnu

ignoring nonexistent directory “/include”

ignoring duplicate directory

“/usr/lib/gcc/x86_64-linux-gnu/6.3.0/…/…/…/…/include/x86_64-linux-gnu/c++/6.3.0”

#include “…” search starts here:

#include <…> search starts here:

/usr/lib/gcc/x86_64-linux-gnu/6.3.0/…/…/…/…/include/c++/6.3.0

/usr/lib/gcc/x86_64-linux-gnu/6.3.0/…/…/…/…/include/x86_64-linux-gnu/c++/6.3.0

/usr/lib/gcc/x86_64-linux-gnu/6.3.0/…/…/…/…/include/c++/6.3.0/backward

/usr/local/include

/home/user/Toolchains/clang-4.0/bin/…/lib/clang/4.0.0/include

/usr/include/x86_64-linux-gnu

/usr/include

End of search list.

clang-4.0:

/home/user/Toolchains/clang-4.0/source/tools/clang/lib/Sema/

SemaTemplateInstantiate.cpp:2814: llvm::PointerUnion<Decl *,

LocalInstantiationScope::DeclArgumentPack *>

*clang::LocalInstantiationScope::findInstantiationOf(const clang::Decl *):

Assertion `isa(D) && “declaration not instantiated in this scope”’

failed.

0 clang-4.0 0x0000000001ac29e5

llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 37

1 clang-4.0 0x0000000001ac30b6

2 libpthread.so.0 0x00007f1fd115a0c0

3 libc.so.6 0x00007f1fcfceffff gsignal + 207

4 libc.so.6 0x00007f1fcfcf142a abort + 362

5 libc.so.6 0x00007f1fcfce8e67

6 libc.so.6 0x00007f1fcfce8f12

7 clang-4.0 0x0000000002f0ecb4

clang::LocalInstantiationScope::findInstantiationOf(clang::Decl const*) + 516

8 clang-4.0 0x0000000002f2f815

clang::Sema::FindInstantiatedDecl(clang::SourceLocation, clang::NamedDecl*,

clang::MultiLevelTemplateArgumentList const&) + 181

[…]

The same output from the godbolt compiler gives…

clang version 4.0.0 (tags/RELEASE_400/final 299826)

Target: x86_64-unknown-linux-gnu

Thread model: posix

InstalledDir: /opt/compiler-explorer/clang-4.0.0/bin

Found candidate GCC installation:

/opt/compiler-explorer/gcc-7.2.0/lib/gcc/x86_64-linux-gnu/7.2.0

Selected GCC installation:

/opt/compiler-explorer/gcc-7.2.0/lib/gcc/x86_64-linux-gnu/7.2.0

Candidate multilib: .;@m64

Selected multilib: .;@m64

“/opt/compiler-explorer/clang-4.0.0/bin/clang-4.0” -cc1 -triple

x86_64-unknown-linux-gnu -S -disable-free -disable-llvm-verifier

-discard-value-names -main-file-name example.cpp -mrelocation-model static

-mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases

-munwind-tables -fuse-init-array -target-cpu x86-64 -momit-leaf-frame-pointer -v

-dwarf-column-info -debug-info-kind=limited -dwarf-version=4

-debugger-tuning=gdb -coverage-notes-file

/tmp/compiler-explorer-compiler118118-58-1f6fedy.0ym1/output.gcno -resource-dir

/opt/compiler-explorer/clang-4.0.0/bin/…/lib/clang/4.0.0 -internal-isystem

/opt/compiler-explorer/gcc-7.2.0/lib/gcc/x86_64-linux-gnu/7.2.0/…/…/…/…/

include/c++/7.2.0 -internal-isystem

/opt/compiler-explorer/gcc-7.2.0/lib/gcc/x86_64-linux-gnu/7.2.0/…/…/…/…/

include/c++/7.2.0/x86_64-linux-gnu -internal-isystem

/opt/compiler-explorer/gcc-7.2.0/lib/gcc/x86_64-linux-gnu/7.2.0/…/…/…/…/

include/c++/7.2.0/backward -internal-isystem /usr/local/include

-internal-isystem

/opt/compiler-explorer/clang-4.0.0/bin/…/lib/clang/4.0.0/include

-internal-externc-isystem /usr/include/x86_64-linux-gnu

-internal-externc-isystem /include -internal-externc-isystem /usr/include -O2

-std=c++1z -fdeprecated-macro -fdebug-compilation-dir

/tmp/compiler-explorer-compiler118118-58-1f6fedy.0ym1 -ferror-limit 19

-fmessage-length 0 -fobjc-runtime=gcc -fcxx-exceptions -fexceptions

-fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp

-mllvm --x86-asm-syntax=intel -o

/tmp/compiler-explorer-compiler118118-58-1f6fedy.0ym1/output.s -x c++

clang -cc1 version 4.0.0 based upon LLVM 4.0.0 default target

x86_64-unknown-linux-gnu

ignoring nonexistent directory “/include”

#include “…” search starts here:

#include <…> search starts here:

/opt/compiler-explorer/gcc-7.2.0/lib/gcc/x86_64-linux-gnu/7.2.0/…/…/…/…/

include/c++/7.2.0

/opt/compiler-explorer/gcc-7.2.0/lib/gcc/x86_64-linux-gnu/7.2.0/…/…/…/…/

include/c++/7.2.0/x86_64-linux-gnu

/opt/compiler-explorer/gcc-7.2.0/lib/gcc/x86_64-linux-gnu/7.2.0/…/…/…/…/

include/c++/7.2.0/backward

/usr/local/include

/opt/compiler-explorer/clang-4.0.0/bin/…/lib/clang/4.0.0/include

/usr/include/x86_64-linux-gnu

/usr/include

End of search list.

Compiler returned: 0

Does anyone have an ideas why my compiler should crash? Would anybody please be

able to test my fragment and report if they also have a crash like me. I’ve

tried the 6.0.0 compiler too with the same results on my machine. I’m building

the 7.0.0 compiler now to see if the problem still occurs, but it looks like it

does (based on the rc-compiler I had already built).

(I have a bug report 39916 for a similar issue, but the code in the bug report

also exhibits problems on godbolt as well as my local compiler, producing both

invalid code and compiler crashes so I don’t think this is an isolated problem.)

Any help would be gratefully received – I am pulling my hair out trying to get

this code to work :o)

Thanks,

Andy

Possible that the online one isn’t built with assertions enabled (you could test this with other known crashers to see if they reproduce on godbolt with assertion crash dumps or only with raw segfaults)? If that’s the case,t hen it’s possible that the codepath that should assert continues on and perhaps either has unexpected or even undefined behavior but not a crash.

The snippet you show is already quite minimal, so its ok to file another bug specifically for that one.

Yes, it seems this is right. I have done a number of further tests and it seems that the godbolt compilers are built without asserts.

This, however, is a possible problem generally, isn’t it? I build my compilers always with release-asserts but I would guess it common that compiler builds are simply release builds. And this means, if there is a bug in the compiler, it may generate invalid code with no warning at all (my bug report gives an example of this) where in fact, if it were built with asserts then the bug would have been made visible (and maybe fixed!).

I know there can always be bugs which still act invisibly, but given that clang is good at sticking asserts everywhere in its code :o) isn’t it worth ensuring asserts are always enabled? i.e. build ‘release-asserts’ even when asked to do a release build?

Cheers,
Andy

Possible that the online one isn’t built with assertions enabled (you could test this with other known crashers to see if they reproduce on godbolt with assertion crash dumps or only with raw segfaults)? If that’s the case,t hen it’s possible that the codepath that should assert continues on and perhaps either has unexpected or even undefined behavior but not a crash.

Yes, it seems this is right. I have done a number of further tests and it seems that the godbolt compilers are built without asserts.

This, however, is a possible problem generally, isn’t it? I build my compilers always with release-asserts but I would guess it common that compiler builds are simply release builds. And this means, if there is a bug in the compiler, it may generate invalid code with no warning at all (my bug report gives an example of this) where in fact, if it were built with asserts then the bug would have been made visible (and maybe fixed!).

I know there can always be bugs which still act invisibly, but given that clang is good at sticking asserts everywhere in its code :o) isn’t it worth ensuring asserts are always enabled? i.e. build ‘release-asserts’ even when asked to do a release build?

Assertions are expensive (at one point the LLVM build system had a warning about builds with assertions enabled, that they may be 10x slower than without assertions) - so it’s not practical for most folks to run with them enabled for all their builds.

  • Dave