[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
[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 <https://gcc.gnu.org/bugs/> for instructions.
Compiler returned: 1
Cheers,
Romain
[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
[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
[Bug c++/96310] New: Ignoring Wnonnull via pragma gcc diagnostics still produces a unwanted note
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96310
Bug ID: 96310
Summary: Ignoring Wnonnull via pragma gcc diagnostics still
produces a unwanted note
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,
When trying to ignore some uses of null object which apparently are done on
purpose in Boost::concept, I noticed that ignoring the Wnonnull warning via
pragmas still produces an unwanted note giving the details of the callstack.
See this (compiled with -Wnonnull):
struct C {
void method() {}
};
void f()
{
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wnonnull"
static_cast(0)->method();
#pragma GCC diagnostic pop
}
generates the following compiler note output, while we did expect none:
: In function 'void f()':
:2:10: note: in a call to non-static member function 'void C::method()'
2 | void method() {}
| ^~
Compiler returned: 0
Cheers,
Romain
[Bug ipa/96291] [10/11 Regression] -flto fails as "internal compiler error: Segmentation fault" during IPA pass: cp incall_for_symbol_thunks_and_aliases()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96291 Romain Geissler changed: What|Removed |Added CC||romain.geissler at amadeus dot com --- Comment #3 from Romain Geissler --- Hi, FYI, I just tried to build Protobuf 3.12.3 with the trunk from a few days ago, using "-flto" and I experience similar ICE: [2020-07-24T12:16:07.637Z] CXXLDprotobuf-lite-test [2020-07-24T12:16:10.993Z] during IPA pass: cp [2020-07-24T12:16:10.993Z] lto1: internal compiler error: Segmentation fault [2020-07-24T12:16:15.263Z] 0x9e42da crash_signal [2020-07-24T12:16:15.263Z] /workdir/src/gcc-11.0.0/gcc/toplev.c:328 [2020-07-24T12:16:15.263Z] 0xfe6b04 has_undead_caller_from_outside_scc_p [2020-07-24T12:16:15.263Z] /workdir/src/gcc-11.0.0/gcc/ipa-cp.c:5670 [2020-07-24T12:16:15.263Z] 0xf042c0 cgraph_node::call_for_symbol_thunks_and_aliases(bool (*)(cgraph_node*, void*), void*, bool, bool) [2020-07-24T12:16:15.263Z] /workdir/src/gcc-11.0.0/gcc/cgraph.c:2450 [2020-07-24T12:16:15.263Z] 0x13130bc identify_dead_nodes [2020-07-24T12:16:15.263Z] /workdir/src/gcc-11.0.0/gcc/ipa-cp.c:5687 [2020-07-24T12:16:15.263Z] 0x13130bc ipcp_decision_stage [2020-07-24T12:16:15.263Z] /workdir/src/gcc-11.0.0/gcc/ipa-cp.c:5730 [2020-07-24T12:16:15.263Z] 0x13130bc ipcp_driver [2020-07-24T12:16:15.263Z] /workdir/src/gcc-11.0.0/gcc/ipa-cp.c:5908 [2020-07-24T12:16:15.263Z] 0x13130bc execute [2020-07-24T12:16:15.263Z] /workdir/src/gcc-11.0.0/gcc/ipa-cp.c:5999 [2020-07-24T12:16:15.263Z] Please submit a full bug report, [2020-07-24T12:16:15.263Z] with preprocessed source if appropriate. [2020-07-24T12:16:15.263Z] Please include the complete backtrace with any bug report. [2020-07-24T12:16:15.263Z] See <https://gcc.gnu.org/bugs/> for instructions. [2020-07-24T12:16:15.263Z] CXXLDprotobuf-lite-arena-test [2020-07-24T12:16:15.263Z] lto-wrapper: fatal error: g++ returned 1 exit status [2020-07-24T12:16:15.263Z] compilation terminated. If you have a patch, I can try to test it as well on this Protobuf case. Cheers, Romain
[Bug c++/96003] [11 Regression] Maybe a false positive for -Werror=nonnull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96003
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
--- Comment #9 from Romain Geissler ---
Hi,
FYI, I tried to build rapidjson with the latest gcc 11, and I also see a lot of
Wnonnull warnings (which I think are false positives too) now. As rapidjson
seems to use -Werror by default, it breaks the build, I am going to remove this
-Werror to unblock me.
FYI, among the many warnings reported, you can see this one:
/workdir/src/rapidjson-1.1.0/include/rapidjson/schema.h:2104:93: error: 'this'
pointer null [-Werror=nonnull]
2104 | bool Bool(bool b) { RAPIDJSON_SCHEMA_HANDLE_VALUE_(Bool,
(CurrentContext(), b), (b)); }
|
^
/workdir/src/rapidjson-1.1.0/include/rapidjson/schema.h:2089:87: note: in
definition of macro 'RAPIDJSON_SCHEMA_HANDLE_PARALLEL_'
2089 |
static_cast(context->validators[i_])->method arg2;\
|
^~~~
/workdir/src/rapidjson-1.1.0/include/rapidjson/schema.h:2104:31: note: in
expansion of macro 'RAPIDJSON_SCHEMA_HANDLE_VALUE_'
2104 | bool Bool(bool b) { RAPIDJSON_SCHEMA_HANDLE_VALUE_(Bool,
(CurrentContext(), b), (b)); }
| ^~
/workdir/src/rapidjson-1.1.0/include/rapidjson/schema.h:2104:10: note: in a
call to non-static member function 'bool
rapidjson::GenericSchemaValidator::Bool(bool) [with SchemaDocumentType =
rapidjson::GenericSchemaDocument > >;
OutputHandler = rapidjson::BaseReaderHandler, void>;
StateAllocator = rapidjson::CrtAllocator]'
2104 | bool Bool(bool b) { RAPIDJSON_SCHEMA_HANDLE_VALUE_(Bool,
(CurrentContext(), b), (b)); }
| ^~~~
All the examples I checked were using the static_cast pattern similar to
comment #8.
Cheers,
Romain
[Bug bootstrap/92484] In tree build of ISL 0.22 fails: requires C++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92484 Romain Geissler changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from Romain Geissler --- Current trunk (gcc 11) builds with C++11 now, so ISL 0.22 is useable during a full bootstrap in tree. Closing.
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 --- Comment #28 from Romain Geissler --- Hi David, Do you have plans to submit this patch for review when stage 1 of gcc 11 opens ? Cheers, Romain
[Bug preprocessor/94367] New: pragma GCC diagnostics messes up with one line "if" blocks without curly braces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94367
Bug ID: 94367
Summary: pragma GCC diagnostics messes up with one line "if"
blocks without curly braces
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
It looks like "if" blocks without curly braces cannot be surrounded by pragma
diagnostics. It looks like this is a very old issue, gcc 4.6 already seem to
have this problem on Compiler Explorer. Clang raises no such error.
void f()
{
if (true)
#pragma GCC diagnostic push
;
#pragma GCC diagnostic pop
else
;
}
: In function 'void f()':
:7:5: error: 'else' without a previous 'if'
7 | else
| ^~~~
Compiler returned: 1
Compiler Explorer uses cookies and other related techs to serve you
[Bug tree-optimization/94335] False positive -Wstringop-overflow warning with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94335 --- Comment #4 from Romain Geissler --- Thanks Richard. Indeed, beyond the false positive described in this bug, our whole code that implement "relative pointer" is I think quite hacky and not very compiler friendly (around alignment, aliasing rule, pointer arithmetic). We should review and update it a lot. Actually a similar class exists in Boost.Interprocess under the name "offset_ptr", and they did write this in their header: https://github.com/boostorg/interprocess/blob/develop/include/boost/interprocess/offset_ptr.hpp //Note: using the address of a local variable to point to another address //is not standard conforming and this can be optimized-away by the compiler. //Non-inlining is a method to remain illegal but correct //Undef BOOST_INTERPROCESS_OFFSET_PTR_INLINE_XXX if your compiler can inline //this code without breaking the library any time they need to deal with pointer to offset conversion, or vice-versa. I happens that we also suffer from similar problems and had to put attribute "noinline" "randomly" in places to "fix" (actually workaround our poor understanding of how the compiler works) problems we are seeing with the behavior of this library when compiled with optimizations. We should obviously review greatly in depths what we are doing which seems wrong in many places. PS Martin: I am ok to leave unresolved, just I think the wording of the error should be somehow updated so that the fact that it's only a possibility for not a certainty, other of your warnings around string management do print the range of value that gcc found out is possible, and that helps in understanding and fixing/silencing the warnings.
[Bug tree-optimization/94335] False positive -Wstringop-overflow warning with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94335 --- Comment #2 from Romain Geissler --- Thanks for the explanation. However few observations: - Is it really expected that the wording of the warning seems to imply gcc knows for sure that there is an invalid access ? What is the warning meant to find ? Potential issues, or real issues gcc can prove will happen 100% of the time ? Here I see that you pasted: if (_24 != -9223372036854775808) goto ; [94.29%] else goto ; [5.71%] so gcc itself is able to see that the most likely case is that we go in basic block 4 rather than 5 which emits this warning. So either the wording of the warning shall be updated to reflect that "maybe" the code wrong, either if possible we should try to make a different when gcc is sure and when it is not (like -Wuninitialized vs -Wmaybe-uninitialized). - Second observations, how do you suggest we teach gcc that this is indeed a false positive and we want the warning to be silenced. You mentioned "if (d == kEmptyPointer) __builtin_unreachable;", does this statement result in effectively having a new basic block branching where one side terminates the program and the other runs the actual expected behavior of "setVal". In other words, will the condition in the "if" really be emitted by the codegen and evaluated at runtime, or do I have the guarantee it will not emit new branches and only teach the optimizer that some cases are impossible ? In the case the answer is that it will emit a real codegen branch potentially impacting runtime, do you think it's worth adding a __builtin_assume in gcc like clang has (not in gcc 10 obviously, but in gcc 11 during stage 1) ? Cheers, Romain
[Bug tree-optimization/94335] New: False positive -Wstringop-overflow warning with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94335
Bug ID: 94335
Summary: False positive -Wstringop-overflow warning with -O2
Product: gcc
Version: 10.0
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 code emits a false positive -Wstringop-overflow warning with gcc
trunk with -O2 and -O3.
It's reduced manually from a much more complex scenario, where we try to define
an iterator that can be stored in shared memory, thus referencing object
through relative addresses rather than absolute addresses. In the warning of
this scenario, I don't see how we can access offset -424242 as the initial
pointed address is never nullptr.
Note: gcc 8/9 do not emit such warning.
#include
#include
#include
#include
#include
template
struct relative_address_iterator {
typedef T value;
typedef T *pointer;
typedef const T *const_pointer;
typedef T
typedef const T _reference;
typedef T value_type;
typedef ptrdiff_t difference_type;
typedef std::forward_iterator_tag iterator_category;
off_t d;
static constexpr off_t kEmptyPointer = std::numeric_limits::min();
/** Constructs the object from a pointer.
*/
relative_address_iterator(pointer t)
{
if (t)
{
d = (char *)t - (char *)this;
}
else
{
d = kEmptyPointer;
}
}
/** Copy constructor.
*/
relative_address_iterator(const relative_address_iterator )
{
if (r.d != kEmptyPointer)
{
d = (char *) - (char *)this + r.d;
}
else
{
// Normally this should not happen in this example, but gcc thinks
it does,
// as the error message references the special value -424242.
// d = kEmptyPointer;
d = -424242;
}
}
/** Initializes the pointee with the given value.
*/
void setVal(const_reference value) { *(pointer)((char *)this + d) = value;
}
/** Dereferences the object.
*/
operator pointer()
{
if (d == kEmptyPointer) return nullptr;
return ((pointer)((char *)this + d));
}
/** Preincrement operator.
*/
relative_address_iterator ++()
{
d += sizeof(value);
return (*this);
}
};
void f()
{
char* aDummyBuffer = static_cast(malloc(10));
memset(aDummyBuffer, 10, 0);
relative_address_iterator it(aDummyBuffer);
relative_address_iterator itCopy(it);
itCopy.setVal('A');
char* aDummySource = static_cast(malloc(10));
memset(aDummySource, 10, 0);
std::copy(relative_address_iterator(aDummySource),
relative_address_iterator(aDummySource + 5),
it);
}
int main()
{
f();
}
In member function 'void
relative_address_iterator::setVal(relative_address_iterator::const_reference)
[with T = char]',
inlined from 'void f()' at :82:18:
:56:71: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
56 | void setVal(const_reference value) { *(pointer)((char *)this + d) =
value; }
|
~^~~
: In function 'void f()':
:80:37: note: at offset -424242 to object 'itCopy' with size 8 declared
here
80 | relative_address_iterator itCopy(it);
| ^~
Compiler returned: 0
Cheers,
Romain
[Bug c++/94309] New: Fail to find post-increment operator in templated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94309
Bug ID: 94309
Summary: Fail to find post-increment operator in templated
function
Product: gcc
Version: 10.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,
This snippet started to fail recently with gcc trunk. Note, it was working fine
with "g++ (GCC) 10.0.1 20200305", and it works fine with gcc <= 9, and all
clang versions
struct A
{
int _i;
operator int&()
{
return _i;
}
};
void f()
{
A a;
a++; // works
}
template void f()
{
A a;
a++; // fails
}
The error is:
#2 with x86-64 gcc (trunk)
: In function 'void f()':
:20:6: error: no post-increment operator for type
20 | a++; // fails
| ^~
Compiler returned: 1
Cheers,
Romain
[Bug libstdc++/94209] New: std::variant can't be initialized from unsigned int with gcc trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94209
Bug ID: 94209
Summary: std::variant can't be initialized from unsigned
int with gcc trunk
Product: gcc
Version: 10.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,
With gcc trunk the following fails, while it was working with gcc 8 and 9. I
think (but am not sure) the implicit conversion from unsigned int to int shall
be allowed.
#include
void f()
{
std::variant{1}; // works
std::variant{std::in_place_type_t(), 1}; // works
std::variant{std::in_place_type_t(), 1u}; // works
std::variant{1u}; // fails
};
: In function 'void f()':
:8:25: error: no matching function for call to
'std::variant::variant()'
8 | std::variant{1u}; // fails
| ^
In file included from :1:
/opt/compiler-explorer/gcc-trunk-20200317/include/c++/10.0.1/variant:1407:2:
note: candidate: 'template constexpr
std::variant<_Types>::variant(std::in_place_index_t<_Np>,
std::initializer_list<_Up>, _Args&& ...) [with long unsigned int _Np = _Np; _Up
= _Up; _Args = {_Args ...}; _Tp = _Tp; =
; _Types = {int}]'
1407 | variant(in_place_index_t<_Np>, initializer_list<_Up> __il,
| ^~~
/opt/compiler-explorer/gcc-trunk-20200317/include/c++/10.0.1/variant:1407:2:
note: template argument deduction/substitution failed:
:8:25: note: mismatched types 'std::in_place_index_t<_Idx>' and
'unsigned int'
8 | std::variant{1u}; // fails
| ^
In file included from :1:
/opt/compiler-explorer/gcc-trunk-20200317/include/c++/10.0.1/variant:1396:2:
note: candidate: 'template constexpr std::variant<_Types>::variant(std::in_place_index_t<_Np>,
_Args&& ...) [with long unsigned int _Np = _Np; _Args = {_Args ...}; _Tp = _Tp;
= ; _Types = {int}]'
1396 | variant(in_place_index_t<_Np>, _Args&&... __args)
| ^~~
/opt/compiler-explorer/gcc-trunk-20200317/include/c++/10.0.1/variant:1396:2:
note: template argument deduction/substitution failed:
:8:25: note: mismatched types 'std::in_place_index_t<_Idx>' and
'unsigned int'
8 | std::variant{1u}; // fails
| ^
In file included from :1:
/opt/compiler-explorer/gcc-trunk-20200317/include/c++/10.0.1/variant:1386:2:
note: candidate: 'template
constexpr std::variant<_Types>::variant(std::in_place_type_t<_Tp>,
std::initializer_list<_Up>, _Args&& ...) [with _Tp = _Tp; _Up = _Up; _Args =
{_Args ...}; = ; _Types =
{int}]'
1386 | variant(in_place_type_t<_Tp>, initializer_list<_Up> __il,
| ^~~
/opt/compiler-explorer/gcc-trunk-20200317/include/c++/10.0.1/variant:1386:2:
note: template argument deduction/substitution failed:
:8:25: note: mismatched types 'std::in_place_type_t<_Tp>' and
'unsigned int'
8 | std::variant{1u}; // fails
| ^
In file included from :1:
/opt/compiler-explorer/gcc-trunk-20200317/include/c++/10.0.1/variant:1376:2:
note: candidate: 'template constexpr
std::variant<_Types>::variant(std::in_place_type_t<_Tp>, _Args&& ...) [with _Tp
= _Tp; _Args = {_Args ...}; =
; _Types = {int}]'
1376 | variant(in_place_type_t<_Tp>, _Args&&... __args)
| ^~~
/opt/compiler-explorer/gcc-trunk-20200317/include/c++/10.0.1/variant:1376:2:
note: template argument deduction/substitution failed:
:8:25: note: mismatched types 'std::in_place_type_t<_Tp>' and
'unsigned int'
8 | std::variant{1u}; // fails
| ^
In file included from :1:
/opt/compiler-explorer/gcc-trunk-20200317/include/c++/10.0.1/variant:1366:2:
note: candidate: 'template constexpr
std::variant<_Types>::variant(_Tp&&) [with _Tp = _Tp;
= ; =
; _Tj = _Tj; =
; _Types = {int}]'
1366 | variant(_Tp&& __t)
| ^~~
/opt/compiler-explorer/gcc-trunk-20200317/include/c++/10.0.1/variant:1366:2:
note: template argument deduction/substitution failed:
/opt/compiler-explorer/gcc-trunk-20200317/include/c++/10.0.1/variant: In
substitution of 'template template using
__accepted_type = std::variant<_Types>::__to_type<__accepted_index<_Tp> > [with
_Tp = unsigned int&&; = void; _Types = {int}]':
/opt/compiler-explorer/gcc-trunk-20200317/include/c++/10.0.1/variant:1362:9:
required from here
/opt/compiler-explorer/gcc-trunk-20200317/include/c++/10.0.1/variant:1332:8:
error: no type named 'type' in 'struct std::enable_if'
1332 | using __accepted_type = __to_type<__accepted_index<_Tp>>;
|^~~
/opt/compiler-explorer/gcc-
[Bug lto/94150] New: Improve LTO diagnosis for LTO triggered warnings/error: print source.o or source.a(lib.o) when printing location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94150 Bug ID: 94150 Summary: Improve LTO diagnosis for LTO triggered warnings/error: print source.o or source.a(lib.o) when printing location Product: gcc Version: lto Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: romain.geissler at amadeus dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Hi, When LTO warnings/error are reported and print a given location, it would be nice to not only print the C/C++ file name, but also from which .o or .a library it comes from. Example of -Werror=lto-type-mistmatch I just got because I was mixing incompatible .o built against different version of the same header file "toolbox/UTF8Utils.h": /remote/intdeliv/components/mdw/Toolbox/18-0-0-56/include/toolbox/UTF8Utils.h:106: error: type of ‘operator[]’ does not match original declaration [-Werror=lto-type-mismatch] char operator[] (size_t x); src/UTF8Utils.cpp:148: note: implicit this pointer type mismatch include/toolbox/UTF8Utils.h:23: note: type ‘struct UTF8Char’ itself violates the C++ One Definition Rule /remote/tmp/rnd-aqg/software_factory/bms_replication/mdw/Toolbox/18-0-0-48/include/toolbox/UTF8Utils.h:22: note: the incompatible type is defined here class TOOLBOX_EXPORT UTF8Char src/UTF8Utils.cpp:148: note: ‘operator[]’ was previously declared here src/UTF8Utils.cpp:148: note: code may be misoptimized unless -fno-strict-aliasing is used The problem here is that I mixed our own version of a library named "Toolbox" from version 18-0-0-56 and 18-0-0-48 which are incompatible. I need to rebuild the .o which is using version 18-0-0-48 as given in the error, however I have no idea which libraries is that, and I have hundreds of them, which unfortunately I can't rebuild massively easily. So if the location in LTO mode could print something like: /path/to/wrong/lib.a(name_of_o_file.o):/remote/tmp/rnd-aqg/software_factory/bms_replication/mdw/Toolbox/18-0-0-48/include/toolbox/UTF8Utils.h:22: note: the incompatible type is defined here class TOOLBOX_EXPORT UTF8Char that would help identifying which files need rebuilding. Cheers, Romain
[Bug c++/94057] New: [9/10 Regression] -std=gnu++20 causes failure naming nested templated class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94057
Bug ID: 94057
Summary: [9/10 Regression] -std=gnu++20 causes failure naming
nested templated class
Product: gcc
Version: 10.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 fails with gcc trunk and with gcc 9 if I compile with
-std=gnu++20, but not with -std=gnu++17. gcc <= 8 or any clang version happily
compiles it whatever -std value I use.
template class A
{
template class B
{
B(const A::B&) = default;
};
};
It reads:
:5:23: error: 'typename A::B' names 'template
template class A::B', which is not a type
5 | B(const A::B&) = default;
| ^~~
:5:34: error: expected unqualified-id before '&' token
5 | B(const A::B&) = default;
| ^
:5:34: error: expected ')' before '&' token
5 | B(const A::B&) = default;
| ~ ^
| )
:5:34: error: constructors may not be ref-qualified
:5:34: error: expected ';' at end of member declaration
5 | B(const A::B&) = default;
| ^
| ;
:5:35: error: expected unqualified-id before ')' token
5 | B(const A::B&) = default;
| ^
Compiler returned: 1
Cheers,
Romain
[Bug c++/93958] New: gcc trunk supports -std=c++20 but not -std=gnu++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93958 Bug ID: 93958 Summary: gcc trunk supports -std=c++20 but not -std=gnu++20 Product: gcc Version: 10.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, Quite simple (and not important) "bug" report, recently Jason added the support of -std=c++20 (instead of -std=c++2a), but it looks like the gnu counter part -std=gnu++20 is not allowed. # This works: g++ -std=c++20 -o /dev/null -x c++ -c - <<<"" # This doesn't: g++ -std=gnu++20 -o /dev/null -x c++ -c - <<<"" g++: error: unrecognized command-line option ‘-std=gnu++20’; did you mean ‘-std=gnu++2a’? Cheers, Romain
[Bug libstdc++/92267] [9 Regression] crash with a cppunit test case (built by GCC 9) and cpptest (built with GCC 8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92267 --- Comment #10 from Romain Geissler --- Ok, I was not sure whether it was more important to have a given major branch (ie all gcc 9 releases) consistent or favor compatibility with the biggest number of gcc releases (cross branches). You replied to that. Do you think this shall be somehow be listed as a known issue in the gcc 9 release notes https://gcc.gnu.org/gcc-9/changes.html ?
[Bug libstdc++/92267] [9 Regression] crash with a cppunit test case (built by GCC 9) and cpptest (built with GCC 8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92267 Romain Geissler changed: What|Removed |Added CC||romain.geissler at amadeus dot com --- Comment #8 from Romain Geissler --- Hi Jonathan, Sorry to jump back into this old bug, but isn't it a issue that this was backported to gcc 9 after some releases of gcc 9 were in the wild yet ? I mean, someone having built some binaries with gcc 9.1.0 or 9.2.0, mixing it later with a binary built with the upcoming gcc 9.3.0 will also see a similar crash, no ? I think (but I am not sure yet) this is actually happening to me (although I am not using gcc releases, but directly compile from git from gcc-9-branch, so I understand my right to complain is low, if not non legit at all). What is advocated in this case, that all binaries build with gcc 9.1.0 or 9.2.0 shall be rebuilt as well ? Or is there any way that somehow the gcc 9 branch (and not gcc 10 one) can support both ABIs to cope with past mistakes ? Cheers, Romain
[Bug middle-end/80922] #pragma diagnostic ignored not honoured with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80922 Romain Geissler changed: What|Removed |Added CC||romain.geissler at amadeus dot com --- Comment #2 from Romain Geissler --- Hi, I am hitting this issue when trying to leverage lto in many libraries (on the exact same warning class by the way, but this affects all warnings). Since the last entry in this bug 3 years ago, is there now updated plans to stream/support warning flags/pragma diagnostics in the LTO sections in gcc 11 ? Cheers, Romain
[Bug c++/93821] Define __cplusplus to 202002L in C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93821 --- Comment #2 from Romain Geissler --- You may have misunderstood my intentions here. I was just trying to suggest a change which I think is better for the consistency with the standard and with clang which just implemented this change. So yes I agree with you it's definitely not a bug, and no I am not writing such __cplusplus == X checks for real, I know I should use __cplusplus >= X or even better use SD-6 macros. It's definitely not the first time you complain I open bugs which aren't bugs. However I see other gcc contributors use this ticket system to also track things like "change requests", "feature requests", or "enhancement". I also know in that case the change should be trivial enough so that I could actually submit the patch myself, however I am still trying to find a legal agreement that would suit both my employer and the FSF (wrt copyright assignment). So what do you suggest I do in that case ? Open a bug ? Start a discussion on the gcc mailing list ?
[Bug c++/93821] New: Define __cplusplus to 202002L in C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93821 Bug ID: 93821 Summary: Define __cplusplus to 202002L in C++20 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, A few hours ago the clang folks did add explicit support for the flag -std=c++20, and not only did they change that, they also changed the value of __cplusplus to 202002L. I think in gcc this __cplusplus value shall be updated too. Right now on Compiler Explorer you need to use this assertions so that there is no error on clang/gcc trunk: #ifndef __clang__ static_assert(__cplusplus == 201709L); #else static_assert(__cplusplus == 202002L); #endif https://godbolt.org/z/kh2sxc Cheers, Romain
[Bug tree-optimization/93017] FAIL: gcc.dg/graphite/interchange-1.c scan-tree-dump graphite "tiled"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93017 --- Comment #5 from Romain Geissler --- Ah actually I see this on branch gcc 8 as well, with ISL 0.21. And apparently it is not making "make check" return an error code, so it's very possible that I had this error before without noticing it.
[Bug tree-optimization/93017] FAIL: gcc.dg/graphite/interchange-1.c scan-tree-dump graphite "tiled"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93017 Romain Geissler changed: What|Removed |Added CC||romain.geissler at amadeus dot com --- Comment #4 from Romain Geissler --- Hi, I am seeing similar fails on current release branch gcc 9 as well, using ISL 0.21. Some months ago with the same ISL version and branch gcc 9 I did not see such failures. Cheers, Romain
[Bug preprocessor/47857] Pragma once warning when compiling PCH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47857 Romain Geissler changed: What|Removed |Added CC||romain.geissler at amadeus dot com --- Comment #8 from Romain Geissler --- Hi, This is still the case up to gcc 9 (already released) and current trunk of gcc 10. Cheers, Romain
[Bug libstdc++/92570] New: clang fails to instantiate std::optional if A is not const copy constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92570
Bug ID: 92570
Summary: clang fails to instantiate std::optional if A is
not const copy constructible
Product: gcc
Version: 10.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,
The following snippet fails to build with clang >= 8 using libstdc++ >= 8.1.0:
#include
class A
{
public:
A() = default;
A(A&) = default;
};
void f()
{
std::optional a1 [[maybe_unused]];
//std::optional a2(a1);
}
compiled with -std=gnu++17.
gcc is ok with that if we keep commented the last line of "f". However clang
seems to eagerly check if " = default" declaration actually make sense, even if
it's never used. It reads:
In file included from :1:
/opt/compiler-explorer/gcc-9.2.0/lib/gcc/x86_64-linux-gnu/9.2.0/../../../../include/c++/9.2.0/optional:148:7:
error: the parameter for this explicitly-defaulted copy constructor is const,
but a member or base requires it to be non-const
_Optional_payload_base(const _Optional_payload_base&) = default;
^
/opt/compiler-explorer/gcc-9.2.0/lib/gcc/x86_64-linux-gnu/9.2.0/../../../../include/c++/9.2.0/optional:354:7:
note: in instantiation of template class 'std::_Optional_payload_base'
requested here
: _Optional_payload_base<_Tp>
^
/opt/compiler-explorer/gcc-9.2.0/lib/gcc/x86_64-linux-gnu/9.2.0/../../../../include/c++/9.2.0/optional:511:30:
note: in instantiation of template class 'std::_Optional_payload' requested here
_Optional_payload<_Tp> _M_payload;
^
/opt/compiler-explorer/gcc-9.2.0/lib/gcc/x86_64-linux-gnu/9.2.0/../../../../include/c++/9.2.0/optional:657:15:
note: in instantiation of template class 'std::_Optional_base'
requested here
: private _Optional_base<_Tp>,
^
:12:22: note: in instantiation of template class 'std::optional'
requested here
std::optional a1 [[maybe_unused]];
^
1 error generated.
Compiler returned: 1
Here I am not sure who is really right. Shall libstdc++ extensively use things
like enable_if to conditionally define all these explicitly defaulted functions
to please clang, or is clang too eager in checking this even when it's not
actually used/needed ? I am fine opening a clang bug report if you consider the
issue is on clang side.
Cheers,
Romain
[Bug c++/92562] New: Allow [[maybe_unused]] in class member declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92562
Bug ID: 92562
Summary: Allow [[maybe_unused]] in class member declaration
Product: gcc
Version: 10.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 is accepted by clang but reject by gcc (any version I
tested: 8, 9, and trunk):
class A
{
// Maybe unused to silence clang error: private field '_i' is not used
[-Werror,-Wunused-private-field]
int _i [[maybe_unused]];
};
It happens that this [[maybe_unused]] attribute may be needed in some cases to
silence the clang-specific warning -Wunused-private-field, in the strange cases
where you actually want to keep the unused member rather than removing it. An
alternative would be of course to use gcc pragma diagnostics, but still it
would be cool if gcc would accept [[maybe_unused]] on class member
declarations.
Today, gcc issues:
:4:27: error: 'maybe_unused' attribute ignored [-Werror=attributes]
4 | int _i [[maybe_unused]];
| ^
cc1plus: all warnings being treated as errors
Compiler returned: 1
Cheers,
Romain
[Bug other/92484] In tree build of ISL 0.22 fails: requires C++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92484 --- Comment #2 from Romain Geissler --- Yes this is what I did, I reverted back to ISL 0.21 which for me has been working for the past months (don't know if it's a recommanded version though). Shall we keep this bug open to track the upcoming support of in-tree 0.22 or shall it be closed ?
[Bug other/92484] New: In tree build of ISL 0.22 fails: requires C++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92484 Bug ID: 92484 Summary: In tree build of ISL 0.22 fails: requires C++11 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: romain.geissler at amadeus dot com Target Milestone: --- Hi, ISL 0.22 was released recently, and I tried to use it in builds of gcc 8, 9 and 10. It fails on all these three branches will millions of error, the first ones being: In file included from /home/jenkins/workspace/OTF_Toolchain_release_4.0/output/build/temporary-system/install/include/c++/8.3.1/type_traits:35, from /workdir/src/gcc-8.3.1/isl/include/isl/cpp.h:34, from /workdir/src/gcc-8.3.1/isl/isl_test_cpp.cc:16: /home/jenkins/workspace/OTF_Toolchain_release_4.0/output/build/temporary-system/install/include/c++/8.3.1/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options. #error This file requires compiler and library support \ ^ In file included from /workdir/src/gcc-8.3.1/isl/isl_test_cpp.cc:16: /workdir/src/gcc-8.3.1/isl/include/isl/cpp.h: In member function 'isl_ctx* isl::ctx::release()': /workdir/src/gcc-8.3.1/isl/include/isl/cpp.h:57:8: error: 'tmp' does not name a type; did you mean 'tm'? auto tmp = ptr; ^~~ tm /workdir/src/gcc-8.3.1/isl/include/isl/cpp.h:58:9: error: 'nullptr' was not declared in this scope ptr = nullptr; ^~~ /workdir/src/gcc-8.3.1/isl/include/isl/cpp.h:59:10: error: 'tmp' was not declared in this scope return tmp; ^~~ Obviously the problem is that isl seems to require C++11 now, and gcc is being built with C++98. Is there any official way to build gcc with another C++ standard by default ? And is in-tree build of libs like gmp/mpfr/mpc/isl still supported or officially declared deprecated and shall not be used anymore ? Cheers, Romain
[Bug c/92063] [10 Regression] ICE in operation_could_trap_p, at tree-eh.c:2528 when compiling Python's Python/_warnings.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92063
--- Comment #1 from Romain Geissler ---
Python code is here:
https://github.com/python/cpython/blob/v3.7.4/Python/_warnings.c#L753
#define ascii_lower(c) ((c <= 127) ? Py_TOLOWER(c) : 0)
/* if filename.lower().endswith(".pyc"): */
if (len >= 4 &&
PyUnicode_READ(kind, data, len-4) == '.' &&
ascii_lower(PyUnicode_READ(kind, data, len-3)) == 'p' &&
ascii_lower(PyUnicode_READ(kind, data, len-2)) == 'y' &&
ascii_lower(PyUnicode_READ(kind, data, len-1)) == 'c')
{
*filename = PyUnicode_Substring(*filename, 0,
PyUnicode_GET_LENGTH(*filename)-1);
if (*filename == NULL)
goto handle_error;
}
else
Py_INCREF(*filename);
[Bug c/92063] New: [10 Regression] ICE in operation_could_trap_p, at tree-eh.c:2528 when compiling Python's Python/_warnings.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92063 Bug ID: 92063 Summary: [10 Regression] ICE in operation_could_trap_p, at tree-eh.c:2528 when compiling Python's Python/_warnings.c Product: gcc Version: 10.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 have an ICE in gcc 10 when trying to setup a GNU toolchain with current sources. It fails when trying to build Python 3.7.4. I don't have access to any build artefacts though, just the job logs. Gcc is built from r276854 on x64 Linux. Gcc itself is bootstrapped with LTO + PGO. Building gcc itself works fine (as well as building the LLVM toolchain, glibc, and binutils with that gcc). binutils: 2.33 glibc: 2.30 I am trying to build Python 3.7.4 from sources: gcc -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -O2 -msse -msse2 -msse3 -I/workdir/build/build-pack/build-pack-temporary-static-dependencies/install/include -I/workdir/build/build-pack/build-pack-temporary-static-dependencies/install/include/ncursesw -I/workdir/build/build-pack/build-pack-temporary-static-dependencies/install/lib/libffi-3.2.1/include -I/opt/1A/toolchain/x86_64-v20.0.3/build-pack/20.0.3.0/internal-python-only-for-build-pack/include -Wno-error -O2 -msse -msse2 -msse3 -I/workdir/build/build-pack/build-pack-temporary-static-dependencies/install/include -I/workdir/build/build-pack/build-pack-temporary-static-dependencies/install/include/ncursesw -I/workdir/build/build-pack/build-pack-temporary-static-dependencies/install/lib/libffi-3.2.1/include -I/opt/1A/toolchain/x86_64-v20.0.3/build-pack/20.0.3.0/internal-python-only-for-build-pack/include -Wno-error -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Wno-cast-function-type -Wstrict-prototypes -Werror=implicit-function-declaration -IObjects -IInclude -IPython -I. -I/workdir/src/Python-3.7.4/Include -I/workdir/build/build-pack/build-pack-temporary-static-dependencies/install/include -I/workdir/build/build-pack/build-pack-temporary-static-dependencies/install/include/ncursesw -I/workdir/build/build-pack/build-pack-temporary-static-dependencies/install/lib/libffi-3.2.1/include -I/opt/1A/toolchain/x86_64-v20.0.3/build-pack/20.0.3.0/internal-python-only-for-build-pack/include -I/workdir/build/build-pack/build-pack-temporary-static-dependencies/install/include -I/workdir/build/build-pack/build-pack-temporary-static-dependencies/install/include/ncursesw -I/workdir/build/build-pack/build-pack-temporary-static-dependencies/install/lib/libffi-3.2.1/include -I/opt/1A/toolchain/x86_64-v20.0.3/build-pack/20.0.3.0/internal-python-only-for-build-pack/include -DPy_BUILD_CORE -o Python/_warnings.o /workdir/src/Python-3.7.4/Python/_warnings.c /workdir/src/Python-3.7.4/Python/_warnings.c: In function 'setup_context': /workdir/src/Python-3.7.4/Python/_warnings.c:753:13: internal compiler error: in operation_could_trap_p, at tree-eh.c:2528 753 | ascii_lower(PyUnicode_READ(kind, data, len-1)) == 'c') | ^~~ 0x5f2081 operation_could_trap_p(tree_code, bool, bool, tree_node*) /workdir/src/gcc-10.0.0/gcc/tree-eh.c:2528 0x5f2081 operation_could_trap_p(tree_code, bool, bool, tree_node*) /workdir/src/gcc-10.0.0/gcc/tree-eh.c:2518 0xef269a tree_could_trap_p(tree_node*) /workdir/src/gcc-10.0.0/gcc/tree-eh.c:2635 0xf960d1 simple_operand_p_2 /workdir/src/gcc-10.0.0/gcc/fold-const.c:4451 0xf91e62 fold_truth_andor /workdir/src/gcc-10.0.0/gcc/fold-const.c:8290 0xf1d2fd fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) /workdir/src/gcc-10.0.0/gcc/fold-const.c:10606 0xf1be99 fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) /workdir/src/gcc-10.0.0/gcc/fold-const.c:12382 0xf0bd53 c_fully_fold_internal /workdir/src/gcc-10.0.0/gcc/c/c-fold.c:535 0xf0bc4c c_fully_fold_internal /workdir/src/gcc-10.0.0/gcc/c/c-fold.c:513 0xf0bc4c c_fully_fold_internal /workdir/src/gcc-10.0.0/gcc/c/c-fold.c:513 0xf0ae6b c_fully_fold(tree_node*, bool, bool*, bool) /workdir/src/gcc-10.0.0/gcc/c/c-fold.c:125 0xf42a8a c_parser_condition /workdir/src/gcc-10.0.0/gcc/c/c-parser.c:5677 0xf420ce c_parser_paren_condition /workdir/src/gcc-10.0.0/gcc/c/c-parser.c:5695 0xf0793e c_parser_if_statement /workdir/src/gcc-10.0.0/gcc/c/c-parser.c:5874 0xf0793e c_parser_statement_after_labels /workdir/src/gcc-10.0.0/gcc/c/c-parser.c:5506 0xf033da c_parser_compound_statement_nostart /workdir/src/gcc-10.0.0/gcc/c/c-parser.c:5185 0xf00ac7 c_parser_compound_statement /workdir/src/gcc-10.0.0/gcc/c/c-parser.c:5019 0xf07f09 c_parser_if_body
[Bug lto/84579] __gnu_lto_v1 should be removed when linking with -fno-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84579 --- Comment #10 from Romain Geissler --- Ah thanks, I had backported this one as well, but not the one you mentionned: commit 217597acb2493b727255b66cd199fafa065427b7 Author: marxin Date: Wed Jul 24 07:00:48 2019 + Fix off-by-one in simple-object-elf.c (PR lto/91228). 2019-07-24 Martin Liska PR lto/91228 * simple-object-elf.c (simple_object_elf_copy_lto_debug_sections): Find first '\0' starting from gnu_lto + 1. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@273757 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug lto/84579] __gnu_lto_v1 should be removed when linking with -fno-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84579 Romain Geissler changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Romain Geissler --- Hi, I am closing this ticket as it's fixed in gcc 10. This will not backported officially to gcc 8 and 9, however in the Amadeus toolchain we are using these different patches untouched implemented that in gcc 8 and 9 for one month, successfully so far. Cheers, Romain
[Bug debug/91239] New: gcc generates invalid .debug_macro sections (according to lld folks)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91239 Bug ID: 91239 Summary: gcc generates invalid .debug_macro sections (according to lld folks) Product: gcc Version: 9.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: romain.geissler at amadeus dot com Target Milestone: --- Hi, After a bug report opened to lld here https://bugs.llvm.org/show_bug.cgi?id=42030, lld folks rejected it as invalid based on the reason that apparently .debug_macro sections generated by gcc don't see valid. I am quoting them here, you can see my initial bug report to check what was my initial problem: <http://www.sco.com/developers/gabi/latest/ch4.sheader.html#section_groups , such relocations to .Ldebug_macro should not be allowed. > A symbol table entry with STB_LOCAL binding that is defined relative to one > of a group's sections, and that is contained in a symbol table section that > is not part of the group, must be discarded if the group members are > discarded. References to this symbol table entry from outside the group are > not allowed. I think ld.bfd/gold/lld error if the section containing the relocation is SHF_ALLOC. .debug* do not have the SHF_ALLOC flag and those relocations are allowed. lld resolves such relocations to 0. ld.bfd and gold, however, have some CB_PRETEND/PRETEND logic to resolve relocations to the definitions in the prevailing comdat groups. The code is hacky and may not suit lld. I think the proper fix of this problem is to patch gdb to ignore 0 DW_MACRO_import. = Paul Robinson 2019-07-01 06:30:34 PDT = If references to comdats aren't being emitted correctly, that seems like a compiler problem not a linker or debugger problem. This has the feel of bfd/gold working around a gcc issue. END_OF_QUOTE I am not sure to understand what they mean, I hope it's clearer for you ;) Cheers, Romain
[Bug lto/84579] __gnu_lto_v1 should be removed when linking with -fno-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84579 --- Comment #6 from Romain Geissler --- Hi, After trying to build our own set of open source components with this patch (among the sqlite, openssl, boost, tcmalloc), we have no link issues resulting from this change. Tested with gcc 8 and gcc 9. The only problem being adapting the 2 binutils LTO tests which are now failing. Cheers, Romain
[Bug lto/84579] __gnu_lto_v1 should be removed when linking with -fno-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84579 --- Comment #5 from Romain Geissler --- Hi, Your patch applies cleanly to both gcc 8 and 9. I was able to bootstrap two toochains gcc 8 and 9 with it, however it caused regression in the binutils testsuite: FAIL: ld-plugin/lto-3r FAIL: ld-plugin/lto-5r For which I have no more details, but it should be easy to reproduce. I will go past these regression in the binutils and try to build some of our open source components with it to have a bigger test surface. Cheers, Romain
[Bug lto/84579] __gnu_lto_v1 should be removed when linking with -fno-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84579 --- Comment #3 from Romain Geissler --- Hi, @Martin (and @Richard), I have seen you submitted this patch https://gcc.gnu.org/ml/gcc-patches/2019-07/msg01059.html which I guess would fix this bug. If accepted in gcc 10, do you think it is safe to backport in gcc 8/9 (I can patch my gcc's locally, but I would like to know if that removal relies on other commits which are only in gcc 10). Thanks, Romain
[Bug lto/84579] __gnu_lto_v1 should be removed when linking with -fno-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84579 --- Comment #2 from Romain Geissler --- Hi, @Martin (and @Richard), I have seen you submitted this patch https://gcc.gnu.org/ml/gcc-patches/2019-07/msg01059.html which I guess would fix this bug. If accepted in gcc 10, do you think it is safe to backport in gcc 8/9 (I can patch my gcc's locally, but I would like to know if that removal relies on other commits which are only in gcc 10). Thanks, Romain
[Bug tree-optimization/84561] -Wstringop-truncation with -O2 depends on strncpy's size type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84561 --- Comment #5 from Romain Geissler --- Hi, With the new release of gcc 9, I am seeing new occurences of this issue. I am trying to put a statement _string[len] = 0; after the strncpy to silence the warning, but still it triggers sometimes. Is the patch you posted back then still being discussed ? Cheers, Romain
[Bug tree-optimization/90892] New: [9/10 regression] -O2 miscompiles __builtin_strncmp with string containing '\0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90892
Bug ID: 90892
Summary: [9/10 regression] -O2 miscompiles __builtin_strncmp
with string containing '\0'
Product: gcc
Version: 9.1.1
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,
It looks like doing things like __builtin_strncmp(someString, "A\0", 2) does an
out of bound comparison (ie comparing 3 chars instead of 2), and leads to wrong
behavior. It happens with gcc 9.1.1 and apparently 10 as well (checked on
godbolt: https://godbolt.org/z/CDvkRs)
> cat test.c
volatile char a[3] = { 'A', '\0', 42 };
int main()
{
char b[3] = {a[0], a[1], a[2]};
return __builtin_strncmp(b, "A\0", 2);
}
> gcc -O2 -o test test.c
> ./test && echo 'OK!!!' || echo 'KO...'
KO...
I would expect that it always returns "OK!!!" no matter which optimization
level is used. -O0 and -O1 are working fine. gcc 8 is happy with this at all
optimization levels. I hope using strings like "A\0" is not UB.
Cheers,
Romain
[Bug libbacktrace/90636] New: [libbacktrace] Tests edtest/edtest_alloc/ttest/ttest_alloc are failing on x64 Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90636 Bug ID: 90636 Summary: [libbacktrace] Tests edtest/edtest_alloc/ttest/ttest_alloc are failing on x64 Linux Product: gcc Version: 9.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libbacktrace Assignee: unassigned at gcc dot gnu.org Reporter: romain.geissler at amadeus dot com CC: ian at gcc dot gnu.org Target Milestone: --- Hi, I am trying to build and test gcc from branch gcc-9-branch, and the tests edtest/edtest_alloc/ttest/ttest_alloc are failing always for the same reason: test1: [0]: missing file name or function name I use: - Linux x64 (runtime kernel is a Linux 4.4 Ubuntu, headers against my toolchain is built are from Linux 4.12) - Binutils 2.32 (from git branch binutils-2_32-branch, configured with --enable-compressed-debug-sections=all) - glibc 2.29 (from git branch release/2.29/master) - gcc 9.1.1 20190524 built with PGO + LTO I have tried to remove PGO/LTO build of gcc, as well as removing --enable-compressed-debug-sections=all in binutils, and these test still fail. I have no idea how to investigate this further, nor if I am the only one to have these failures. Cheers, Romain
[Bug rtl-optimization/57193] [7 Regression] suboptimal register allocation for SSE registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57193 Romain Geissler changed: What|Removed |Added CC||romain.geissler at amadeus dot com --- Comment #20 from Romain Geissler --- Hi, It looks like the GCC 9/10 re-occurence is being tracked in this bug 87716. Cheers, Romain
[Bug rtl-optimization/87716] [9/10 Regression] FAIL: gcc.target/i386/pr57193.c scan-assembler-times movdqa 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87716 Romain Geissler changed: What|Removed |Added CC||romain.geissler at amadeus dot com --- Comment #6 from Romain Geissler --- Hi, If this test is failing for quite some time and if the fix seems to be complex to write, shall this test be marked as xfailing for now ? Cheers, Romain
[Bug c++/90339] New: Change default c++ dialect to -std=gnu++17 in gcc 10 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90339 Bug ID: 90339 Summary: Change default c++ dialect to -std=gnu++17 in gcc 10 ? Product: gcc Version: 10.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, In today's release announcement https://gcc.gnu.org/ml/gcc/2019-05/msg00024.html C++17 is now marked as no longer experimental in gcc 9. Support has matured for a few years. Do you think it would make sense to change in gcc 10 the default dialect to -std=gnu++17 so that distro packages slowly adapt their code to be C++17 compatible ? For example we hit a few cases last year where some components were typedef'ing a type named "byte" which resulted in ambiguity when using -std=gnu++17 defining std::byte. Cheers, Romain
[Bug c++/89906] New: [8 Regression] template template parameter redeclared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89906
Bug ID: 89906
Summary: [8 Regression] template template parameter redeclared
Product: gcc
Version: 8.3.1
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 started to be rejected between:
g++ (GCC) 8.3.1 20190225
and
g++ (GCC) 8.3.1 20190331
, only when using -std=gnu++17). Clang 8 happily compiles it.
> cat reproducer.cpp
template class Tmpl> struct TemplateSel {};
template class T1> struct Templates1
{
typedef TemplateSel Head;
};
template class F> struct
quote3;
template class F> struct
quote3 {};
> /opt/1A/toolchain/x86_64-2.6.32-v4.0.55/bin/g++ -std=gnu++17 -o reproducer
> -c reproducer.cpp
reproducer.cpp:8:66: error: template parameter ‘template class F’
template class F> struct
quote3;
^
reproducer.cpp:10:76: error: redeclared here as ‘template class F’
template class F> struct
quote3 {};
^~
Cheers,
Romain
[Bug libstdc++/88782] New: Crash when mixing make_shared from gcc <= 8.2 with make_shared from gcc >= 8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88782
Bug ID: 88782
Summary: Crash when mixing make_shared from gcc <= 8.2 with
make_shared from gcc >= 8.3
Product: gcc
Version: 9.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,
The change introduced in r266380 makes newer gcc >= 8.3 and gcc 9 sometimes
incompatible with object files (archive libraries) generated with gcc <= 8.2,
even when all the generated objects are using -frtti.
See this example where mixing an old library build with an old gcc 8 and a new
library build with a new gcc 8 result in the end in a segfault:
cat > A.h < library1.cpp <
void f1()
{
std::make_shared(A::Constructor1());
}
END_OF_FILE
cat > library2.cpp <
void f2()
{
std::make_shared(A::Constructor2());
}
END_OF_FILE
cat > main.cpp <
extern void f1();
extern void f2();
int main()
{
f1();
f2();
}
END_OF_FILE
### Built like this: ###
old-g++-8 -g -o library1.o -c library1.cpp
ar cr library1.a library1.o
new-g++-8 -g -o library2.o -c library2.cpp
ar cr library2.a library2.o
new-g++-8 -g -o main.o -c main.cpp
new-g++-8 -o main main.o library1.a library2.a
(in my case, old-g++-8 is actually named
/remote/tools/Linux/2.6/1A/toolchain/x86_64-2.6.32-v4.0.40/bin/g++ and
new-g++-8 is actually named
/remote/tools/Linux/2.6/1A/toolchain/x86_64-2.6.32-v4.0.46/bin/g++)
### When you run it (with gdb): ###
(gdb) r
Starting program: /tmp/reproduce-gcc-make-shared/main
Program received signal SIGSEGV, Segmentation fault.
0x004011bd in std::type_info::operator== (this=0x403200
, __arg=...)
at
/remote/tools/Linux/2.6/1A/toolchain/x86_64-2.6.32-v4.0.40/include/c++/8.2.1/typeinfo:123
123 || (__name[0] != '*' &&
(gdb) bt
#0 0x004011bd in std::type_info::operator== (this=0x403200
, __arg=...)
at
/remote/tools/Linux/2.6/1A/toolchain/x86_64-2.6.32-v4.0.40/include/c++/8.2.1/typeinfo:123
#1 0x00401d6f in std::_Sp_counted_ptr_inplace,
(__gnu_cxx::_Lock_policy)2>::_M_get_deleter (this=0x418c20, __ti=...)
at
/remote/tools/Linux/2.6/1A/toolchain/x86_64-2.6.32-v4.0.40/include/c++/8.2.1/bits/shared_ptr_base.h:569
#2 0x0040176e in
std::__shared_count<(__gnu_cxx::_Lock_policy)2>::_M_get_deleter
(this=0x7fffc4e8, __ti=...)
at
/remote/tools/Linux/2.6/1A/toolchain/x86_64-2.6.32-v4.0.40/include/c++/8.2.1/bits/shared_ptr_base.h:749
#3 0x00401f8c in std::__shared_ptr::__shared_ptr, A::Constructor2>
(this=0x7fffc4e0, __tag=..., __a=...)
at
/remote/tools/Linux/2.6/1A/toolchain/x86_64-2.6.32-v4.0.46/include/c++/8.2.1/bits/shared_ptr_base.h:1328
#4 0x00401f1d in std::shared_ptr::shared_ptr,
A::Constructor2> (this=0x7fffc4e0, __tag=..., __a=...)
at
/remote/tools/Linux/2.6/1A/toolchain/x86_64-2.6.32-v4.0.46/include/c++/8.2.1/bits/shared_ptr.h:360
#5 0x00401ee0 in std::allocate_shared,
A::Constructor2> (__a=..., __args#0=...)
at
/remote/tools/Linux/2.6/1A/toolchain/x86_64-2.6.32-v4.0.46/include/c++/8.2.1/bits/shared_ptr.h:707
#6 0x00401e68 in std::make_shared (__args#0=...)
at
/remote/tools/Linux/2.6/1A/toolchain/x86_64-2.6.32-v4.0.46/include/c++/8.2.1/bits/shared_ptr.h:723
#7 0x00401e00 in f2 () at library2.cpp:6
#8 0x00401152 in main () at main.cpp:9
The reason for that is that the symbols and the vtable for the class
std::_Sp_counted_ptr_inplace comes from the first object that defines it, which
in this case is library1 built with the old gcc behavior. This class is common
both when you call make_shared with constructor 1 or constructor 2, and this is
where _M_get_deleter does it's check for the typeid(_Sp_make_shared_tag).
On the other side, there are two different callers of _M_get_deleter. One with
the old typeid(__tag) tag in the library 1 (when instantiating the call to
constructor 1) and one with the new _Sp_make_shared_tag::_S_ti() tag in the
library 2 (when instantiating the call to constructor 2). Because the linker
picked the "wrong" old _M_get_deleter, the second call ends it in seg fault.
Do we foresee a way to avoid rebuilding all libraries that were built with gcc
<= 8.2 when mixing them with libraries build with gcc >= 8.3 ? I am thinking
about doing something like this:
--- bits/shared_ptr_base.h
+++ bits/shared_ptr_base.h
@@ -509,8 +509,12 @@
static const type_info&
_S_ti() noexcept _GLIBCXX_VISIBILITY(default)
{
+#if __cpp_rtti
+ return typeid(_Sp_make_shared_tag);
+#else
alignas(type_info) static constexpr char __tag[sizeof(type_info)] = { };
return reinterpret_cast(__tag);
+#endif
}
};
@@ -567,12 +571,6 @@
// as a real type_in
[Bug libstdc++/88749] [9 Regression] Failure while building libstdc++-v3/src/filesystem/ops.cc on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749 --- Comment #15 from Romain Geissler --- Thanks for these remarks. FYI, what I am following are the Linux From Scratch guidelines, which build the initial gcc like this (with both c and C++ support, disabling libstdc++ build): http://www.linuxfromscratch.org/lfs/view/development/chapter05/gcc-pass1.html Then after building the glibc, they do build the libstdc++ alone like this: http://www.linuxfromscratch.org/lfs/view/development/chapter05/gcc-libstdc++.html With this PR I just found out that either my understanding of LFS is wrong, either LFS itself is. Indeed I don't like much that when configured using my bootstrap scripts libstdc++ doesn't use the C compiler but the C++ one to find C headers. I will have a look to sort this out.
[Bug libstdc++/88749] [9 Regression] Failure while building libstdc++-v3/src/filesystem/ops.cc on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749 --- Comment #9 from Romain Geissler --- This may be some naive question, but if we are currently trying to build a libstdc++, shouldn't we assume there is no pre-existing libstdc++ and run the different checks in the configure script either with the C compiler (if indeed we never use C++) or with CXXFLAGS like -nodefaultlib ?
[Bug libstdc++/88749] [9 Regression] Failure while building libstdc++-v3/src/filesystem/ops.cc on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749 --- Comment #8 from Romain Geissler --- Your patch is working. I may add some context to better understand this strange scenario. In my case, the config log says: configure:80434: checking for utimensat configure:80484: x86_64-1a-linux-gnu-g++ -o conftest -O2 -mmmx -msse -msse2 -msse3 -fno-exceptions -O2 -mmmx -msse -msse2 -msse3 conftest.cpp >&5 /home/jenkins/workspace/OTF_Toolchain_release_20.0-GWCRYYLPVAZ3GI64ZF43J2FVALYHUCNKGFBXVRTH6NJF73DCK7SQ/output/build/temporary-system/install/bin/../lib/gcc/x86_64-1a-linux-gnu/9.0.0/../../../../x86_64-1a-linux-gnu/bin/ld: cannot find -lstdc++ for all find of header check, so in the end they all end up being as not found. I don't just build gcc or libstdc++ in my build, actually it's a full toolchain bootstrap following what is done in Linux From Scratch. I build in that order: - binutils, with a linker configured to look for system libraries in a non-standard folder, empty for now - gcc, without libstdc++ - glibc, using the above binutils/gcc, which fills in the non standard lib folder with only a libc. - libstdc++, using the above binutils/gcc/glibc. At the moment we build this first libstdc++, there is no existing libstdc++ yet, thus the above configure failures. Note that this is just the beginning of the bootstrap. After this other gcc/libstdc++ are being built, and this time the configure script works unpatched. So with these explanations, do you think the patch you proposed should land in trunk (it worked for me in that specific bootstrap configuration).
[Bug libstdc++/88749] [9 Regression] Failure while building libstdc++-v3/src/filesystem/ops.cc on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749 --- Comment #5 from Romain Geissler --- Note that it was building fine with gcc commit 4a4bec8257aa255cca9be7f24a61159cadb36942 from Fri Dec 28 (aka r267451), and the same glibc commit.
[Bug libstdc++/88749] [9 Regression] Failure while building libstdc++-v3/src/filesystem/ops.cc on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749 --- Comment #4 from Romain Geissler --- Thanks I will test this ASAP. I am using x86-64, and a very recent glibc near current master: GLIBC_VERSION="2.28.90" GLIBC_COMMIT="0253580a75decdaf22b6abce60d8265b2adb7dea"
[Bug libstdc++/88749] New: Failure while building libstdc++-v3/src/filesystem/ops.cc on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749 Bug ID: 88749 Summary: Failure while building libstdc++-v3/src/filesystem/ops.cc on trunk Product: gcc Version: 9.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, With the latest move of libstdc++fs.so in libstdc++.so, I am seeing these new build errors: /workdir/src/gcc-9.0.0/libstdc++-v3/src/filesystem/ops.cc: In function 'void std::experimental::filesystem::v1::last_write_time(const std::experimental::filesystem::v1::path&, std::experimental::filesystem::v1::file_time_type, std::error_code&)': /workdir/src/gcc-9.0.0/libstdc++-v3/src/filesystem/ops.cc:913:10: error: 'utimbuf' is not a member of 'posix'; did you mean 'utimbuf'? 913 | posix::utimbuf times; | ^~~ In file included from /workdir/src/gcc-9.0.0/libstdc++-v3/src/filesystem/ops.cc:50, from /workdir/src/gcc-9.0.0/libstdc++-v3/src/filesystem/cow-ops.cc:26: /home/jenkins/workspace/OTF_Toolchain_release_20.0-GWCRYYLPVAZ3GI64ZF43J2FVALYHUCNKGFBXVRTH6NJF73DCK7SQ/output/build/temporary-system/install/include/utime.h:36:8: note: 'utimbuf' declared here 36 | struct utimbuf |^~~ In file included from /workdir/src/gcc-9.0.0/libstdc++-v3/src/filesystem/cow-ops.cc:26: /workdir/src/gcc-9.0.0/libstdc++-v3/src/filesystem/ops.cc:914:3: error: 'times' was not declared in this scope; did you mean 'time'? 914 | times.modtime = s.count(); | ^ | time /workdir/src/gcc-9.0.0/libstdc++-v3/src/filesystem/ops.cc:917:14: error: 'utime' is not a member of 'posix'; did you mean 'utime'? 917 | if (posix::utime(p.c_str(), )) | ^ So there may need some fixes around things like _GLIBCXX_USE_UTIMENSAT or _GLIBCXX_HAVE_UTIME_H. Cheers, Romain
[Bug c++/84436] [8/9 Regression] Missed optimization with switch on enum constants returning the same value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84436 --- Comment #13 from Romain Geissler --- Apparently the clang-tlbgen failures started with r265241. Checking if it still happens on gcc trunk with r265463 reverted.
[Bug c++/84436] [8/9 Regression] Missed optimization with switch on enum constants returning the same value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84436 --- Comment #12 from Romain Geissler --- Hi, I have tried the following script directly inside docker using the official "debian:buster" docker image, so I hope it will not require much more dependencies than what is written here. Tested with x86-64.
[Bug c++/84436] [8/9 Regression] Missed optimization with switch on enum constants returning the same value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84436 Romain Geissler changed: What|Removed |Added CC||romain.geissler at amadeus dot com --- Comment #10 from Romain Geissler --- Hi, FYI, I bisected this revision r265463 to introduce a regression when building the llvm toolchain. If you do the following: - build gcc 9 >= r265463 (including recent revisions from late December) - build clang 7 or clang 8 svn with this gcc 9 (it will work) - finally with the resulting clang, build llvm's compiler-rt then clang itself will ICE. Before r265463 it was not the case, and considering the nature of the fix (missed optimization) I suspect more a gcc bug rather than a clang one. The exact clang failure is: FAILED: CMakeFiles/clang_rt.builtins-x86_64.dir/divtc3.c.o /workdir/build/final-system/llvm-build/./bin/clang --target=x86_64-1a-linux-gnu -DVISIBILITY_HIDDEN -O2 -mmmx -msse -msse2 -msse3 -I/workdir/build/final-system/llvm-temporary-static-dependencies/install/include -I/workdir/build/final-system/llvm-temporary-static-dependencies/install/include/ncursesw -O3 -DNDEBUG-m64 -std=c11 -fPIC -fno-builtin -fvisibility=hidden -fomit-frame-pointer -MD -MT CMakeFiles/clang_rt.builtins-x86_64.dir/divtc3.c.o -MF CMakeFiles/clang_rt.builtins-x86_64.dir/divtc3.c.o.d -o CMakeFiles/clang_rt.builtins-x86_64.dir/divtc3.c.o -c /workdir/src/llvm-8.0.0/compiler-rt/lib/builtins/divtc3.c fatal error: error in backend: Cannot select: 0x1a4b558: ch = fsqrt 0x199e868, 0x1a46e38, FrameIndex:i64<0> 0x1a46e38: f80,ch = CopyFromReg 0x199e868, Register:f80 %0 0x1a46d68: f80 = Register %0 0x1a4bd10: i64 = FrameIndex<0> In function: __divtc3 clang-8: error: clang frontend command failed with exit code 70 (use -v to see invocation) clang version 8.0.0 Target: x86_64-1a-linux-gnu Thread model: posix InstalledDir: /workdir/build/final-system/llvm-build/./bin clang-8: note: diagnostic msg: PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script. clang-8: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang-8: note: diagnostic msg: /tmp/divtc3-106b93.c clang-8: note: diagnostic msg: /tmp/divtc3-106b93.sh clang-8: note: diagnostic msg: Note: step 2 and 3 (build clang then build compiler-rt with the resulting clang) is done automatically when bootstrapping a 2-stage PGO clang using this cmake configuration: https://github.com/llvm-mirror/clang/blob/master/cmake/caches/PGO.cmake I don't know how to help more in investigating this regression. If I can do something, please ask. Cheers, Romain
[Bug c++/87956] New: Gcc should emit deprecation warnings when using throw() in C++ >= 17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87956 Bug ID: 87956 Summary: Gcc should emit deprecation warnings when using throw() in C++ >= 17 Product: gcc Version: 9.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, Today gcc always generates an error when you use a dynamic exception specification with some exception. However I would expect we might also get a warning with -Wdeprecated for "throw()" expressions. With -std=gnu++17 -Wdeprecated #include void f() throw(); // No deprecation warning saying you should use noexcept instead void g() throw(std::exception); // Errors in C++17 I would expect a deprecation warning for f. FYI, clang's -Wdeprecated flag finds and notifies about this. Cheers, Romain
[Bug libstdc++/87822] [6/7/8/9 Regression] Binary incompatibility in std::pair introduced by PR 86751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87822 --- Comment #10 from Romain Geissler --- Thanks for the quick patch ! If no commit is planned in the branch 6, I am going to apply this patch on top myself. I hope people do read the release notes to figure out about this potential ABI breaking.
[Bug libstdc++/87822] New: [regression 6/7/8/9] Binary incompatibility in std::pair introduced by PR 86751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87822 Bug ID: 87822 Summary: [regression 6/7/8/9] Binary incompatibility in std::pair introduced by PR 86751 Product: gcc Version: 9.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 having core dumps when mixing libraries built with gcc 6.4.1 and the final gcc 6.5.0 (I know gcc 6 branch is closed, but since the incompatibility is about a std::pair type that is quite commonly used I guess this is still valid). You have the exact same incompatibility with early gcc 7 vs newest gcc 7, early gcc 8 vs newest gcc 8. See this simple snippet that builds fine with both gcc 6.4 and 6.5 shows the change of type size (on x64): #include #include #if __GNUC__ == 6 && __GNUC_MINOR__ <= 4 static_assert(sizeof(std::pair, std::string>) == 96, ""); #elif __GNUC__ == 6 && __GNUC_MINOR__ >= 5 static_assert(sizeof(std::pair, std::string>) == 104, ""); // Size of type changed with r265162 #endif Shall we revert PR 86751 or find another way to fix it (introduce a new tagged std::pair type and provide dual abi ?). Cheers, Romain
[Bug rtl-optimization/87780] [9 regression] ICE error: unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87780 --- Comment #5 from Romain Geissler --- Hi, Trying with today's trunk with this patch included, my clang PGO+LTO bootstrap goes further, but then the generated clang fails to compile itself. Just putting here the clang error for reference: fatal error: error in backend: Cannot select: 0x20c13f8: ch = fp_to_fp16 0x201f1d8, 0x20bccd8, FrameIndex:i64<0> 0x20bccd8: f80,ch = CopyFromReg 0x201f1d8, Register:f80 %0 0x20bcc08: f80 = Register %0 0x20c1bb0: i64 = FrameIndex<0> In function: __divtc3 clang-7: error: clang frontend command failed with exit code 70 (use -v to see invocation) The only thing that I changed recently is binutils/gcc/glibc, not the clang sources. So there might still have some code gen issue left in gcc trunk (which I don't know how to investigate). Cheers, Romain
[Bug debug/87428] "Missed" inline instances cause bogus DWARF to be emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87428 Romain Geissler changed: What|Removed |Added CC||romain.geissler at amadeus dot com --- Comment #4 from Romain Geissler --- Hi, The same issue happens with gcc 8 as well: /workdir/src/gdb-8.2/gdb/dwarf2read.c:9715: internal-error: void dw2_add_symbol_to_list(symbol*, pending**): Assertion `(*listhead) == NULL || (SYMBOL_LANGUAGE ((*listhead)->symbol[ 0]) == SYMBOL_LANGUAGE (symbol))' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) [answered Y; input not from terminal] I could validate on my side that applying this patch + rebuilding all LTO-enabled libraries participating into the final link of my binary did solve this issue. Cheers, Romain
[Bug rtl-optimization/87780] New: [9 regression] ICE error: unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87780 Bug ID: 87780 Summary: [9 regression] ICE error: unrecognizable insn Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: romain.geissler at amadeus dot com Target Milestone: --- Hi, I have the following ICE when building llvm+clang+lld 7.0.0 (PGO + LTO profile) on x64 with gcc from 28/10/2018 (while it was working fine with gcc from 11/10/2018): /workdir/src/llvm-7.0.0.src/tools/clang/lib/Sema/TreeTransform.h:5222:1: error: unrecognizable insn: 5222 | } | ^ (insn 1262 1261 1263 2 (set (reg:V1TI 678) (reg:TI 1 dx [ TL ])) "/workdir/src/llvm-7.0.0.src/tools/clang/lib/Sema/TreeTransform.h":5212:1 -1 (nil)) during RTL pass: subreg2 /workdir/src/llvm-7.0.0.src/tools/clang/lib/Sema/TreeTransform.h:5222:1: internal compiler error: in extract_insn, at recog.c:2305 0xfb86cb ??? /workdir/src/gcc-9.0.0/gcc/rtl-error.c:108 0xfb86e7 ??? /workdir/src/gcc-9.0.0/gcc/rtl-error.c:116 0x90ac09 ??? /workdir/src/gcc-9.0.0/gcc/recog.c:2305 0x179be75 ??? /workdir/src/gcc-9.0.0/gcc/lower-subreg.c:1483 0x180b49d ??? /workdir/src/gcc-9.0.0/gcc/lower-subreg.c:1750 0x12750d6 ??? /workdir/src/gcc-9.0.0/gcc/passes.c:2428 0x12e9abc ??? /workdir/src/gcc-9.0.0/gcc/passes.c:2517 0x14dd528 ??? /workdir/src/gcc-9.0.0/gcc/cgraphunit.c:2194 0x12727ca ??? /workdir/src/gcc-9.0.0/gcc/cgraphunit.c:2332 0x1268677 ??? /workdir/src/gcc-9.0.0/gcc/cgraphunit.c:2861 0x1240f3a ??? /workdir/src/gcc-9.0.0/gcc/toplev.c:480 0x11b05c6 ??? /workdir/src/gcc-9.0.0/gcc/toplev.c:2172 0x11af92a ??? /workdir/src/gcc-9.0.0/gcc/main.c:39 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. ninja: build stopped: subcommand failed. Cheers, Romain
[Bug lto/87698] [lto] Shared library build with -ffat-lto-objects generates extra global absolute symbol relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87698 --- Comment #6 from Romain Geissler --- Versions of gcc and ld: > gcc --version gcc (GCC) 8.2.1 20181011 Copyright (C) 2018 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. > ld --version GNU ld (GNU Binutils) 2.31.1.20181011 Copyright (C) 2018 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty.
[Bug lto/87698] [lto] Shared library build with -ffat-lto-objects generates extra global absolute symbol relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87698
--- Comment #5 from Romain Geissler ---
Reduced test case:
> cat test.c
void f() {}
> cat test2.c
void f();
void g()
{
f();
}
> cat test.ver
{
local: *;
};
> gcc -g -flto -ffat-lto-objects -fPIC -o test.fat-objects.o -c test.c
> gcc -g -flto -ffat-lto-objects -fPIC -o test2.fat-objects.o -c test2.c
> gcc -g -flto -ffat-lto-objects -fPIC -shared -o test.fat-objects.so
> test.fat-objects.o test2.fat-objects.o -Wl,-version-script=test.ver
> gcc -g -flto -fno-fat-lto-objects -fPIC -o test.slim-objects.o -c test.c
> gcc -g -flto -fno-fat-lto-objects -fPIC -o test2.slim-objects.o -c test2.c
> gcc -g -flto -fno-fat-lto-objects -fPIC -shared -o test.slim-objects.so
> test.slim-objects.o test2.slim-objects.o -Wl,-version-script=test.ver
> readelf -a test.fat-objects.so|grep ABS
5: 0 NOTYPE GLOBAL DEFAULT ABS f <--- unexpected
symbol here
29: 0 FILELOCAL DEFAULT ABS crtstuff.c
37: 0 FILELOCAL DEFAULT ABS
40: 0 FILELOCAL DEFAULT ABS crtstuff.c
42: 0 FILELOCAL DEFAULT ABS
77: 0 FILELOCAL DEFAULT ABS
> readelf -a test.slim-objects.so|grep ABS
29: 0 FILELOCAL DEFAULT ABS crtstuff.c
37: 0 FILELOCAL DEFAULT ABS
40: 0 FILELOCAL DEFAULT ABS crtstuff.c
42: 0 FILELOCAL DEFAULT ABS
65: 0 FILELOCAL DEFAULT ABS
