[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=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=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=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=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
