[Bug c++/85714] New: -Wimplicit-fallthrough and nested exhaustive switch statements with enum classes and return

2018-05-09 Thread thomas.o...@pdv-fs.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85714

Bug ID: 85714
   Summary: -Wimplicit-fallthrough and nested exhaustive switch
statements with enum classes and return
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas.o...@pdv-fs.de
  Target Milestone: ---

Nesting enum class switch statements which are exhaustive and whose cases all
return produces a false positive -Werror=implicit-fallthrough warning:

$ ~/gcc/8.1.0/bin/g++ -Wall -Wextra -c switch_fallthrough.cpp -Werror
switch_fallthrough.cpp: In function 'int example(Foo, Bar)':
switch_fallthrough.cpp:8:7: error: this statement may fall through
[-Werror=implicit-fallthrough=]
   switch(b) {
   ^~
switch_fallthrough.cpp:13:5: note: here
 case Foo::E2:
 ^~~~


Uncommenting the [[fallthrough]]; fixes this, but should not be required since
no fallthrough can happen.

Related, the last return -1 in the function should not be required since the
outer switch is also exhaustive.



enum class Foo { E1, E2 };
enum class Bar { A, B }; 

int example(Foo f, Bar b)
{
  switch(f) {
case Foo::E1:
  switch(b) {
 case Bar::A:  return 1;
 case Bar::B:  return 2;
  }
///[[fallthrough]]; // -Wimplicit-fallthrough -- new in gcc 8.1
case Foo::E2:
  switch(b) {
 case Bar::A:  return 3;
 case Bar::B:  return 4;
  }

  }
  return -1; // -Wreturn-type -- already in gcc 7.3, should not be required
}

[Bug c++/85714] -Wimplicit-fallthrough and nested exhaustive switch statements with enum classes and return

2018-05-09 Thread thomas.o...@pdv-fs.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85714

--- Comment #1 from Thomas Otto  ---
Created attachment 44098
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44098&action=edit
-Werror=implicit-fallthrough false positive demo

[Bug c++/85714] -Wimplicit-fallthrough and nested exhaustive switch statements with enum classes and return

2018-05-16 Thread thomas.o...@pdv-fs.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85714

--- Comment #3 from Thomas Otto  ---
I thought forcing out-of-range enum values is no longer unspecified but now
undefined behavior in C++17:

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1766
http://obiwahn.org/c++draft/expr.static.cast/#10

> The value is unchanged if the original value is within the range of the 
> enumeration values ([dcl.enum]). Otherwise, the behavior is undefined.

And this warning also shows up with -std=c++17

[Bug c++/86485] New: [ 7 regression] "anonymous" maybe-uninitialized false positive with ternary operator

2018-07-11 Thread thomas.o...@pdv-fs.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86485

Bug ID: 86485
   Summary: [ 7 regression] "anonymous" maybe-uninitialized false
positive with ternary operator
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas.o...@pdv-fs.de
  Target Milestone: ---

Created attachment 44382
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44382&action=edit
Minimal example for maybe-uninitialized false positive regression

The following minimal code example triggers the maybe-uninitialized warning on
gcc 8.1 and 7.3, but not on 5.3 or 6.2. Only shows up when optimizations are
enabled, and removing seemingly unrelated code "fixes" it again.



// compile with g++ 7.3 or 8.1 and optimizations enabled (not 5.3 or 6.2)
// g++ -O1 -c maybe_uninitialized_false_positive.cpp -o /dev/null
-Werror=maybe-uninitialized
// minimal working example created with creduce

struct empty_but_important {};
struct in_ternary_op {
  in_ternary_op() noexcept {}
  empty_but_important e; // REMOVE (or replace with int)
 // and the error disappears
};

struct M {
  M(in_ternary_op) noexcept;
};

struct MustInheritBase {
  virtual M get_a(bool b) noexcept;
};

struct ZZ : MustInheritBase {
  M get_a(bool b) noexcept { // b = true; // ADD and the error disappears
return M( b ? in_ternary_op{} : in_ternary_op{} );
// ^~
// error: '' may be used uninitialized in 
//this function [-Werror=maybe-uninitialized]
// --
  }
};

ZZ zz_fn() { // REMOVE and the error disappears
  ZZ z;
  return z;
}

[Bug middle-end/61409] [6 regression] -Wmaybe-uninitialized false-positive with -O2

2018-07-11 Thread thomas.o...@pdv-fs.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61409

Thomas Otto  changed:

   What|Removed |Added

 CC||thomas.o...@pdv-fs.de

--- Comment #30 from Thomas Otto  ---
(So... close as fixed?)