[llvm-bugs] [Bug 51127] New: Clang segfaults when compiling code with std::variant

via llvm-bugs llvm-bugs at lists.llvm.org
Sat Jul 17 15:30:07 PDT 2021


https://bugs.llvm.org/show_bug.cgi?id=51127

            Bug ID: 51127
           Summary: Clang segfaults when compiling code with std::variant
           Product: clang
           Version: 12.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: cerg2010cerg2010 at mail.ru
                CC: llvm-bugs at lists.llvm.org, neeilans at live.com,
                    richard-llvm at metafoo.co.uk

Created attachment 25032
  --> https://bugs.llvm.org/attachment.cgi?id=25032&action=edit
stacktrace output

Consider this code snippet:

#include <variant>

struct Foo
{
    operator std::variant<int, float>()
    {
        return 0;
    }
};

constexpr void foo()
{
  std::variant<int, float, Foo> var1 = 0;
  std::variant<int, float> var2;
  var2 = std::visit([](auto arg) -> decltype(var2) { return arg; }, var1);
}

int main(int argc, char** argv)
{
    return 0;
}

Latest Clang release version (12.0.1 atm), as well as trunk and older versions
up to 3.9.0 which has -std=c++1z and variant header (tested on godbolt.org)
segfault when compiling this. GCC handles this code fine. Also it crashes with
both -stdlib=libc++ and -stdlib=libstdc++.

One particular thing which is interesting here is that if you replace return 0
in conversion function with return {}, the trunk version will compile this, but
12.0.1 will not. I've also had other variants of this code when adding a
newline at the end of file and removing it will determine the result. The
example provided here is the most stable to reproduce.

I've tried this mostly on godbolt.org, but it also successfully reproduces on
my local machine with Arch Linux (with clang version 12.0.1)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210717/9f5e4ae5/attachment.html>


More information about the llvm-bugs mailing list