Crash on (rather ridiculous) pointer declaration

[GabrielRavier]

Bugzilla Link	52300
Version	trunk
OS	Linux
CC	@DougGregor,@zygoloid

Extended Description

#define PTR1 * * * * * * * * * *
#define PTR2 PTR1 PTR1 PTR1 PTR1 PTR1 PTR1 PTR1 PTR1 PTR1 PTR1
#define PTR3 PTR2 PTR2 PTR2 PTR2 PTR2 PTR2 PTR2 PTR2 PTR2 PTR2
#define PTR4 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3
#define PTR5 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4
#define PTR6 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5

int PTR4 q3_var = 0;

Trying to compile this crashes Clang, with this message:

Stack dump:
0. Program arguments: /usr/bin/clang-12 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all --mrelax-relocations -disable-free -disable-llvm-verifier -discard-value-names -main-file-name test.c -mrelocation-model static -mframe-pointer=all -fmath-errno -fno-rounding-math -mconstructor-aliases -munwind-tables -target-cpu x86-64 -tune-cpu generic -fno-split-dwarf-inlining -debugger-tuning=gdb -resource-dir /usr/lib64/clang/12.0.1 -internal-isystem /usr/local/include -internal-isystem /usr/lib64/clang/12.0.1/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdebug-compilation-dir /tmp/tmp.621xf1iUgA -ferror-limit 19 -fgnuc-version=4.2.1 -fcolor-diagnostics -faddrsig -o /tmp/test-5d4390.o -x c test.c

1.  test.c:8:5 <Spelling=test.c:1:28>: current parser token '*'
   

#​0 0x00007fa9c0d183f6 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/lib64/libLLVM-12.so+0xc063f6)
#​1 0x00007fa9c0d162e4 llvm::sys::RunSignalHandlers() (/lib64/libLLVM-12.so+0xc042e4)
#​2 0x00007fa9c0d16466 (/lib64/libLLVM-12.so+0xc04466)
#​3 0x00007fa9bfd61320 __restore_rt /usr/src/debug/glibc-2.33-20.fc34.x86_64/signal/../sysdeps/unix/sysv/linux/sigaction.c:675:0
#​4 0x00007fa9c6d1622b clang::DeclSpec::Finish(clang::Sema&, clang::PrintingPolicy const&) (/lib64/libclang-cpp.so.12+0x103c22b)
#​5 0x00007fa9c6703a47 clang::Parser::ParseTypeQualifierListOpt(clang::DeclSpec&, unsigned int, bool, bool, llvm::Optional<llvm::function_ref<void ()> >) (/lib64/libclang-cpp.so.12+0xa29a47)
#​6 0x00007fa9c66fe2a9 clang::Parser::ParseDeclaratorInternal(clang::Declarator&, void (clang::Parser::)(clang::Declarator&)) (/lib64/libclang-cpp.so.12+0xa242a9)
#​7 0x00007fa9c66fe2e1 clang::Parser::ParseDeclaratorInternal(clang::Declarator&, void (clang::Parser::)(clang::Declarator&)) (/lib64/libclang-cpp.so.12+0xa242e1)
#​8 0x00007fa9c66fe2e1 clang::Parser::ParseDeclaratorInternal(clang::Declarator&, void (clang::Parser::)(clang::Declarator&)) (/lib64/libclang-cpp.so.12+0xa242e1)
#​9 0x00007fa9c66fe2e1
[most of this stack dump omitted because I don't exactly wan
clang::Parser::ParseDeclaratorInternal(clang::Declarator&, void (clang::Parser::)(clang::Declarator&)) (/lib64/libclang-cpp.so.12+0xa242e1)
#​253 0x00007fa9c66fe2e1 clang::Parser::ParseDeclaratorInternal(clang::Declarator&, void (clang::Parser::)(clang::Declarator&)) (/lib64/libclang-cpp.so.12+0xa242e1)
#​254 0x00007fa9c66fe2e1 clang::Parser::ParseDeclaratorInternal(clang::Declarator&, void (clang::Parser::)(clang::Declarator&)) (/lib64/libclang-cpp.so.12+0xa242e1)
#​255 0x00007fa9c66fe2e1 clang::Parser::ParseDeclaratorInternal(clang::Declarator&, void (clang::Parser::*)(clang::Declarator&)) (/lib64/libclang-cpp.so.12+0xa242e1)
clang-12: error: unable to execute command: Segmentation fault (core dumped)
clang-12: error: clang frontend command failed due to signal (use -v to see invocation)

I can also confirm over on Godbolt that this seems to crash trunk Clang too: https://godbolt.org/z/j84dKe5qT

Final note, clang -c test.c makes the error completely silent (e.g. the output makes it seem as though compiling was successful, although the return value is at least 255), which seems especially odd.

[gysddn]

I might be wrong here but isn't this a predictable behavior, for what I know compilers don't impose a limit for this in the implementation but a machine does. On my machine it crashes on PTR4 with clang and on PTR6 with gcc, which I believe has to do more with how they're using the stack.
The standard says that an implementation should support at least 12 levels, which it does. I don't know if there is anything to do here.

[GabrielRavier]

It seems reasonable to me to expect the implementation not to crash (i.e. either to impose a limit or to avoid recursion in these circumstances), but I guess the current behavior might be just fine (although I do find it kind of poor). Have you been able to reproduce the version where it doesn't even output anything and just has the process return 126 ? (which is probably the most serious problem here)

[gysddn]

Nope, only the crash.

[AaronBallman]

https://reviews.llvm.org/D124915

[llvmbot]

@llvm/issue-subscribers-clang-frontend