[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

2023-04-27 Thread cuzdav at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107532

Chris Uzdavinis  changed:

   What|Removed |Added

 CC||cuzdav at gmail dot com

--- Comment #33 from Chris Uzdavinis  ---
Could an attribute or annotation be added so we can mark our classes to opt-out
of this warning for them?

I like the warning in general but it is hitting one of our core "span-like"
classes that stores pointers, and is going off so much that I'm going to need
to disable it.  I'd be much happier disabling it on a per-object basis, rather
than globally.

[Bug c++/114706] New: ICE - std::bit_cast in consteval function involving union

2024-04-12 Thread cuzdav at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114706

Bug ID: 114706
   Summary: ICE - std::bit_cast in consteval function involving
union
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cuzdav at gmail dot com
  Target Milestone: ---

ICE in a consteval function bit_casting an array of unions.  The code isn't
valid due to the union, but the compiler is not handling it properly (since
gcc11...trunk).  Reduced to the following program:

CODE

#include 
union U { int u; };
consteval void f() {
U result[]{0, 0};   
auto x = std::bit_cast(result);
}
int main() { f(); }

LIVE:
https://godbolt.org/z/Y943bc5zK


OUTPUT

/opt/compiler-explorer/gcc-trunk-20240412/include/c++/14.0.1/bit:94:33:
internal compiler error: in native_encode_initializer, at fold-const.cc:8468
   94 |   return __builtin_bit_cast(_To, __from);
  | ^~~
0x267826c internal_error(char const*, ...)
???:0
0xa58c63 fancy_abort(char const*, int, char const*)
???:0
0xfa0eaf native_encode_initializer(tree_node*, unsigned char*, int, int,
unsigned char*)
???:0
0xacf0f0 maybe_constant_value(tree_node*, tree_node*, mce_value)
???:0
0xd3a75f store_init_value(tree_node*, tree_node*, vec**, int)
???:0
0xb474fe cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int,
cp_decomp*)
???:0
0xc5c81a c_parse_file()
???:0
0xdb1489 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/110810] New: ICE in check_noexcept_r, at cp/except.cc:1068

2023-07-25 Thread cuzdav at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110810

Bug ID: 110810
   Summary: ICE in check_noexcept_r, at cp/except.cc:1068
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cuzdav at gmail dot com
  Target Milestone: ---

Created attachment 55634
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55634&action=edit
preprocessed code, zipped

Starting with x86_64 version of gcc 12.1 (linux), and through all newer
versions (including the trunk) on Compiler explorer, I receive an internal
compiler error on the following code:

Some overlap with https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109899 but there
is enough difference that I thought it might still be useful to report.

https://godbolt.org/z/ThTdxqzKG

#include 

struct Foo {
Foo() {}
~Foo() {}
};

struct X {
Foo data[4];
};

template
void f() {
char storage[256];
auto& object = *new(storage) X{};
object.~X();
}

* removing {} in the call to placement new "fixes" it, or replacing with
parenthesis.  Another fix is removing either the default ctor or destructor
from Foo, or making data not be an array, or f() not be a template.  It's a
strange and specific combination.

Output:


source>: In function 'void f()':
:15:36: internal compiler error: in check_noexcept_r, at
cp/except.cc:1068
   15 | auto& object = *new(storage) X{};
  |^
0x246af2e internal_error(char const*, ...)
???:0
0xac8ab6 fancy_abort(char const*, int, char const*)
???:0
0x16d661c 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 >*))
???:0
0x16d9912 walk_tree_without_duplicates_1(tree_node**, tree_node*
(*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*))
???:0
0xbd04a3 expr_noexcept_p(tree_node*, int)
???:0
0xbd64f0 build_vec_delete(unsigned int, tree_node*, tree_node*,
special_function_kind, int, int)
???:0
0xbd6a1e build_delete(unsigned int, tree_node*, tree_node*,
special_function_kind, int, int, int)
???:0
0xb8c5cc cxx_maybe_build_cleanup(tree_node*, int)
???:0
0xaf6b55 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
???:0
0xaf78e7 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
???:0
0xbde5fc build_new(unsigned int, vec**,
tree_node*, tree_node*, vec**, int, int)
???:0
0xcae89f c_parse_file()
???:0
0xdee919 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/111742] New: Misaligned generated code with MI using aligned virtual base

2023-10-09 Thread cuzdav at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111742

Bug ID: 111742
   Summary: Misaligned generated code with MI using aligned
virtual base
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cuzdav at gmail dot com
  Target Milestone: ---

Generated code is misaligned (and crashes in slightly more complex code), in
trunk all the way back to gcc 8.1, when built in c++11 or higher, with O3. 
(Linux, x86)

Complete code:
//
struct X {
  void * a = nullptr;
  void * b = nullptr;
};

struct alignas(16) AlignedData { };

struct A : virtual AlignedData {
  X xxx;
};

struct B : virtual AlignedData {};

struct Test : B, A {};

Test* t = new Test;

int main() {}
//

Compiler Explorer demo:
https://godbolt.org/z/aodTdaedW

Running with UB-san reports this:
/app/example.cpp:14:8: runtime error: constructor call on misaligned address
0x0227f2b8 for type 'struct A', which requires 16 byte alignment
0x0227f2b8: note: pointer points here
 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00
00 00 00  00 00 00 00
  ^ 
/app/example.cpp:8:8: runtime error: member access within misaligned address
0x0227f2b8 for type 'struct A', which requires 16 byte alignment
0x0227f2b8: note: pointer points here
 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00
