[Bug c/67629] bogus -Wreturn-type in a function with tautological if-else

2021-03-13 Thread egallager at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67629

Eric Gallager  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||mwoehlke.floss at gmail dot 
com,
   ||skvadrik at gmail dot com

--- Comment #10 from Eric Gallager  ---
Redoing some ccs that mysteriously disappeared without being marked as
"removed" in the bug history (guessing it was from the server migration)

[Bug c/67629] bogus -Wreturn-type in a function with tautological if-else

2019-09-23 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67629

--- Comment #9 from Eric Gallager  ---
(In reply to Matthew Woehlke from comment #8)
> Given what -Wreturn-type is trying to accomplish, I wonder if a "delayed
> issuance" strategy would be in order? IOW, have the front end "trigger" the
> warning, as now, but stuff it in a queue or such, continue on with
> optimization, then go back and check the queue to see if the warning still
> looks legitimate, and only *then* emit it.
> 
> Where this gets sticky is that at -O0, we still may not know that the
> warning is spurious. We might, ideally, want to perform optimization anyway
> on a function with a "pending" -Wreturn-type warning, but throw out the
> result.

I think Martin Sebor's work to introduce a __builtin_warning() function might
be relevant here...

[Bug c/67629] bogus -Wreturn-type in a function with tautological if-else

2018-09-24 Thread mwoehlke.floss at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67629

--- Comment #8 from Matthew Woehlke  ---
Given what -Wreturn-type is trying to accomplish, I wonder if a "delayed
issuance" strategy would be in order? IOW, have the front end "trigger" the
warning, as now, but stuff it in a queue or such, continue on with
optimization, then go back and check the queue to see if the warning still
looks legitimate, and only *then* emit it.

Where this gets sticky is that at -O0, we still may not know that the warning
is spurious. We might, ideally, want to perform optimization anyway on a
function with a "pending" -Wreturn-type warning, but throw out the result.

[Bug c/67629] bogus -Wreturn-type in a function with tautological if-else

2018-09-20 Thread manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67629

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||skvadrik at gmail dot com

--- Comment #7 from Manuel López-Ibáñez  ---
*** Bug 60725 has been marked as a duplicate of this bug. ***

[Bug c/67629] bogus -Wreturn-type in a function with tautological if-else

2018-09-20 Thread manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67629

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||mwoehlke.floss at gmail dot com

--- Comment #6 from Manuel López-Ibáñez  ---
*** Bug 87371 has been marked as a duplicate of this bug. ***

[Bug c/67629] bogus -Wreturn-type in a function with tautological if-else

2017-10-19 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67629

--- Comment #5 from Martin Liška  ---
That's for CC. However as the warning is triggered early, we don't have
optimized IL:

(gdb) p debug_function(cfun->decl, 0)
foo (_Bool a)
{
  int D.1836;

   [0.00%] [count: INV]:
  if (a != 0)
goto ; [INV] [count: INV]
  else
goto ; [INV] [count: INV]

   [0.00%] [count: INV]:
  D.1836 = 0;
  // predicted unlikely by early return (on trees) predictor.
  goto ; [INV] [count: INV]

   [0.00%] [count: INV]:
  _1 = ~a;
  if (_1 != 0)
goto ; [INV] [count: INV]
  else
goto ; [INV] [count: INV]

   [0.00%] [count: INV]:
  D.1836 = 1;
  // predicted unlikely by early return (on trees) predictor.
  goto ; [INV] [count: INV]

   [0.00%] [count: INV]:
  return;

   [0.00%] [count: INV]:
:
  return D.1836;

}

[Bug c/67629] bogus -Wreturn-type in a function with tautological if-else

2017-10-18 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67629

Eric Gallager  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
cc-ing Martin Liska since he made -Wreturn-type enabled by default now.

[Bug c/67629] bogus -Wreturn-type in a function with tautological if-else

2017-07-28 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67629

Eric Gallager  changed:

   What|Removed |Added

 CC||yyc1992 at gmail dot com

--- Comment #2 from Eric Gallager  ---
*** Bug 68336 has been marked as a duplicate of this bug. ***

[Bug c/67629] bogus -Wreturn-type in a function with tautological if-else

2017-07-28 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67629

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-28
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Eric Gallager  ---
(In reply to Martin Sebor from comment #0)
> While testing Marek's patch for PR 64249 I noticed that both gcc and g++
> incorrectly issue a -Wreturn-type warning for the following snippet:
> 
> $ cat u.c && xgcc -Wreturn-type -c u.c
> int foo (_Bool a) {
> if (a) return 0;
> else if (!a) return 1;
> }
> u.c: In function ‘foo’:
> u.c:4:1: warning: control reaches end of non-void function [-Wreturn-type]
>  }
>  ^

Confirmed.

[Bug c/67629] bogus -Wreturn-type in a function with tautological if-else

2015-11-13 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67629

--- Comment #1 from Martin Sebor  ---
See also bug 68336, which may be a possible duplicate of this one.