[Bug tree-optimization/109720] -Wmaybe-uninitialized triggering when I can see no path that would allow it

[psmith at gnu dot org via Gcc-bugs]

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

[psmith at gnu dot org via Gcc-bugs]

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

[psmith at gnu dot org via Gcc-bugs]

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=edit
LocalStorage.i compressed

[Bug c++/109850] New: ICE compiling ccache 4.8

[psmith at gnu dot org via Gcc-bugs]

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

[psmith at gnu dot org via Gcc-bugs]

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

[psmith at gnu dot org via Gcc-bugs]

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

[psmith at gnu dot org via Gcc-bugs]

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

[psmith at gnu dot org via Gcc-bugs]

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

[psmith at gnu dot org via Gcc-bugs]

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

[psmith at gnu dot org via Gcc-bugs]

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

[psmith at gnu dot org via Gcc-bugs]

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*) +
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

[psmith at gnu dot org via Gcc-bugs]

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

[psmith at gnu dot org via Gcc-bugs]

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

[psmith at gnu dot org via Gcc-bugs]

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

[Bug c++/78147] The -Wshadow warning is too aggressive with constructor parameters

[psmith at gnu dot org via Gcc-bugs]

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

[psmith at gnu dot org via Gcc-bugs]

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

[psmith at gnu dot org via Gcc-bugs]

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

[psmith at gnu dot org via Gcc-bugs]

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

[psmith at gnu dot org via Gcc-bugs]

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

[psmith at gnu dot org via Gcc-bugs]

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

[psmith at gnu dot org via Gcc-bugs]

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

[psmith at gnu dot org via Gcc-bugs]

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

[psmith at gnu dot org via Gcc-bugs]

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

[psmith at gnu dot org via Gcc-bugs]

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

[psmith at gnu dot org via Gcc-bugs]

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.

[Bug pch/90306] ICE when using precompiled headers with -MD and -fpch-deps

[psmith at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90306

--- Comment #2 from Paul Smith  ---
Yes that seems like it would definitely solve the ICE.

But then this bug report changes to say that the output of -fpch-deps is wrong
(it's empty when it shouldn't be) :p :).

That would potentially cause build failures as make will not be properly
rebuilding targets due to incorrect dependency lists.

The real question/bug is that the deps section of the PCH file is empty, or at
least not parsed during the PCH read.  Obviously, there ARE dependencies from
the PCH file so that should not be empty.

[Bug pch/90306] New: ICE when using precompiled headers with -MD and -fpch-deps

[psmith at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90306

Bug ID: 90306
   Summary: ICE when using precompiled headers with -MD and
-fpch-deps
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: pch
  Assignee: unassigned at gcc dot gnu.org
  Reporter: psmith at gnu dot org
  Target Milestone: ---

I've seen this issue both with GCC 8.1.0 and the latest GCC 9.0.1 20190430
pre-release, on GNU/Linux x86_64 with binutils 2.30 and 2.32 (not that I
suppose that matters here).

Some info on the mailing list: https://gcc.gnu.org/ml/gcc/2019-04/msg00289.html
and into May: https://gcc.gnu.org/ml/gcc/2019-05/msg1.html

I don't have a reproducible case since it doesn't happen every time for me. 
But I can reproduce it locally on certain systems so I'm happy to participate
in some directed debugging.  Here's what I've discovered so far:

IT WORKS FINE:
If I build my PCH file like this:

  g++  -o obj/foo_pch.h.gch -x c++-header foo_pch.h

And I build my source code like this:

  g++  -Winvalid-pch -iquote"obj" --include=foo_pch.h -o obj/foo.cpp.o
foo.cpp

I GET ICEs:
_Sometimes_ get ICE errors if I build as below on _some_ systems.  It appears
possibly related to the speed of the system; it never fails on my local system
(which is very beefy) but often fails on our (older, less beefy) build servers.

First, when building the PCH file I add the -MD flag:

  g++  -MD -o obj/foo_pch.h.gch -x c++-header foo_pch.h

Second, when compiling my source code I add the -fpch-deps flag:

  g++  -fpch-deps -Winvalid-pch -iquote"obj" --include=foo_pch.h -o
obj/foo.cpp.o foo.cpp

Then I get ICE failures (this is from GCC 9.0.1-20190430):

  : internal compiler error: Segmentation fault
  0x9d4fdb crash_signal
/work/src/cc/gcc-9.0.1-RC-20190430/gcc/toplev.c:326
  0x12f6144 apply_vpath
/work/src/cc/gcc-9.0.1-RC-20190430/libcpp/mkdeps.c:127
  0x12f648e deps_add_dep(deps*, char const*)
/work/src/cc/gcc-9.0.1-RC-20190430/libcpp/mkdeps.c:258
  0x12f699c deps_restore(deps*, _IO_FILE*, char const*)
/work/src/cc/gcc-9.0.1-RC-20190430/libcpp/mkdeps.c:432
  0x12f7cca cpp_read_state(cpp_reader*, char const*, _IO_FILE*,
save_macro_data*)
/work/src/cc/gcc-9.0.1-RC-20190430/libcpp/pch.c:859
  0x59971c c_common_read_pch(cpp_reader*, char const*, int, char const*)
/work/src/cc/gcc-9.0.1-RC-20190430/gcc/c-family/c-pch.c:365
  0x12e9d3c should_stack_file
/work/src/cc/gcc-9.0.1-RC-20190430/libcpp/files.c:814
  0x12e9f33 _cpp_stack_file
/work/src/cc/gcc-9.0.1-RC-20190430/libcpp/files.c:900
  0x12ea0ee _cpp_stack_include
/work/src/cc/gcc-9.0.1-RC-20190430/libcpp/files.c:1063
  0x12ea5a6 cpp_push_include(cpp_reader*, char const*)
/work/src/cc/gcc-9.0.1-RC-20190430/libcpp/files.c:1498
  0x597015 push_command_line_include
/work/src/cc/gcc-9.0.1-RC-20190430/gcc/c-family/c-opts.c:1502
  0x59741b c_finish_options
/work/src/cc/gcc-9.0.1-RC-20190430/gcc/c-family/c-opts.c:1471
  0x598dbc c_common_parse_file()
/work/src/cc/gcc-9.0.1-RC-20190430/gcc/c-family/c-opts.c:1150
  Please submit a full bug report,

Debugging with GDB and follow-fork, I can see this backtrace:

  (gdb) set follow-fork child
  (gdb) run
  Starting program:
/tools/x86_64-linux/cc/unknown/bin/x86_64-unknown-linux-gnu-g++ ... -fpch-deps
-Winvalid-pch -iquote/src/dir --include=foo_pch.h -o foo.cpp.o -c foo.cpp
  [Attaching after process 310 vfork to child process 317]
  [New inferior 2 (process 317)]
  [Detaching vfork parent process 310 after child exec]
  [Inferior 1 (process 310) detached]
  process 317 is executing new program:
/tools/x86_64-linux/cc/unknown/libexec/gcc/x86_64-unknown-linux-gnu/9.0.1/cc1plus

  Thread 2.1 "cc1plus" received signal SIGSEGV, Segmentation fault.
  [Switching to process 317]
  apply_vpath (d=d@entry=0x0,
  t=t@entry=0x20a4530 "/src/foo_pch.h") at
/work/src/cc/gcc-9.0.1-RC-20190430/libcpp/mkdeps.c:127
  127 /work/src/cc/gcc-9.0.1-RC-20190430/libcpp/mkdeps.c: No such file or
directory.

  (gdb) bt
  #0  apply_vpath (d=d@entry=0x0,
t=t@entry=0x20a4530 "/sec/foo_pch.h") at
/work/src/cc/gcc-9.0.1-RC-20190430/libcpp/mkdeps.c:127
  #1  0x012f648f in deps_add_dep (d=d@entry=0x0,