00 00 00  00 00 00 00
  ^

[Bug c++/111742] Misaligned generated code with MI using aligned virtual base

2023-10-09 Thread cuzdav at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111742

--- Comment #2 from Chris Uzdavinis  ---
No, this is not a ubsan report.
Code *crashes* and I thought showing the UBsan warning was enough to
demonstrate it.
A minimal change to make the code crash instead of just report ubsan errors:


struct X {
  void * a = nullptr;
  void * b = nullptr;
};

struct alignas(16) AlignedData { };

struct A : virtual AlignedData {
int x = 0;   // << add this
  X xxx;
int& ref = x;// << and this
};

struct B : virtual AlignedData {};

struct Test : B, A {};

Test* t = new Test;

int main() {}


*** SEGFAULT ***

https://godbolt.org/z/f57vs7jxP

[Bug tree-optimization/80635] [8/9/10/11 regression] std::optional and bogus -Wmaybe-uninitialized warning

2020-10-15 Thread cuzdav at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635

Chris Uzdavinis  changed:

   What|Removed |Added

 CC||cuzdav at gmail dot com

--- Comment #54 from Chris Uzdavinis  ---
I'm not sure if this is the same bug or a different one, but it's in the same
family (I think).  Visible in current trunk, 10.2 release, and as far back as
8.1.

I found optimize level -Os is necessary 

https://godbolt.org/z/Ta55jM


#include 
using Opt = std::optional;

Opt f(int x) {   
Opt ret; 
Opt val = (x == 1) ? 999 : (x == 2) ? Opt(2) : std::nullopt;
if (val.has_value())
ret = val.value();
return ret;
}


: In function 'Opt f(int)':
:9:12: error: 'val.std::_Optional_payload_base::_Storage::_M_value' may be used uninitialized in this function
[-Werror=maybe-uninitialized]

9 | return ret;

  |^~~

[Bug analyzer/107725] New: Spurious warning: use of uninitialized value with std::any

2022-11-16 Thread cuzdav at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107725

Bug ID: 107725
   Summary: Spurious warning: use of uninitialized value with
std::any
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: cuzdav at gmail dot com
  Target Milestone: ---

Created attachment 53914
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53914&action=edit
preprocessed code

With the analyzer (-fanalyzer), this built cleanly with GCC10 and GCC11, but
starting with GCC 12 (still occurring in trunk) in either C++17 or c++20 mode,
I see this warning (x86 linux):

