[Bug c++/88323] implement C++20 language features.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88323 Romain Geissler changed: What|Removed |Added CC||romain.geissler at amadeus dot com --- Comment #1 from Romain Geissler --- Hi, With C++20 core feature being almost fully implemented (besides modules, but it seems modules are quite a beast and other compilers seem to also partially implement it for now), and with C++20 library feature also in a very advanced state (Jon even marked #88322 as implemented, though some bug/improvement tickets have been opened afterwards), and considering that gcc 15 will be released in 2025 leaving one year to polish the last C++20 issues, would it make sense to switch the default C++ dialect to C++20 for GCC 15 ?
[Bug libstdc++/114394] New: std::bind uses std::result_of which is deprecated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114394
Bug ID: 114394
Summary: std::bind uses std::result_of which is deprecated
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Created attachment 57738
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57738=edit
Tentative patch
Hi,
Clang >= 18 now prints a valid deprecation warning with this snippet:
#include
void f();
void g()
{
std::function a = std::bind();
}
Warning:
In file included from :1:
/opt/compiler-explorer/gcc-13.2.0/lib/gcc/x86_64-linux-gnu/13.2.0/../../../../include/c++/13.2.0/functional:552:2:
warning: 'result_of' is deprecated: use 'std::invoke_result'
instead [-Wdeprecated-declarations]
552 | using _Res_type_impl
| ^
/opt/compiler-explorer/gcc-13.2.0/lib/gcc/x86_64-linux-gnu/13.2.0/../../../../include/c++/13.2.0/functional:556:2:
note: in instantiation of template type alias '_Res_type_impl' requested here
556 | using _Res_type = _Res_type_impl<_Functor, _CallArgs,
_Bound_args...>;
| ^
/opt/compiler-explorer/gcc-13.2.0/lib/gcc/x86_64-linux-gnu/13.2.0/../../../../include/c++/13.2.0/functional:586:28:
note: in instantiation of template type alias '_Res_type' requested here
586 |typename _Result = _Res_type>>
| ^
:7:31: note: in instantiation of template class 'std::_Bind' requested here
7 | std::function a = std::bind();
| ^
/opt/compiler-explorer/gcc-13.2.0/lib/gcc/x86_64-linux-gnu/13.2.0/../../../../include/c++/13.2.0/type_traits:2590:9:
note: 'result_of' has been explicitly marked deprecated here
2590 | { } _GLIBCXX17_DEPRECATED_SUGGEST("std::invoke_result");
| ^
/opt/compiler-explorer/gcc-13.2.0/lib/gcc/x86_64-linux-gnu/13.2.0/../../../../include/c++/13.2.0/x86_64-linux-gnu/bits/c++config.h:122:45:
note: expanded from macro '_GLIBCXX17_DEPRECATED_SUGGEST'
122 | # define _GLIBCXX17_DEPRECATED_SUGGEST(ALT)
_GLIBCXX_DEPRECATED_SUGGEST(ALT)
| ^
/opt/compiler-explorer/gcc-13.2.0/lib/gcc/x86_64-linux-gnu/13.2.0/../../../../include/c++/13.2.0/x86_64-linux-gnu/bits/c++config.h:98:19:
note: expanded from macro '_GLIBCXX_DEPRECATED_SUGGEST'
98 | __attribute__ ((__deprecated__ ("use '" ALT "' instead")))
| ^
1 warning generated.
Compiler returned: 0
(see on Compiler Explorer: https://godbolt.org/z/3jxGr77Ye).
I tried very quickly the attached patch, which seems to fix the warning for me
(however I didn't really test it, so maybe it's not correct).
Note: I guess the fix will qualify for a backport in releases branches, in my
case I have hit this with gcc 13.
[Bug c++/114383] New: Wrong std::enable_if mangling ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114383
Bug ID: 114383
Summary: Wrong std::enable_if mangling ?
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
Following this bug on clang side:
https://github.com/llvm/llvm-project/issues/85656 where apparently clang folks
claim they fixed a mangling issue, I found out that clang >= 18 and gcc now
differ in mangling some std::enable_if expression. I am opening this bug to
track an potential mangling change needed on gcc side to be on par with the
current clang logic. I definitely don't have the knowledge to say which
mangling is correct, so I am going to trust clang folks who apparently changed
on purpose ;)
This snippet:
#include
template class SomeCondition
{
public:
static constexpr bool value = true;
};
template ::value,
int>::type = 0> void SomeFunction(const T&);
void f()
{
SomeFunction(0);
}
results in mangling the call to "SomeFunction" as
_Z12SomeFunctionIiTnNSt9enable_ifIXsr13SomeConditionIT_EE5valueEiE4typeELi0EEvRKS1_
by clang >= 18 while gcc for now mangles it as _Z12SomeFunctionIiLi0EEvRKT_.
Does gcc need any long term mangling change to handle this case ?
[Bug sanitizer/111057] [11/12/13 only] build error: libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp:180:10: fatal error: crypt.h: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111057 Romain Geissler changed: What|Removed |Added CC||romain.geissler at amadeus dot com --- Comment #6 from Romain Geissler --- @Chris the gcc maintainers don't really review patches send in bug reports, they expect it to be sent on the mailing list (gcc-patc...@gcc.gnu.org). Do you want to post it there so this gets integrated ?
[Bug libstdc++/105562] [12 Regression] std::function::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105562 --- Comment #28 from Romain Geissler --- Ok it's clear. I haven't really played yet with sanitizers, I didn't know it had these well known "issue" with creating more middle end false positive warnings (I am used to them in LTO mode). So I will advise that we relax warning severity/disable some warnings in my company when using sanitizers. Thanks !
[Bug libstdc++/105562] [12 Regression] std::function::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105562 --- Comment #25 from Romain Geissler --- So it means we should rather go for "silencing" workaround from comment #19 ?
[Bug libstdc++/105562] [12 Regression] std::function::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105562 Romain Geissler changed: What|Removed |Added CC||romain.geissler at amadeus dot com --- Comment #23 from Romain Geissler --- Hi, We have also hit an occurence of this bug while using address sanitizer and gcc 13. I see in comment #22 Jakub proposes to re-open this ticket, but I can re-create a dedicated one just for the ASAN related issue if you prefer. I don't know if the proposal to silence this warning made by Jonathan in #19 is considered a "long term fix" for this or just a temporary solution until the internal compiler bug is fixed. Cheers, Romain
[Bug tree-optimization/106238] [12/13/14 regression] Inline optimization causes dangling pointer warning on "include/c++/12.1.0/bits/stl_tree.h"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106238 --- Comment #10 from Romain Geissler --- Hi, It seems the reproducers from comment #1 and #5 don't happen anymore with gcc 13 or trunk. So it seems fixed. Cheers, Romain
[Bug c/107954] Support -std=c23/gnu23 as aliases of -std=c2x/gnu2x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107954 --- Comment #4 from Romain Geissler --- In the latest agenda published (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3156.pdf) it seems that now the next C revision has been delayed a bit. At this point, is it known already if it will be officially called C23 or C24 ?
[Bug libstdc++/110133] New: System error message should ideally use strerror_r over strerror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110133 Bug ID: 110133 Summary: System error message should ideally use strerror_r over strerror Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: romain.geissler at amadeus dot com Target Milestone: --- Hi, Checking the source code, it seems that the underlying implementation of generic_category/system_category message() function uses this code: return string(strerror(i)); which happens to be thread safe when targetting glibc, but that remains an implementation details, and not necessarily all libc implement this behavior. Ideally strerror_r shall be used when available. Note that unfortunately, glibc has two strerror_r implementations, with a different return type and thus a different behavior. As an example to cope with both behavior libc++ choose to use this overloading mechanism: https://github.com/llvm/llvm-project/blob/2bd82c5462d511f1e58e7d9a4dcd5628cd16a32d/libcxx/src/system_error.cpp#LL114C8-L114C21 In the gcc project, the maintainers of libgfortran have implemented a similar change this way: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=723553bdc16695ecc686a2ffdff6d15bd600b676;hp=62f9aedcd0a97001f290a1c13fa66efd207a23cc
[Bug c++/109918] New: Unexpected -Woverloaded-virtual with virtual conversion operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109918
Bug ID: 109918
Summary: Unexpected -Woverloaded-virtual with virtual
conversion operators
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
Now that the -Woverloaded-virtual=1 is enabled by default with -Wall, the
following code raises warning while I think it should not (for the specific
case of conversion operators):
#include
struct A
{
virtual operator int() { return 42; }
virtual operator char() = 0;
};
struct B : public A
{
operator char() override { return 'A'; }
};
int main()
{
B b;
std::cout << static_cast(b) << std::endl; // int conversion was not
hiden, contrary to what -Woverloaded-virtual claims
std::cout << static_cast(b) << std::endl;
}
Godbolt link: https://godbolt.org/z/4Wb9rxbMP
Compiled with -Wall, it raises this warning:
:5:13: warning: 'virtual A::operator int()' was hidden
[-Woverloaded-virtual=]
5 | virtual operator int() { return 42; }
| ^~~~
: note: by 'operator'
ASM generation compiler returned: 0
:5:13: warning: 'virtual A::operator int()' was hidden
[-Woverloaded-virtual=]
5 | virtual operator int() { return 42; }
| ^~~~
: note: by 'operator'
Execution build compiler returned: 0
Program returned: 0
42
A
I have hit this issue in a real code base, while migrating to gcc 13.
Cheers,
Romain
[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 --- Comment #31 from Romain Geissler --- Ok thanks for confirming. I was about to ask for a deployment one of our gcc-based toolchain in production containing the current gcc 13.1.1, I will wait a bit that this patch lands in the gcc 13 branch then. And in the future I will pay more attention to newly added symbols/gnu versions in minor version of libstdc++ why deploying new toolchains then ;)
[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 --- Comment #29 from Romain Geissler --- Typo: If yes, given that you also maintain the gcc package in fedora 38 (https://src.fedoraproject.org/rpms/gcc/commits/f38), does it mean that something built in some future up to date Fedora 38 won't run on an old "unpatched"/"not up to date" fedora 38 ?
[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 Romain Geissler changed: What|Removed |Added CC||romain.geissler at amadeus dot com --- Comment #28 from Romain Geissler --- Hi, Sorry to jump here, but I wish to clarify something. If I understood the commit message/diff correctly, I expect that this commit will eventually land in the gcc 13 branch, not just in master, right ? So let's imagine gcc 13.2.0 is released with this, it will mean that a binary (including ) built with gcc 13.2.0 won't be runnable with the runtime of gcc 13.1.0 ? If yes, given that you also maintain the gcc package in fedora 38 (https://src.fedoraproject.org/rpms/gcc/commits/f38), does it mean that something build in some future up to date Fedora 38 won't build on an old "unpatched" fedora 38 ? In other words, in general, is there any guarantee that something built using gcc N.X.0 can be run with the runtime of gcc N.Y.0 for X > Y ? (I am not speaking about mixing gcc 13 with gcc 12, but point releases of gcc 13). Cheers, Romain
[Bug libstdc++/109602] Import Gentoo msgfmt patch ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109602 --- Comment #5 from Romain Geissler --- Hi, My intention was to try to raise upstream an issue that people packaging gcc may hit in some cases. Gentoo has such a patch, but I also have a similar one on my side since couple of years, it's only yesterday that I discovered Gentoo had one too (and Alpine Linux). I am not a user of Gentoo nor Alpine Linux myself, I just also package my own gcc. So I apologize to the Gentoo and Gcc communities if I offended anyone by opening this bug report, that was not the intention. Cheers, Romain
[Bug libstdc++/109602] New: Import Gentoo msgfmt patch ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109602 Bug ID: 109602 Summary: Import Gentoo msgfmt patch ? Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: romain.geissler at amadeus dot com Target Milestone: --- Hi, I am wondering, would it make sense to import Gentoo's msgfmt patch ? In some occasion, it seems that the build system of gcc/libstdc++ wrongly sets LD_LIBRARY_PATH when building (in case it helps, in my case it seems to happens only when doing a gcc bootstrap). I am speaking about this patch: https://gitweb.gentoo.org/proj/gcc-patches.git/tree/10.3.0/gentoo/36_all_msgfmt-libstdc++-link.patch?id=6fb906ef2da01327d64cea263887ef34c97c1bbf and more globally about this set of Gentoo bugs https://bugs.gentoo.org/372377 or https://bugs.gentoo.org/843119 It seems at least Alpine Linux also carries this patch: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/gcc/0009-Ensure-that-msgfmt-doesn-t-encounter-problems-during.patch I understand the underlying issue is more that LD_LIBRARY_PATH shouldn't be set, but it seems past investigations didn't really lead to finding this root cause (see bug #105688), so in the meantime, maybe this workaround patch should be imported in upstream tree directly. It's just a proposal, I would understand this is refused. Cheers, Romain
[Bug tree-optimization/106238] Inline optimization causes dangling pointer on "include/c++/12.1.0/bits/stl_tree.h"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106238 --- Comment #7 from Romain Geissler --- Another case in real life code base (in this case Boost): https://github.com/boostorg/algorithm/pull/113
[Bug tree-optimization/106238] Inline optimization causes dangling pointer on "include/c++/12.1.0/bits/stl_tree.h"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106238
--- Comment #6 from Romain Geissler ---
Hi,
After upgrading to the latest gcc trunk, I have hit another variant of this
problem. For people just willing to exchange containers with swap, just
swapping the arguments makes it work, and actually has the same logic:
#include
void f(std::set& a)
{
std::set b;
// b.swap(a); // Ok and has same effect
a.swap(b); // KO
}
Compiled on x86_64 with -O2 -Werror=dangling-pointer:
In file included from
/opt/compiler-explorer/gcc-trunk-20230314/include/c++/13.0.1/set:62,
from :1:
In member function 'void std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::swap(std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>&) [with
_Key = int; _Val = int; _KeyOfValue = std::_Identity; _Compare =
std::less; _Alloc = std::allocator]',
inlined from 'void std::set<_Key, _Compare, _Alloc>::swap(std::set<_Key,
_Compare, _Alloc>&) [with _Key = int; _Compare = std::less; _Alloc =
std::allocator]' at
/opt/compiler-explorer/gcc-trunk-20230314/include/c++/13.0.1/bits/stl_set.h:443:18,
inlined from 'void f(std::set&)' at :8:11:
/opt/compiler-explorer/gcc-trunk-20230314/include/c++/13.0.1/bits/stl_tree.h:2092:36:
error: storing the address of local variable 'b' in '*MEM[(struct
_Rb_tree_node_base * &) + 16].std::_Rb_tree_node_base::_M_parent'
[-Werror=dangling-pointer=]
2092 | __t._M_root()->_M_parent = __t._M_end();
| ~^~
: In function 'void f(std::set&)':
:5:19: note: 'b' declared here
5 | std::set b;
| ^
:5:19: note: 'b.std::set, std::allocator
>::_M_t.std::_Rb_tree, std::less,
std::allocator >::_M_impl.std::_Rb_tree,
std::less, std::allocator >::_Rb_tree_impl,
true>::.std::_Rb_tree_header::_M_header.std::_Rb_tree_node_base::_M_parent'
declared here
cc1plus: some warnings being treated as errors
Compiler returned: 1
[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608 --- Comment #34 from Romain Geissler --- >From what I wrote here https://sourceware.org/pipermail/libc-alpha/2022-November/143633.html apparently I already tried gcc 12 back in end of november 2022 and all float issues in glibc testsuite were gone. I didn't test gcc 12 since then.
[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608 --- Comment #32 from Romain Geissler --- Hi, Thanks for the fix, indeed it has fixed quite some glibc maths tests ;) FYI, most likely it's totally unrelated to this bug, for right now with latest gcc trunk and glibc trunk on x86-64, I still see the following iseqsig errors: FAIL: math/test-double-iseqsig FAIL: math/test-float-iseqsig FAIL: math/test-float128-iseqsig FAIL: math/test-float32-iseqsig FAIL: math/test-float32x-iseqsig FAIL: math/test-float64-iseqsig FAIL: math/test-float64x-iseqsig FAIL: math/test-ldouble-iseqsig Cheers, Romain
[Bug tree-optimization/108374] [12/13 Regression] unexpected -Wstringop-overflow when using std::atomic and std::shared_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108374 --- Comment #1 from Romain Geissler --- I forgot to mention: this happens on x86-64 with -O1.
[Bug tree-optimization/108374] New: [12/13 Regression] unexpected -Wstringop-overflow when using std::atomic and std::shared_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108374
Bug ID: 108374
Summary: [12/13 Regression] unexpected -Wstringop-overflow when
using std::atomic and std::shared_ptr
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
The following snippet produces an unexpected -Wstringop-overflow with gcc 12
and current trunk:
#include
#include
struct A: public std::enable_shared_from_this
{
std::atomic _attr;
};
void f(std::shared_ptr pointer)
{
std::weak_ptr weakPointer(pointer);
[[maybe_unused]] const unsigned int aAttr = weakPointer.lock()->_attr;
}
Compiler Explorer output:
In file included from
/opt/compiler-explorer/gcc-trunk-20230111/include/c++/13.0.0/atomic:41,
from :1:
In member function 'std::__atomic_base<_IntTp>::__int_type
std::__atomic_base<_IntTp>::load(std::memory_order) const [with _ITp = long
unsigned int]',
inlined from 'std::__atomic_base<_IntTp>::operator __int_type() const [with
_ITp = long unsigned int]' at
/opt/compiler-explorer/gcc-trunk-20230111/include/c++/13.0.0/bits/atomic_base.h:365:20,
inlined from 'void f(std::shared_ptr)' at :13:69:
/opt/compiler-explorer/gcc-trunk-20230111/include/c++/13.0.0/bits/atomic_base.h:505:31:
error: 'long unsigned int __atomic_load_8(const volatile void*, int)' writing 8
bytes into a region of size 0 overflows the destination
[-Werror=stringop-overflow=]
505 | return __atomic_load_n(&_M_i, int(__m));
|~~~^
In function 'void f(std::shared_ptr)':
cc1plus: note: destination object is likely at address zero
cc1plus: some warnings being treated as errors
Compiler returned: 1
I have found bug #104475 which seems to also deal with atomics and
-Wstringop-overflow however I can't judge if it looks like a duplicate or a
different issue.
Cheers,
Romain
[Bug tree-optimization/106238] Inline optimization causes dangling pointer on "include/c++/12.1.0/bits/stl_tree.h"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106238
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
--- Comment #5 from Romain Geissler ---
Hi,
This seems to still happen with current trunk:
#include
std::map _Map;
void f()
{
std::map localMap;
_Map.swap(localMap);
}
compiled with -Wall -Werror -O2:
In file included from
/opt/compiler-explorer/gcc-trunk-20230108/include/c++/13.0.0/map:62,
from :1:
In member function 'void std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::swap(std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>&) [with
_Key = int; _Val = std::pair; _KeyOfValue =
std::_Select1st >; _Compare = std::less; _Alloc
= std::allocator >]',
inlined from 'void std::map<_Key, _Tp, _Compare,
_Alloc>::swap(std::map<_Key, _Tp, _Compare, _Alloc>&) [with _Key = int; _Tp =
int; _Compare = std::less; _Alloc = std::allocator >]' at
/opt/compiler-explorer/gcc-trunk-20230108/include/c++/13.0.0/bits/stl_map.h:1172:18,
inlined from 'void f()' at :8:14:
/opt/compiler-explorer/gcc-trunk-20230108/include/c++/13.0.0/bits/stl_tree.h:2091:36:
error: storing the address of local variable 'localMap' in '*MEM[(struct
_Rb_tree_node_base * &) + 16].std::_Rb_tree_node_base::_M_parent'
[-Werror=dangling-pointer=]
2091 | __t._M_root()->_M_parent = __t._M_end();
| ~^~
: In function 'void f()':
:7:24: note: 'localMap' declared here
7 | std::map localMap;
|^~~~
:7:24: note: 'localMap.std::map,
std::allocator > >::_M_t.std::_Rb_tree, std::_Select1st >,
std::less, std::allocator >
>::_M_impl.std::_Rb_tree,
std::_Select1st >, std::less,
std::allocator > >::_Rb_tree_impl,
true>::.std::_Rb_tree_header::_M_header.std::_Rb_tree_node_base::_M_parent'
declared here
cc1plus: all warnings being treated as errors
Compiler returned: 1
Cheers,
Romain
[Bug c++/108165] -Wdangling-reference false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165 --- Comment #3 from Romain Geissler --- In my real life case B was std::string and used a "string literal" at call site, and I guess using the implicit conversion from const char[] to std::string is something that might happen in many call sites in big code bases. Is it expected that -Wdangling-reference doesn't take into account the definition of f ? The problem of dangling reference in general needs function definitions to be effective, otherwise I fear there might be quite some false positives.
[Bug c++/108165] New: -Wdangling-reference false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165 Bug ID: 108165 Summary: -Wdangling-reference false positive Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: romain.geissler at amadeus dot com Target Milestone: --- Hi, The following snippet issues a wrong -Wdangling-reference warning when compiled with -Wall with current gcc trunk: <: In function 'const A& g(const A&)': :13:14: warning: possibly dangling reference to a temporary [-Wdangling-reference] 13 | const A& result = f(a, 42); | ^~ :13:24: note: the temporary was destroyed at the end of the full expression 'f((* & a), B(42))' 13 | const A& result = f(a, 42); | ~^~~ ASM generation compiler returned: 0 : In function 'const A& g(const A&)': :13:14: warning: possibly dangling reference to a temporary [-Wdangling-reference] 13 | const A& result = f(a, 42); | ^~ :13:24: note: the temporary was destroyed at the end of the full expression 'f((* & a), B(42))' 13 | const A& result = f(a, 42); | ~^~~
[Bug c++/108077] [13 Regression] Can't brace initialize container of llvm::opt::OptSpecifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108077 Romain Geissler changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Romain Geissler --- Indeed this is working now after Jason reverted his commit as mentioned in Bug 108071. I close this ticket.
[Bug c++/108077] New: [13 Regression] Can't brace initialize container of llvm::opt::OptSpecifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108077
Bug ID: 108077
Summary: [13 Regression] Can't brace initialize container of
llvm::opt::OptSpecifier
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
I can't build llvm 15 with the current gcc 13, while it was working a few weeks
ago.
I tried to reduce a bit, and I have ended up with this snippet (compiled with
-std=gnu++17):
<
class OptSpecifier {
unsigned ID = 0;
public:
explicit OptSpecifier(bool) = delete; // Works if this is commented
OptSpecifier(unsigned ID) : ID(ID) {}
};
//void f(llvm::ArrayRef) {}
void f(std::list) {}
int main()
{
f({1U, 2U, 3U}); // Works
f({1, 2, 3}); // Fails with gcc 13
}
END_OF_FILE
According to Compiler Explorer, this seems to build fine with any clang
version, and any gcc <= 12, but not with current gcc 13 trunk. The error is the
following:
In file included from
/opt/compiler-explorer/gcc-trunk-20221212/include/c++/13.0.0/x86_64-linux-gnu/bits/c++allocator.h:33,
from
/opt/compiler-explorer/gcc-trunk-20221212/include/c++/13.0.0/bits/allocator.h:46,
from
/opt/compiler-explorer/gcc-trunk-20221212/include/c++/13.0.0/list:63,
from :1:
/opt/compiler-explorer/gcc-trunk-20221212/include/c++/13.0.0/bits/new_allocator.h:
In instantiation of 'void std::__new_allocator<_Tp>::construct(_Up*, _Args&&
...) [with _Up = OptSpecifier; _Args = {const int&}; _Tp =
std::_List_node]':
/opt/compiler-explorer/gcc-trunk-20221212/include/c++/13.0.0/bits/alloc_traits.h:524:17:
required from 'static void std::allocator_traits
>::construct(allocator_type&, _Up*, _Args&& ...) [with _Up = OptSpecifier;
_Args = {const int&}; _Tp = std::_List_node; allocator_type =
std::allocator >]'
/opt/compiler-explorer/gcc-trunk-20221212/include/c++/13.0.0/bits/stl_list.h:713:33:
required from 'std::__cxx11::list<_Tp, _Alloc>::_Node*
std::__cxx11::list<_Tp, _Alloc>::_M_create_node(_Args&& ...) [with _Args =
{const int&}; _Tp = OptSpecifier; _Alloc = std::allocator; _Node
= std::__cxx11::list::_Node]'
/opt/compiler-explorer/gcc-trunk-20221212/include/c++/13.0.0/bits/stl_list.h:2005:32:
required from 'void std::__cxx11::list<_Tp, _Alloc>::_M_insert(iterator,
_Args&& ...) [with _Args = {const int&}; _Tp = OptSpecifier; _Alloc =
std::allocator; iterator =
std::__cxx11::list::iterator]'
/opt/compiler-explorer/gcc-trunk-20221212/include/c++/13.0.0/bits/stl_list.h:1321:19:
required from 'std::__cxx11::list<_Tp, _Alloc>::reference
std::__cxx11::list<_Tp, _Alloc>::emplace_back(_Args&& ...) [with _Args = {const
int&}; _Tp = OptSpecifier; _Alloc = std::allocator; reference =
OptSpecifier&]'
/opt/compiler-explorer/gcc-trunk-20221212/include/c++/13.0.0/bits/stl_list.h:1934:18:
required from 'void std::__cxx11::list<_Tp,
_Alloc>::_M_initialize_dispatch(_InputIterator, _InputIterator,
std::__false_type) [with _InputIterator = const int*; _Tp = OptSpecifier;
_Alloc = std::allocator]'
/opt/compiler-explorer/gcc-trunk-20221212/include/c++/13.0.0/bits/stl_list.h:882:26:
required from 'std::__cxx11::list<_Tp, _Alloc>::list(_InputIterator,
_InputIterator, const allocator_type&) [with _InputIterator = const int*;
= void; _Tp = OptSpecifier; _Alloc =
std::allocator; allocator_type = std::allocator]'
:17:6: required from here
/opt/compiler-explorer/gcc-trunk-20221212/include/c++/13.0.0/bits/new_allocator.h:187:11:
error: call of overloaded 'OptSpecifier(const int&)' is ambiguous
187 | { ::new((void *)__p) _Up(std::forward<_Args>(__args)...); }
| ^~
:8:3: note: candidate: 'OptSpecifier::OptSpecifier(unsigned int)'
8 | OptSpecifier(unsigned ID) : ID(ID) {}
| ^~~~
:7:12: note: candidate: 'OptSpecifier::OptSpecifier(bool)' (deleted)
7 | explicit OptSpecifier(bool) = delete; // Works if this is commented
|^~~~
:3:7: note: candidate: 'constexpr OptSpecifier::OptSpecifier(const
OptSpecifier&)'
3 | class OptSpecifier {
| ^~~~
:3:7: note: candidate: 'constexpr
OptSpecifier::OptSpecifier(OptSpecifier&&)'
Compiler returned: 1
[Bug driver/107954] New: Support -std=c23/gnu23 as aliases of -std=c2x/gnu2x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107954 Bug ID: 107954 Summary: Support -std=c23/gnu23 as aliases of -std=c2x/gnu2x Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: romain.geissler at amadeus dot com Target Milestone: --- Hi, I raise this ticket (I agree not very important, and more a feature request than a bug) following a similar one on C++/clang side and a remark from Aaron Ballman: https://github.com/llvm/llvm-project/issues/59300#issuecomment-1335623903 It seems that the future C2x standard has reached at least the feature freeze phase and the expectations are that it will be ratified in 2023. So, it is already the time to accept -std=c23/gnu23 as aliases of -std=c2x/gnu2x or is it early for this ? On C++ side gcc already accepts -std=c++23 since gcc 11 as now C++ standards seems to strictly follow the 3 years cadence. Cheers, Romain
[Bug tree-optimization/107569] [13 Regression] Failure to optimize std::isfinite since r13-3596
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569 Romain Geissler changed: What|Removed |Added CC||romain.geissler at amadeus dot com --- Comment #39 from Romain Geissler --- Hi, FYI, when trying to bootstrap a GNU toolchain with glibc (current master branch), binutils (current 2.39 release branch) and gcc, I noticed that the fixes done for this bug caused the following regressions on glibc side (tested on x86_64 Linux): FAIL: math/test-double-cosh FAIL: math/test-double-exp10 FAIL: math/test-double-expm1 FAIL: math/test-double-lgamma FAIL: math/test-double-log1p FAIL: math/test-double-tgamma FAIL: math/test-float-cosh FAIL: math/test-float-expm1 FAIL: math/test-float-lgamma FAIL: math/test-float-log1p FAIL: math/test-float-tgamma FAIL: math/test-float128-catan FAIL: math/test-float128-catanh FAIL: math/test-float128-cosh FAIL: math/test-float128-exp10 FAIL: math/test-float128-lgamma FAIL: math/test-float128-log FAIL: math/test-float128-log1p FAIL: math/test-float128-pow FAIL: math/test-float128-tgamma FAIL: math/test-float128-y0 FAIL: math/test-float128-y1 FAIL: math/test-float32-cosh FAIL: math/test-float32-expm1 FAIL: math/test-float32-lgamma FAIL: math/test-float32-log1p FAIL: math/test-float32-tgamma FAIL: math/test-float32x-cosh FAIL: math/test-float32x-exp10 FAIL: math/test-float32x-expm1 FAIL: math/test-float32x-lgamma FAIL: math/test-float32x-log1p FAIL: math/test-float32x-tgamma FAIL: math/test-float64-cosh FAIL: math/test-float64-exp10 FAIL: math/test-float64-expm1 FAIL: math/test-float64-lgamma FAIL: math/test-float64-log1p FAIL: math/test-float64-tgamma FAIL: math/test-float64x-cosh FAIL: math/test-float64x-lgamma FAIL: math/test-float64x-tgamma FAIL: math/test-ldouble-cosh FAIL: math/test-ldouble-lgamma FAIL: math/test-ldouble-tgamma These tests are working with gcc-13-3916-g5b6ce16adec (daily bump from 12th of November) and failing with gcc-13-3933-g30d77d49628 (daily bump from 13th of November). I did try to use the current master, it still fails. I also tried to patch from PR107879 and it still fails. Cheers, Romain
[Bug c++/102730] New: Consistency of deprecation warning emission with type alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102730 Bug ID: 102730 Summary: Consistency of deprecation warning emission with type alias Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: romain.geissler at amadeus dot com Target Milestone: --- Hi, While trying to rename an enum from one name to another in an existing framework, I try to use the following mechanism that works partially with gcc (but not clang) of: - deprecating the old type declaration with [[deprecated]] - use some "using NewType = DeprecatedType;" statement to define the new name our user shall use in their code. I would expect that gcc correctly emit a warning when we use "DeprecatedType" instead of "NewType" in the code, but not when I use "NewType", which allows people to migrate to the new name without any impact on name mangling implied by this name change. It seems that it works partially. See this snippet: <
[Bug libstdc++/100630] Unexpected implicit conversion from volatile bool& to std::filesystem::path in gcc <= 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100630 --- Comment #5 from Romain Geissler --- Hi, Thanks for providing a fix that quickly ! I backported it in my own copy of gcc 8 and 9 and it fixed my issue on these branches as well. Cheers, Romain
[Bug libstdc++/100630] New: Unexpected implicit conversion from volatile bool& to std::filesystem::path in gcc <= 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100630
Bug ID: 100630
Summary: Unexpected implicit conversion from volatile bool& to
std::filesystem::path in gcc <= 10
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
I came across this issue today (which I think is unexpected) with gcc 8, 9 and
10. It seems that the following code triggers some implicit conversion from
volatile bool& to std::filesystem::path while this was definitely not the
intention:
#include
#include
class Printer
{
public:
Printer& operator<<(bool iValue)
{
std::cout << __PRETTY_FUNCTION__<< ": " << std::boolalpha << iValue
<< std::endl;
return *this;
};
Printer& operator<<(const std::filesystem::path& iPath)
{
std::cout << __PRETTY_FUNCTION__<< ": " << std::boolalpha << iPath
<< std::endl;
return *this;
};
};
int main()
{
Printer aPrinter;
volatile bool a = false;
aPrinter << a;
};
It raises the following error (for example using gcc 10 in Compiler Explorer):
In file included from
/opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/filesystem:45,
from :1:
/opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/bits/fs_path.h: In
instantiation of 'struct
std::filesystem::__cxx11::__detail::__constructible_from':
/opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/type_traits:138:12:
required from 'struct std::__and_ >,
std::filesystem::__cxx11::__detail::__constructible_from
>'
/opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/type_traits:143:12:
required from 'struct std::__and_ >, std::__not_ >,
std::filesystem::__cxx11::__detail::__constructible_from
>'
/opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/bits/fs_path.h:123:11:
required by substitution of 'template using _Path =
typename std::enable_if >::type,
std::filesystem::__cxx11::path> >, std::__not_::type> >,
std::filesystem::__cxx11::__detail::__constructible_from<_Tp1, _Tp2> >::value,
std::filesystem::__cxx11::path>::type [with _Tp1 = volatile bool; _Tp2 = void]'
/opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/bits/fs_path.h:223:7:
required by substitution of 'template
std::filesystem::__cxx11::path::path(const _Source&,
std::filesystem::__cxx11::path::format) [with _Source = volatile bool; _Require
= ]'
:27:17: required from here
/opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/bits/fs_path.h:119:29:
error: no matching function for call to '__is_path_src(volatile bool, int)'
119 | : decltype(__is_path_src(std::declval<_Source>(), 0))
|~^~~~
/opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/bits/fs_path.h:95:5: note:
candidate: 'template
std::filesystem::__cxx11::__detail::__is_path_iter_src<_Iter>
std::filesystem::__cxx11::__detail::__is_path_src(_Iter, int)'
95 | __is_path_src(_Iter, int);
| ^
/opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/bits/fs_path.h:95:5: note:
template argument deduction/substitution failed:
/opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/bits/fs_path.h: In
substitution of 'template using
__is_path_iter_src = std::__and_::type, char>,
std::is_same::type, wchar_t>, std::is_same::type, char16_t>,
std::is_same::type, char32_t> >,
std::is_base_of > [with _Iter = bool; _Iter_traits =
std::iterator_traits]':
/opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/bits/fs_path.h:95:5:
required by substitution of 'template
std::filesystem::__cxx11::__detail::__is_path_iter_src<_Iter>
std::filesystem::__cxx11::__detail::__is_path_src(_Iter, int) [with _Iter =
bool]'
/opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/bits/fs_path.h:119:29:
required from 'struct
std::filesystem::__cxx11::__detail::__constructible_from'
/opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/type_traits:138:12:
required from 'struct std::__and_ >,
std::filesystem::__cxx11::__detail::__constructible_from
>'
/opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/type_traits:143:12:
required from 'struct std::__and_ >, std::__not_ >,
std::filesystem::__cxx11::__detail::__constructible_from
>'
/opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/bits/fs_path.h:123:11:
required by substitution of 'template using _Path =
typename std::enable_if >::type,
std::filesystem::__cxx11::path> >, std::__not_::type> >,
std::filesystem::__cxx11::__detail::__constructible_from<_Tp1, _Tp2> >::value,
std::filesystem::__cxx11::path>::type [with _Tp1 = volatile bool; _Tp2 = void]'
/opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/bits/fs_path.h:223:7:
required by substitution of 'template
std::filesystem::__cxx11::path::path(const
[Bug c++/93821] Define __cplusplus to 202002L in C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93821 Romain Geissler changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from Romain Geissler --- Hi, This was implemented in gcc 11 with this commit: https://gcc.gnu.org/git/?p=gcc.git;a=commit;f=libcpp/init.c;h=445430e16bd08ade34637d2346ded40dd49de508 Closing. Cheers, Romain
[Bug middle-end/98465] Bogus warning stringop-overread wuth -std=gnu++20 -O2 and std::string::insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465
--- Comment #3 from Romain Geissler ---
I have found another example in my code base raising this error:
#include
std::string f1()
{
std::string aString = "string";
aString = "bigger str";
return aString;
}
With: -O2 -std=gnu++20 -Werror=stringop-overread -Wno-system-headers -g
raises:
/opt/compiler-explorer/gcc-trunk-20201230/include/c++/11.0.0/bits/char_traits.h:402:56:
error: 'void* __builtin_memcpy(void*, const void*, long unsigned int)' reading
10 bytes from a region of size 7 [-Werror=stringop-overread]
402 | return static_cast(__builtin_memcpy(__s1, __s2,
__n));
|
^
Yet now what confuses me is that if I add copy of this function later using
bigger strings (so not exposing the bug), the new f2 function makes the warning
disappear form the f1 function:
#include
std::string f1()
{
std::string aString = "string";
aString = "bigger str"; // <--- no more warning here when we have function
f2 !
return aString;
}
std::string f2()
{
std::string aString = "initial string with enough capacity";
aString = "smaller str";
return aString;
}
Why does having a function f2 affects warnings in function f1 ?
[Bug middle-end/98465] Bogus warning stringop-overread wuth -std=gnu++20 -O2 and std::string::insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465 --- Comment #2 from Romain Geissler --- Hi Martin, Thanks for your investigation. I have a few questions: - Since the warning seems to be fully emitted by system headers, shouldn't it be silenced by default ? Why isn't it the case here ? On compiler explorer, "x86-64 gcc 10.2" and flags "-std=gnu++20 -O2" I get no warning, yet with flags "-std=gnu++20 -O2 -Wsystem-headers" I get a -Wstringop-overflow warning about the same problem. Meaning that for stringop-overflow system headers seems to be taken into account, but not for stringop-overread, is that expected ? - I understood why you did not reproduce the bug with gcc 11, my test case, and flags "-std=gnu++20 -O2". It looks like Compiler explorer forces "-g" by default. And it seems debug output generation does affect the warning. With flags "-std=gnu++20 -O2 -g0" (effectively disable debug information generation) I get no warning, while with "-std=gnu++20 -O2 -g" I get the stringop-overread warning. Again, gcc 10 doesn't seem to be impacted by debug output generation to trigger this warning, is this expected ? There seems to be a strange interaction between -Wsystem-headers and -g in gcc 11 which I don't understand. See the following matrix: - "-std=gnu++20 -O2 -Wno-system-headers -g0" --> no warning - "-std=gnu++20 -O2 -Wno-system-headers -g" --> warning - "-std=gnu++20 -O2 -Wsystem-headers -g0"--> warning - "-std=gnu++20 -O2 -Wsystem-headers -g" --> warning (this last matrix was tested on compiler explorer). I am confused. Cheers, Romain
[Bug c++/98463] [11 Regression] internal compiler error: in output_constructor_regular_field, at varasm.c:5491 by r11-2720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98463 --- Comment #3 from Romain Geissler --- Hi, While I initially flagged this as a regression in gcc 11, it's indeed a latent gcc bug which predates gcc 11. What makes it for my specific test case a regression is because now tuple use [[no_unique_address]] which seems to be already identified as creating ICEs in issues #96863 and #97804. Cheers, Romain
[Bug middle-end/98465] New: Bogus warning stringop-overread wuth -std=gnu++20 -O2 and std::string::insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465
Bug ID: 98465
Summary: Bogus warning stringop-overread wuth -std=gnu++20 -O2
and std::string::insert
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
The following C++ code compiled with -std=gnu++20 -O2 -Werror=stringop-overread
emits a bogus warning/error with gcc trunk, while it works without problem when
using gnu++17 instead. Tested on compiler explorer on x64 Linux:
#include
const char constantString[] = {42, 53};
void f(std::string& s)
{
s.insert(0, static_cast(constantString), 2);
}
In file included from
/opt/compiler-explorer/gcc-trunk-20201228/include/c++/11.0.0/string:40,
from :1:
In static member function 'static constexpr std::char_traits::char_type*
std::char_traits::copy(std::char_traits::char_type*, const
char_type*, std::size_t)',
inlined from 'static void std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_S_copy(_CharT*, const _CharT*, std::__cxx11::basic_string<_CharT,
_Traits, _Alloc>::size_type) [with _CharT = char; _Traits =
std::char_traits; _Alloc = std::allocator]' at
/opt/compiler-explorer/gcc-trunk-20201228/include/c++/11.0.0/bits/basic_string.h:351:21,
inlined from 'static void std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_S_copy(_CharT*, const _CharT*, std::__cxx11::basic_string<_CharT,
_Traits, _Alloc>::size_type) [with _CharT = char; _Traits =
std::char_traits; _Alloc = std::allocator]' at
/opt/compiler-explorer/gcc-trunk-20201228/include/c++/11.0.0/bits/basic_string.h:346:7,
inlined from 'std::__cxx11::basic_string<_CharT, _Traits, _Allocator>&
std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_M_replace(std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::size_type, std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::size_type, const _CharT*, std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::size_type) [with _CharT = char; _Traits = std::char_traits;
_Alloc = std::allocator]' at
/opt/compiler-explorer/gcc-trunk-20201228/include/c++/11.0.0/bits/basic_string.tcc:481:20,
inlined from 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::replace(std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::size_type, std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::size_type, const _CharT*, std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::size_type) [with _CharT = char; _Traits = std::char_traits;
_Alloc = std::allocator]' at
/opt/compiler-explorer/gcc-trunk-20201228/include/c++/11.0.0/bits/basic_string.h:1946:19,
inlined from 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::insert(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type,
const _CharT*, std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type)
[with _CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]' at
/opt/compiler-explorer/gcc-trunk-20201228/include/c++/11.0.0/bits/basic_string.h:1693:29,
inlined from 'void f(std::string&)' at :7:60:
/opt/compiler-explorer/gcc-trunk-20201228/include/c++/11.0.0/bits/char_traits.h:402:56:
error: 'void* __builtin_memcpy(void*, const void*, long unsigned int)' reading
2 bytes from a region of size 0 [-Werror=stringop-overread]
402 | return static_cast(__builtin_memcpy(__s1, __s2,
__n));
|
^
: In function 'void f(std::string&)':
:3:12: note: at offset 2 into source object 'constantString' of size 2
3 | const char constantString[] = {42, 53};
|^~
cc1plus: some warnings being treated as errors
Compiler returned: 1
Note that gcc 10 doesn't issue any warning even with -Wall -Wextra with
gnu++20.
Cheers,
Romain
[Bug c++/98463] New: [11 Regression] internal compiler error: in output_constructor_regular_field, at varasm.c:5491
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98463
Bug ID: 98463
Summary: [11 Regression] internal compiler error: in
output_constructor_regular_field, at varasm.c:5491
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
The following C++ code fails to compile with gcc trunk but works on gcc 9 and
10 (tested on compiler explorer):
#include
struct A
{
std::unique_ptr _member;
virtual ~A(){}
};
A a;
Compiled without any CXXFLAGS on x64 Linux. Compiler explorer shows:
:10:4: internal compiler error: in output_constructor_regular_field, at
varasm.c:5491
10 | A a;
|^
0x1cba449 internal_error(char const*, ...)
???:0
0x6b0031 fancy_abort(char const*, int, char const*)
???:0
0x13ceaf3 assemble_variable(tree_node*, int, int, int)
???:0
0xb4207f symbol_table::finalize_compilation_unit()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug ipa/98106] New: gcc trunk miscompiles glibc dynamic loader
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98106 Bug ID: 98106 Summary: gcc trunk miscompiles glibc dynamic loader Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: romain.geissler at amadeus dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Hi, I would like to report a regression in trunk which for me result in glibc segfaulting in the dynamic linker at the very beginning of symbol resolution. I do compile binutils 2.35 (from the release branch, I use git commit 1c5243df7f8c0a18f1518825ab1dacdf40188a41), then gcc, and with the resulting gcc + binutils I build glibc (taken from a rather recent commit from master, git sha1 29fddfc7dfd6444fa61a256e9a0d0127545e1f2e). I build this on x86_64, using just the CFLAGS/CXXFLAGS "-O2" when building all these components. This resulting glibc seems to be miscompiled, as running any program with its dynamic linker results in this seg fault: root@e92b8eb029ef:/# /workdir/build/temporary-system/install/lib/libc.so.6 Segmentation fault (core dumped) root@e92b8eb029ef:/# gdb /workdir/build/temporary-system/install/lib/libc.so.6 GNU gdb (Debian 8.2.1-2+b3) 8.2.1 ... (snapped) Reading symbols from /workdir/build/temporary-system/install/lib/libc.so.6...done. (gdb) r Starting program: /workdir/build/temporary-system/install/lib/libc.so.6 Program received signal SIGSEGV, Segmentation fault. 0x77fdadf0 in _dl_lookup_symbol_x () from /workdir/build/temporary-system/install/lib/ld-linux-x86-64.so.2 (gdb) bt #0 0x77fdadf0 in _dl_lookup_symbol_x () from /workdir/build/temporary-system/install/lib/ld-linux-x86-64.so.2 #1 0x77fd3627 in dl_main () from /workdir/build/temporary-system/install/lib/ld-linux-x86-64.so.2 #2 0x77fea277 in _dl_sysdep_start () from /workdir/build/temporary-system/install/lib/ld-linux-x86-64.so.2 #3 0x77fd2009 in _dl_start () from /workdir/build/temporary-system/install/lib/ld-linux-x86-64.so.2 #4 0x77fd1058 in _start () from /workdir/build/temporary-system/install/lib/ld-linux-x86-64.so.2 #5 0x0001 in ?? () #6 0x7fffeeae in ?? () #7 0x in ?? () (gdb) info shared >FromTo Syms Read Shared Object Library 0x77fd1050 0x77ff132e Yes (*) /workdir/build/temporary-system/install/lib/ld-linux-x86-64.so.2 (gdb) disas (*): Shared library is missing debugging information. Dump of assembler code for function _dl_lookup_symbol_x: 0x77fdade0 <+0>: push %r15 0x77fdade2 <+2>: push %r14 0x77fdade4 <+4>: push %r13 0x77fdade6 <+6>: push %r12 0x77fdade8 <+8>: mov%rdi,%r12 0x77fdadeb <+11>:push %rbp 0x77fdadec <+12>:mov%rdx,%rbp 0x77fdadef <+15>:push %rbx => 0x77fdadf0 <+16>:mov%fs:0x10,%rax 0x77fdadf9 <+25>:sub$0x98,%rsp 0x77fdae00 <+32>:mov%rsi,0x8(%rsp) 0x77fdae05 <+37>:mov%rcx,0x18(%rsp) 0x77fdae0a <+42>:mov%r8,(%rsp) 0x77fdae0e <+46>:mov%r9d,0x14(%rsp) 0x77fdae13 <+51>:mov%rax,0x28(%rsp) 0x77fdae18 <+56>:movzbl (%r12),%edx 0x77fdae1d <+61>:test %dl,%dl 0x77fdae1f <+63>:je 0x77fdb050 <_dl_lookup_symbol_x+624> 0x77fdae25 <+69>:mov%r12,%rcx 0x77fdae28 <+72>:mov$0x1505,%ebx 0x77fdae2d <+77>:nopl (%rax) (gdb) info reg rax0x7fffe980 140737488349568 rbx0x7fffe9a0 140737488349600 rcx0x77ffeb08 140737354132232 rdx0x7fffe978 140737488349560 rsi0x77ffe770 140737354131312 rdi0x77ff32ea 140737354085098 rbp0x7fffe978 0x7fffe978 rsp0x7fffe8b8 0x7fffe8b8 r8 0x7fffe9a0 140737488349600 r9 0x0 0 r100x7022 1879048226 r110x3250 r120x77ff32ea 140737354085098 r130x77ffe770 140737354131312 r140x7fffe978 140737488349560 r150x0 0 rip0x77fdadf0 0x77fdadf0 <_dl_lookup_symbol_x+16> eflags 0x10246 [ PF ZF IF RF ] cs 0x3351 ss 0x2b43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 Gcc's trunk from early november had no problem, but trunk from 1st december does expose this
[Bug libstdc++/97758] New: bits/std_function.h: error: unknown type name 'type_info' when using -fno-exceptions -fno-rtti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97758 Bug ID: 97758 Summary: bits/std_function.h: error: unknown type name 'type_info' when using -fno-exceptions -fno-rtti Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: romain.geissler at amadeus dot com Target Milestone: --- Hi, I am using the trunk from today (8th november, git revision b642fca1c31b2e2175e0860daf32b4ee0d918085). When trying to build clang with it I end up with this error (on Linux x86_64): FAILED: lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/ParallelCG.cpp.o /workdir/build/final-system/llvm-build/./bin/clang++ -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/CodeGen -I/workdir/src/llvm-12.0.0/llvm/lib/CodeGen -Iinclude -I/workdir/src/llvm-12.0.0/llvm/include -isystem /workdir/build/final-system/llvm-temporary-static-dependencies/install/include -O2 -I/workdir/build/final-system/llvm-temporary-static-dependencies/install/include -I/workdir/build/final-system/llvm-temporary-static-dependencies/install/include/ncursesw -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -fdiagnostics-color -ffunction-sections -fdata-sections -fprofile-instr-generate="/workdir/build/final-system/llvm-build/tools/clang/stage2-instrumented-bins/profiles/%4m.profraw" -flto -O3 -DNDEBUG-fno-exceptions -fno-rtti -std=c++14 -MD -MT lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/ParallelCG.cpp.o -MF lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/ParallelCG.cpp.o.d -o lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/ParallelCG.cpp.o -c /workdir/src/llvm-12.0.0/llvm/lib/CodeGen/ParallelCG.cpp In file included from /workdir/src/llvm-12.0.0/llvm/lib/CodeGen/ParallelCG.cpp:13: In file included from /workdir/src/llvm-12.0.0/llvm/include/llvm/CodeGen/ParallelCG.h:17: In file included from /opt/1A/toolchain/x86_64-v21.0.10/lib64/gcc/x86_64-1a-linux-gnu/11.0.0/../../../../include/c++/11.0.0/functional:59: /opt/1A/toolchain/x86_64-v21.0.10/lib64/gcc/x86_64-1a-linux-gnu/11.0.0/../../../../include/c++/11.0.0/bits/std_function.h:190:31: error: unknown type name 'type_info' __dest._M_access() = nullptr; ^ 1 error generated. Note that apparently these llvm files are compiled with -fno-exceptions -fno-rtti, so it seems triggered by the recent changes around std::function without rtti support. Cheers, Romain
