[Bug middle-end/37845] New: gcc ignores FP_CONTRACT pragma set to OFF

[Bug middle-end/37845] New: gcc ignores FP_CONTRACT pragma set to OFF

[vincent at vinc17 dot org]

To be conform to the ISO C standard (when FLT_EVAL_METHOD is 0, 1 or 2, which
is the case of gcc), gcc should either take FP_CONTRACT pragmas into account or
(in the mean time) assume they are set to OFF, i.e. disallow the contraction of
floating expressions. This means in particular that -mno-fused-madd should be
the default (with processors for which this option is supported, e.g. PowerPC).

I've tested with gcc-4.4-20081010 on ia64 that this bug is still present.


-- 
           Summary: gcc ignores FP_CONTRACT pragma set to OFF
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: vincent at vinc17 dot org


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

[Bug target/37845] gcc ignores FP_CONTRACT pragma set to OFF

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2008-10-16 09:40 -------
Confirmed.  The FP_CONTRACT macro is not implemented, but the default behavior
of GCC is to behave like it was set to OFF.

This is a target issue (sofar ia64 is identified as buggy).


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |37846
             Status|UNCONFIRMED                 |NEW
          Component|middle-end                  |target
     Ever Confirmed|0                           |1
 GCC target triplet|                            |ia64-*-*
           Keywords|                            |wrong-code
   Last reconfirmed|0000-00-00 00:00:00         |2008-10-16 09:40:12
               date|                            |


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

[Bug target/37845] gcc ignores FP_CONTRACT pragma set to OFF

[rguenth at gcc dot gnu dot org]

------- Comment #2 from rguenth at gcc dot gnu dot org  2008-10-16 09:42 -------
The fma patterns on ia64 are not guarded properly.  They should be off
as long as flag_unsafe_math_optimizations is not specified.


-- 


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

[Bug target/37845] gcc ignores FP_CONTRACT pragma set to OFF

[vincent at vinc17 dot org]

