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

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

[p.vanhoof at oma dot be]

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

            Bug ID: 65425
           Summary: code optimization leads to spurious FP exception
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: p.vanhoof at oma dot be

Created attachment 35035
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35035&action=edit
program that triggers the bug

Compile the attached test case with

gcc -O3 -ftrapping-math -fno-math-errno bug.c -lm

This produces no output. Running the executable will result in a spurious FP
exception. This happens with all gcc versions I tested since 4.7.0. Versions
4.6.4 and earlier work correctly, so this is a regression. It looks like the
code is being optimized with the implicit assumption that FP exceptions are not
trapped. However, using the -ftrapping-math flag should prevent such
optimizations (and should be the default as well).

% gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc492/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc492/configure --prefix=/usr/local/gcc492
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.9.2 (GCC)

[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 <rguenth at gcc dot gnu.org> ---
Created attachment 35056
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35056&action=edit
incomplete patch

[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 <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)?