http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50082
--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-08-15
15:31:37 UTC ---
(In reply to comment #2)
> Not sure I understand your question about tree-ssa-forwprop.c. Are you saying
> that overflow warnings are already deferred at that point, so that passing
> WARN_STRICT_OVERFLOW_CONDITIONAL causes extraneous warnings to be issued? Are
> overflow warnings already deferred during tree-ssa-forwprop.c? Because if
> they
> aren't deferred then I don't see why changing the last argument to
> fold_undefer_overflow_warnings would make any difference.
No, but the warning is defered as WARN_STRICT_OVERFLOW_MAGNITUDE and then
re-issued as WARN_STRICT_OVERFLOW_CONDITIONAL. I'm not sure why forwprop
"raises" the severity forcefully - maybe you'd remember? Maybe you
remember why you added the ability to forcefully override?
The issue is hidden now on trunk, still visible on the 4.6 branch and
with obfuscating the testcase to
void
insert_cache_boundary_ok (int gap_start, int i)
{
int tem;
if (i < 0)
__builtin_abort ();
tem = i - 1;
if (tem < gap_start)
__builtin_abort ();
}
also on trunk. It should warn for -Wstrict-overflow=5 but not for
-Wstrict-overflow=1.
I suppose the forwprop code wants to force a warning at -Wstrict-overflow=1
if the conditional becomes optimized to a constant at compile-time?
