[Bug tree-optimization/65425] code optimization leads to spurious FP exception

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed|2015-03-18 00:00:00 |2019-1-8

--- Comment #3 from Richard Biener  ---
Reconfirmed.  Now needs -ftree-loop-if-convert (which also makes it fail ontop
of -O[12]).

As said, not sure what to do - __builtin_log10 (and others) are const nothrow
with -fno-math-errno -ftrapping-math.  if_convertible_stmt_p does

case GIMPLE_CALL:
  {
tree fndecl = gimple_call_fndecl (stmt);
if (fndecl)
  {
int flags = gimple_call_flags (stmt);
if ((flags & ECF_CONST)
&& !(flags & ECF_LOOPING_CONST_OR_PURE)
/* We can only vectorize some builtins at the moment,
   so restrict if-conversion to those.  */
&& fndecl_built_in_p (fndecl))
  return true;
  }
return false;

which fails to consider externally throwing stmts (internal throws would
be rejected by other means).  But 'nothrow' doesn't go away with
-ftrapping-math (which is also the default btw).  logN(0) is documented
to raise FE_DIVBYZERO.

One possibility here is to simply check flag_trapping_math but then
even functions like sin() would be flagged.

Joseph?  How would you arrange things so that those builtin calls are
flagged as possibly trapping (rather than throwing)?  We could add
a built_in_could_trap_p helper, explicitely spelling out things.
I think there's no function attribute glibc could place on a
function to say it won't ever trap?  (even sin() is documented to
trap on +-Inf)

[Bug tree-optimization/65425] code optimization leads to spurious FP exception

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  ---
 has my comments 
on ways in which libm functions can be "const/pure with exceptions".  It 
would be possible to have attributes to describe the ways in which most 
libm functions are const apart from rounding mode, exceptions and errno.

I didn't discuss there any possibilities relating to functions raising 
some exceptions but not others, or the possible exceptions depending on 
-ffinite-math-only.  For example, sin can raise inexact and underflow for 
finite arguments, as well as invalid for infinite arguments; cos can raise 
inexact for finite arguments but not underflow.  Most functions can raise 
inexact.

(There's also the difference between raising exception flags, which is 
what's available when using standard facilities, and actually generating a 
signal and calling a signal handler, when using feenableexcept which is a 
GNU extension.  -ftrapping-math covers both at present.)

[Bug tree-optimization/65425] code optimization leads to spurious FP exception

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-03-18
 CC||jsm28 at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I think we have a duplicate bug for this - if-conversion transforms the loop
body to execute the log10 unconditionally:

  iftmp.0_11 = log10 (_10);
  iftmp.0_2 = _10 > 0.0 ? iftmp.0_11 : -9.e+4;

it's

static bool
if_convertible_stmt_p (gimple stmt, vec refs,
   bool *any_mask_load_store)
{
...
case GIMPLE_CALL:
  {
tree fndecl = gimple_call_fndecl (stmt);
if (fndecl)
  {
int flags = gimple_call_flags (stmt);
if ((flags & ECF_CONST)
&& !(flags & ECF_LOOPING_CONST_OR_PURE)
/* We can only vectorize some builtins at the moment,
   so restrict if-conversion to those.  */
&& DECL_BUILT_IN (fndecl))
  return true;
  }
return false;

which fails to check whether the call may trap.

I have a patch for that issue, but log10 is also using ATTR_NOTHROW_*
thus it is declared as never trapping.  It looks like _all_ functions
will have this issue.

Then the canonical helper gimple_could_trap_p doesn't consider the _body_
of the call but only the call instruction itself.  So we have to "abuse"
gimple_call_nothrow_p here.

I'm not sure about how to deal with this (adding another layer distinguishing
flag_trapping_math in builtins.def)?

[Bug tree-optimization/65425] code optimization leads to spurious FP exception

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Created attachment 35056
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35056&action=edit
incomplete patch