------- Comment #3 from vincent at vinc17 dot org  2008-10-16 13:54 -------
(In reply to comment #1)
> Confirmed.  The FP_CONTRACT macro is not implemented, but the default behavior
> of GCC is to behave like it was set to OFF.

The problem is that on PowerPC, x*y+z is fused (contracted) by default (which
is forbidden when FP_CONTRACT is OFF). I could test only with Apple's gcc
4.0.1, but the man page of the gcc snapshot implies that the problem remains
with the current versions:

   IBM RS/6000 and PowerPC Options

   -mfused-madd
   -mno-fused-madd
       Generate code that uses (does not use) the floating point multiply
       and accumulate instructions.  These instructions are generated by
       default if hardware floating is used.

But the correct behavior would be that these instructions should not be
generated by default.

On http://www.vinc17.org/software/tst-ieee754.c compiled with

  gcc -Wall -O2 -std=c99 tst-ieee754.c -o tst-ieee754 -lm

I get:

$ ./tst-ieee754 | grep fused
x * y + z with FP_CONTRACT OFF is fused.

I need to add -mno-fused-madd to get the correct behavior:

$ ./tst-ieee754 | grep fused
x * y + z with FP_CONTRACT OFF is not fused.


-- 


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

Re: [Bug target/37845] gcc ignores FP_CONTRACT pragma set to OFF

[Andrew Thomas Pinski]

Sent from my iPhone

On Oct 16, 2008, at 2:42 AM, "rguenth at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org 
 > wrote:

>
>
> ------- Comment #2 from rguenth at gcc dot gnu dot org  2008-10-16  
> 09:42 -------
> The fma patterns on ia64 are not guarded properly.  They should be off
> as long as flag_unsafe_math_optimizations is not specified.

No that is not true. They should be on by default.

>
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37845
>

[Bug target/37845] gcc ignores FP_CONTRACT pragma set to OFF

[pinskia at gmail dot com]

------- Comment #4 from pinskia at gmail dot com  2008-10-16 15:40 -------
Subject: Re:  gcc ignores FP_CONTRACT pragma set to OFF



Sent from my iPhone

On Oct 16, 2008, at 2:42 AM, "rguenth at gcc dot gnu dot org"
<gcc-bugzilla@gcc.gnu.org 
 > wrote:

>
>
> ------- Comment #2 from rguenth at gcc dot gnu dot org  2008-10-16  
> 09:42 -------
> The fma patterns on ia64 are not guarded properly.  They should be off
> as long as flag_unsafe_math_optimizations is not specified.

No that is not true. They should be on by default.

>
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37845
>


-- 


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

[Bug target/37845] gcc ignores FP_CONTRACT pragma set to OFF

[joseph at codesourcery dot com]

------- Comment #5 from joseph at codesourcery dot com  2008-10-16 16:31 -------
Subject: Re:  gcc ignores FP_CONTRACT pragma set to OFF

On Thu, 16 Oct 2008, rguenth at gcc dot gnu dot org wrote:

> Confirmed.  The FP_CONTRACT macro is not implemented, but the default behavior
> of GCC is to behave like it was set to OFF.

No, the default is to behave like it is ON, on targets with fused 
operations, with target-specific options to turn it off.  A default of ON 
is fine according to C99.

It so happens that GCC's version of "ON" is buggy, in that it contracts 
even outside the bounds of source language expressions - those boundaries 
are lost at gimplification, long before the insn patterns are applied.  
Fixing this would probably require fused operations to be identified in 
the front end in conforming mode, and the only insn patterns in conforming 
mode for the fused instructions to have RTL describing them precisely as 
fused operations so non-fused ones don't get combined.

This situation is much like the other floating-point pragmas:

* GCC doesn't support any of the pragmas, and doesn't claim to support 
those parts of C99; the features can only be enabled or disabled for a 
whole translation unit on the command line.

* The features for a whole translation unit are in practice rather buggy 
and incomplete.  -fno-cx-limited-range (on by default) doesn't work for 
constant arithmetic (bug 30789).  -ftrapping-math (on by default) doesn't 
cause all required exceptions to be generated, and spurious exceptions are 
generated in some cases; no real effort has been made to get it to work 
properly in all cases.  -frounding-math (off by default) comes with a 
specific warning in the manual that it's experimental and incomplete, 
which is quite correct.

Yes, there should be a target-independent option to disable contracting 
rather than needing separate options for each target, and in conformance 
mode (flag_iso) contracting, if enabled, should be restricted to source 
language expressions.  I'm not aware of anyone working on this, or on the 
other issues with the options approximating to the standard pragmas, or on 
the pragmas themselves.


-- 


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

[Bug target/37845] gcc ignores FP_CONTRACT pragma set to OFF

[vincent-gcc at vinc17 dot net]

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

Vincent Lefèvre <vincent-gcc at vinc17 dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #6 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
This bug has been fixed by:

r204460 | jsm28 | 2013-11-06 17:52:47 +0100 (Wed, 06 Nov 2013) | 9 lines
Changed paths:
   M /trunk/gcc/c-family/ChangeLog
   M /trunk/gcc/c-family/c-cppbuiltin.c
   M /trunk/gcc/c-family/c-opts.c
   M /trunk/gcc/testsuite/ChangeLog
   A /trunk/gcc/testsuite/gcc.dg/torture/c99-contract-1.c

c-family:
        * c-opts.c (c_common_post_options): Set -ffp-contract=off in C
        standards modes.
        * c-cppbuiltin.c (cpp_iec_559_value): Consider -ffp-contract=fast
        to mean lack of IEEE 754 support.

testsuite:
        * gcc.dg/torture/c99-contract-1.c: New test.

gcc/c-family/c-opts.c now contains:

  /* ISO C restricts floating-point expression contraction to within
     source-language expressions (-ffp-contract=on, currently an alias
     for -ffp-contract=off).  */
  if (flag_iso
      && !c_dialect_cxx ()
      && (global_options_set.x_flag_fp_contract_mode
          == (enum fp_contract_mode) 0)
      && flag_unsafe_math_optimizations == 0)
    flag_fp_contract_mode = FP_CONTRACT_OFF;

I tested, and this works as expected.

Note: This bug was about FP contraction being done despite the use of:
#pragma STDC FP_CONTRACT OFF
not about the pragma being ignored (the implementation of this pragma is not
required by the ISO C standard if the default is OFF, which is now the case
with GCC). So, this bug is really fixed. A new enhancement bug could be opened
(if not already done) for the implementation of the STDC FP_CONTRACT pragma.
>From gcc-bugs-return-494840-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 14 15:19:14 2015
Return-Path: <gcc-bugs-return-494840-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 22551 invoked by alias); 14 Aug 2015 15:19:14 -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 22528 invoked by uid 48); 14 Aug 2015 15:19:11 -0000
From: "rsandifo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/67218] New: Combine incorrectly folds (double) (float) (unsigned)
Date: Fri, 14 Aug 2015 15:19:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rsandifo at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-67218-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-08/txt/msg00982.txt.bz2
Content-length: 1171

https://gcc.gnu.org/bugzilla/show_bug.cgi?idg218

            Bug ID: 67218
           Summary: Combine incorrectly folds (double) (float) (unsigned)
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rsandifo at gcc dot gnu.org
  Target Milestone: ---

simplify-rtx.c folds (double) (float) (some-int) into
(double) (some-int) if it can prove that the intermediate
(float) doesn't have any effect.  This check is based on
the number of known "sign bit copies", which inherently assumes
a signed interpretation of (some-int) and is therefore only
valid for FLOAT.  For UNSIGNED_FLOAT we can end up treating a
large unsigned value as fitting in a float.

The following test case fails at -O and above on aarch64-linux-gnu
because of this:

extern void abort (void) __attribute__ ((noreturn));

double __attribute__ ((noinline, noclone))
foo (unsigned int x)
{
  return (double) (float) (x | 0xffff0000);
}

int
main ()
{
  if (foo (1) != 0x1.fffep31)
    abort ();
  return 0;
}