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

["rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

Richard Biener <rguenth at gcc dot gnu.org> 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 <rguenth at gcc dot gnu.org> ---
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.9999e+4;

it's

static bool
if_convertible_stmt_p (gimple stmt, vec<data_reference_p> 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)?