:4:13: warning: use of uninitialized value '' [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
4 | return {};
  | ^
  'std::any create()': events 1-2
|
|3 | std::any create() {
|  | ^
|  | |
|  | (1) region created on stack here
|4 | return {};
|  | ~
|  | |
|  | (2) use of uninitialized value '' here
|
Compiler returned: 0


This is the code in its entirety:

#include 
std::any create() {
return {};
}

https://godbolt.org/z/TWPcaW4Kn

[Bug analyzer/107725] Spurious warning: use of uninitialized value with std::any

2022-11-16 Thread cuzdav at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107725

--- Comment #1 from Chris Uzdavinis  ---
I get a similar warning with this code.  Unsure if it's the same underlying
issue.  Also does not warn with g++10 or g++11, but does with newer versions.

#include 
#include 

std::string create() {
std::ostringstream oss;
return oss.str();
}


https://godbolt.org/z/cz66zhKn5

:6:20: warning: use of uninitialized value '' [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
6 | return oss.str();
  |^
  'std::string create()': events 1-2
|
|4 | std::string create() {
|  |^
|  ||
|  |(1) region created on stack here
|5 | std::ostringstream oss;
|6 | return oss.str();
|  |~
|  ||
|  |(2) use of uninitialized value '' here

[Bug analyzer/107725] Spurious warning: use of uninitialized value with std::any

2022-11-16 Thread cuzdav at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107725

--- Comment #3 from Chris Uzdavinis  ---
Ah, sorry I didn't realize that.  Its use was suggested by Jason Turner in his
most recent C++ Weekly so I started to give it a try.  Perhaps there will be an
influx of such premature reports since it was put on the radar.

[Bug tree-optimization/107852] New: Spurious warnings stringop-overflow and array-bounds copying data as bytes into vector

2022-11-23 Thread cuzdav at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107852

Bug ID: 107852
   Summary: Spurious warnings stringop-overflow and array-bounds
copying data as bytes into vector
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cuzdav at gmail dot com
  Target Milestone: ---

Created attachment 53957
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53957&action=edit
preprocessed source code, if that's useful.

Starting with gcc 12 and continuing into the current trunk, with optimizations
enabled, the compiler emits warnings from static analysis regarding copying
data internal to the vector class, both on Compiler Explorer, and on my local
linux box running Centos9.

Options: g++ warnings.cpp -Werror -O2 -Warray-bounds 

Code:

#include 
std::vector bytes;
int value{};

void copyValueBytes() {
bytes.clear();
auto ptr = reinterpret_cast(&value);
bytes.insert(bytes.end(), ptr, ptr + sizeof(value));
}

https://godbolt.org/z/MfjM9xKjP

Observations:
* if I don't clear() the vector first, it does not report any errors
* if I call bytes.resize(0) it reports the same output
* if I call bytes.resize(1) it compiles cleanly
* if I use a std::deque instead of a vector, it compiles cleanly

A reinterpret_cast always is eye-raising, but I think this is a valid use since
its address is casted to a char*, a compatible type.

Output:

In file included from
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/vector:60,
 from :1:
In static member function 'static _Tp* std::__copy_move<_IsMove, true,
std::random_access_iterator_tag>::__copy_m(const _Tp*, const _Tp*, _Tp*) [with
_Tp = char; bool _IsMove = true]',
inlined from '_OI std::__copy_move_a2(_II, _II, _OI) [with bool _IsMove =
true; _II = char*; _OI = char*]' at
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/stl_algobase.h:495:30,
inlined from '_OI std::__copy_move_a1(_II, _II, _OI) [with bool _IsMove =
true; _II = char*; _OI = char*]' at
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/stl_algobase.h:522:42,
inlined from '_OI std::__copy_move_a(_II, _II, _OI) [with bool _IsMove =
true; _II = char*; _OI = char*]' at
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/stl_algobase.h:529:31,
inlined from '_OI std::copy(_II, _II, _OI) [with _II =
move_iterator; _OI = char*]' at
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/stl_algobase.h:620:7,
inlined from 'static _ForwardIterator
std::__uninitialized_copy::__uninit_copy(_InputIterator, _InputIterator,
_ForwardIterator) [with _InputIterator = std::move_iterator;
_ForwardIterator = char*]' at
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/stl_uninitialized.h:147:27,
inlined from '_ForwardIterator std::uninitialized_copy(_InputIterator,
_InputIterator, _ForwardIterator) [with _InputIterator = move_iterator;
_ForwardIterator = char*]' at
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/stl_uninitialized.h:185:15,
inlined from '_ForwardIterator std::__uninitialized_copy_a(_InputIterator,
_InputIterator, _ForwardIterator, allocator<_Tp>&) [with _InputIterator =
move_iterator; _ForwardIterator = char*; _Tp = char]' at
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/stl_uninitialized.h:372:37,
inlined from '_ForwardIterator
std::__uninitialized_move_if_noexcept_a(_InputIterator, _InputIterator,
_ForwardIterator, _Allocator&) [with _InputIterator = char*; _ForwardIterator =
char*; _Allocator = allocator]' at
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/stl_uninitialized.h:397:2,
inlined from 'void std::vector<_Tp, _Alloc>::_M_range_insert(iterator,
_ForwardIterator, _ForwardIterator, std::forward_iterator_tag) [with
_ForwardIterator = const char*; _Tp = char; _Alloc = std::allocator]' at
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/vector.tcc:801:9,
inlined from 'void std::vector<_Tp, _Alloc>::_M_insert_dispatch(iterator,
_InputIterator, _InputIterator, std::__false_type) [with _InputIterator = const
char*; _Tp = char; _Alloc = std::allocator]' at
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/stl_vector.h:1779:19,
inlined from 'std::vector<_Tp, _Alloc>::iterator std::vector<_Tp,
_Alloc>::insert(const_iterator, _InputIterator, _InputIterator) [with
_InputIterator = const char*;  = void; _Tp = char;
_Alloc = std::allocator]' at
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/stl_vector.h:1481:22,
inlined from 'void copyValueBytes()' at :9:17:
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/stl_algobase.h:431:30:
error: 'void* __builtin_memcpy(void*, const void*, long unsigned int)' offset 4
is out of the bounds [0, 4] [-Werror=array-bounds]
  431 | __builtin_memmove(_

[Bug c++/105386] New: Tuple in unevaluated context is instantiated; creates reference to void

2022-04-25 Thread cuzdav at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105386

Bug ID: 105386
   Summary: Tuple in unevaluated context is instantiated; creates
reference to void
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cuzdav at gmail dot com
  Target Milestone: ---

Created attachment 52878
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52878&action=edit
preprocessed code

Starting with g++11.2 some of meta-programming code started to fail.
While instantiating a tuple in an unevaluated context, it now complains that
the tuple contains a void member and it's creating a reference to void, yet it
is the same type as in the working case, just computed differently.


Output of g++ -v
(base) bash-4.2$ /opt/imc/gcc-11.2.0/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/opt/imc/gcc-11.2.0/bin/g++
COLLECT_LTO_WRAPPER=/opt/imc/gcc-11.2.0/libexec/gcc/x86_64-pc-linux-gnu/11.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-11.2.0/configure --prefix=/opt/imc/gcc-11.2.0
--enable-languages=c,c++,fortran,lto --disable-multilib
--with-build-time-tools=/opt/buildagent/work/d7a993299378ca7e/11.2.0/INSTALLDIR//opt/imc/gcc-11.2.0/bin
--enable-libstdcxx-time=rt
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.2.0 (GCC) 



Code appears in its entirety in attachment, but here is the main focus of the
error:

class Chunk { };
using ChunkMetaData = std::tuple;

template  ChunkMetaData chunkMetaData(MessageT&&);


template 
class ChunkSeq
{
public:

  
  using good_type = ChunkMetaData;


#ifdef SHOWBUG
  using bad_type = decltype(chunkMetaData(std::declval()));
  static_assert(std::is_same_v);
  using MetaData = bad_type;
#else
  using MetaData = good_type;
#endif

  


In gcc10, when SHOWBUG is defined, it still builds.  The static assertion
passes.  With gcc11 and 12, it fails, upset about a tuple creating a reference
to void.


Live example:
https://godbolt.org/z/4Wq3s936W


Errors:
In file included from krx/feed/sr10/foo.cpp:1:
/opt/imc/gcc-11.2.0/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../include/c++/11.2.0/tuple:
In instantiation of ‘struct std::_Head_base<2, void, false>’:
/opt/imc/gcc-11.2.0/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../include/c++/11.2.0/tuple:407:12:
  required from ‘struct std::_Tuple_impl<2, void>’
/opt/imc/gcc-11.2.0/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../include/c++/11.2.0/tuple:244:12:
  required from ‘struct std::_Tuple_impl<0, void, Chunk, void>’
/opt/imc/gcc-11.2.0/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../include/c++/11.2.0/tuple:599:11:
  required from ‘class std::tuple’
krx/feed/sr10/foo.cpp:171:42:   [ skipping 2 instantiation contexts, use
-ftemplate-backtrace-limit=0 to disable ]
krx/feed/sr10/foo.cpp:111:57:   required from ‘constexpr const bool
InvertPredicate >::value >’
krx/feed/sr10/foo.cpp:122:11:   required from ‘struct
RemoveIfImpl >,
std::tuple, PartialField<1> > >’
krx/feed/sr10/foo.cpp:235:7:   required by substitution of ‘template
using PartialStartField = typename KeepIf, typename
RemoveIfImpl >,
std::tuple, PartialField<1> > >::type>::type [with T = Chunk]’
krx/feed/sr10/foo.cpp:240:47:   required from ‘constexpr const bool
HasPartialBegin::value’
krx/feed/sr10/foo.cpp:111:57:   required from ‘constexpr const bool
InvertPredicate::value’
krx/feed/sr10/foo.cpp:122:11:   required from ‘struct
RemoveIfImpl, std::tuple >’
krx/feed/sr10/foo.cpp:247:6:   required from here
/opt/imc/gcc-11.2.0/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../include/c++/11.2.0/tuple:182:17:
error: forming reference to void
  182 |   constexpr _Head_base(const _Head& __h)
  | ^~
/opt/imc/gcc-11.2.0/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../include/c++/11.2.0/tuple:219:7:
error: forming reference to void
  219 |   _M_head(_Head_base& __b) noexcept { return __b._M_head_impl; }
  |   ^~~
/opt/imc/gcc-11.2.0/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../include/c++/11.2.0/tuple:222:7:
error: forming reference to void
  222 |   _M_head(const _Head_base& __b) noexcept { return
__b._M_head_impl; }
  |   ^~~
/opt/imc/gcc-11.2.0/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../include/c++/11.2.0/tuple:224:13:
error: ‘std::_Head_base<_Idx, _Head, false>::_M_head_impl’ has incomplete type
  224 |   _Head _M_head_impl;
  | ^~~~
/opt/imc/gcc-11.2.0/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../include/c++/11.2.0/tuple:224:13:
error: invalid use of ‘void’
In file included from krx/feed/sr10/foo.cpp:1:
/opt/imc/gcc-11.2.0/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../include/c++/11.2.0/tuple:
In instantiation of ‘struct std::_Tuple_impl<2, void>’:
/opt/imc/gcc-11.2.0/lib/gcc/x86

[Bug c++/105511] New: Spurious warning: "expected 'template' keyword..." when lt and gt compare over ternary

2022-05-06 Thread cuzdav at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105511

Bug ID: 105511
   Summary: Spurious warning: "expected 'template' keyword..."
when lt and gt compare over ternary
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cuzdav at gmail dot com
  Target Milestone: ---

Only on g++ 12 (new warning).

Building with the freshly released G++12 with warning enabled
(-Werror=missing-template-keyword)

Complete, minimized code:

template 
bool before(bool ascending, X & a, X * b) {
return ascending ? a.value < (*b).value : a.value > (*b).value;
}


:4:26: warning: expected 'template' keyword before dependent template
name [-Wmissing-template-keyword]
4 | return ascending ? a.value < (*b).value : a.value > (*b).value;
  |  ^

Visible on Compiler Explorer
https://godbolt.org/z/dW9hjbdex

Yes, the left-angle and right-angle brackets are present, but it's not looking
quite hard enough to see that they are on opposite sides of a ternary ':'.


My Compiler, if it matters:
/opt/imc/gcc-12.1.0/bin/g++
(base) bash-4.2$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/opt/imc/gcc-12.1.0/libexec/gcc/x86_64-pc-linux-gnu/12.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-12.1.0/configure --prefix=/opt/imc/gcc-12.1.0
--enable-languages=c,c++,fortran,lto --disable-multilib
--with-build-time-tools=/home/trading/cuzdav/code/imc-gcc/gcc/12.1.0/INSTALLDIR//opt/imc/gcc-12.1.0/bin
--enable-libstdcxx-time=rt
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.1.0 (GCC)

[Bug c++/105571] New: Spurious "set but not used" on static constexpr local, used in lambda

2022-05-11 Thread cuzdav at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105571

Bug ID: 105571
   Summary: Spurious "set but not used" on static constexpr local,
used in lambda
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cuzdav at gmail dot com
  Target Milestone: ---

With -Wall, in every c++ language level on virtually every version of g++ as
far back as 4.9, g++ warns ("variable 'THIS_IS_USED' set but not used") on the
following complete code:


template 
void for_each(IterT b, IterT e, FuncT f) {
while (b != e) {
f(*b++);
}
}

volatile int sink; 
void xxx(int x) {
sink = x;
}

void foo() {
static constexpr auto THIS_IS_USED = 1;  
int arr[10]{1,2,3,4,5,6,7,8,9,10};

for_each(arr, arr+10, [](auto v) {
xxx(THIS_IS_USED + v);
});
}


: In function 'void foo()':
:15:27: warning: variable 'THIS_IS_USED' set but not used
[-Wunused-but-set-variable]
   15 | static constexpr auto THIS_IS_USED = 1;
  |   ^~~~
Compiler returned: 0

https://godbolt.org/z/b1s5Yqb3r


This appears to be related to the "auto" parameter in the lambda.  Changing it
to 'int' makes the problem go away.

[Bug c++/105589] New: [ICE] templated type alias over std::array with bound type in template function fails

2022-05-12 Thread cuzdav at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105589

Bug ID: 105589
   Summary: [ICE] templated type alias over std::array with bound
type in template function fails
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cuzdav at gmail dot com
  Target Milestone: ---

Created attachment 52969
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52969&action=edit
preprocessed code

Internal compiler error - new in gcc12

COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/imc/gcc-12.1.0/libexec/gcc/x86_64-pc-linux-gnu/12.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-12.1.0/configure --prefix=/opt/imc/gcc-12.1.0
--enable-languages=c,c++,fortran,lto --disable-multilib
--with-build-time-tools=/home/trading/cuzdav/code/imc-gcc/gcc/12.1.0/INSTALLDIR//opt/imc/gcc-12.1.0/bin
--enable-libstdcxx-time=rt
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.1.0 (GCC) 


Spent a long time minimizing it to this example, so it's contrived but small. 

The user-provided constructor in the element type seems related.
The auto parameter in form() is also necessary, even if unused.

///
#include 

struct X {
X() {}
};

template
using C = std::array;

void form(auto) {
  auto w = C<16>{};
}
///

LIVE:
(Also visible on the 12.1 on godbolt)
https://godbolt.org/z/qWba56onf

OUTPUT:
foo2.cpp: In function ‘void form(auto:3)’:
foo2.cpp:11:18: internal compiler error: in build_value_init, at cp/init.cc:347
   11 |   auto w = C<16>{};
  |  ^
0x1b1211a diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char
const*, __va_list_tag (*) [1], diagnostic_t)
???:0
0x13637ff internal_error(char const*, ...)
???:0
0x13638d1 fancy_abort(char const*, int, char const*)
???:0
0x7665e6 build_value_init(tree_node*, int) [clone .cold]
???:0
0x1901bb1 build_vec_init_expr(tree_node*, tree_node*, int)
???:0
0x809217 digest_init_r(tree_node*, tree_node*, int, int, int) [clone .cold]
???:0
0x157c0ca massage_init_elt(tree_node*, tree_node*, int, int, int)
???:0
0x8096e7 digest_init_r(tree_node*, tree_node*, int, int, int) [clone .cold]
???:0
0x18ff96c finish_compound_literal(tree_node*, tree_node*, int, fcl_t)
???:0
0x15453de cp_parser_functional_cast(cp_parser*, tree_node*)
???:0
0x153e4ac cp_parser_postfix_expression(cp_parser*, bool, bool, bool, bool,
cp_id_kind*)
???:0
0x153c5dc cp_parser_binary_expression(cp_parser*, bool, bool, bool,
cp_parser_prec, cp_id_kind*)
???:0
0x153c2b2 cp_parser_assignment_expression(cp_parser*, cp_id_kind*, bool, bool)
???:0
0x153c130 cp_parser_constant_expression(cp_parser*, int, bool*, bool)
???:0
0x153bf7b cp_parser_initializer(cp_parser*, bool*, bool*, bool)
???:0
0x7a2ea4 cp_parser_init_declarator(cp_parser*, int, cp_decl_specifier_seq*,
vec*, bool, bool, int, bool*,
tree_node**, unsigned int*, tree_node**) [clone .cold]
???:0
0x15300c5 cp_parser_simple_declaration(cp_parser*, bool, tree_node**)
???:0
0x1542170 cp_parser_declaration_statement(cp_parser*)
???:0
0x1540bf3 cp_parser_statement(cp_parser*, tree_node*, bool, bool*,
vec*, unsigned int*)
???:0
0x1540657 cp_parser_compound_statement(cp_parser*, tree_node*, int, bool)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.


Preprocessed code attached.

[Bug c++/105726] New: spurious warning with -Warray-bounds

2022-05-24 Thread cuzdav at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105726

Bug ID: 105726
   Summary: spurious warning with -Warray-bounds
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cuzdav at gmail dot com
  Target Milestone: ---

Created attachment 53030
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53030&action=edit
preprocessed version

I just ran into an issue that seems to have appeared in Gcc 10.1 and is still
there in 11, 12, and in the trunk.

The following code produces a spurious warning about reading out of bounds,
but if I remove the "pad" field, or change from std::array to a "raw" array,
the warning goes away.  

//===
#include 
#include 

struct X {
char pad[4];
std::array mField;
};

void encode(char* aBuffer, const X& aMessage) {
strncpy(aBuffer, aMessage.mField.data(), 1);
}
//===

LIVE: https://godbolt.org/z/zEsx5P8eP

: In function 'void encode(char*, const X&)':
:10:16: warning: 'char* strncpy(char*, const char*, size_t)' offset 4
from the object at 'aMessage' is out of the bounds of referenced subobject
'std::array::_M_elems' with type 'char [1]' at offset 4
[-Warray-bounds]
   10 | strncpy(aBuffer, aMessage.mField.data(), 1);
  | ~~~^~~~
In file included from :1:
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/array:115:56: note:
subobject 'std::array::_M_elems' declared here
  115 |   typename _AT_Type::_Type _M_elems;
  |^~~~
Compiler returned: 0


OUTPUT of g++ -v

Using built-in specs.
COLLECT_GCC=/opt/imc/gcc-12.1.0/bin/g++
COLLECT_LTO_WRAPPER=/opt/imc/gcc-12.1.0/libexec/gcc/x86_64-pc-linux-gnu/12.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-12.1.0/configure --prefix=/opt/imc/gcc-12.1.0
--enable-languages=c,c++,fortran,lto --disable-multilib
--with-build-time-tools=/build/INSTALLDIR//opt/imc/gcc-12.1.0/bin
--enable-libstdcxx-time=rt
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.1.0 (GCC)

[Bug tree-optimization/106044] New: Spurious warning: -Wrestrict for adding std::strings (__builtin_memcpy)

2022-06-21 Thread cuzdav at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106044

Bug ID: 106044
   Summary: Spurious warning: -Wrestrict for adding std::strings
(__builtin_memcpy)
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cuzdav at gmail dot com
  Target Milestone: ---

Created attachment 53182
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53182&action=edit
preprocessed code

At optimization O3, beginning in g++ 12.1 (and still present in trunk) with
-Wrestrict enabled I see the following warning:

warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)'
accessing 9223372036854775810 or more bytes at offsets [2, 9223372036854775807]
and 1 may overlap up to 9223372036854775813 bytes at offset -3 [-Wrestrict]

