[Bug c++/109740] -Woverloaded-virtual is too aggressive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109740 Paul Smith changed: What|Removed |Added Version|13.1.0 |14.2.0 --- Comment #6 from Paul Smith --- I verified this still happens with GCC 14.2. I've had to simply disable this warning as too inaccurate to be useful, which is a shame because it would be really handy to have this warning where it IS useful.
[Bug tree-optimization/109720] -Wmaybe-uninitialized triggering when I can see no path that would allow it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109720 --- Comment #7 from Paul Smith --- Just to note this code also throws this warning in GCC 12.3 but it doesn't complain in GCC 11.3 which is what I was using before.
[Bug c++/109850] ICE compiling ccache 4.8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109850 --- Comment #2 from Paul Smith --- I don't know if this is of any use but I ran under valgrind and get this result: ==3019683== Command: /data/src/build/x86_64-linux/cc/unknown/bin/../libexec/gcc/x86_64-unknown-linux-gnu/12.3.0/cc1plus -fpreprocessed LocalStorage.i -quiet -dumpbase LocalStorage.i -dumpbase-ext .i -m64 -mtune=generic -march=x86-64 -o /tmp/ccaQvBYi.s ==3019683== ==3019683== Invalid read of size 4 ==3019683==at 0x7B5503: ??? (in /data/src/build/x86_64-linux/cc/unknown/libexec/gcc/x86_64-unknown-linux-gnu/12.3.0/cc1plus) ==3019683==by 0x1390609: walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) (in /data/src/build/x86_64-linux/cc/unknown/libexec/gcc/x86_64-unknown-linux-gnu/12.3.0/cc1plus) ==3019683==by 0x1390A11: walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) (in /data/src/build/x86_64-linux/cc/unknown/libexec/gcc/x86_64-unknown-linux-gnu/12.3.0/cc1plus) ==3019683==by 0x148A6C3: ??? (in /data/src/build/x86_64-linux/cc/unknown/libexec/gcc/x86_64-unknown-linux-gnu/12.3.0/cc1plus) ==3019683==by 0x1390609: walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) (in /data/src/build/x86_64-linux/cc/unknown/libexec/gcc/x86_64-unknown-linux-gnu/12.3.0/cc1plus) ==3019683==by 0x13906DD: walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) (in /data/src/build/x86_64-linux/cc/unknown/libexec/gcc/x86_64-unknown-linux-gnu/12.3.0/cc1plus) ==3019683==by 0x1390730: walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) (in /data/src/build/x86_64-linux/cc/unknown/libexec/gcc/x86_64-unknown-linux-gnu/12.3.0/cc1plus) ==3019683==by 0x139096F: walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) (in /data/src/build/x86_64-linux/cc/unknown/libexec/gcc/x86_64-unknown-linux-gnu/12.3.0/cc1plus) ==3019683==by 0x1484986: check_for_bare_parameter_packs(tree_node*, unsigned int) (in /data/src/build/x86_64-linux/cc/unknown/libexec/gcc/x86_64-unknown-linux-gnu/12.3.0/cc1plus) ==3019683==by 0x157004A: finish_expr_stmt(tree_node*) (in /data/src/build/x86_64-linux/cc/unknown/libexec/gcc/x86_64-unknown-linux-gnu/12.3.0/cc1plus) ==3019683==by 0x1689186: tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) (in /data/src/build/x86_64-linux/cc/unknown/libexec/gcc/x86_64-unknown-linux-gnu/12.3.0/cc1plus) ==3019683==by 0x1689087: tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) (in /data/src/build/x86_64-linux/cc/unknown/libexec/gcc/x86_64-unknown-linux-gnu/12.3.0/cc1plus) ==3019683== Address 0x5c is not stack'd, malloc'd or (recently) free'd ==3019683==
[Bug c++/109850] ICE compiling ccache 4.8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109850 Paul Smith changed: What|Removed |Added CC||psmith at gnu dot org --- Comment #1 from Paul Smith --- Created attachment 55080 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55080&action=edit LocalStorage.i compressed
[Bug c++/109850] New: ICE compiling ccache 4.8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109850
Bug ID: 109850
Summary: ICE compiling ccache 4.8
Product: gcc
Version: 12.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: psmith at gnu dot org
Target Milestone: ---
I've started working with GCC 12.3.0 I've built myself and I've gotten an ICE
trying to compile ccache 4.8. The preprocessor output is attached. I'm
building using a sysroot from a Rocky Linux 8.4 x86_64 system with glibc 2.28.
I'm using my own binutils 2.40.
I was able to reduce the command line to just: g++ -o LocalStorage.o -c
LocalStorage.i
I attached the .i file.
Output from my build:
$ /data/src/tooldir/bin/x86_64-tools-linux-gnu-g++ -o LocalStorage.o -c
LocalStorage.i
/data/src/ccache/ccache-4.8/src/storage/local/LocalStorage.cpp: In
instantiation of 'storage::local::LocalStorage::recompress(std::optional, uint32_t, const storage::local::ProgressReceiver&):: [with auto:39 = unsigned char; auto:40 =
std::function]':
/data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/12.3.0/type_traits:2559:26:
required by substitution of 'template static
std::__result_of_success()((declval<_Args>)()...)),
std::__invoke_other> std::__result_of_other_impl::_S_test(int) [with _Fn =
storage::local::LocalStorage::recompress(std::optional, uint32_t,
const storage::local::ProgressReceiver&)::&; _Args = {unsigned char, const std::function&}]'
/data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/12.3.0/type_traits:2570:55:
required from 'struct std::__result_of_impl, uint32_t,
const storage::local::ProgressReceiver&)::&, unsigned char, const std::function&>'
/data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/12.3.0/bits/std_function.h:348:9:
recursively required by substitution of 'template
struct std::__is_invocable_impl<_Result, _Ret, true, std::__void_t > [with _Result =
std::__invoke_result, uint32_t, const storage::local::ProgressReceiver&)::&, unsigned char, const
std::function&>; _Ret = void]'
/data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/12.3.0/bits/std_function.h:348:9:
required from 'struct std::function&)>::_Callable, uint32_t, const storage::local::ProgressReceiver&)::,
storage::local::LocalStorage::recompress(std::optional, uint32_t,
const storage::local::ProgressReceiver&)::,
std::__invoke_result, uint32_t, const storage::local::ProgressReceiver&)::&, unsigned char, const std::function&>
>'
/data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/12.3.0/bits/std_function.h:353:8:
required by substitution of 'template
template using _Requires =
std::__enable_if_t<_Cond::value, _Tp> [with _Cond = std::function&)>::_Callable, uint32_t, const storage::local::ProgressReceiver&)::,
storage::local::LocalStorage::recompress(std::optional, uint32_t,
const storage::local::ProgressReceiver&)::,
std::__invoke_result, uint32_t, const storage::local::ProgressReceiver&)::&, unsigned char, const std::function&>
>; _Tp = void; _Res = void; _ArgTypes = {unsigned char, const
std::function&}]'
/data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/12.3.0/bits/std_function.h:434:9:
required by substitution of 'template
std::function&)>::function(_Functor&&) [with _Functor =
storage::local::LocalStorage::recompress(std::optional, uint32_t,
const storage::local::ProgressReceiver&)::; _Constraints = ]'
/data/src/ccache/ccache-4.8/src/storage/local/LocalStorage.cpp:701:24:
required from here
/data/src/ccache/ccache-4.8/src/storage/local/LocalStorage.cpp:710:44: internal
compiler error: Segmentation fault
710 | LOG("Failed to acquire content lock for {}/{}", l1_index,
l2_index);
|^~~
0x7f1399b2c08f ???
/build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x7f1399b0d082 __libc_start_main
../csu/libc-start.c:308
I tried to use -freport-bug but it said "The bug is not reproducible, so it is
likely a hardware or OS problem." But I don't think it's a hardware or OS
problem. It could be related to how I compiled GCC maybe? The crash is
completely repeatable on my system.
[Bug c++/109740] -Woverloaded-virtual is too aggressive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109740 --- Comment #2 from Paul Smith --- What I'm trying to say is that it's not useful (to me) for GCC to warn about code that I could maybe write in the future but didn't actually write, and which if I did write it would generate a compiler error anyway, rather than "doing the wrong thing". On the other hand, it's very useful for GCC to warn me about situations where I could be actually getting an unexpected result, without a compiler error. For example if the parent method takes an int and the child method takes a char, then I might call B.foo(10) expecting to get the parent method but actually the child method will be invoked. That kind of warning is very helpful. So, it would be nice to have a way to warn about things that might miscompile silently in unexpected ways, without also warning about things that can't possibly miscompile in unexpected ways. I did read the description in the docs, and the suggestion of adding using A::foo to the child class, but that inherits all the parent class's virtual methods into the child class which I don't want to do in all cases.
[Bug c++/109740] New: -Woverloaded-virtual is too aggressive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109740
Bug ID: 109740
Summary: -Woverloaded-virtual is too aggressive
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: psmith at gnu dot org
Target Milestone: ---
I understand the impetus for the -Woverloaded-virtual warning but I think it
should be further constrained, or maybe broken into levels of severity that can
be enabled.
The issue I'm running into is that a superclass has a virtual method signature
with some number of arguments, and the subclass has an overloaded method with a
different number of arguments. For example:
struct A { virtual void foo(int); };
struct B : public A { void foo(); };
We do this kind of thing all the time because the subclass's version of this
method has more knowledge, or whatever, and doesn't need the extra arguments.
However, this fires the overloaded-virtual warning. I don't think this
warrants a warning: if I call B.foo() then it will always do the right thing.
If I call B.foo(10) it will give me an error. There's no way that the compiler
could ever call the wrong thing "behind my back" due to some sort of type
conversion that is not obvious from the code, because the number of arguments
are different: either it does exactly what I expect and there's no need for a
warning, or I get an error and there's no need for a warning.
This subclassing capability is (IMO) useful and shouldn't be restricted, but I
would prefer to keep the warning for in other situations that could potentially
cause misbehavior.
Would it be possible to suppress this warning if the overload can't possibly
conflict due to number of arguments?
There is also the possibility that a subclass method has the same number of
arguments but they are of incompatible types which cannot be converted between.
There is an argument to be made that this, also, shouldn't cause a warning.
I'm not sure how straightforward it is to determine "can't be converted"
although there are some obvious ones.
[Bug tree-optimization/109717] -Warray-bound error with gnu++20 and fmt library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109717 --- Comment #9 from Paul Smith --- > Now they're issued even when the "problem" is in a system header. Oh interesting: I have been in the habit of including all my 3rdparty library headers using -isystem to avoid worrying about warnings/errors in them. Regarding this issue I understand the rock versus hard place situation. If there's an assert or something that can help, I can suggest it to the fmt folks; they have been receptive to adding compiler-specific tricks in the past. If I can find the time I'll try to test this by editing my copy. I still find it strange that I can't reproduce this failure using the GDB 13.1 / fmt 9.1.0 libraries available on godbolt: it works fine there. It would be great if this warning could be split into "this is a definite problem" versus "this might be a problem", as some others have been, but I understand that could be complex and a lot of work.
[Bug tree-optimization/109720] -Wmaybe-uninitialized triggering when I can see no path that would allow it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109720 --- Comment #6 from Paul Smith --- I'm happy to provide the source for DynamicBitSet (it's basically a union of a uint64_t and a boost::dynamic_bitset so that if you have <=64 bits you use the uint64_t and if you have >64 bits you use boost::dynamic_bitset). I have a hacked-up version of the original that removes all the unnecessary methods and also throws away some of the complexity for handling the small bitset leg of the union, which is not used in this example. Providing the Boost stuff is harder because, as I'm sure you're aware if you've used Boost, it's a LOT of headers and they all include others, etc. :). But I can try to get the necessary headers, or Boost can be downloaded separately.
[Bug tree-optimization/109720] -Wmaybe-uninitialized triggering when I can see no path that would allow it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109720 --- Comment #3 from Paul Smith --- Created attachment 54986 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54986&action=edit bitset.i.gz compressed preprocessor output Hm, I did attach it when I filed the bug; I guess I forgot to click some final "OK" button because it's not there now! Sorry about that attaching now.
[Bug tree-optimization/109720] -Wmaybe-uninitialized triggering when I can see no path that would allow it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109720 --- Comment #1 from Paul Smith --- Hm, maybe it's due to the union. Maybe GCC can't grok that we ensure that we only use the dynamic_bitset leg of the union after we've initialized it? I wonder if this warning could just assume that if the code uses one leg of the union, that the other legs should be avoided. Or something like that. Else I don't see how this warning can ever be used in code which uses unions.
[Bug c++/109720] New: -Wmaybe-uninitialized triggering when I can see no path that would allow it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109720
Bug ID: 109720
Summary: -Wmaybe-uninitialized triggering when I can see no
path that would allow it
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: psmith at gnu dot org
Target Milestone: ---
I recently upgraded to GCC 13.1 and when building some code that uses
boost::dynamic_bitset I'm seeing the -Wmaybe-ininitialized warning triggering
when it's impossible for any object of the class to be created without the
m_num_bits field being initialized.
I've tried to reduce this without luck. Also if I do other, seemingly
irrelevant things then the warning goes away. I wonder if it's somehow related
to the placement new that we use for the union...?
I'll attach the postprocessed output.
Code:
DynamicBitSet set(200);
size_t setup(size_t ln)
{
size_t count = 0;
DynamicBitSet nbits(set);
for (auto bit: nbits) {
count += bit;
}
return count;
}
I checked and this also failed in GCC 11.3; maybe -Wall didn't used to include
this warning and now it does which is why I didn't notice it before?
Results:
$ /data/src/build/x86_64-linux/bin/x86_64-rl84-linux-gnu-g++
-I/data/src/build/common/boost/include -std=gnu++20 -Wmaybe-uninitialized -O2
-c -o /tmp/bitset.o /tmp/bitset.i
In member function 'boost::dynamic_bitset::size_type
boost::dynamic_bitset::size() const [with Block = long
unsigned int; Allocator = std::allocator]',
inlined from 'boost::dynamic_bitset::size_type
boost::dynamic_bitset::find_next(size_type) const [with Block
= long unsigned int; Allocator = std::allocator]' at
/tmp/bitset.i:70473:30,
inlined from 'DynamicBitSet::size_type DynamicBitSet::find_next(size_type)
const' at /tmp/bitset.i:77301:44,
inlined from 'DynamicBitSet::Iterator&
DynamicBitSet::Iterator::operator++()' at /tmp/bitset.i:77325:38,
inlined from 'size_t setup(size_t)' at /tmp/bitset.i:77340:20:
/tmp/bitset.i:70355:12: warning: '*(const boost::dynamic_bitset >*)((char*)&nbits +
offsetof(DynamicBitSet,
DynamicBitSet::)).boost::dynamic_bitset<>::m_num_bits' may be used
uninitialized [-Wmaybe-uninitialized]
70355 | return m_num_bits;
|^~
/tmp/bitset.i: In function 'size_t setup(size_t)':
/tmp/bitset.i:77339:19: note: 'nbits' declared here
77339 | DynamicBitSet nbits(set);
| ^
[Bug tree-optimization/109717] -Warray-bound error with gnu++20 and fmt library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109717 --- Comment #3 from Paul Smith --- OK, well, we don't have to say "broken"; all I know is that perfectly respectable code that used to work without triggering these warnings in older versions of GCC, and with older -std=c++..., is now failing in GCC 13.1 / -std=c++20 widely enough that I must disable these warnings, which is unfortunate.
[Bug c++/109717] -Warray-bound error with gnu++20 and fmt library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109717 --- Comment #1 from Paul Smith --- This same test case also causes spurious errors for -Wstringop-overflow :( If I use this compile line with the same source file, I get these errors: $ g++-13.1 -I/data/src/build/common/fmt/include -std=gnu++20 -Wstringop-overflow -O2 -c -o /tmp/fmt1.o /tmp/fmt1.cpp In file included from /data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/13.1.0/vector:62, from /tmp/fmt1.cpp:1: In static member function 'static constexpr _Up* std::__copy_move<_IsMove, true, std::random_access_iterator_tag>::__copy_m(_Tp*, _Tp*, _Up*) [with _Tp = unsigned int; _Up = unsigned int; bool _IsMove = false]', inlined from 'constexpr _OI std::__copy_move_a2(_II, _II, _OI) [with bool _IsMove = false; _II = unsigned int*; _OI = unsigned int*]' at /data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/13.1.0/bits/stl_algobase.h:506:30, inlined from 'constexpr _OI std::__copy_move_a1(_II, _II, _OI) [with bool _IsMove = false; _II = unsigned int*; _OI = unsigned int*]' at /data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/13.1.0/bits/stl_algobase.h:533:42, inlined from 'constexpr _OI std::__copy_move_a(_II, _II, _OI) [with bool _IsMove = false; _II = unsigned int*; _OI = unsigned int*]' at /data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/13.1.0/bits/stl_algobase.h:540:31, inlined from 'constexpr _OI std::copy(_II, _II, _OI) [with _II = unsigned int*; _OI = unsigned int*]' at /data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/13.1.0/bits/stl_algobase.h:633:7, inlined from 'static _ForwardIterator std::__uninitialized_copy::__uninit_copy(_InputIterator, _InputIterator, _ForwardIterator) [with _InputIterator = unsigned int*; _ForwardIterator = unsigned int*]' at /data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/13.1.0/bits/stl_uninitialized.h:147:27, inlined from '_ForwardIterator std::uninitialized_copy(_InputIterator, _InputIterator, _ForwardIterator) [with _InputIterator = unsigned int*; _ForwardIterator = unsigned int*]' at /data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/13.1.0/bits/stl_uninitialized.h:185:15, inlined from 'constexpr void fmt::v9::basic_memory_buffer::grow(size_t) [with T = unsigned int; long unsigned int SIZE = 32; Allocator = std::allocator]' at /data/src/build/common/fmt/include/fmt/format.h:925:26, inlined from 'constexpr void fmt::v9::detail::buffer::try_reserve(size_t) [with T = unsigned int]' at /data/src/build/common/fmt/include/fmt/core.h:928:39, inlined from 'constexpr void fmt::v9::detail::buffer::try_reserve(size_t) [with T = unsigned int]' at /data/src/build/common/fmt/include/fmt/core.h:927:24, inlined from 'constexpr void fmt::v9::detail::buffer::try_resize(size_t) [with T = unsigned int]' at /data/src/build/common/fmt/include/fmt/core.h:919:16, inlined from 'constexpr void fmt::v9::basic_memory_buffer::resize(size_t) [with T = unsigned int; long unsigned int SIZE = 32; Allocator = std::allocator]' at /data/src/build/common/fmt/include/fmt/format.h:897:63, inlined from 'constexpr void fmt::v9::detail::bigint::assign(UInt) [with UInt = long unsigned int; typename std::enable_if<(std::is_same::value || std::is_same::value), int>::type = 0]' at /data/src/build/common/fmt/include/fmt/format.h:2792:19, inlined from 'constexpr void fmt::v9::detail::bigint::operator=(Int) [with Int = int]' at /data/src/build/common/fmt/include/fmt/format.h:2813:11, inlined from 'constexpr void fmt::v9::detail::bigint::assign_pow10(int)' at /data/src/build/common/fmt/include/fmt/format.h:2886:32: /data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/13.1.0/bits/stl_algobase.h:437:30: warning: 'void* __builtin_memmove(void*, const void*, long unsigned int)' writing between 5 and 9223372036854775807 bytes into a region of size 4 overflows the destination [-Wstringop-overflow=] 437 | __builtin_memmove(__result, __first, sizeof(_Tp) * _Num); | ~^~~ Again that same test works fine with GCC 11.3. It seems that overflow detection in GCC 13.1 is really broken.
[Bug c++/109717] New: -Warray-bound error with gnu++20 and fmt library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109717
Bug ID: 109717
Summary: -Warray-bound error with gnu++20 and fmt library
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: psmith at gnu dot org
Target Milestone: ---
Created attachment 54983
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54983&action=edit
fmt1.i preprocessor output (compressed)
I found SO MANY issues related to -Warray-bound, many of them reported with GCC
11 or so. I can't tell if this is a duplicate or not, although this issue
doesn't reproduce for me with GCC 11.3.
I have built my own GCC 13.1 from source on x86_64 GNU/Linux (as I've been
doing for >10 years) and it works great except for one thing. When I use some
parts of the fmt 9.1.0 library, and "-O2 -Werror-builds -std=gnu++20" (removing
any one of those, or changing to -std=gnu++17, makes the error go away).
I try to compile this:
#include
#include
#include
void add_info(std::vector& buf)
{
fmt::format_to(std::back_inserter(buf), "hello {}", "there");
}
and I get this output:
$ g++-13.1 -I/data/src/build/common/fmt/include -std=gnu++20 -Warray-bounds -O2
-c -o /tmp/fmt1.o /tmp/fmt1.cpp
In file included from
/data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/13.1.0/vector:62,
from /tmp/fmt1.cpp:1:
In static member function 'static constexpr _Up* std::__copy_move<_IsMove,
true, std::random_access_iterator_tag>::__copy_m(_Tp*, _Tp*, _Up*) [with _Tp =
unsigned int; _Up = unsigned int; bool _IsMove = false]',
inlined from 'constexpr _OI std::__copy_move_a2(_II, _II, _OI) [with bool
_IsMove = false; _II = unsigned int*; _OI = unsigned int*]' at
/data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/13.1.0/bits/stl_algobase.h:506:30,
inlined from 'constexpr _OI std::__copy_move_a1(_II, _II, _OI) [with bool
_IsMove = false; _II = unsigned int*; _OI = unsigned int*]' at
/data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/13.1.0/bits/stl_algobase.h:533:42,
inlined from 'constexpr _OI std::__copy_move_a(_II, _II, _OI) [with bool
_IsMove = false; _II = unsigned int*; _OI = unsigned int*]' at
/data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/13.1.0/bits/stl_algobase.h:540:31,
inlined from 'constexpr _OI std::copy(_II, _II, _OI) [with _II = unsigned
int*; _OI = unsigned int*]' at
/data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/13.1.0/bits/stl_algobase.h:633:7,
inlined from 'static _ForwardIterator
std::__uninitialized_copy::__uninit_copy(_InputIterator, _InputIterator,
_ForwardIterator) [with _InputIterator = unsigned int*; _ForwardIterator =
unsigned int*]' at
/data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/13.1.0/bits/stl_uninitialized.h:147:27,
inlined from '_ForwardIterator std::uninitialized_copy(_InputIterator,
_InputIterator, _ForwardIterator) [with _InputIterator = unsigned int*;
_ForwardIterator = unsigned int*]' at
/data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/13.1.0/bits/stl_uninitialized.h:185:15,
inlined from 'constexpr void fmt::v9::basic_memory_buffer::grow(size_t) [with T = unsigned int; long unsigned int SIZE = 32;
Allocator = std::allocator]' at
/data/src/build/common/fmt/include/fmt/format.h:925:26,
inlined from 'constexpr void
fmt::v9::detail::buffer::try_reserve(size_t) [with T = unsigned int]' at
/data/src/build/common/fmt/include/fmt/core.h:928:39,
inlined from 'constexpr void
fmt::v9::detail::buffer::try_reserve(size_t) [with T = unsigned int]' at
/data/src/build/common/fmt/include/fmt/core.h:927:24,
inlined from 'constexpr void fmt::v9::detail::buffer::try_resize(size_t)
[with T = unsigned int]' at
/data/src/build/common/fmt/include/fmt/core.h:919:16,
inlined from 'constexpr void fmt::v9::basic_memory_buffer::resize(size_t) [with T = unsigned int; long unsigned int SIZE = 32;
Allocator = std::allocator]' at
/data/src/build/common/fmt/include/fmt/format.h:897:63,
inlined from 'constexpr void fmt::v9::detail::bigint::assign(UInt) [with
UInt = long unsigned int; typename std::enable_if<(std::is_same::value || std::is_same::value),
int>::type = 0]' at
/data/src/build/common/fmt/include/fmt/format.h:2792:19,
inlined from 'constexpr void fmt::v9::detail::bigint::operator=(Int) [with
Int = int]' at /data/src/build/common/fmt/include/fmt/format.h:2813:11,
inlined from 'constexpr void fmt::v9::detail::bigint::assign_pow10(int)' at
/data/src/build/common/fmt/include/fmt/format.h:2886:32:
/data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/13.1.0/bits/stl_algobase.h:437:30:
warning: 'void* __builtin_memmove(void*, const void*, long unsigned int)'
forming offs
[Bug c++/78147] The -Wshadow warning is too aggressive with constructor parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78147 --- Comment #7 from Paul Smith --- I don't really think this change is related to -Wunused-private-field: at least I don't see any relationship. My personal preference would be to not even bother to create an option for this; I think that GCC should _never_ warn about this usage. I really can't fathom a reason that anyone would want to enable shadow warnings in this situation, such that creating a separate option to control it worth the effort.
[Bug bootstrap/105487] Sysroots without 32bit components cause mysterious errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105487 --- Comment #9 from Paul Smith --- Just to note, there are similar needs for empty directories in the GCC installation itself; for example in a GCC install of a 64bit compiler without 32bit support this directory will be created by the installer: unknown/x86_64-unknown-linux-gnu/lib which will be empty. GCC searches paths that are relative to this directory, as in: unknown/bin/../lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../../../x86_64-unknown-linux-gnu/lib/../lib64/ Note how this uses x86_64-unknown-linux-gnu/lib/../lib64 so if that empty lib directory is not present, this path cannot be found and linking will fail. While it is true that the GCC install creates that empty directory, if you store the compiler in a facility that doesn't preserve empty directories (like git) they will disappear. Of course this can be worked around by creating a temp file in empty directories and since the empty directories ARE created as part of the compiler install this is not really a bug; it's just a slightly surprising annoyance that has to be kept in mind. It would be better (IMO) if GCC used resolved paths here as well.
[Bug bootstrap/105487] Sysroots without 32bit components cause mysterious errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105487 --- Comment #7 from Paul Smith --- Just to be clear when I say "Build GCC with that directory as the sysroot" I mean something like this: ../gcc-11.3.0/configure --with-sysroot=/sysroot ...
[Bug bootstrap/105487] Sysroots without 32bit components cause mysterious errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105487 --- Comment #6 from Paul Smith --- If it is really required, then the GCC configure script or makefile or something should detect this situation and fail. There's nothing in the current build system or documentation that says this is needed and I don't see how any reasonable person would be expected to guess this. My personal opinion is that it's not correct to require unwanted and unnecessary directories to exist, just so that relative pathname lookups to completely unrelated directories can succeed. Here's how to reproduce: * Create an empty directory. * Obtain the necessary 64bit library packages (for example, the 64bit versions of glibc / glibc-common / glibc-devel / glibc-headers / libgcc RPMs from a CentOS repository--you might need kernel-headers too). * Unpack them into the empty directory (for example, using rpm2cpio). * Build GCC with that directory as the sysroot. * Witness failure. The 64bit library RPMs do not (as they shouldn't!) create or put any content into the /usr/lib directory, so it won't exist in your sysroot. In order to have /usr/lib show up, you have to either install the 32bit library packages, which we don't want or need, or else understand enough about what's going on to create that directory by hand (and dump a ".keep" file or something in it to be sure that empty directory pruning doesn't delete it again).
[Bug bootstrap/105487] Sysroots without 32bit components cause mysterious errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105487 --- Comment #3 from Paul Smith --- There's nothing "incorrect" about a sysroot that doesn't have /usr/lib in it. If you have a 64bit system and you don't need to run 32bit binaries, then /usr/lib will be empty and everything will be in /usr/lib64.
[Bug bootstrap/105487] Sysroots without 32bit components cause mysterious errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105487 --- Comment #1 from Paul Smith --- Ugh, when I wrote "doesn't contain any 32bit values" I meant "doesn't contain any 32bit files".
[Bug bootstrap/105487] New: Sysroots without 32bit components cause mysterious errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105487 Bug ID: 105487 Summary: Sysroots without 32bit components cause mysterious errors Product: gcc Version: 11.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: psmith at gnu dot org Target Milestone: --- I first reported this issue here: https://gcc.gnu.org/pipermail/gcc/2020-August/233361.html I said I would file a bug but I don't see any evidence that I ever did so. It's still present in GCC 11.3. It actually isn't limited to bootstrap, either: if you set to a sysroot that doesn't contain any 32bit values, and thus doesn't contain the /sysroot/usr/lib directory at all but only has /sysroot/usr/lib64, then you can't compile GCC itself against that sysroot and, if you have a built GCC, you can't compile programs against that sysroot. I have hacked a workaround by creating an empty /sysroot/usr/lib directory in my sysroot, but it took me the better part of a day to figure out the problem... even though I had already figured this out less than two years ago. It would be nice to avoid the problem. While building GCC, you will get this relatively obscure error trying to build libgcc_s.so: ld: error: cannot open crti.o: No such file or directory ld: error: cannot open crtn.o: No such file or directory ld: error: cannot find -lc If you debug it, you'll see that /sysroot/usr/lib64/crti.o does exist (same with the others) so you will be confused. If you look more carefully and add -v to see search paths, you'll find that the path we use to locate 64bit content is a relative path to the /sysroot/usr/lib directory: ... -L/sysroot/usr/lib/../lib64 instead using the direct path: ... -L/sysroot/usr/lib64 So, if you don't HAVE a /sysroot/usr/lib directory (because you aren't supporting 32bit builds and have no need for it) your builds will fail.
[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932 --- Comment #32 from Paul Smith --- No movement AFAIK. It's apparently the tip of a particularly gross iceberg. It doesn't seem like partial measures appeal to people, and no one has the needed combination of time, knowledge, and contacts to attack the entire iceberg. For myself, since I build my own version of GCC for my work, I apply something similar to (or maybe exactly, I can't remember now) Xi Ruoyao's patch attached to this bug, and it Works For Me, at least for this specific problem.
[Bug middle-end/98055] __builtin_alloca should not have warn_unused_result attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98055
--- Comment #5 from Paul Smith ---
IMO that response is missing the point. This bug should be reopened and
resolved by removing this attribute from the __builtin_alloca function in GCC.
That's all that's needed: there's no need for more complexity.
First, there's no need to add this attribute to alloca(): it's has virtually no
useful effect. The chance that it actually catches a noticeable bug is almost
nil; any incorrect result that was more severe than reserving more stack than
was strictly necessary (actually failing to assign to a variable where it was
needed) would be obvious.
Second, alloca() is not just GCC's __builtin_alloca(). There are other
implementations, that behave differently than __builtin_alloca() and in those
implementations calling alloca() without using the return value is a valid and
useful thing to do. I agree that it should not be up to GCC to try to suggest
portability options and am not suggesting it should do that. However by adding
this attribute GCC is actively and affirmatively working _AGAINST_ portability.
The GCC docs say:
> warn_unused_result
> The warn_unused_result attribute causes a warning to be emitted if a caller
> of the function with this attribute does not use its return value. This is
> useful for functions where not checking the result is either a security
> problem or always a bug, such as realloc.
Using alloca() without checking the result is not a security problem, and it is
not always a bug as I've explained. If it were the case that a commonly-used
malloc() replacement required calling malloc(0) (and not using the return
value) periodically for proper functioning, then absolutely GCC should clearly
not emit a warning for that usage even though GCC's malloc() doesn't work that
way, because otherwise it's hard to write code that doesn't depend on a
particular compiler.
Put more simply, I have this code in my program:
alloca (0);
I need that line there so things work properly on compilers that don't provide
alloca().
How do you suggest I compile with GCC without either (a) forgoing this warning
everywhere or (b) adding a lot of pragma boilerplate to allow me to disable the
warning for this line or (c) creating a hack such as:
{ void *__p = alloca (0); (void) __p; }
Is there some preprocessor magic that lets me know that I'm using GCC's
__builtin_alloc so I can avoid calling alloca(0) in that situation? I can't
think of one myself.
[Bug middle-end/98055] __builtin_alloca should not have warn_unused_result attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98055 --- Comment #2 from Paul Smith --- I see no resolution to that thread, but the current behavior of GCC in this respect is not right and Martin Sebor's arguments are missing the point: the thinking there is too GCC-centric. Whether or not builtin-alloca is used is irrelevant: the issue is _portability_ to _other compilers_.
[Bug c/98055] New: __builtin_alloca should not have warn_unused_result attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98055 Bug ID: 98055 Summary: __builtin_alloca should not have warn_unused_result attribute Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: psmith at gnu dot org Target Milestone: --- Code that wants to use alloca() and still be portable will often include replacements where memory is allocated on the heap, and the user is expected to invoke alloca(0) periodically to free up this memory. See for example the GNU gnulib replacement alloca(). (Please no comments about the usefulness or not of alloca()--I'm not interested in that discussion. alloca() has problems but it's strictly more powerful than VLAs, while providing the possibility of portability to compilers that don't support them). In this situation (invoking alloca(0)) there's no point in assigning the return value, and older versions of GCC this works fine but when I try to compile the same code with GCC 10.2.0 compilation fails because apparently __builtin_alloca() now has the warn_unused_result attribute applied to it (this isn't documented anywhere that I can find, but appears to be the case): In file included from src/makeint.h:31, from src/read.c:17: src/read.c: In function 'eval_makefile': lib/alloca.h:46:18: error: ignoring return value of '__builtin_alloca' declared with attribute 'warn_unused_result' [-Werror=unused-result] 46 | # define alloca __builtin_alloca src/read.c:435:3: note: in expansion of macro 'alloca' 435 | alloca (0); | ^~ Because (void) doesn't work around this attribute there's no easy way to resolve this; I don't think it's appropriate to add this attribute to alloca() and it should be removed.
