[Bug c/57029] New: GCC doesn't set the inexact flag on inexact compile-time int-to-float conversion

[Bug c/57029] New: GCC doesn't set the inexact flag on inexact compile-time int-to-float conversion

[vincent-gcc at vinc17 dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57029

             Bug #: 57029
           Summary: GCC doesn't set the inexact flag on inexact
                    compile-time int-to-float conversion
    Classification: Unclassified
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: vincent-gcc@vinc17.net


GCC doesn't set the inexact flag on inexact compile-time int-to-float
conversion:

#include <stdio.h>
#include <fenv.h>

#pragma STDC FENV_ACCESS ON

void test1 (void)
{
  volatile float c;

  c = 0x7fffffbf;
  printf ("c = %a, inexact = %d\n", c, fetestexcept (FE_INEXACT));
}

void test2 (void)
{
  volatile float c;
  volatile int i = 0x7fffffbf;

  c = i;
  printf ("c = %a, inexact = %d\n", c, fetestexcept (FE_INEXACT));
}

int main (void)
{
  test1 ();
  test2 ();
  return 0;
}

Under Linux/x86_64:

$ gcc -std=c99 -O3 conv-int-flt-inex.c -o conv-int-flt-inex -lm
$ ./conv-int-flt-inex
c = 0x1.fffffep+30, inexact = 0
c = 0x1.fffffep+30, inexact = 32

Ditto without optimizations.

Note: the STDC FENV_ACCESS pragma is currently not supported (PR 34678), but I
don't think it is directly related (this is not an instruction ordering
problem...).

This bug has been found from:

  http://gcc.gnu.org/ml/gcc-help/2013-04/msg00164.html

[Bug c/57029] GCC doesn't set the inexact flag on inexact compile-time int-to-float conversion

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57029

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-04-22
     Ever Confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> 2013-04-22 13:01:09 UTC ---
There is no -finexact-math flag similar to -frounding-math we could guard
such transforms with.  Certainly the default of that flag is 'off' by
design, similar to -frounding-math.

[Bug c/57029] GCC doesn't set the inexact flag on inexact compile-time int-to-float conversion

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57029

--- Comment #2 from Marc Glisse <glisse at gcc dot gnu.org> 2013-04-22 13:07:07 UTC ---
There is -ftrapping-math, which I think is supposed to have an effect here. And
if this was implemented properly, I hope it would be turned off by default.

[Bug c/57029] GCC doesn't set the inexact flag on inexact compile-time int-to-float conversion

[vincent-gcc at vinc17 dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57029

--- Comment #3 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> 2013-04-22 13:32:10 UTC ---
(In reply to comment #2)
> There is -ftrapping-math, which I think is supposed to have an effect here. And
> if this was implemented properly, I hope it would be turned off by default.

-ftrapping-math is on by default. And whether -ftrapping-math or
-fno-trapping-math is used, the behavior is the same.
>From gcc-bugs-return-420741-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Apr 22 13:34:47 2013
Return-Path: <gcc-bugs-return-420741-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 1342 invoked by alias); 22 Apr 2013 13:34:47 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 929 invoked by uid 48); 22 Apr 2013 13:34:43 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/56474] [4.8/4.9 regression] bogus Storage_Error raised for record containing empty zero-based array
Date: Mon, 22 Apr 2013 13:34:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P4
X-Bugzilla-Assigned-To: ebotcazou at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.1
X-Bugzilla-Changed-Fields:
Message-ID: <bug-56474-4-KTV6Dmj9lH@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-56474-4@http.gcc.gnu.org/bugzilla/>
References: <bug-56474-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
X-SW-Source: 2013-04/txt/msg01886.txt.bz2
Content-length: 5073


http://gcc.gnu.org/bugzilla/show_bug.cgi?idV474

--- Comment #16 from Richard Biener <rguenth at gcc dot gnu.org> 2013-04-22 13:34:40 UTC ---
The testcase in the patch posted to the mailing list is

-- { dg-do compile }

with Ada.Streams;

