[Bug c++/102804] New: template matching fails w/ false ambiguity on ternary expressions with enums

2021-10-17 Thread rudick at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102804

Bug ID: 102804
   Summary: template matching fails w/ false ambiguity on ternary
expressions with enums
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rudick at gmail dot com
  Target Milestone: ---

E.g. w/ -std=c++11

#include 
int main() {
  enum: unsigned int32_t { FOO, BAR } foobar = FOO;
  std::cout << ((time(nullptr) % 2) ? foobar : 13) << std::endl;
}

The initial error is:

error: ambiguous overload for ‘operator<<’ (operand types are ‘std::ostream’
{aka ‘std::basic_ostream’} and ‘unsigned int’)

in gcc9.2 & gcc 11.2.0

gcc7 happily compiles the code.

with -Wextra, all 3 versions warn:

error: enumerated and non-enumerated type in conditional expression

Version: 11.2.0

system: CentOS Linux 7.7.1908 on Intel Xeon

command: g++ -Wall -Wextra -std=c++11 20211017-bug.cpp

[Bug c++/102805] New: at -O2, spurious stringop-overflow warning writing to std::vector::back()

2021-10-17 Thread rudick at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102805

Bug ID: 102805
   Summary: at -O2, spurious stringop-overflow warning writing to
std::vector::back()
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rudick at gmail dot com
  Target Milestone: ---

g++ -O2 -Wextra -Wall -Werror -Wextra vectorBackWrite.cpp

#include 
#include 
#include 

extern FILE* f;
void triggerBug(uint64_t start, uint64_t end) {
  if (f && end > start) {
std::vector data(end - start + 1);
auto res = fread(&data[0], end-start, 1, f);
if (res == 1) {
  data.back() = 0;
}
  }
}

error is:

vectorBackWrite.cpp: In function ‘void triggerBug(uint64_t, uint64_t)’:
vectorBackWrite.cpp:11:19: error: writing 1 byte into a region of size 0
[-Werror=stringop-overflow=]
   11 |   data.back() = 0;
  |   ^~~
In file included from
/opt/gcc-11.2.0/include/c++/11.2.0/x86_64-linux-gnu/bits/c++allocator.h:33,
 from /opt/gcc-11.2.0/include/c++/11.2.0/bits/allocator.h:46,
 from /opt/gcc-11.2.0/include/c++/11.2.0/vector:64,
 from vectorBackWrite.cpp:1:
/opt/gcc-11.2.0/include/c++/11.2.0/ext/new_allocator.h:127:48: note: at offset
[0, 9223372036854775806] into destination object of size [2,
9223372036854775807] allocated by ‘operator new’
  127 | return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp)));
  |  ~~^~~
cc1plus: all warnings being treated as errors


Interestingly, this also fails w/ the same error:
*(data.rbegin()) = 0;

but this is accepted:
data[data.size()-1] = 0;

code works in gcc7 & gcc9 on the same platform, & works on gcc11 with -O1
It also seems to require the fread to be present

Version: 11.2.0

system: CentOS Linux 7.7.1908 on Intel Xeon

[Bug tree-optimization/102805] at -O2, spurious stringop-overflow warning writing to std::vector::back()

2021-10-17 Thread rudick at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102805

--- Comment #2 from rudick at gmail dot com ---
Interesting.

if (f && end > start && start < 100 && end < 100) {

& I still get the warning though

[Bug c++/102804] template matching fails w/ false ambiguity on ternary expressions with enums class defined with unsigned typdef

2021-10-18 Thread rudick at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102804

--- Comment #5 from Todd Rudick  ---
Richard, is there a way to represent the part of this that is a bug? 
Presumably accepting the construct but having it break template specialization
with an error that can be arbitrarily disconnected from the definition is not a
desired behavior. In the production code that I eventually isolated this from,
there is in fact no reference at all to the header that contained the enum.

Also, it seems likely that the compiler state is bad at that point (?), as the
error message indicates an 'unsigned int' ambiguity that doesn't actually
exist.