[Bug libstdc++/98518] New: std::array not bound checked with _GLIBCXX_ASSERTIONS

[arnaud02 at users dot sourceforge.net via Gcc-bugs]

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

Bug ID: 98518
   Summary: std::array not bound checked with _GLIBCXX_ASSERTIONS
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnaud02 at users dot sourceforge.net
  Target Milestone: ---

operator[] of std::array is not bound checked when specifying
_GLIBCXX_ASSERTIONS.

Considering:
#define _GLIBCXX_ASSERTIONS 1
#include 
#include 
int f(int i) {
  std::array x = {1, 4};
  return x[i]; // bounds are not checked  
}
int main() {
  volatile int i = 2;
  printf("f=%d\n", f(i));
}

the array bound violation is not detected. By constrast, replacing std::array
by std::vector results in the expected assertion violation.

[Bug libstdc++/98518] std::array not bound checked with _GLIBCXX_ASSERTIONS

[arnaud02 at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #2 from Arnaud Desitter  ---
It is indeed fixed. Fantastic.

[Bug c++/101368] New: -Wlogical-op and string comparison

[arnaud02 at users dot sourceforge.net via Gcc-bugs]

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

Bug ID: 101368
   Summary: -Wlogical-op and string comparison
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnaud02 at users dot sourceforge.net
  Target Milestone: ---

Considering
#include 
bool f(int num) {
return num != 2 || num != 3;
}

bool g(std::string_view s) {
using namespace std::literals;
return s != "AA"sv || s != "BB"sv;
}

"g++ -std=c++17 -Wlogical-op -O2" emits:
: In function 'bool f(int)':
:3:21: warning: logical 'or' of collectively exhaustive tests is always
true [-Wlogical-op]
3 | return num != 2 || num != 3;
  |~^~~

g++ spots the defect in "f". It would be incredibly useful if the similar
defect was reported in "g".

In this case, the gcc x64 backend emits identical code for f and g:
f(int):
mov eax, 1
ret
g(std::basic_string_view >):
mov eax, 1
ret

[Bug c++/117504] New: Incorrect code emitted when using "constexpr std::array"

[arnaud02 at users dot sourceforge.net via Gcc-bugs]

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

Bug ID: 117504
   Summary: Incorrect code emitted when using "constexpr
std::array"
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnaud02 at users dot sourceforge.net
  Target Milestone: ---

Considering:

#include 
#include 
#include 
#include 
#include 

auto f(int const n) {
using s_t = std::pair;

#if defined(WITH_CONST)
const
#else
// gcc 14 emits incorrect code with "constexpr"
constexpr
#endif
std::array a_vec{s_t{1, 123}};

auto const vec{[&a_vec]() -> std::span { return a_vec; }()};

{
auto const it = std::ranges::find_if(vec, [n](auto const& v) {
std::cout << v.first << ", " << v.second << '\n';
return n >= v.first;
});
if (it != std::ranges::end(vec)) {
return it->second;
}
}
return -1;
}

int main() {
auto const r = f(1);
std::cout << "Found=" << r << " expected=123\n";
}


Using g++ 14.2

>g++ -std=c++20 -O0 -DWITH_CONST ex.cpp
>./a.out
1, 123
Found=123 expected=123

But
>g++ -std=c++20 -O0 exp.cpp
>./a.out
-2120994312, 32766
Found=32766 expected=123

Using "constepxr std::array" instead of "const std::array" results in incorrect
code.


This can be reproduced with: https://godbolt.org/z/Ysoc59179