package Array3 is

   use type Ada.Streams.Stream_Element_Offset;

   type Vector (Size : Ada.Streams.Stream_Element_Offset) is record
      Value : Ada.Streams.Stream_Element_Array (0 .. Size);
   end record;

   Empty_Vector : Vector (-1);

end Array3;


is the testcase when changed to 'Empty_Vector : Vector (-2);' valid?
In any case, in 0 .. Size, Size seems to be signed.
Also, there is the special-case

              /* Similarly, if one of the values overflows in sizetype and the
                 range is null, use 1..0 for the sizetype bounds.  */
              else if (TREE_CODE (gnu_min) == INTEGER_CST
                       && TREE_CODE (gnu_max) == INTEGER_CST
                       && (TREE_OVERFLOW (gnu_min) || TREE_OVERFLOW (gnu_max))
                       && tree_int_cst_lt (gnu_orig_max, gnu_orig_min))
                {
                  gnu_min = size_one_node;
                  gnu_max = size_zero_node;
                  gnu_high = gnu_max;
                }

that simply chooses [1, 0] as "empty" domain, regardless of the original
min or max.  So both cases (of which you fix only one),

              /* Otherwise, if the high bound is constant but the low bound is
                 not, we use the expression (hb >= lb) ? lb : hb + 1 for the
                 lower bound.  Note that the comparison must be done in the
                 original type to avoid any overflow during the conversion.  */
              else if (TREE_CODE (gnu_max) == INTEGER_CST
                       && TREE_CODE (gnu_min) != INTEGER_CST)
                {
                  gnu_high = gnu_max;
                  gnu_min
                    = build_cond_expr (sizetype,
                                       build_binary_op (GE_EXPR,
                                                        boolean_type_node,
                                                        gnu_orig_max,
                                                        gnu_orig_min),
                                       gnu_min,
                                       size_binop (PLUS_EXPR, gnu_max,
                                                   size_one_node));
                }

              /* Finally we use (hb >= lb) ? hb : lb - 1 for the upper bound
                 in all the other cases.  Note that, here as well as above,
                 the condition used in the comparison must be equivalent to
                 the condition (length != 0).  This is relied upon in order
                 to optimize array comparisons in compare_arrays.  */
              else
                gnu_high
                  = build_cond_expr (sizetype,
                                     build_binary_op (GE_EXPR,
                                                      boolean_type_node,
                                                      gnu_orig_max,
                                                      gnu_orig_min),
                                     gnu_max,
                                     size_binop (MINUS_EXPR, gnu_min,
                                                 size_one_node));

could be combined to

             else
               {
                  gnu_min
                    = build_cond_expr (sizetype,
                                       build_binary_op (GE_EXPR,
                                                        boolean_type_node,
                                                        gnu_orig_max,
                                                        gnu_orig_min),
                                       gnu_min,
                                       size_one_node));
                gnu_high
                  = build_cond_expr (sizetype,
                                     build_binary_op (GE_EXPR,
                                                      boolean_type_node,
                                                      gnu_orig_max,
                                                      gnu_orig_min),
                                     gnu_max,
                                     size_zero_node);
                }

which fixes the issue for me.

I can also easily guard the existing size_binop (MINUS_EXPR, gnu_min,
size_one_node) for gnu_min being zero, or I can simply use
int_const_binop here instead, as you expect that operation to _never_
set TREE_OVERFLOW if not gnu_min had TREE_OVERFLOW set.

Note that if gnu_max - 1 is not computable as compile-time constant here,
but is retained as tree expression and folded later overflow will not
be considered either (it doesn't go the size_* API way, which is supposed
to be the interface giving overflow hints to the FEs via means of
TREE_OVERFLOW which better should not appear later during optimization).

[Bug c/57029] GCC doesn't set the inexact flag on inexact compile-time int-to-float conversion

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
PR84407 was related which was about rounding modes and int-to-float conversion
which means the testcase in this bug should now also be fixed if you supply
-frounding-math which is documented as to determine the default of
#pragma STDC FENV_ACCESS when the latter is implemented.

But yes, -ftrapping-math is not enough to preserve the conversions from being
constant folded (and thus the exception being lost).  Not sure if separate
control of this is really desirable.