Here is the code:

///
#include 

std::string f(std::size_t n) {
return "_" + std::to_string(n);
}
///

On Compiler explorer: https://godbolt.org/z/KMWehnscM

Command line:

g++12 -O3 --std=c++20 -Wrestrict source.cpp

Output:
In file included from
/opt/compiler-explorer/gcc-trunk-20220621/include/c++/13.0.0/string:40,
 from :1:
In static member function 'static constexpr std::char_traits::char_type*
std::char_traits::copy(char_type*, const char_type*, std::size_t)',
inlined from 'static constexpr void std::__cxx11::basic_string<_CharT,
_Traits, _Alloc>::_S_copy(_CharT*, const _CharT*, size_type) [with _CharT =
char; _Traits = std::char_traits; _Alloc = std::allocator]' at
/opt/compiler-explorer/gcc-trunk-20220621/include/c++/13.0.0/bits/basic_string.h:423:21,
inlined from 'constexpr std::__cxx11::basic_string<_CharT, _Traits,
_Allocator>& std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_M_replace(size_type, size_type, const _CharT*, size_type) [with
_CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]' at
/opt/compiler-explorer/gcc-trunk-20220621/include/c++/13.0.0/bits/basic_string.tcc:532:22,
inlined from 'constexpr std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>& std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::replace(size_type, size_type, const _CharT*, size_type) [with _CharT =
char; _Traits = std::char_traits; _Alloc = std::allocator]' at
/opt/compiler-explorer/gcc-trunk-20220621/include/c++/13.0.0/bits/basic_string.h:2171:19,
inlined from 'constexpr std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>& std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::insert(size_type,
const _CharT*) [with _CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]' at
/opt/compiler-explorer/gcc-trunk-20220621/include/c++/13.0.0/bits/basic_string.h:1928:22,
inlined from 'constexpr std::__cxx11::basic_string<_CharT, _Traits,
_Allocator> std::operator+(const _CharT*, __cxx11::basic_string<_CharT,
_Traits, _Allocator>&&) [with _CharT = char; _Traits = char_traits;
_Alloc = allocator]' at
/opt/compiler-explorer/gcc-trunk-20220621/include/c++/13.0.0/bits/basic_string.h:3594:36,
inlined from 'std::string f(std::size_t)' at :4:34:
/opt/compiler-explorer/gcc-trunk-20220621/include/c++/13.0.0/bits/char_traits.h:434:56:
warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)'
accessing 9223372036854775810 or more bytes at offsets [2, 9223372036854775807]
and 1 may overlap up to 9223372036854775813 bytes at offset -3 [-Wrestrict]
  434 | return static_cast(__builtin_memcpy(__s1, __s2,
__n));
  |   