t=t@entry=0x20a4530 "/src/foo_pch.h") at
/work/src/cc/gcc-9.0.1-RC-20190430/libcpp/mkdeps.c:258
  #2  0x012f699d in deps_restore (deps=0x0, fd=fd@entry=0x20a1420,
self=self@entry=0x2039780 "/src/obj/foo_pch.h.gch")
at /work/src/cc/gcc-9.0.1-RC-20190430/libcpp/mkdeps.c:432
  #3  0x012f7ccb in cpp_read_state (r=r@entry=0x2027b70,
name=name@entry=0x2039780 "/src/obj/foo_pch.h.gch", f=f@entry=0x20a1420,
data=)
at /work/src/cc/gcc-9.0.1-RC-20190430/libcpp/pch.c:859
  #4  0x0059971d in c_common_read_p

[Bug libstdc++/85965] [8/9 Regression] G++ gives cryptic error instead of incomplete type

[psmith at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85965

--- Comment #4 from Paul Smith  ---
Oops sorry: I guess I'm not familiar enough with the vagaries of the bug
trackers :).  Thanks Jonathan!

[Bug c++/78147] The -Wshadow warning is too aggressive with constructor parameters

[psmith at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78147

--- Comment #3 from Paul Smith  ---
Unfortunately not because I never had time to do more than the patch attached
here: in particular I didn't hook it up to any command-line arguments, nor did
I add regression tests for it.  I didn't think it would be helpful to post the
patch in its current form to gcc-patches.  However I'm happy to do so if it
seems useful.

Looking at my schedule realistically the earliest I would have time to do
significant work on this would be February... I'm on the hook for
already-late-ish changes for a January release date at DayJob.  Sorry for that
:(.

[Bug c++/85965] New: G++ gives cryptic error instead of incomplete type

[psmith at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85965

Bug ID: 85965
   Summary: G++ gives cryptic error instead of incomplete type
   Product: gcc
   Version: 8.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: ---

Compiling code with GCC 8.1 / binutils 2.30 (built locally on GNU/Linux amd64)
which previously compiled and worked OK with GCC 6.2 and 7.3.

I received a very cryptic error that had me running around reworking class
implementations for quite a while before I realized the problem: I had an
incomplete type.  I don't know if there's anything G++ could do better here,
but FYI I had this code:

class Bar
{
public:
struct Less
{
bool operator()(const Bar& lhs, const Bar& rhs) const;
bool operator()(const Bar* lhs, const Bar* rhs) const;
};
};

class Biz;

#include 

class Foo
{
std::set _map;
};

It's not immediately clear that the incomplete Biz class is a problem,
especially in my code which is significantly more complex and crosses multiple
header files, and G++ doesn't give a very helpful (to me) error:

$ g++ -o set.o -c set.cpp
In file included from x86_64-generic-linux-gnu/include/c++/8.1.0/set:60,
 from set.cpp:13:
x86_64-generic-linux-gnu/include/c++/8.1.0/bits/stl_tree.h: In instantiation of
'class std::_Rb_tree,
Bar::Less, std::allocator >':
x86_64-generic-linux-gnu/include/c++/8.1.0/bits/stl_set.h:133:17:   required
from 'class std::set'
set.cpp:17:37:   required from here
x86_64-generic-linux-gnu/include/c++/8.1.0/bits/stl_tree.h:452:21: error:
static assertion failed: comparison object must be invocable with two arguments
of key type
   static_assert(__is_invocable<_Compare&, const _Key&, const _Key&>{},
 ^

If I had included the complete type for class Biz, the compiler would have seen
that Biz is a subclass of Bar and it would have been fine; adding in the header
file fixed my problem:

class Bar
{
public:
struct Less
{
bool operator()(const Bar& lhs, const Bar& rhs) const;
bool operator()(const Bar* lhs, const Bar* rhs) const;
};
};

class Biz : public Bar
{}

#include 

class Foo
{
std::set _map;
};

[Bug c++/85783] alloc-size-larger-than fires incorrectly with new[] and can't be disabled

[psmith at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85783

--- Comment #9 from Paul Smith  ---
Sorry; Andrew's original reply seemed to say that the use-case is
non-conforming so the issue was WONTFIX.  I also thought your comment #6 was
referring to my example in comment #5: I just wanted to clarify that that
example was conforming (although still, admittedly, very unrealistic).

If this issue is best left WONTFIX in deference to the more accurate/detailed
one you opened that's fine with me.

Cheers!

[Bug c++/85783] alloc-size-larger-than fires incorrectly with new[] and can't be disabled

[psmith at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85783

--- Comment #7 from Paul Smith  ---
Is there a way (in standard C++) to force non-inline?  I'm not aware of one. 
So that means the only standard-conforming way to replace operator new is if
it's in its own compilation unit all by itself?  I don't have a copy of the
standard but cppreference says only that replacement operator new can't have an
inline specifier, that it can't be static, and that it has to be in the global
namespace, all of which requirements this example appears to meet.

Regarding throw, does the standard really say that the throw must be explicit
in the implementation of the function directly?  If my operator new[] invokes a
function to throw, rather than throwing directly, is that not
standard-conforming?  That seems bizarre to me: just because the compiler can't
prove to itself that my operator new will throw properly, the compiler is
allowed to assume the code is non-conforming?

[Bug c++/85783] alloc-size-larger-than fires incorrectly with new[] and can't be disabled

[psmith at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85783

--- Comment #5 from Paul Smith  ---
I simplified my example too much; I think this should be re-opened.

In my real code, operator new[] does not invoke exit(); it invokes my own
function (which is defined as noreturn, but that's not required).  There's no
way for the compiler to know whether this function will throw or not, so
"replacing a non-throwing operator new[]" isn't why my case is not working. 
Also, you mention an inline implementation of operator new[], but there's
nothing in your code example that I can see that forces my replacement to be
inline.  Is there some magic about global operator new replacement that I'm
forgetting?

Here's an example which still fails with the warning and which I think is valid
C++ (interestingly this version requires -O2 to show the problem):

void allocFail(__SIZE_TYPE__ _s);

void* operator new[](__SIZE_TYPE__ n)
{
  void* p = __builtin_malloc (n);
  if (!p)  allocFail (n);
  return p;
}

struct A
{
  A ();
  ~A ();
};


void* f (__SIZE_TYPE__ n)
{
  if (!n)
return 0;

  return new A[n];
}

In function 'void* operator new [](long unsigned int)',
inlined from 'void* f(long unsigned int)' at p1.cpp:22:17:
p1.cpp:5:30: warning: argument 1 value '18446744073709551615' exceeds maximum
object size 9223372036854775807 [-Walloc-size-larger-than=]
   void* p = __builtin_malloc (n);
 ~^~~
p1.cpp: In function 'void* f(long unsigned int)':
p1.cpp:5:30: note: in a call to built-in allocation function 'void*
__builtin_malloc(long unsigned int)'

[Bug c++/85783] alloc-size-larger-than fires incorrectly with new[] and can't be disabled

[psmith at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85783

--- Comment #4 from Paul Smith  ---
Well, clearly I disagree with this conclusion and feel this is a bug.

At the very least, the fact that it's impossible to disable the warning needs
to be considered a bug.  The statement on the mailing list from Martin Sebor
was:

> -Walloc-size-larger-than, like most (all?) other middle-end
> warnings, is designed to trigger only for calls that truly have
> an argument in excess of the limit.  Unlike -Wmaybe-uninitialized,
> it is not intended to diagnose case where the argument may but
> need not be excessive (i.e., it's not expected to have false
> positives, and I don't think it is particularly prone to them).

If this WONTFIX resolution means that we are not going to fix known false
positives for this warning, then IMO the above description of the situation is
not accurate and we should add the ability to disable the warning.

[Bug c++/85783] alloc-size-larger-than fires incorrectly with new[] and can't be disabled

[psmith at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85783

--- Comment #2 from Paul Smith  ---
> Did you try: -Wno-alloc-size-larger-than ?

Yes.

  cc1plus: error: unrecognized command line option
'-Wno-alloc-size-larger-than'

> Also in your code, numberFields is a signed int and then casted to size_t.  
> On LP64 targets (or rather sizeof(size_t) != sizeof(int)), then value is sign 
> extended.

I'm not suggesting the code is well-written.  Just that it shouldn't throw a
warning.

In any event, if I change numberFields to "unsigned int" I still get the same
warning.

[Bug c++/85783] New: alloc-size-larger-than fires incorrectly with new[] and can't be disabled

[psmith at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85783

Bug ID: 85783
   Summary: alloc-size-larger-than fires incorrectly with new[]
and can't be disabled
   Product: gcc
   Version: 8.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 44131
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44131=edit
sample source file

GCC 8.1.0 / binutils 2.30
GNU/Linux x86_64 with a sysroot of Red Hat EL 6.5.

Recently I started upgrading from GCC 7.3 to GCC 8.1.  I discovered three
locations in my codebase where the alloc-size-larger-than warning is generated.
 It wasn't ever generated with 7.3.  Since I build with -Wall -Werror this
causes compiles to fail.

The first issue is, I wasn't able to find any way to turn off this warning
other than by removing -Wall which seems entirely too severe.  There should be
some way to disable it; maybe by providing -Walloc-size-larger-than=0 or
similar.

I did work around this issue by casting the value given to new[] to type
unsigned int, but that's unpleasant.

Of course removing the false positive would be helpful as well.

I spent quite a while trying to create a small sample; the results are below. 
Most any change to this file appears to cause the warning to go away: for
example I tried to use a simple template I created rather than
std::shared_ptr<>, or even remove that field altogether: no warning.  If I
remove or modify the if-statements in the method significantly, no warning. 
Etc.  I didn't try all changes of course.  Also without optimization it doesn't
warn but with both -O1 and -O2 it does.

Results of compiling the attached file:

  $ x86_64-rh65-linux-gnu-g++ -v -o /tmp/SP.o -c -O2 -Wall -Werror params.cpp
  Using built-in specs.
 
COLLECT_GCC=/work/src/build/x86_64-linux/cc/generic/bin/x86_64-generic-linux-gnu-g++
  Target: x86_64-generic-linux-gnu
  Configured with: /work/src/cc/gcc-8.1.0/configure --disable-nls
--disable-werror --prefix=/work/src/cc/x86_64-linux/final/generic
--host=x86_64-tools-linux-gnu --target=x86_64-generic-linux-gnu
--with-sysroot=/work/src/build/x86_64-linux/sysroot/generic CFLAGS=-O2
CXXFLAGS=-O2 LDFLAGS=-O2 --enable-gold --enable-languages=c,c++
  Thread model: posix
  gcc version 8.1.0 (GCC) 
  COLLECT_GCC_OPTIONS='-m64' '-isystem' '=/usr/include-fixed' '-v' '-o'
'/tmp/SP.o' '-c' '-O2' '-Wall' '-Werror' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 
/work/src/build/x86_64-linux/cc/generic/bin/../libexec/gcc/x86_64-generic-linux-gnu/8.1.0/cc1plus
-quiet -v -iprefix
/work/src/build/x86_64-linux/cc/generic/bin/../lib/gcc/x86_64-generic-linux-gnu/8.1.0/
-isysroot /work/src/build/x86_64-linux/sysroot/rh65 -D_GNU_SOURCE -isystem
=/usr/include-fixed params.cpp -quiet -dumpbase SortParameters.cpp -m64
-mtune=generic -march=x86-64 -auxbase-strip /tmp/SP.o -O2 -Wall -Werror
-version -o /tmp/ccuJobAh.s
  GNU C++14 (GCC) version 8.1.0 (x86_64-generic-linux-gnu)
compiled by GNU C version 8.1.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.18-GMP

  GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
  Compiler executable checksum: e2fe942476766bd673c0e36030131141
  In function 'void* operator new [](size_t)',
inlined from 'static Params* Params::buildParams(size_t, Info*)' at
params.cpp:52:47:
  params.cpp:8:21: error: argument 1 value '18446744073709551615' exceeds
maximum object size 9223372036854775807 [-Werror=alloc-size-larger-than=]
   void* p = malloc(size);
 ~~^~
...
  /work/src/build/x86_64-linux/sysroot/rh65/usr/include/stdlib.h: In static
member function 'static Params* Params::buildParams(size_t, Info*)':
  /work/src/build/x86_64-linux/sysroot/rh65/usr/include/stdlib.h:471:14: note:
in a call to allocation function 'void* malloc(size_t)' declared here
   extern void *malloc (size_t __size) __THROW __attribute_malloc__ __wur;
^~
  cc1plus: all warnings being treated as errors

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

[psmith at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932

--- Comment #25 from Paul Smith  ---
> (1) Find the mangled name of the vtable of tv.
> (2) Demangle the name, to be 'vtable for TreeVector::Tree'.
> (3) Skip 'vtable for ' and get 'TreeVector::Tree'.
> (4) Lookup this symbol.

Right, and this is my concern: how many different types of symbol modifications
are we going to expect GDB to attempt?  Massaging this type to all its
different equivalent types and then attempting to look them up seems pretty
inefficient.  I'm not familiar at all with the implementation but I'm not sure
I see why we can't just ensure that the symbol values provided match
identically to the de-mangled names, so we always know that we can demangle the
name then look up the symbol.

I also filed a bug against GDB (mentioned above) which is similar: in that case
the demangled name contained the default value for a defaulted template
argument, but the actual symbol provided didn't contain that default: again the
lookup didn't match.  How can GDB know that this argument is the default and it
should try removing that argument and looking up the symbol without it?

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

[psmith at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932

--- Comment #23 from Paul Smith  ---
The lookup_type() was just to show the problem more clearly: I don't do that in
my actual Python code.  This part (or something similar) is what I use:

  class tv(gdb.Function):
  def __init__(self):
  gdb.Function.__init__(self, "tv")
  def invoke(self, vector):
  gdb.write("depth: %d\n" % (vector['tree']['_depth']))

and when I run this I get:

  warning: RTTI symbol not found for class 'TreeVector::Tree'

In other words, it's not that I'm trying to look up that type myself: that's
the type that GDB is trying to look up when it tries to evaluate the variable
of type "TreeVector::Tree" in my program.

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

[psmith at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932

--- Comment #19 from Paul Smith  ---
Hi; is there a next step for this?  I understand there's some concern that we
should be asking GDB to improve their capabilities but in the meantime can we
get GCC to emit the previous format?  It would be great if this could be fixed
for GCC 7.3.

I found another issue in GDB finding types containing defaulted template
arguments, but this problem exists in all versions of GCC so I filed the issue
against GDB instead.  No response so far.

https://sourceware.org/bugzilla/show_bug.cgi?id=22013

I also posted a question to the GDB mailing list asking for some conversation
around this issue, but also no response so far.

https://sourceware.org/ml/gdb/2017-08/msg00069.html

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

[psmith at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932

--- Comment #16 from Paul Smith  ---
I'm not familiar with the implementations but I'm not sure we can expect GDB to
be able to handle this situation, at least not with any sort of efficiency. 
It's already a difficult part of GDB's job, looking up types quickly.  I filed
a bug a few years ago where GDB macros slowed down by over 94x (from a few
seconds to over 11 minutes) due to a symbol lookup issue: it's a very sensitive
area.

Adding more complexity to this and asking GDB to try one variation of a given
type after another until it finds one seems less than optimal.

Even if it's decided that a change does need to happen on the GDB side,
hopefully GCC will continue to generate the expected debugging symbols until
that change is made and published in GDB.

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

[psmith at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932

--- Comment #12 from Paul Smith  ---
Xi Ruoyao (comment #9):
> This works for:

Excellent.

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

[psmith at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932

--- Comment #7 from Paul Smith  ---
I'm not sure what the impacts of "if (pp->flags & pp_c_flag_gnu_v3)" are; does
this mean it only works if you specify -ggdb3?  Is that the right thing?  I
don't know what the differences are between the different debug types.

Thanks for picking up this issue so quickly!

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

[psmith at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932

--- Comment #3 from Paul Smith  ---
Created attachment 42030
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42030=edit
tv.py

Test case attached.  To run it:

$ gcc -ggdb3 -o tvtest tvtest.cpp

$ gdb tvtest -ex 'br 28' -ex 'source tv.py' -ex 'run' -ex 'p $tv(tv)'
  ...
Reading symbols from tvtest...done.
Breakpoint 1 at 0x400804: file tvtest.cpp, line 28.
Starting program: /home/psmith/src/gcc/tvtest 

Breakpoint 1, main (argc=1, argv=0x7fffe758) at tvtest.cpp:28
28  return tv.tree->_depth;
vector: TreeVector
tree: TreeVector::Tree *
warning: RTTI symbol not found for class 'TreeVector::Tree'
depth: 3
Python Exception  No type named TreeVector::Tree.: 
Error occurred in Python convenience function: No type named TreeVector::Tree.
(gdb) 


If you build with GCC 6.2 instead, it will work fine.

Note, I'm not sure whether the old type containing "2u" is right and the new
one is wrong or vice versa, but there's definitely a problem in that in the new
one we see "2" in the type but something in the debug symbols is still looking
for "2u" as evidenced by the RTTI symbol warning.

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

[psmith at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932

--- Comment #2 from Paul Smith  ---
Created attachment 42029
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42029=edit
tvtest.cpp

[Bug c++/81932] New: Template arguments of type unsigned generate incorrect debugging information

[psmith at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932

Bug ID: 81932
   Summary: Template arguments of type unsigned generate incorrect
debugging information
   Product: gcc
   Version: 7.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: ---

I've upgraded from GCC 6.2/binutils 2.27 to GCC 7.2/binutils 2.29 (compiled
myself), running on GNU/Linux on x86_64.  Everything is fine except that GDB
(I've tried both 7.11 and 8.0) can no longer correctly print objects of one of
my templated classes, which I have created a Python printer for.

My template is complex but it's basically:

  template
  class TreeVector
  {
...
  class Tree
  {
...
  private:
  uint const _depth;
  };
...
  Tree* tree;
  uint64 _maxIndex;
...
  };

When I compile with GCC 6.2, I'm able to see the type of my object via GDB
Python macros:

  (gdb) ptype tv
  type = class TreeVector<Pod, 2u> [with T = Pod] {
private:
  TreeVector<T, 2u>::Tree *tree;
  volatile uint64 _maxIndex;
...

  (gdb) ptype tv.tree
  type = class TreeVector<Pod, 2u>::Tree {
private:
  const uint _depth;
...

  (gdb) python
  >class tv(gdb.Function):
  >def __init__(self):
  >gdb.Function.__init__(self, "tv")
  >def invoke(self, vector):
  >gdb.write("vector: %s\n" % (str(vector.type)))
  >gdb.write("tree: %s\n" % (str(vector['tree'].type)))
  >gdb.write("depth: %d\n" % (vector['tree']['_depth']))
  >tt = gdb.lookup_type("TreeVector<Pod, 2u>::Tree")
  >return 0
  >tv()
  >^D

  (gdb) p $tv(tv)
  vector: TreeVector<Pod, 2u>
  tree: TreeVector<Pod, 2u>::Tree *
  depth: 3
  $1 = 0

Note here how the value for the second template argument is "2u" and everything
works.

Now I compile this same code with GCC 7.2/binutils 2.29 and use the same GDB,
and my results are different:

  (gdb) ptype tv
  type = class TreeVector<Pod, 2> [with T = Pod] {
private:
  TreeVector<T, 2>::Tree *tree;
  volatile uint64 _maxIndex;
...

  (gdb) ptype tv.tree
  type = class TreeVector<Pod, 2>::Tree {
private:
  const uint _depth;
...

  (gdb) p $tv(tv)
  vector: TreeVector<Pod, 2>
  tree: TreeVector<Pod, 2>::Tree *
  warning: RTTI symbol not found for class 'TreeVector<Pod, 2u>::Tree'
  depth: 3
  Python Exception  No type named TreeVector<Pod,
2u>::Tree.: 
  Error occurred in Python convenience function: No type named TreeVector<Pod,
2u>::Tree.

Note how the value in the template is just "2", not "2u".  But, when GDB shows
the RTTI warning it's still looking for the "2u" in the type.  However that
type definitely doesn't exist (we get an error trying to look it up).

If I change my template to use "int" instead of "unsigned int", then everything
works in both versions of GCC (removing the now-invalid gdb.lookup_type call):

  (gdb) ptype tv
  type = class TreeVector<Pod, 2> [with T = Pod] {
...

  (gdb) p $tv(tv)
  vector: TreeVector<Pod, 2>
  tree: TreeVector<Pod, 2>::Tree *
  depth: 3
  $1 = 0

[Bug c++/78147] New: The -Wshadow warning is too aggressive with constructor parameters

[psmith at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78147

Bug ID: 78147
   Summary: The -Wshadow warning is too aggressive with
constructor parameters
   Product: gcc
   Version: 6.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: ---

Created attachment 39918
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39918=edit
Simple patch disables shadow warnings for ctor params

There's a very common idiom in C++, I've even seen coding standards that
require it, where the constructor arguments have the same name as the member
they initialize:

  class Foo
  {
  int foo;
  public:
  Foo(int foo) : foo(foo) {}
  };

Unfortunately -Wshadow warns for this case.

Clang has an extra warning flag, -Wshadow-field-in-constructor, which controls
this (from what I can tell).  By default in Clang, -Wshadow doesn't enable this
you need to separately enable it.

Attached below is a patch which permanently disables the warning for parameters
in constructors.  If this seems interesting/desirable to people I can see about
putting some effort into adding it as a separate warning option.  If we would
prefer GCC, unlike clang, enable it automatically with -Wshadow and allow
-Wno-shadow-field-in-constructor to disable it, that's OK with me.

In an ideal world we'd disable shadow warnings only for situations where the
parameter is used as a simple assignment in an initializer list, but that's
clearly a lot more work so I didn't do that.  If we could do that I'd even
recommend not having a separate shadow option to control it, and just
hardcoding -Wshadow to never warn about that situation.

[Bug c++/64431] "-Wignored-qualifiers" warning gives misleading position in code

[psmith at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64431

Paul Smith  changed:

   What|Removed |Added

 CC||psmith at gnu dot org

--- Comment #6 from Paul Smith  ---
Still see this in GCC 6.2.0.  It was even more confusing for me because in my
case the const in the return type was hidden in a typedef:

  class Foo
  {
  typedef const char* const MyType;
...

  MyType myFunction() const { ... }
  };

Shows this error:

  Foo.h:202:26: error: type qualifiers ignored on function return type
   MyType myFunction() const
   ^

I was _really_ confused :).

I'm not even sure this should trigger this error... I mean, it's inside a type.
 In my case I can take it out without a big problem but what if I wanted to
have the const in the type?  Then I can't return that type anymore without a
warning?  Maybe that's a separate bug.

[Bug c/48996] fixincl on Red Hat EL 5 breaks sys/stat.h fstat64()

[psmith at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48996

--- Comment #7 from Paul Smith psmith at gnu dot org ---
I haven't seen this issue in a while and don't care enough to try to reproduce
it or to have it reopened, but as far as I can see the problem was pretty
clearly in the fixincl tool that comes with GCC.  I don't know if that's
considered C FE or not; perhaps I mis-categorized it.

Fixincl was adding __inline__ to functions in header files it was fixing, quite
inappropriately (in this case anyway).

[Bug debug/54533] breakpoint on C-style variadic function not hit at -O0 on amd64

[psmith at gnu dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54533

Paul Smith psmith at gnu dot org changed:

   What|Removed |Added

 CC||psmith at gnu dot org

--- Comment #4 from Paul Smith psmith at gnu dot org ---
See also https://sourceware.org/bugzilla/show_bug.cgi?id=16280 which has a
repro case for C++ inline functions on x86_64 (very latest GCC and GDB
releases).

[Bug debug/47471] [4.7/4.8/4.9 Regression] stdarg functions extraneous too-early prologue end

[psmith at gnu dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47471

Paul Smith psmith at gnu dot org changed:

   What|Removed |Added

 CC||psmith at gnu dot org

--- Comment #11 from Paul Smith psmith at gnu dot org ---
See also https://sourceware.org/bugzilla/show_bug.cgi?id=16280 which has a
repro case for C++ inline functions on x86_64 (very latest GCC 4.8.2 and GDB
7.6.1 releases).

[Bug debug/55586] Incorrect .debug_line section for function with variable number of arguments in PowerPC

[psmith at gnu dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55586

Paul Smith psmith at gnu dot org changed:

   What|Removed |Added

 CC||psmith at gnu dot org

--- Comment #4 from Paul Smith psmith at gnu dot org ---
See also https://sourceware.org/bugzilla/show_bug.cgi?id=16280 which has a
repro case for C++ inline functions on x86_64 (very latest GCC 4.8.2 and GDB
7.6.1 releases).

[Bug other/58467] Documentation of the used variable attribute needs additional information

[psmith at gnu dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58467

--- Comment #6 from Paul Smith psmith at gnu dot org ---
A minor typo:

- attached to a variable with the static storage,
+ attached to a variable with static storage,

Also, I wonder if it might be helpful to be clear that it can ONLY be applied
to variables with static storage, or else you get a warning/error.  That would
require more substantial changes to the text though.

Cheers!

[Bug other/58467] Documentation of the used variable attribute needs additional information

[psmith at gnu dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58467

--- Comment #5 from Paul Smith psmith at gnu dot org ---
Thank you!

[Bug other/58467] Documentation of the used variable attribute needs additional information

[psmith at gnu dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58467

--- Comment #1 from Paul Smith psmith at gnu dot org ---
Housekeeping: it would be very nice to have a Doc component in bugzilla.  As
it was I picked c because it was that part of the docs.  Thx!

[Bug c/58467] New: Documentation of the used variable attribute needs additional information

[psmith at gnu dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58467

Bug ID: 58467
   Summary: Documentation of the used variable attribute needs
additional information
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: psmith at gnu dot org

The used variable attribute in the GCC documentation (gcc/doc/extend.texi,
section Variable Attributes) says that it can be attached to a variable.

However, this attribute cannot be applied to auto variables, only global or
static variables.  If you try to attach __attribute__((used)) to an auto
variable you'll get a confusing error saying that you can't do that, with no
reason why, and the documentation doesn't provide any guidance.

[Bug bootstrap/51935] New: Configure fails on included mpc/mpfr

[psmith at gnu dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51935

 Bug #: 51935
   Summary: Configure fails on included mpc/mpfr
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: psm...@gnu.org


Created attachment 26404
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26404
Add /src to mpfr directories in configure.ac

I was trying to follow the advice of various people by including GMP/MPC/MPFR
into the GCC source tree (GCC 4.6.2 / GMP 5.0.2 / MPFR 3.1.0 / MPC 0.9),
however this failed during configure:

checking whether time.h and sys/time.h may both be included... yes
checking for creal in -lm... yes
checking for __gmpz_init in -lgmp... yes
checking for MPFR... yes
checking for recent GMP... yes
checking for recent MPFR... no
configure: error: MPFR version = 2.4.2 required
make[4]: *** [configure-stage1-mpc] Error 1
make[4]: Leaving directory `/usr/src/gcc/obj-stage1/gcc'
make[3]: *** [stage1-bubble] Error 2
make[3]: Leaving directory `/usr/src/gcc/obj-stage1/gcc'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/usr/src/gcc/obj-stage1/gcc'
make[1]: *** [/usr/src/gcc/.stamp/stage1.install] Error 2

Investigating, I found the configure was using the wrong path to location mpfr
headers and libraries; for example mpc/config.log says:

configure:11278: checking for recent MPFR
configure:11290: gcc -c -g -fkeep-inline-functions
-I/usr/src/gcc/obj-stage1/gcc
/./gmp -I/usr/src/gcc/gcc-4.6.2/mpfr  conftest.c 5
conftest.c:34:3: error: #error Minimal MPFR version is 2.4.2
conftest.c:35: error: expected '=', ',', ';', 'asm' or '__attribute__' at
end of
 input
configure:11290: $? = 1

This is due to the configure script assuming that MPFR headers are in the root
MPFR directory, but they're not: they live the src subdirectory in MPFR.  If
you fix the headers then it will fail during link because it's looking for
libmpfr.a in the wrong place, too.

I have an MPFR installed natively on the system, but it's version 2.2.1.  My
suspicion is that most people who test this already have a new enough MPFR
installed in /usr/include so they don't notice that this path is wrong, since
configure finds the one in /usr/include and is happy with it.

The attached patch to configure.ac that fixes things.

[Bug bootstrap/50461] mpfr.h found in mpfr-3.1.0/src instead of mpfr-3.0.1/. as previously

[psmith at gnu dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50461

psmith at gnu dot org changed:

   What|Removed |Added

 CC||psmith at gnu dot org

--- Comment #4 from psmith at gnu dot org 2012-01-21 18:14:00 UTC ---
Oops I filed a duplicate bug #51935

That bug includes a patch to fix the problem.

[Bug bootstrap/51935] Configure fails on included mpc/mpfr

[psmith at gnu dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51935

--- Comment #1 from psmith at gnu dot org 2012-01-21 18:15:24 UTC ---
Created attachment 26406
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26406
Handle both old and new MPFR dir layouts

Added a new patch that works with both old and new layouts.

[Bug bootstrap/51935] Configure fails on included mpc/mpfr

[psmith at gnu dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51935

--- Comment #2 from psmith at gnu dot org 2012-01-21 18:17:23 UTC ---
BTW, this is a duplicate of bug #50461

[Bug bootstrap/51935] Configure fails on included mpc/mpfr

[psmith at gnu dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51935

--- Comment #5 from psmith at gnu dot org 2012-01-21 18:54:37 UTC ---
It's fine to close this bug as a dup as it's later than the other, but note
I've attached a fix to this bug (there's no fix attached to the other) so
please don't lose the patch.

Cheers!

[Bug bootstrap/51935] Configure fails on included mpc/mpfr

[psmith at gnu dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51935

--- Comment #6 from psmith at gnu dot org 2012-01-21 23:24:18 UTC ---
Created attachment 26407
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26407
Fix typo

[Bug c/48996] fixincl on Red Hat EL 5 breaks sys/stat.h fstat64()

[psmith at gnu dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48996

--- Comment #2 from psmith at gnu dot org 2011-05-16 11:56:33 UTC ---
Created attachment 24251
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24251
Un-fixed sys/stat.h

Yes, sorry, it was silly not to have done that.

[Bug c/48996] fixincl on Red Hat EL 5 breaks sys/stat.h fstat64()

[psmith at gnu dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48996

--- Comment #4 from psmith at gnu dot org 2011-05-16 15:07:40 UTC ---
I'm attaching a small test program that fails for me.  I'm just running the
compiler with c++ -o tstfstat.o -c tstfstat.cpp; no extra flags.

After looking more carefully I can see that when I build this without
optimization I get this problem; the ifdef around the definition of the inline
version is:

# if defined __USE_LARGEFILE64 \
   (! defined __USE_FILE_OFFSET64 \
  || (defined __REDIRECT_NTH  defined __OPTIMIZE__))

In my system __USE_LARGEFILE64 is 1, __USE_FILE_OFFSET64 is 1, and
__REDIRECT_NTH is defined.  So, this entire if statement is true if
__OPTIMIZE__ is true, and false otherwise.

On the other hand the declaration doesn't care about __OPTIMIZE__; it declares
the function to be __inline__ regardless.

Sure enough, when I add -O2 to the compile line I don't see any complaints from
the compiler.  However that's not something I can do :-).

[Bug c/48996] fixincl on Red Hat EL 5 breaks sys/stat.h fstat64()

[psmith at gnu dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48996

--- Comment #5 from psmith at gnu dot org 2011-05-16 15:08:35 UTC ---
Created attachment 24253
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24253
Test invocation of fstat64()

[Bug c/48996] New: fixincl on Red Hat EL 5 breaks sys/stat.h fstat64()

[psmith at gnu dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48996

   Summary: fixincl on Red Hat EL 5 breaks sys/stat.h fstat64()
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: psm...@gnu.org


Hi all.  When I run fixincl from GCC 4.5.3 on my Red Hat EL 5 system, the
resulting sys/stat.h will throw an error whenever I try to call fstat64() from
my code.  If I delete sys/stat.h from the include-fixed directory, so the
original is used, then all is happy again.

Before fixincl the code reads:

extern int fstat64 (int __fd, struct stat64 *__buf) __THROW __nonnull ((2));

After fixincl it reads:

#ifdef __GNUC_GNU_INLINE__
extern
#endif
__inline__ int fstat64 (int __fd, struct stat64 *__buf) __THROW __nonnull
((2));

and the compiler error I get is:

include-fixed/sys/stat.h:255:16: error: inline function 'int fstat64(int,
stat64*)' used but never defined

where line 255 is the __inline__ line above.

Checking with the preprocessor I see that __GNUC_GNU_INLINE__ is built-in
defined to be 1.

[Bug preprocessor/48957] New: GCC's handling of include-fixed does not work well with --sysroot

[psmith at gnu dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48957

   Summary: GCC's handling of include-fixed does not work well
with --sysroot
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: psm...@gnu.org


When GCC builds, it creates and stows away internally an include-fixed
directory containing fixed-up versions of the system headers files on the
system it was built with.  This feels wrong to me: it gives GCC a hard
dependency on the specific set of system header files present when GCC was
built.  It's potentially incorrect even for straightforward installations,
where a newer header file provided with a package upgrade might be ignored in
preference to an older fixed version.  However, when attempting to create a
relocatable version of GCC it's even more problematic.

In particular, it seems very wrong (and, in fact, it often doesn't work) to
search the include-fixed directory when the user has specified a --sysroot
flag, choosing to compile against a wholly different set of headers and
libraries than the ones on the host system.

I think that the include-fixed directory should be associated with the sysroot,
somehow, not embedded deeply into the compiler internals, and when --sysroot is
provided there should be a well-known location inside the sysroot which will be
searched for include-fixed headers.

Also, the fixinc.sh script should be better documented and enhanced to be
simpler to run, so that it can be invoked more easily against a given sysroot
to construct the include-fixed directory for that sysroot.

[Bug c/40548] New: If a dir on PATH contains a directory named gcc, badness ensues

[psmith at gnu dot org]

I have a directory on my PATH that contains a subdirectory named gcc.  When I
run gcc (not fully-qualified) I get all sorts of very bizarre behavior.  For
example:

$ cat t.c
#include limits.h

$ mkdir gcc

$ PATH=.:$PATH gcc -E t.c /dev/null
In file included from /tmp/t.c:1:
/usr/include/limits.h:125:26: error: no include path in which to search for
limits.h

But, if I don't have a local directory gcc then all is fine:

$ rmdir gcc
$ PATH=.:$PATH gcc -E t.c /dev/null
$

If I use a fully-qualified path for GCC (/usr/bin/gcc) then it also does not
fail.

It looks to me like the test GCC performs when looking for itself through PATH
just checks for executability (if I have a non-executable file in a directory
on PATH this doesn't happen) but doesn't check for directory-ness.  This is
wrong, because the shell's PATH search algorithm DOES check for directory-ness
and skips directories that appear in directories on your PATH.


-- 
   Summary: If a dir on PATH contains a directory named gcc,
badness ensues
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: psmith at gnu dot org
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40548

[Bug c/40548] If a dir on PATH contains a directory named gcc, badness ensues

[psmith at gnu dot org]

--- Comment #2 from psmith at gnu dot org  2009-06-25 05:00 ---
Ah, thanks for the pointer.  I did search before I created a new bug but wasn't
successful in narrowing down my search to something reasonable.  It would be
nice if the real bug mentioned PATH in the summary; I was trying to use
case-sensitive searches for PATH but searching comments turned up 150 bugs.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40548

[Bug libgomp/36442] libgomp/libssp/libmudflap builds fail when using --with-build-sysroot

[psmith at gnu dot org]

--- Comment #2 from psmith at gnu dot org  2008-09-04 17:34 ---
I tried this with the latest stable, GCC 4.3.2, and I still had the same
failures.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36442

[Bug libgomp/36442] New: libgomp fails when using --with-build-sysroot

[psmith at gnu dot org]

I'm using both --with-build-sysroot and --with-sysroot when I compile GCC, so
that I can compile it against a different version of the local system than the
one I'm compiling on.  Most of the build works fine, with the exception of the
libraries libgomp, libmudflap, and libssp.

Each of those fails because they do not take notice of the --with-build-sysroot
directive, and thus they cannot find important files like crti.o etc.

I configured with this:

--with-build-sysroot=/tmp/invalid/gcc/i686-redhat71-linux-gnu
--with-sysroot=/invalid

where /tmp/invalid/gcc/i686-redhat71-linux-gnu is an extracted sysroot from Red
Hat 7.1 (surprise!)  Everything chugs along OK until the above-mentioned
libraries, then:

/usr/src/gcc/obj/gcc/./gcc/xgcc -B/usr/src/gcc/obj/gcc/./gcc/
-B/tmp/invalid/gcc/i686-generic-linux-gnu/bin/
-B/tmp/invalid/gcc/i686-generic-linux-gnu/lib/ -isystem
/tmp/invalid/gcc/i686-generic-linux-gnu/include -isystem
/tmp/invalid/gcc/i686-generic-linux-gnu/sys-include -shared  .libs/ssp.o
.libs/gets-chk.o .libs/memcpy-chk.o .libs/memmove-chk.o .libs/mempcpy-chk.o
.libs/memset-chk.o .libs/snprintf-chk.o .libs/sprintf-chk.o .libs/stpcpy-chk.o
.libs/strcat-chk.o .libs/strcpy-chk.o .libs/strncat-chk.o .libs/strncpy-chk.o
.libs/vsnprintf-chk.o .libs/vsprintf-chk.o  
-Wl,--version-script=/usr/src/gcc/gcc-4.2.4/libssp/ssp.map -Wl,-soname
-Wl,libssp.so.0 -o .libs/libssp.so.0.0.0
/tmp/invalid/gcc/bin/i686-generic-linux-gnu-ld: crti.o: No such file: No such
file or directory
collect2: ld returned 1 exit status
make[4]: *** [libssp.la] Error 1
make[4]: Leaving directory `/usr/src/gcc/obj/gcc/i686-generic-linux-gnu/libssp'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/usr/src/gcc/obj/gcc/i686-generic-linux-gnu/libssp'
make[2]: *** [all-target-libssp] Error 2

The other two libraries gave essentially identical errors.  I don't think the
-B etc. options here are correct; they seem to be remnants from previous
versions of GCC, before the --with-sysroot and --with-build-sysroot flags were
supported.

The configure.in files for these libraries need to be updated.


-- 
   Summary: libgomp fails when using --with-build-sysroot
   Product: gcc
   Version: 4.2.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: psmith at gnu dot org
GCC target triplet: i686-generic-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36442