Bug 421704

Created attachment 128560 [details]
full backtrace

konqui seems to be bugged and can't send the crash as an attachment.

This is almost certainly a bug in libclang and needs to be reported there.

(In reply to Sven Brauch from comment #2)
> This is almost certainly a bug in libclang and needs to be reported there.

Agreed. This seems to be the deserialization of a stored AST, likely from a preamble. For a reproducer, you can try working with PCHs (http://clang.llvm.org/docs/PCHInternals.html). Since you're using the standard library, you'll want to work without -cc1.

With test.hpp: "#include <memory>" and test.cpp empty, run

    clang -fsyntax-only -std=c++2a test.hpp -Xclang -emit-pch >test.hpp.pch
    clang -c -std=c++2a -include-pch test.hpp.pch test.cpp -o test.s

I can't reproduce this here, but I haven't installed the update to GCC 10 yet, which also comes with a new libstdc++ that you're likely using here.

Concepts are pretty new, so I'm not surprised it's still a bit rough around the edges. Looking at the code, we're here (https://github.com/llvm/llvm-project/blob/llvmorg-10.0.0/clang/lib/Serialization/ASTReaderDecl.cpp#L2885-L2891):

    if (TX->hasTypeConstraint() != TY->hasTypeConstraint())
      return false;
    if (TX->hasTypeConstraint()) {
      const TypeConstraint *TXTC = TX->getTypeConstraint();
      const TypeConstraint *TYTC = TY->getTypeConstraint();
      if (TXTC->getNamedConcept() != TYTC->getNamedConcept())  // <---
        return false;

with either TXTC or TYTC being nullptr. This is a bit strange, since TX->hasTypeConstraint() and TY->hasTypeConstraint() are both true. But both functions check different flags (https://github.com/llvm/llvm-project/blob/llvmorg-10.0.0/clang/include/clang/AST/DeclTemplate.h#L1343-L1359):

  const TypeConstraint *getTypeConstraint() const {
    return TypeConstraintInitialized ? getTrailingObjects<TypeConstraint>() :
         nullptr;
  }

  bool hasTypeConstraint() const {
    return HasTypeConstraint;
  }

My recommendation (since we're talking about pretty recent code) would be to try a current master build and see if you can reproduce the issue there. There is bit of a chance that it is already fixed.

Since you're on Tumbleweed, you can also try 10.0.1-rc1 (https://build.opensuse.org/project/show/home:aaronpuchert:branches:devel:tools:compiler), but sometimes people forget to port back bug fixes.

The crash occurs because <memory> includes <ranges>, which includes a code pattern that triggers a bug.

For a minimal reproducer, see Bug 422716 Comment 2.

(In reply to Matt Whitlock from comment #4)
> For a minimal reproducer, see Bug 422716 Comment 2.

Thanks, that's what I've been looking for. I've used this in my upstream bug report https://bugs.llvm.org/show_bug.cgi?id=46355, I hope you don't mind.

(In reply to Aaron Puchert from comment #5)
> I hope you don't mind.

Not at all! I'm glad you were able to come up with an incantation that makes Clang crash when run from the command line. Thanks for catching my pass and running with it.

*** Bug 422716 has been marked as a duplicate of this bug. ***

Just FYI, this has been reported again as https://bugs.llvm.org/show_bug.cgi?id=46790 which was fixed in https://github.com/llvm/llvm-project/commit/73c12bd8ff1a9cd8375a357ea06f171e127ec1b8. The fix will be in Clang 11.