^
Compiler returned: 0

//

local machine g++ output (where I first encountered it)

[cuzdav@docker tmp]$ /opt/imc/gcc-12.1.0/bin/g++ -v 
Using built-in specs.
COLLECT_GCC=/opt/imc/gcc-12.1.0/bin/g++
COLLECT_LTO_WRAPPER=/opt/imc/gcc-12.1.0/libexec/gcc/x86_64-pc-linux-gnu/12.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-12.1.0/configure --prefix=/opt/imc/gcc-12.1.0
--enable-languages=c,c++,fortran,lto --disable-multilib
--with-build-time-tools=/build/INSTALLDIR//opt/imc/gcc-12.1.0/bin
--enable-libstdcxx-time=rt
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.1.0 (GCC)

[Bug tree-optimization/106044] Spurious warning: -Wrestrict for adding std::strings (__builtin_memcpy)

2022-06-21 Thread cuzdav at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106044

--- Comment #1 from Chris Uzdavinis  ---
only in c++20, too.

[Bug tree-optimization/106044] Spurious warning: -Wrestrict for adding std::strings (__builtin_memcpy)

2022-06-21 Thread cuzdav at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106044

--- Comment #2 from Chris Uzdavinis  ---
Even marginally simpler:

#include 
auto f() {
return "_" + std::string(" ");
}


