[Bug sanitizer/91389] [7/8/9/10 Regression] error: control reaches end of non-void function with -fsanitize=thread since r219201

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Forgot to say, if you are just looking for a workaround for the warning (note,
-O2 -Wreturn-type doesn't warn, in this case you need also no optimizations),
then I'd just move the return from the default: clause to after the switch if
the package maintainers insist on their weird coding conventions.

[Bug sanitizer/91389] [7/8/9/10 Regression] error: control reaches end of non-void function with -fsanitize=thread since r219201

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #5)
> (In reply to Martin Liška from comment #4)
> > (In reply to Jakub Jelinek from comment #3)
> > > I see dead code everywhere in the function, they must have some weirdo 
> > > macro
> > > for cases that wraps everything in case something { ... } break;
> > 
> > Is the 'break;' really dead in such situation (when you don't have a return
> > or another break within the {} block)?
> > 
> > > Many of those break; statements are dead code.
> 
> It is dead when you do have an unconditional return in there.  As I said in
> the other PR, we try hard to do a good job with block_may_fallthru and
> gimple_seq_may_fallthru, but it can't handle everything, feel free to
> improve those.  And all -fsanitize=thread does is it adds a cleanup code,
> the same thing as you get if you have an automatic variable with a
> destructor.
> 
> *** This bug has been marked as a duplicate of bug 86899 ***

Sure, thank you for your time.

[Bug sanitizer/91389] [7/8/9/10 Regression] error: control reaches end of non-void function with -fsanitize=thread since r219201

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #5 from Jakub Jelinek  ---
(In reply to Martin Liška from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > I see dead code everywhere in the function, they must have some weirdo macro
> > for cases that wraps everything in case something { ... } break;
> 
> Is the 'break;' really dead in such situation (when you don't have a return
> or another break within the {} block)?
> 
> > Many of those break; statements are dead code.

It is dead when you do have an unconditional return in there.  As I said in the
other PR, we try hard to do a good job with block_may_fallthru and
gimple_seq_may_fallthru, but it can't handle everything, feel free to improve
those.  And all -fsanitize=thread does is it adds a cleanup code, the same
thing as you get if you have an automatic variable with a destructor.

*** This bug has been marked as a duplicate of bug 86899 ***

[Bug sanitizer/91389] [7/8/9/10 Regression] error: control reaches end of non-void function with -fsanitize=thread since r219201

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #3)
> I see dead code everywhere in the function, they must have some weirdo macro
> for cases that wraps everything in case something { ... } break;

Is the 'break;' really dead in such situation (when you don't have a return or
another break within the {} block)?

> Many of those break; statements are dead code.

[Bug sanitizer/91389] [7/8/9/10 Regression] error: control reaches end of non-void function with -fsanitize=thread since r219201

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
I see dead code everywhere in the function, they must have some weirdo macro
for cases that wraps everything in case something { ... } break;
Many of those break; statements are dead code.

[Bug sanitizer/91389] [7/8/9/10 Regression] error: control reaches end of non-void function with -fsanitize=thread since r219201

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Created attachment 46688
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46688=edit
Original test-case

I'm fine with the approach to remove a dead code. However, I can't easily find
what to change in the original source file. The warning location does not help
much.

[Bug sanitizer/91389] [7/8/9/10 Regression] error: control reaches end of non-void function with -fsanitize=thread since r219201

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Don't do it then?  The no fallthru early discovery isn't perfect and with the
sanitizer instrumentation it gets even harder.
Looks like a dup of PR86899 to me anyway.
If I do a small modification like:
class A {
  struct B {
enum {} type;
  };
  B *m_fn1();
};
struct C { C (); ~C (); };
A::B *A::m_fn1() {
  C c;
  B *a;
  switch (a->type) {
break;
  default:
return a;
  }
}
then it emits the false positive warning even with just -O0 -Wreturn-type.
I really think it doesn't hurt if people remove the clearly unreachable code
from their code to get rid of this warning.