[Bug libstdc++/94164] [10 Regression] std::unintialized_fill_n fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94164 Laurent Stacul changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #3 from Laurent Stacul --- (In reply to Jonathan Wakely from comment #1) > That's not an iterator. Okay. Thanks for the information. When all the requirements are written it works. Let's close this one. Regards, Stac
[Bug libstdc++/94164] [10 Regression] std::unintialized_fill_n fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94164 --- Comment #2 from Laurent Stacul --- (In reply to Jonathan Wakely from comment #1) > That's not an iterator. Yes sure. I reduced my example to have the minimal example. I will add all de needed requirement of an iterator if needed.
[Bug libstdc++/94164] New: [Regression 10] std::unintialized_fill_n fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94164 Bug ID: 94164 Summary: [Regression 10] std::unintialized_fill_n fails to compile Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: laurent.stacul at gmail dot com Target Milestone: --- Hello, I have this piece of code: #include template struct ref { typedef T value_type; typedef T* pointer; typedef T& reference; typedef ptrdiff_t difference_type; typedef std::random_access_iterator_tag iterator_category; int d; explicit ref(int =0): d(-1) {} operator pointer() { if (d == -1) { return 0; } else { return reinterpret_cast(this + d); } } ref& operator++() { d += sizeof(value_type); return *this; } }; int main(int, const char *[]) { ref r; std::uninitialized_fill_n(r, 10, 'a'); return 0; } I compile it with the following command (the -std option is not important): $ g++ -Wall -Wextra -std=gnu++2a -c -o main.o main.cpp When I compile it with gcc (GCC) 10.0.1 20200305, if fails with the following error: /x86_64-v20.0.13/include/c++/10.0.1/bits/stl_algobase.h: In instantiation of 'constexpr _OutputIterator std::__fill_n_a(_OutputIterator, _Size, const _Tp&, std::random_access_iterator_tag) [with _OutputIterator = ref; _Size = int; _Tp = char]': /x86_64-v20.0.13/include/c++/10.0.1/bits/stl_algobase.h:1085:29: required from 'constexpr _OI std::fill_n(_OI, _Size, const _Tp&) [with _OI = ref; _Size = int; _Tp = char]' /x86_64-v20.0.13/include/c++/10.0.1/bits/stl_uninitialized.h:254:29: required from 'static _ForwardIterator std::__uninitialized_fill_n::__uninit_fill_n(_ForwardIterator, _Size, const _Tp&) [with _ForwardIterator = ref; _Size = int; _Tp = c har]' /x86_64-v20.0.13/include/c++/10.0.1/bits/stl_uninitialized.h:289:17: required from '_ForwardIterator std::uninitialized_fill_n(_ForwardIterator, _Size, const _Tp&) [with _ForwardIterator = ref; _Size = int; _Tp = char]' main.cpp:32:41: required from here /x86_64-v20.0.13/include/c++/10.0.1/bits/stl_algobase.h:1056:20: error: no matching function for call to '__fill_a(ref&, ref::pointer, const char&)' 1056 | std::__fill_a(__first, __first + __n, __value); | ~^ /x86_64-v20.0.13/include/c++/10.0.1/bits/stl_algobase.h:904:5: note: candidate: 'template constexpr void std::__fill_a(_FIte, _FIte, const _Tp&)' 904 | __fill_a(_FIte __first, _FIte __last, const _Tp& __value) | ^~~~ /x86_64-v20.0.13/include/c++/10.0.1/bits/stl_algobase.h:904:5: note: template argument deduction/substitution failed: /x86_64-v20.0.13/include/c++/10.0.1/bits/stl_algobase.h:1056:20: note: deduced conflicting types for parameter '_FIte' ('ref' and 'char*') 1056 | std::__fill_a(__first, __first + __n, __value); | ~^ /x86_64-v20.0.13/include/c++/10.0.1/bits/stl_algobase.h:909:5: note: candidate: 'template void std::__fill_a(const __gnu_debug::_Safe_iterator<_Ite, _Seq, _Cat>&, const __gnu_debug::_Safe_iterator<_Ite, _Seq , _Cat>&, const _Tp&)' 909 | __fill_a(const ::__gnu_debug::_Safe_iterator<_Ite, _Seq, _Cat>&, | ^~~~ /x86_64-v20.0.13/include/c++/10.0.1/bits/stl_algobase.h:909:5: note: template argument deduction/substitution failed: /x86_64-v20.0.13/include/c++/10.0.1/bits/stl_algobase.h:1056:20: note: 'ref' is not derived from 'const __gnu_debug::_Safe_iterator<_Ite, _Seq, _Cat>' 1056 | std::__fill_a(__first, __first + __n, __value); | ~^ /x86_64-v20.0.13/include/c++/10.0.1/bits/stl_algobase.h:1057:22: error: could not convert '(__first.ref::operator ref::pointer() + ((sizetype)__n))' from 'ref::pointer' {aka 'char*'} to 'ref' 1057 | return __first + __n; | ^ | | | ref::pointer {aka char*} make: *** [Makefile:6: main.o] Error 1 Conversely, this code compiles with gcc (GCC) 9.2.1. Maybe is it related to https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=6004c17b4d1a2dd1e1936b2e705a5ccfb6e48ab2 but I don' t know if the current bahviour is expected. Stac
[Bug lto/94138] [gcc10] unresolvable R_X86_64_TPOFF32 relocation against symbol when LTO activated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94138 --- Comment #12 from Laurent Stacul --- Ok I think we will not waste time on this one. Actually, the build system allows to force the standard version to build the libfolly.so (in out case gnu++20) but somehow the tests are build with -std=gnu++14. (If I twaek the whole build system to use gnu++20, the tests do no compile because GTest is not C++20-ready). So I think this ticket is invalid since we have to ensure some flags consistency between each compilation units of a project. For information, tt seems there is no problem in this situation if LTO is deactivated. Sorry for inconvenience and thanks for your investigation. Stac
[Bug lto/94138] [gcc10] unresolvable R_X86_64_TPOFF32 relocation against symbol when LTO activated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94138 --- Comment #9 from Laurent Stacul --- Here is the command line: g++ -E -DFOLLY_XLOG_STRIP_PREFIXES=\"/home/docker/development/opensource-pack-builder/components/folly/BUILD/folly-2020.03.02.00:/home/docker/development/opensource-pack-builder/components/folly/BUILD/folly-2020.03.02.00/_build_shared\" -D_GNU_SOURCE -D_REENTRANT -I../ -I. -I/home/docker/development/opensource-pack-builder/components/folly/DEPS/osp/Boost/latest/osp/include -I/home/docker/development/opensource-pack-builder/components/folly/DEPS/osp/DoubleConversion/latest/osp/include -I/home/docker/development/opensource-pack-builder/components/folly/DEPS/osp/Gflags/latest/osp/include -I/home/docker/development/opensource-pack-builder/components/folly/DEPS/osp/Glog/latest/osp/include -I/home/docker/development/opensource-pack-builder/components/folly/DEPS/osp/Libevent/latest/osp/include -I/home/docker/development/opensource-pack-builder/components/folly/DEPS/osp/OpenSSL/latest/osp/include -I/home/docker/development/opensource-pack-builder/components/folly/DEPS/osp/ZLib/latest/osp/include -I/home/docker/development/opensource-pack-builder/components/folly/DEPS/osp/BZip2/latest/osp/include -I/home/docker/development/opensource-pack-builder/components/folly/DEPS/osp/Aio/latest/osp/include -isystem /home/docker/development/opensource-pack-builder/components/folly/DEPS/osp/Gmock/latest/osp/include -isystem /home/docker/development/opensource-pack-builder/components/folly/DEPS/osp/Gtest/latest/osp/include -isystem /home/docker/development/opensource-pack-builder/components/folly/DEPS/osp/Fmt/latest/osp/include -DNDEBUG -O3 -flto -ffat-lto-objects -fuse-linker-plugin -std=gnu++20 -fno-working-directory -ggdb3 -Wno-error=maybe-uninitialized -Wno-error=shadow=compatible-local -Wno-error=array-bounds -Wno-error=stringop-overflow -O2 -g -DNDEBUG -fPIE -g -std=gnu++2a -finput-charset=UTF-8 -fsigned-char -Wall -Wno-deprecated -Wno-deprecated-declarations -Wno-sign-compare -Wno-unused -Wunused-label -Wunused-result -Wshadow-compatible-local -Wno-noexcept-type -faligned-new -fopenmp -std=gnu++14 -MD -MT CMakeFiles/cache_locality_test.dir/folly/concurrency/test/CacheLocalityTest.cpp.o -MF CMakeFiles/cache_locality_test.dir/folly/concurrency/test/CacheLocalityTest.cpp.o.d -o CMakeFiles/cache_locality_test.dir/folly/concurrency/test/CacheLocalityTest.cpp.o -c ../folly/concurrency/test/CacheLocalityTest.cpp
[Bug lto/94138] [gcc10] unresolvable R_X86_64_TPOFF32 relocation against symbol when LTO activated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94138 --- Comment #7 from Laurent Stacul --- Created attachment 48019 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48019&action=edit preprocessed sources
[Bug c++/93699] Invalid operator== (returning non-bool type) candidate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93699 --- Comment #4 from Laurent Stacul --- Sorry for this, I will follow your recommendations next time.
[Bug c++/93699] [gcc10] Invalid operator== (returning non-bool type) candidate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93699 --- Comment #1 from Laurent Stacul --- Please note that reversing b and d works fine: if (*b == *d) { // This does not work if (*d == *b) { // This is ok Regards, Stac
[Bug lto/94138] [gcc10] unresolvable R_X86_64_TPOFF32 relocation against symbol when LTO activated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94138 --- Comment #5 from Laurent Stacul --- I forgot to remove some arguments in the command: /opt/1A/toolchain/x86_64-v20/bin/g++ \ -O3 -Wl,-flto -ffat-lto-objects -fuse-linker-plugin \ CacheLocalityTest.cpp.o -o cache_locality_test -L. libfolly.so -pthread
[Bug lto/94138] [gcc10] unresolvable R_X86_64_TPOFF32 relocation against symbol when LTO activated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94138 --- Comment #4 from Laurent Stacul --- Well the problem of folly is that it requires lots of dependencies. What I can do is to isolate the link command with the needed files. Amongst all the link errors, you will get the described error. As the size is high, I put it there: https://www.transfernow.net/7TixXZ032020 You will have the libfolly.so built with LTO, the CacheLocalitytest.cpp.o and run.sh with the reduced command: /opt/1A/toolchain/x86_64-v20/bin/g++ \ -DNDEBUG \ -O3 -Wl,-flto -ffat-lto-objects -fuse-linker-plugin \ -fno-working-directory -ggdb3 -Wl,--as-needed -rdynamic \ CacheLocalityTest.cpp.o -o cache_locality_test -L. libfolly.so -pthread Tell me if it is helpful or if you need something else. Regards, Stac
[Bug lto/94138] [gcc10] unresolvable R_X86_64_TPOFF32 relocation against symbol when LTO activated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94138 --- Comment #2 from Laurent Stacul --- Created attachment 48016 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48016&action=edit preprocessed sources
[Bug lto/94138] [gcc10] unresolvable R_X86_64_TPOFF32 relocation against symbol when LTO activated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94138 --- Comment #1 from Laurent Stacul --- Created attachment 48015 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48015&action=edit preprocessed sources
[Bug lto/94138] New: [gcc10] unresolvable R_X86_64_TPOFF32 relocation against symbol when LTO activated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94138 Bug ID: 94138 Summary: [gcc10] unresolvable R_X86_64_TPOFF32 relocation against symbol when LTO activated Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: laurent.stacul at gmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Hello, I am trying to build Facebook Folly library and I have this linkage problem when LTO is activated. /gcc/x86_64-1a-linux-gnu/10.0.1/../../../../x86_64-1a-linux-gnu/bin/ld: cache_locality_test.ltrans0.ltrans.o(.text+0x45bb): unresolvable R_X86_64_TPOFF32 relocation against symbol `_ZN5folly14AccessSpreaderISt6atomicE8cpuCacheE' I tried to create a small reproducer of this error but I failed. So I fallback to sending you the preprocessed files in attachment. My system: $ uname -a Linux 6248633baf95 5.3.0-40-generic #32-Ubuntu SMP Fri Jan 31 20:24:34 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux $ ./libc.so.6 GNU C Library (GNU libc) stable release version 2.31. $ ./gcc --version gcc (GCC) 10.0.1 20200305 (experimental) $ ld --version GNU ld (GNU Binutils) 2.34.0.20200305 I will try to get a reproducer in parallel but for the time being being it is all I can provide. Tell me is you missed some files. If you need a quick look at the code: https://github.com/facebook/folly/blob/master/folly/concurrency/CacheLocality.h Thanks in advance for your help. Stac
[Bug libstdc++/93923] New: [Regression 10] std::is_copy_constructible raises compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93923 Bug ID: 93923 Summary: [Regression 10] std::is_copy_constructible raises compilation error Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: laurent.stacul at gmail dot com Target Milestone: --- Hello, The following code does not compile anymore with gcc 10 although it works in 9.2, 9.2, 8.x. #include #include class A; template struct B { template< class... Args, std::enable_if_t::value, int> = 0 > B(Args && ... args) {} }; struct A { A(const B& b) {} }; int main(int argc, const char *argv[]) { static_assert(std::is_copy_constructible::value); return 0; } Compiling with the HEAD of gcc 10 I have the following error: $ g++ is_constructible.cpp [jobs: 0][history: 5132] In file included from is_constructible.cpp:1: /remote/tools/Linux/2.6/1A/toolchain/x86_64-v20.0.10/include/c++/10.0.1/type_traits: In instantiation of ‘struct std::is_constructible’: is_constructible.cpp:10:75: required by substitution of ‘template::value, int>::type > B::B(Args&& ...) [with Args = {const A&}; typename std::enable_if::value, int>::type = ]’ /remote/tools/Linux/2.6/1A/toolchain/x86_64-v20.0.10/include/c++/10.0.1/type_traits:901:30: required from ‘struct std::__is_constructible_impl’ /remote/tools/Linux/2.6/1A/toolchain/x86_64-v20.0.10/include/c++/10.0.1/type_traits:930:12: required from ‘struct std::__is_copy_constructible_impl’ /remote/tools/Linux/2.6/1A/toolchain/x86_64-v20.0.10/include/c++/10.0.1/type_traits:936:12: required from ‘struct std::is_copy_constructible’ is_constructible.cpp:21:48: required from here /remote/tools/Linux/2.6/1A/toolchain/x86_64-v20.0.10/include/c++/10.0.1/type_traits:906:12: error: invalid use of incomplete type ‘struct std::__is_constructible_impl’ 906 | struct is_constructible |^~~~ /remote/tools/Linux/2.6/1A/toolchain/x86_64-v20.0.10/include/c++/10.0.1/type_traits:900:12: note: declaration of ‘struct std::__is_constructible_impl’ 900 | struct __is_constructible_impl |^~~ This is true in any standard versions (-std=c/gnu++14, c/gnu++17, c/gnu++2a, c++20). System information $ gcc --version gcc (GCC) 10.0.1 20200220 (experimental) Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ uname -a Linux ncerndobedev6196 4.12.14-95.45-default #1 SMP Wed Dec 11 13:09:13 UTC 2019 (12c8180) x86_64 x86_64 x86_64 GNU/Linux
[Bug lto/93609] gcc -flto -fno-comon places symbols into ".text" section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93609 --- Comment #6 from Laurent Stacul --- Thanks very much for information!
[Bug lto/93732] New: [10 Regression] Incorrect symbol type when activating LTO a compile step
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93732 Bug ID: 93732 Summary: [10 Regression] Incorrect symbol type when activating LTO a compile step Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: laurent.stacul at gmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Hello, With gcc (GCC) 10.0.1 20200211 and the following program: #ifdef __cplusplus extern "C" { #endif char nm_test_var; void nm_test_func(void); void nm_test_func(void){} #ifdef __cplusplus } #endif int main(){nm_test_var='a';nm_test_func();return(0);} If you compile with the LTO support, with the command: $ gcc -c -DNDEBUG -O3 -std=gnu17 -fno-working-directory -ggdb3 -flto -ffat-lto-objects -fuse-linker-plugin conftest.c The symbol nm_test_var will be flagged as in text section. $ nm conftest.o T main T nm_test_func T nm_test_var Whereas, compiling without LTO support as follow: $ $ gcc -c -DNDEBUG -O3 -std=gnu17 -fno-working-directory -ggdb3 -fno-lto -ffat-lto-objects -fuse-linker-plugin conftest.c Will give: $ nm conftest.o T main T nm_test_func B nm_test_var I also compared with gcc (GCC) 9.2.1 20191112. With or without LTO, the result is the same but the symbol nm_test_var is neither in the text section not in the BSS one, but in the common section: T main T nm_test_func C nm_test_var For info, this leads to errors when you build libtoolized libraries (error at configure step). Regards, Laurent
[Bug c++/93699] New: [gcc10] Invalid operator== (returning non-bool type) candidate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93699 Bug ID: 93699 Summary: [gcc10] Invalid operator== (returning non-bool type) candidate Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: laurent.stacul at gmail dot com Target Milestone: --- Hello, With a HEAD of gcc: gcc -v [jobs: 2][history: 5226] Reading specs from /remote/tools/Linux/2.6/1A/toolchain/x86_64-v20.0.8/bin/../lib/gcc/x86_64-1a-linux-gnu/10.0.1/specs COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/remote/tools/Linux/2.6/1A/toolchain/x86_64-v20.0.8/bin/../libexec/gcc/x86_64-1a-linux-gnu/10.0.1/lto-wrapper Target: x86_64-1a-linux-gnu Configured with: /workdir/src/gcc-10.0.1/configure --build=x86_64-1a-linux-gnu --host=x86_64-1a-linux-gnu --target=x86_64-1a-linux-gnu --prefix=/opt/1A/toolchain/x86_64-v20.0.8 --with-local-prefix=/opt/1A/toolchain/x86_64-v20.0.8 --with-native-system-header-dir=/opt/1A/toolchain/x86_64-v20.0.8/include --enable-languages=c,c++,fortran --disable-multilib --enable-linker-build-id --with-linker-hash-style=gnu --enable-gnu-indirect-function --with-build-config=bootstrap-lto --enable-install-libiberty --enable-checking=release Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.0.1 20200211 (experimental) (GCC) In the following example, I think there is something odd: class Base { public: virtual int operator==(const Base&) const { return 1; } }; class Derived : public Base { public: virtual int operator==(const Base&) const { return 1; } }; int main(int argc, const char *argv[]) { Base* b; Derived* d; if (*b == *d) { return 1; } return 0; } The compilation is done as follows: $ g++ -std=gnu++2a rep.cpp : In function 'int main(int, const char**)': :19:12: error: return type of 'virtual int Derived::operator==(const Base&) const' is not 'bool' 19 | if (*b == *d) { | ~~~^ :19:12: note: used as rewritten candidate for comparison of 'Base' and 'Derived' Compiler returned: 1 I understand that C++20 introduced the possibility for the compiler to have the reversed primary operator to be candidate in the function resolution, but as far as I understand the primary comparison operators are not rewritten. Is there a bug in the C++20 support or did I miss something ? Regards, Stac
[Bug c++/93618] [10 Regression] : unknown array size in delete when using C++20 standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93618 --- Comment #3 from Laurent Stacul --- Created attachment 47795 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47795&action=edit preprocessed sources
[Bug c++/93618] [10 Regression] : unknown array size in delete when using C++20 standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93618 --- Comment #2 from Laurent Stacul --- Ok. To ease your work I wrote this small reproducer: #include class A { struct State { int flag; std::atomic next_[]; }; void state(int f) { State s; s.flag = f; } State state_; }; $ >g++ -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -std=gnu++2a -c reproducer.cpp I attach the preprocessed source. Regards, Stac
[Bug c++/93618] New: [10 Regression] : unknown array size in delete when using C++20 standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93618 Bug ID: 93618 Summary: [10 Regression] : unknown array size in delete when using C++20 standard Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: laurent.stacul at gmail dot com Target Milestone: --- Hello, I tried to compile Re2 (https://github.com/google/re2) with a close to HEAD gcc: g++ (GCC) 10.0.1 20200124 (experimental) And I got the error described here: https://github.com/google/re2/issues/102. This one was fixed several years ago for gcc 6.1 & 6,2 through https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71147. Now with gcc 10 it works fine except when I add the flag -std=gnu++2a as you can see below: $ make CXXFLAGS="-std=gnu++2a" -j8 ... g++ -c -o obj/re2/dfa.o -std=c++11 -pthread -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -I. -std=gnu++2a -DNDEBUG re2/dfa.cc re2/dfa.cc: In constructor ‘constexpr re2::DFA::State::State()’: re2/dfa.cc:120:10: error: unknown array size in delete 120 | struct State { | ^ re2/dfa.cc: In member function ‘re2::DFA::State* re2::DFA::CachedState(int*, int, uint32_t)’: re2/dfa.cc:753:9: note: synthesized method ‘constexpr re2::DFA::State::State()’ first required here 753 | State state; | ^ Thanks in advance for you help, Stac
[Bug c++/92847] New: [C++20] ambiguous overload for ‘operator==’ ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92847 Bug ID: 92847 Summary: [C++20] ambiguous overload for ‘operator==’ ? Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: laurent.stacul at gmail dot com Target Milestone: --- Hello, Compiling the following reproducer with the gcc trunk and the option -std=gnu++2a (c++2a), I get the following error: #include template class A { public: A() {} template A(const A&) {} bool operator==(const A&) { return true; } }; int main(int argc, const char *argv[]) { A a; A b; if (a == b) {} return 0; } a.cpp: In function ‘int main(int, const char**)’: a.cpp:25:11: error: ambiguous overload for ‘operator==’ (operand types are ‘A >’ and ‘A >’) 25 | if (a == b) {} | ~ ^~ ~ | || | |A> | A> a.cpp:15:10: note: candidate: ‘bool A::operator==(const A&) [with T = std::__cxx11::basic_string]’ 15 | bool operator==(const A&) { | ^~~~ a.cpp:15:10: note: candidate: ‘bool A::operator==(const A&) [with T = const std::__cxx11::basic_string]’ When I compile with gcc 9.2, I have no issue. The generated code is the one I expect (implicit call to the constructor A, std::allocator > const>::A, std::allocator > >(A, std::allocator > > const&) then call to the A, std::allocator > const>::operator==(A, std::allocator > const> const&). Can you tell me which C++ 20 rule I am breaking here ? Thanks in advance for your reply, Laurent