Originally I marked it as tree-optimization since it's only with -O3, but it
could be an issue in the standard library itself. I didn't consider that
initially.

[Bug libstdc++/106275] New: unordered_map with std::string key, std::hash, and custom equality predicate weirdness

2022-07-12 Thread cuzdav at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106275

Bug ID: 106275
   Summary: unordered_map with std::string key,
std::hash, and custom equality predicate
weirdness
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cuzdav at gmail dot com
  Target Milestone: ---

g++12.1 (on linux), Does not occur on GCC 11 or earlier.

std::unordered_map, CustomPred> acts
strangely such that finds do not seem to use the hasher properly, and seem to
use a linear search, invoking the equality predicate against every key.  

A custom hasher implemented in terms of std::hash fixes it, as does
using the default equality predicate.  It also does not happen with key type
of, say, "int".  I've only seen it for std::string (in my limited
experimentation.)

I added output to the predicate to indicate when it's called, and it shows
excessive calls printed when "SHOWBUG" macro is defined.



#include 
#include 
#include 
#include 

struct EqualToWrapper{
bool operator()(const std::string& key1, const std::string& key2) const {
std::cout << "equal_to(key1=" << key1 << ", key2=" << key2 << ")\n";
return std::equal_to<>{}(key1, key2);
}
};

