Compilation error for std::variant using GCC's 7.1 libstdc++

[llvmbot]

Bugzilla Link	33222
Resolution	FIXED
Resolved on	Jun 11, 2019 10:38
Version	trunk
OS	Linux
Blocks	#38454
Attachments	Preprocessed source code, Full compilation error output
Reporter	LLVM Bugzilla Contributor
CC	@Nedra1998,@davidbolvansky,@drrlvn,@Dushistov,@egorpugin,@gemorin,@zmodem,@mizvekov,@zygoloid,@Tilka,@tstellar,@SuperV1234,@fiesh,@jwakely
Fixed by commit(s)	r341775 r341778 r345409 r345412

Extended Description

Simple std::variant code, compilation fails at line caling std::visit both with clang-4.0 and trunk. With GCC-7.1 compiles fine.

// CODE:

#include

struct A {};
struct B {};

struct Visitor
{
auto operator ()(A) -> void {}
auto operator ()(B) -> void {}
};

auto main() -> int
{
auto variant = std::variant<A, B>{ A{} };
visit(Visitor{}, variant);
}

// COMPILATION OUTPUT (STRIPPED):

$ clang++ -std=c++1z variant.cpp

/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1/variant:235:46: error: cannot cast 'std::variant<A, B>' to its private base class 'std::__detail::__variant::_Variant_storage<true, A, B>'
return __get(std::in_place_index<_Np>, std::forward<_Variant>(__v)._M_u);

// MY THOUGHTS:

std::variant contains friend declaration in its body:
https://github.com/gcc-mirror/gcc/blob/gcc-7_1_0-release/libstdc%2B%2B-v3/include/std/variant#L1154

for some reason it is ignored when compiling std::__detail::__variant::_get
https://github.com/gcc-mirror/gcc/blob/gcc-7_1_0-release/libstdc%2B%2B-v3/include/std/variant#L232

I'm not sure whether it's clang or libstdc++ bug

// SOFTWARE VERSIONS:

$ clang -v
clang version 4.0.0 (tags/RELEASE_400/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-pc-linux-gnu/7.1.1
Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.1.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1
Found candidate GCC installation: /usr/lib64/gcc/x86_64-pc-linux-gnu/7.1.1
Selected GCC installation: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.1.1
Candidate multilib: .;@m64
Selected multilib: .;@m64

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --disable-multilib --disable-werror --enable-checking=release
Thread model: posix
gcc version 7.1.1 20170516 (GCC)

[llvmbot]

Could this get some more attention, please? This makes unusable for the clang + libstdc++ combo, requiring either Boost.Variant or libc++.

[llvmbot]

reduced test case

[llvmbot]

I'm also affected by this.

I reported this to debian BTS as well:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877838

With the help of creduce, here's a "minimal" test-case that shows the problem:

$ cat variant.cpp
namespace __detail {
namespace __variant {

template
decltype(auto) _get(const T &t) {
return t.i;
}

}
}

template class variant {
public:
variant(const T &t) : i_(t) {}
template
friend decltype(auto) __detail::__variant::_get(const Type &);
private:
T i;
};

int main() {
variant v{2};
return __detail::__variant::__get(v);
}

$ g++-7 variant.cpp -std=c++1z
$ clang++-5.0 variant.cpp -std=c++1z
variant.cpp:6:12: error: 'i_' is a private member of 'variant'
return t.i_;
^
variant.cpp:24:31: note: in instantiation of function template
specialization '__detail::__variant::__get<variant >' requested
here
return __detail::__variant::_get(v);
^
variant.cpp:18:5: note: declared private here
T i;
^
1 error generated.

I suspect this might be related to the use of decltype(auto): if I change decltype(auto) to (e.g.) int, it works.

Thanks,

Daniele

[vittorioromeo]

This prevents <variant> from being usable with clang++ on most modern Linux distributions (and MinGW on Windows), unless -stdlib=libc++ is used.

This is a pretty major roadblock - is this being looked into?
Should this be sent to the libstdc++ bug tracker?

[vittorioromeo]

Minimal example to reproduce this:

template <typename U>
auto foo(U u)
{
    u.v;
}

template <typename T>
class X
{
    T v;

public:
    template <typename U>
    friend auto foo(U);
};

int main()
{
    ::foo(X<int>{});
}

This compiles on g++, but fails to compile on clang++ trunk.

Note that calling foo(X<int>{}) (unqualified) will have the same effect (works on g++, fails on clang++), but with a different error (ambiguous foo).

[jwakely]

This prevents <variant> from being usable with clang++ on most modern
Linux distributions (and MinGW on Windows), unless -stdlib=libc++ is used.

This is a pretty major roadblock - is this being looked into?
Should this be sent to the libstdc++ bug tracker?

I've added a workaround in https://gcc.gnu.org/r258854

[zygoloid]

Further reduced, this gives a 'conflicting types' error for 'foo':

auto foo();
template struct X {
friend auto foo();
};

[zygoloid]

Even this is rejected:

int f();
template struct X {
friend T f();
};

It looks like the function template and non-template function cases are actually two distinct bugs.

[zygoloid]

Comment#0 / comment#4 / comment#6 bugs fixed in r341778.
Comment#8 / comment #​9 bug fixed in r341775.

[tstellar]

Comment#0 / comment#4 / comment#6 bugs fixed in r341778.
Comment#8 / comment #​9 bug fixed in r341775.

Richard are these patches OK to merge to the release_70 branch?

[zygoloid]

Richard are these patches OK to merge to the release_70 branch?

Yes.

[tstellar]

Merged: r345409 r345412

[fiesh]

Using gcc-9's libstdc++, which changed the check from #if defined(__clang__) to #if defined(__clang__) && __clang_major__ <= 7, we get the same issue again with clang-8. Changing it to <= 8 works as a workaround again.

So it appears to not be fixed in clang-8.

[fiesh]

My bad, it only reports the same problem again because of the missing noexcept (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90397). Applying the patch also resolves this issue. So the bug is fixed in clang-8.

[jwakely]

My bad, it only reports the same problem again because of the missing
noexcept (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90397). Applying
the patch also resolves this issue. So the bug is fixed in clang-8.

That was Bug 41863 which has similar symptoms.