#ifdef SHOWBUG
using UsageMap =  std::unordered_map,
EqualToWrapper>;
#else
struct MyHash : public std::hash {};
using UsageMap =  std::unordered_map;
#endif

int main() {
UsageMap m;
m.insert(std::make_pair("A", 111));
m.insert(std::make_pair("B", 222));
m.insert(std::make_pair("C", 333));
m.insert(std::make_pair("D", 444));
m.insert(std::make_pair("E", 555));
m.insert(std::make_pair("F", 666));
m.find("foo");
}



With a custom equality predicate and my derived-from-std::hash hasher, output
on g++ 12 is:

  equal_to(key1=C, key2=A)   

When run with -DSHOWBUG macro defined, output is:
  equal_to(key1=B, key2=A)
  equal_to(key1=C, key2=B)
  equal_to(key1=C, key2=A)
  equal_to(key1=D, key2=B)
  equal_to(key1=D, key2=C)
  equal_to(key1=D, key2=A)
  equal_to(key1=E, key2=B)
  equal_to(key1=E, key2=D)
  equal_to(key1=E, key2=C)
  equal_to(key1=E, key2=A)
  equal_to(key1=F, key2=E)
  equal_to(key1=F, key2=B)
  equal_to(key1=F, key2=D)
  equal_to(key1=F, key2=C)
  equal_to(key1=F, key2=A)
  equal_to(key1=foo, key2=F)
  equal_to(key1=foo, key2=E)
  equal_to(key1=foo, key2=B)
  equal_to(key1=foo, key2=D)
  equal_to(key1=foo, key2=C)
  equal_to(key1=foo, key2=A)



On Godbolt:
https://godbolt.org/z/GP5dox1qs



$ g++ -v 
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/opt/imc/gcc-12.1.0/libexec/gcc/x86_64-pc-linux-gnu/12.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-12.1.0/configure --prefix=/opt/imc/gcc-12.1.0
--enable-languages=c,c++,fortran,lto --disable-multilib
--with-build-time-tools=/build/INSTALLDIR//opt/imc/gcc-12.1.0/bin
--enable-libstdcxx-time=rt
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.1.0 (GCC)

[Bug libstdc++/106275] unordered_map with std::string key, std::hash, and custom equality predicate weirdness

2022-07-12 Thread cuzdav at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106275

--- Comment #1 from Chris Uzdavinis  ---
Created attachment 53293
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53293&action=edit
preprocessed code

[Bug libstdc++/106275] unordered_map with std::string key, std::hash, and custom equality predicate weirdness

2022-07-13 Thread cuzdav at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106275

--- Comment #6 from Chris Uzdavinis  ---
Thank you for the information.  If the equality comparison function is slow
enough, the large number of extra calls may not be an optimization.  

While looking into it, the vastly different runtime behavior of it jumped out
to me as an indication of a problem, and seemed to be the answer to why
internal tests drew my attention to this in the first place.  (Behavior is
normal without this optimization, but tests complained with it.)  But now I
understand it better, being a combination of the new behavior and
characteristics of the custom predicate in "real code" of which this is a
minimization.  The extra calls are a symptom, not a cause.

[Bug c++/110620] New: spurious array-bounds

2023-07-10 Thread cuzdav at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110620

Bug ID: 110620
   Summary: spurious array-bounds
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cuzdav at gmail dot com
  Target Milestone: ---

[Bug tree-optimization/110620] spurious array-bounds

2023-07-10 Thread cuzdav at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110620

--- Comment #1 from Chris Uzdavinis  ---
Starting with Gcc12.1 (at least on x86) and through all versions up to the
trunk (post 13.1)
This warning hits with optimization -O2 or higher.

https://godbolt.org/z/q3T39Wf8c


#include 

void foo(std::vector>& vec) {
if (vec.size() > 5) {
vec[3].first = 0;
}
}

int main() {
auto v1 = std::vector{std::pair(1, 2)};
foo(v1);
}

What is interesting to me is that the analyzer is missing the fact that size is
explicitly tested, and the index is a constant expression that is lower.

There are a lot of array-bounds bugs reported, and all have similarities and
I'm not sure if this is a dupe or not, though I went through the open ones in 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
And did not see an example quite like this.


In function 'void foo(std::vector >&)',
inlined from 'int main()' at :11:8:
:5:22: error: array subscript 3 is outside array bounds of
'std::pair [1]' [-Werror=array-bounds=]
5 | vec[3].first = 0;
In file included from
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/x86_64-linux-gnu/bits/c++allocator.h:33,
 from
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/allocator.h:46,
 from
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/vector:63,
 from :1:
In member function '_Tp* std::__new_allocator<_Tp>::allocate(size_type, const
void*) [with _Tp = std::pair]',
inlined from 'constexpr _Tp* std::allocator< 
>::allocate(std::size_t) [with _Tp = std::pair]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/allocator.h:198:40,
inlined from 'static constexpr _Tp*
std::allocator_traits >::allocate(allocator_type&,
size_type) [with _Tp = std::pair]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/alloc_traits.h:482:28,
inlined from 'constexpr std::_Vector_base<_Tp, _Alloc>::pointer
std::_Vector_base<_Tp, _Alloc>::_M_allocate(std::size_t) [with _Tp =
std::pair; _Alloc = std::allocator >]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/stl_vector.h:378:33,
inlined from 'constexpr void std::vector<_Tp,
_Alloc>::_M_range_initialize(_ForwardIterator, _ForwardIterator,
std::forward_iterator_tag) [with _ForwardIterator = const std::pair*;
_Tp = std::pair; _Alloc = std::allocator >]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/stl_vector.h:1687:25,
inlined from 'constexpr std::vector<_Tp,
_Alloc>::vector(std::initializer_list<_Tp>, const allocator_type&) [with _Tp =
std::pair; _Alloc = std::allocator >]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/stl_vector.h:677:21,
inlined from 'int main()' at :10:42:
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/new_allocator.h:147:55:
note: at offset 24 into object of size 8 allocated by 'operator new'
  147 | return static_cast<_Tp*>(_GLIBCXX_OPERATOR_NEW(__n *
sizeof(_Tp)));
  |   ^
cc1plus: all warnings being treated as errors
Compiler returned: 1

[Bug tree-optimization/110620] spurious array-bounds

2023-07-10 Thread cuzdav at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110620

--- Comment #2 from Chris Uzdavinis  ---
Created attachment 55516
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55516&action=edit
preprocessed code

[Bug tree-optimization/110620] spurious array-bounds

2023-07-10 Thread cuzdav at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110620

--- Comment #3 from Chris Uzdavinis  ---
Starting with Gcc12.1 (at least on x86) and through all versions up to the
trunk (post 13.1)
This warning hits with optimization -O2 or higher.

https://godbolt.org/z/q3T39Wf8c


#include 

void foo(std::vector>& vec) {
if (vec.size() > 5) {
vec[3].first = 0;
}
}

int main() {
auto v1 = std::vector{std::pair(1, 2)};
foo(v1);
}

What is interesting to me is that the analyzer is missing the fact that size is
explicitly tested, and the index is a constant expression that is lower.

There are a lot of array-bounds bugs reported, and all have similarities and
I'm not sure if this is a dupe or not, though I went through the open ones in 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
And did not see an example quite like this.


In function 'void foo(std::vector >&)',
inlined from 'int main()' at :11:8:
:5:22: error: array subscript 3 is outside array bounds of
'std::pair [1]' [-Werror=array-bounds=]
5 | vec[3].first = 0;
In file included from
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/x86_64-linux-gnu/bits/c++allocator.h:33,
 from
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/allocator.h:46,
 from
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/vector:63,
 from :1:
In member function '_Tp* std::__new_allocator<_Tp>::allocate(size_type, const
void*) [with _Tp = std::pair]',
inlined from 'constexpr _Tp* std::allocator< 
>::allocate(std::size_t) [with _Tp = std::pair]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/allocator.h:198:40,
inlined from 'static constexpr _Tp*
std::allocator_traits >::allocate(allocator_type&,
size_type) [with _Tp = std::pair]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/alloc_traits.h:482:28,
inlined from 'constexpr std::_Vector_base<_Tp, _Alloc>::pointer
std::_Vector_base<_Tp, _Alloc>::_M_allocate(std::size_t) [with _Tp =
std::pair; _Alloc = std::allocator >]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/stl_vector.h:378:33,
inlined from 'constexpr void std::vector<_Tp,
_Alloc>::_M_range_initialize(_ForwardIterator, _ForwardIterator,
std::forward_iterator_tag) [with _ForwardIterator = const std::pair*;
_Tp = std::pair; _Alloc = std::allocator >]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/stl_vector.h:1687:25,
inlined from 'constexpr std::vector<_Tp,
_Alloc>::vector(std::initializer_list<_Tp>, const allocator_type&) [with _Tp =
std::pair; _Alloc = std::allocator >]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/stl_vector.h:677:21,
inlined from 'int main()' at :10:42:
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/new_allocator.h:147:55:
note: at offset 24 into object of size 8 allocated by 'operator new'
  147 | return static_cast<_Tp*>(_GLIBCXX_OPERATOR_NEW(__n *
sizeof(_Tp)));
  |   ^
cc1plus: all warnings being treated as errors
Compiler returned: 1

[Bug tree-optimization/110620] spurious array-bounds

2023-07-10 Thread cuzdav at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110620

--- Comment #4 from Chris Uzdavinis  ---
(Sorry I was getting bugzilla errors about collisions when adding comments, but
they seemed to have gone through after all.)