[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zimmerma+gcc at loria dot
                   |                            |fr

--- Comment #17 from Paolo Carlini <paolo.carlini at oracle dot com> 2010-10-26 10:32:24 UTC ---
*** Bug 46180 has been marked as a duplicate of this bug. ***

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cck0011 at yahoo dot com

--- Comment #18 from Andrew Pinski <pinskia at gcc dot gnu.org> 2011-02-08 01:58:40 UTC ---
*** Bug 47617 has been marked as a duplicate of this bug. ***

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |frederic.riss at gmail dot
                   |                            |com

--- Comment #19 from Andrew Pinski <pinskia at gcc dot gnu.org> 2011-04-01 19:22:05 UTC ---
*** Bug 48295 has been marked as a duplicate of this bug. ***

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[nmm1 at cam dot ac.uk]

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

Nick Maclaren <nmm1 at cam dot ac.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nmm1 at cam dot ac.uk

--- Comment #20 from Nick Maclaren <nmm1 at cam dot ac.uk> ---
Richard Biener's approach to the default is the one that matches the C
standard and Vincent Lefèvre is mistaken.  C11 7.6.1p2 says:

"... If part of a program tests floating-point status flags, sets
floating-point control modes, or runs under non-default mode settings,
but was translated with the state for the FENV_ACCESS pragma ‘‘off’’,
the behavior is undefined.  The default state (‘‘on’’ or ‘‘off’’) for
the pragma is implementation-defined."  Defining it to be 'off' and
not setting __STDC_IEC_559__ is very reasonable.

Because generated code and the library are potentially dependent on the
rounding mode (including even floating point to integer conversion!),
the default should remain that rounding mode support is off until each
target has been thoroughly checked that it does NOT break.

There are also very strong grounds for not wanting IEEE 754 support by
default, anyway, because of the performance impact and because a lot of
programs won't reset the state before calling external functions (and
hence may well give wrong answers).  That is especially true if the code
is used within a C++ program or uses GPUs or some SIMD units - let alone
OpenMP :-(
>From gcc-bugs-return-434259-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Nov 11 09:38:51 2013
Return-Path: <gcc-bugs-return-434259-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 27811 invoked by alias); 11 Nov 2013 09:38:50 -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 27032 invoked by uid 55); 11 Nov 2013 09:38:18 -0000
From: "ramana at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/58854] [4.8 regression] "sub sp, fp, #40" hoisted above frame accesses
Date: Mon, 11 Nov 2013 09:38:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ramana at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: ramana at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-58854-4-8OyIFcT5Gv@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58854-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58854-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: 2013-11/txt/msg01036.txt.bz2
Content-length: 665

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

--- Comment #8 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
Author: ramana
Date: Mon Nov 11 09:38:14 2013
New Revision: 204665

URL: http://gcc.gnu.org/viewcvs?rev 4665&root=gcc&view=rev
Log:
Backport fix for PR target/58854

2013-11-11  Ramana Radhakrishnan  <ramana.radhakrishnan@arm.com>

       Backported from mainline
        2013-10-30  Ramana Radhakrishnan  <ramana.radhakrishnan@arm.com>

       PR target/58854
       * config/arm/arm.c (arm_expand_epilogue_apcs_frame): Emit blockage


Modified:
    branches/gcc-4_8-branch/gcc/ChangeLog
    branches/gcc-4_8-branch/gcc/config/arm/arm.c

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[vincent-gcc at vinc17 dot net]

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

--- Comment #21 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Nick Maclaren from comment #20)
> Richard Biener's approach to the default is the one that matches the C
> standard and Vincent Lefèvre is mistaken.

No, I'm correct.

> Defining it to be 'off' and not setting __STDC_IEC_559__ is very reasonable.

No, this is really stupid. If the user *decides* to set the STDC FENV_ACCESS
pragma to "on", then the compiler must not assume that it is "off" (this bug is
not about the default state). At least it must behave in this way if -std=c99
(or c11) has been used. Otherwise a compilation failure may be better than
getting wrong results.
>From gcc-bugs-return-434280-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Nov 11 13:58:52 2013
Return-Path: <gcc-bugs-return-434280-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25117 invoked by alias); 11 Nov 2013 13:58:51 -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 24899 invoked by uid 48); 11 Nov 2013 13:58:46 -0000
From: "glisse at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/59077] New: ipa-pure-const.c (better_state): comment and code mistmatch
Date: Mon, 11 Nov 2013 13:58:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: glisse at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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
Message-ID: <bug-59077-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: 2013-11/txt/msg01057.txt.bz2
Content-length: 1112

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

            Bug ID: 59077
           Summary: ipa-pure-const.c (better_state): comment and code
                    mistmatch
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: glisse at gcc dot gnu.org

Doc and prototype for function better_state in ipa-pure-const.c:

/* Merge STATE and STATE2 and LOOPING and LOOPING2 and store
   into STATE and LOOPING better of the two variants.
   Be sure to merge looping correctly.  IPA_NEITHER functions
   have looping 0 even if they don't have to return.  */

static inline void
better_state (enum pure_const_state_e *state, bool *looping,
              enum pure_const_state_e state2, bool looping2)

But if you read the code, nothing ever writes to state. I am looking at this
file for the first time, so I don't know if it is missing:
*state = MIN (*state, state2);
at the end or if the comment is wrong or something else.

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[joseph at codesourcery dot com]

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

--- Comment #22 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Mon, 11 Nov 2013, nmm1 at cam dot ac.uk wrote:

> There are also very strong grounds for not wanting IEEE 754 support by
> default, anyway, because of the performance impact and because a lot of
> programs won't reset the state before calling external functions (and
> hence may well give wrong answers).  That is especially true if the code
> is used within a C++ program or uses GPUs or some SIMD units - let alone
> OpenMP :-(

Note also that the documented default is -ftrapping-math 
-fno-rounding-math.  I suspect that if -ftrapping-math actually 
implemented everything required for the floating-point exceptions aspects 
of FENV_ACCESS, it would be just as bad for optimization as 
-frounding-math - it would disallow constant-folding inexact 
floating-point expressions because that would eliminate the side effect of 
raising the "inexact" exception, for example (just as -frounding-math does 
disable such constant folding, although not in all cases it should, 
because the result depends on the rounding mode), and would mean a value 
computed before a function call can't be reused for the same computation 
after that call because the computation might raise exceptions that the 
function call could have cleared (just as -frounding-math should prevent 
such reuse because the call might change the rounding mode).

So a key part of actually making rounding modes and exceptions work 
reliably would be working out a definition of GCC's default mode that 
allows more or less the same optimizations as at present, while allowing 
users wanting the full support (and consequent optimization cost) to 
specify the appropriate command-line options or FENV_ACCESS pragma to 
enable it.

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[nmm1 at cam dot ac.uk]

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

--- Comment #23 from Nick Maclaren <nmm1 at cam dot ac.uk> ---
(In reply to Vincent Lefèvre from comment #21)
>
> > Richard Biener's approach to the default is the one that matches the C
> > standard and Vincent Lefèvre is mistaken.
> 
> No, I'm correct.
> 
> > Defining it to be 'off' and not setting __STDC_IEC_559__ is very reasonable.
> 
> No, this is really stupid. If the user *decides* to set the STDC FENV_ACCESS
> pragma to "on", then the compiler must not assume that it is "off" (this bug
> is not about the default state). At least it must behave in this way if
> -std=c99 (or c11) has been used. Otherwise a compilation failure may be
> better than getting wrong results.

If __STDC_IEC_559__ is unset or does not have the value 1, setting
STDC FENV_ACCESS to "on" is undefined behaviour (see 6.10.8.3, 7.6 and
Annex F), unless the implementation explicitly chooses to extend the
language to support it.  So the user would get what he so richly
deserves.


(In reply to joseph@codesourcery.com from comment #22)
> 
> So a key part of actually making rounding modes and exceptions work 
> reliably would be working out a definition of GCC's default mode that 
> allows more or less the same optimizations as at present, while allowing 
> users wanting the full support (and consequent optimization cost) to 
> specify the appropriate command-line options or FENV_ACCESS pragma to 
> enable it.

Yes.  That won't deal with the correctness problems of introducing
IEEE 754 support into code not set up to handle it, especially C++,
of course.  I tried to get WG21 to take a stand on that issue, but
failed :-(

Working out what on earth to do in such a case is likely to be a far
fouler task than merely dealing with the performance problems :-(
>From gcc-bugs-return-434297-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Nov 11 17:35:55 2013
Return-Path: <gcc-bugs-return-434297-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 28335 invoked by alias); 11 Nov 2013 17:35:55 -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 28226 invoked by uid 48); 11 Nov 2013 17:35:52 -0000
From: "tromey at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/59075] python pretty printer does not work at OS X
Date: Mon, 11 Nov 2013 17:35:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.6.4
X-Bugzilla-Keywords:
X-Bugzilla-Severity: trivial
X-Bugzilla-Who: tromey at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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:
Message-ID: <bug-59075-4-4XbkH44Mfs@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59075-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59075-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: 2013-11/txt/msg01074.txt.bz2
Content-length: 674

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

--- Comment #2 from Tom Tromey <tromey at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #1)
> Tom, do you know why this would be true on OS X?

Offhand I do not know.  I think there are a few things that
could help us find out, though.

One would be to see the gdb session.  This would tell us
which libstdc++ is being loaded.

Another would be to attach the executable to the bug,
assuming it is small enough (if too large -- write a minimal
reproducer and attach it).  Then I could look at the DWARF.

I'm also curious exactly what options were used to build
the executable.  This can matter sometimes.

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[vincent-gcc at vinc17 dot net]

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

--- Comment #24 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Nick Maclaren from comment #23)
> If __STDC_IEC_559__ is unset or does not have the value 1, setting
> STDC FENV_ACCESS to "on" is undefined behaviour (see 6.10.8.3, 7.6 and
> Annex F), unless the implementation explicitly chooses to extend the
> language to support it.

You're wrong. The C standard doesn't say that.

6.10.8.3 says: "__STDC_IEC_559__ The integer constant 1, intended to indicate
conformance to the specifications in annex F (IEC 60559 floating-point
arithmetic)." and nothing about STDC FENV_ACCESS.

In 7.6, only 7.6.1 is specifically about the FENV_ACCESS pragma, and it
specifies under which conditions the behavior is undefined, but nothing related
to __STDC_IEC_559__ and Annex F.

Annex F doesn't apply in the case __STDC_IEC_559__ is unset.
>From gcc-bugs-return-439939-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jan 10 11:45:55 2014
Return-Path: <gcc-bugs-return-439939-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 1214 invoked by alias); 10 Jan 2014 11:45:55 -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 1183 invoked by uid 48); 10 Jan 2014 11:45:52 -0000
From: "trippels at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/59755] BUG Increment Operator with Accessing Arrays
Date: Fri, 10 Jan 2014 11:45:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.8.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: trippels at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
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_status cc resolution
Message-ID: <bug-59755-4-kCmWqtJijL@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59755-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59755-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-01/txt/msg01081.txt.bz2
Content-length: 793

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

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |trippels at gcc dot gnu.org
         Resolution|---                         |INVALID

--- Comment #2 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
With -Wall one gets:
test.c: In function ‘main’:
test.c:12:14: warning: operation on ‘m’ may be undefined [-Wsequence-point]
  D = A[m][B[m++]];
              ^

Thus your testcase is invalid because of unsequenced modification
and access to m.
>From gcc-bugs-return-439940-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jan 10 11:58:00 2014
Return-Path: <gcc-bugs-return-439940-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 16718 invoked by alias); 10 Jan 2014 11:57:59 -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 16666 invoked by uid 48); 10 Jan 2014 11:57:55 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/59743] [4.9 Regression] ICE: Segmentation fault
Date: Fri, 10 Jan 2014 11:57: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-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: law at redhat dot com
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59743-4-snFuC6Dpbn@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59743-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59743-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: 2014-01/txt/msg01082.txt.bz2
Content-length: 464

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ah, there is:
  /* If the df_live problem is not defined, such as at -O0 and -O1, we
     still need to keep the luids up to date.  This is normally done
     in the df_live problem since this problem has a forwards
     scan.  */
  if (!df_live)
    df_recompute_luids (bb);
in df_lr_bb_local_compute, so I think luids are fine even at -O0/-O1.

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[vincent-gcc at vinc17 dot net]

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

--- Comment #26 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Nick Maclaren from comment #25)
> 3.4.3 says:
>     undefined behavior
>     behavior, upon use of a nonportable or erroneous program construct
>     or of erroneous data, for which this International Standard imposes
>     no requirements
> 
> 4. Conformance, paragraph 2, says:
>     ...  Undefined behavior is otherwise indicated in this International
>     Standard by the words "undefined behavior" or by the omission of any
>     explicit definition of behavior.  There is no difference in emphasis
>     among these three; they all describe "behavior that is undefined".
> 
> What "explicit definition of behavior" is there for the case when
> STDC FENV_ACCESS is set to "on" but __STDC_IEC_559__ is not set to one?

The behavior is defined. The standard says, e.g. for C99:

----
7.6.1 The FENV_ACCESS pragma

The FENV_ACCESS pragma provides a means to inform the implementation when a
program might access the floating-point environment to test floating-point
status flags or run under non-default floating-point control modes.184) [...]

184) The purpose of the FENV_ACCESS pragma is to allow certain optimizations
that could subvert flag tests and mode changes (e.g., global common
ubexpression elimination, code motion, and constant folding). In general, if
the state of FENV_ACCESS is ``off'', the translator can assume that default
modes are in effect and the flags are not tested.
----

And there is here no relation at all with __STDC_IEC_559__.

> As there is none, it is undefined behaviour.  gcc can therefore do
> whatever it likes.

No.
>From gcc-bugs-return-440329-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jan 14 15:06:52 2014
Return-Path: <gcc-bugs-return-440329-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7702 invoked by alias); 14 Jan 2014 15:06:52 -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 7582 invoked by uid 48); 14 Jan 2014 15:06:43 -0000
From: "ktkachov at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/59787] [ARM] mmx-2.c causes ICE when GCC is configured for cortex-a5/vfpv3-d16-fp16
Date: Tue, 14 Jan 2014 15:06:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ktkachov at gcc dot gnu.org
X-Bugzilla-Status: NEW
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_status cf_reconfirmed_on cc everconfirmed
Message-ID: <bug-59787-4-WGiUd32TjT@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59787-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59787-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: 2014-01/txt/msg01471.txt.bz2
Content-length: 647

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

ktkachov at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-01-14
                 CC|                            |ktkachov at gcc dot gnu.org,
                   |                            |vmakarov at redhat dot com
     Ever confirmed|0                           |1

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Adding Vlad to cc, since this seems to be an LRA ICE.

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[nmm1 at cam dot ac.uk]

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

--- Comment #27 from Nick Maclaren <nmm1 at cam dot ac.uk> ---
On Jan 14 2014, vincent-gcc at vinc17 dot net wrote:
>
>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
>
>> What "explicit definition of behavior" is there for the case when
>> STDC FENV_ACCESS is set to "on" but __STDC_IEC_559__ is not set to one?
>
>The behavior is defined. The standard says, e.g. for C99:
>
>7.6.1 The FENV_ACCESS pragma
>
>The FENV_ACCESS pragma provides a means to inform the implementation when a
>program might access the floating-point environment to test floating-point
>status flags or run under non-default floating-point control modes.

I suggest looking up the word "explicit" in a dictionary.

Unless __STDC_IEC_559__ is set to 1, what modes and flags exist (and,
even more importantly) what there semantics are) is at best implicit and
more realistically unspecified - see footnote 204 for a clear statement of
that.

Have you ever implemented a C system for an architecture with non-IEEE
arithmetic but with modes and flags?  Because I have, and I have used
several others.

>> As there is none, it is undefined behaviour.  gcc can therefore do
>> whatever it likes.
>
>No.

You are quite simply wrong.


Regards,
Nick Maclaren.

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[vincent-gcc at vinc17 dot net]

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

--- Comment #28 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Nick Maclaren from comment #27)
> On Jan 14 2014, vincent-gcc at vinc17 dot net wrote:
> >The FENV_ACCESS pragma provides a means to inform the implementation when a
> >program might access the floating-point environment to test floating-point
> >status flags or run under non-default floating-point control modes.
> 
> I suggest looking up the word "explicit" in a dictionary.

The above is an explicit definition. Where do you see an undefined behavior
here?

#include <fenv.h>
#pragma STDC FENV_ACCESS ON
int main (void)
{
  return 0;
}

The modes and so on are dealt with in other parts of the standard, e.g.

----
Each of the macros
        FE_DOWNWARD
        FE_TONEAREST
        FE_TOWARDZERO
        FE_UPWARD
is defined if and only if the implementation supports getting and setting the
represented rounding direction by means of the fegetround and fesetround
functions.
----

This doesn't mean that the rounding direction will necessarily be honored even
for the basic operations (just like the C standard doesn't require "1.0+2.0" to
evaluate as 3.0, and a poorly-designed implementation could decide that 1-bit
accuracy is OK), but honoring the rounding direction when the processor does[*]
is a reasonable QoI feature. Basically, this means: disabling some
optimizations when STDC FENV_ACCESS is set to ON. This is what this bug is
about.

[*] a weaker requirement than __STDC_IEC_559__ being set to 1.

Note that the C standard doesn't explicitly say how a source file as a sequence
of bytes is to be interpreted as a sequence of character, so that if you just
restrict to the C standard, everything is undefined. The discussion is going
nowhere.
>From gcc-bugs-return-440334-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jan 14 15:57:50 2014
Return-Path: <gcc-bugs-return-440334-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18811 invoked by alias); 14 Jan 2014 15:57:49 -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 18777 invoked by uid 48); 14 Jan 2014 15:57:46 -0000
From: "hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/59808] New: [4.9 Regression] r206596 caused: FAIL: gcc.target/i386/sse-14.c (test for excess errors)
Date: Tue, 14 Jan 2014 15:57:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hjl.tools at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
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 cc
Message-ID: <bug-59808-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: 2014-01/txt/msg01476.txt.bz2
Content-length: 602

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

            Bug ID: 59808
           Summary: [4.9 Regression] r206596 caused: FAIL:
                    gcc.target/i386/sse-14.c (test for excess errors)
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hjl.tools at gmail dot com
                CC: kirill.yukhin at intel dot com

On Linux/x86, r206596 caused:

FAIL: gcc.target/i386/sse-14.c (test for excess errors)

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[nmm1 at cam dot ac.uk]

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

--- Comment #29 from Nick Maclaren <nmm1 at cam dot ac.uk> ---
On Jan 14 2014, vincent-gcc at vinc17 dot net wrote:
>
>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
>
>> >The FENV_ACCESS pragma provides a means to inform the implementation whe
>n a
>> >program might access the floating-point environment to test floating-poi
>nt
>> >status flags or run under non-default floating-point control modes.
>
>> I suggest looking up the word "explicit" in a dictionary.
>
>The above is an explicit definition. Where do you see an undefined behavior
>here?

It is not an "explicit definition of BEHAVIOR" (my emphasis), and what
it implies for any nnon-IEEE system is completely unclear.  Of the two
countries active during the standardisation of C99, one voted "no" on
these grounds (among others).

>Note that the C standard doesn't explicitly say how a source file as a sequ
>ence
>of bytes is to be interpreted as a sequence of character, so that if you ju
>st
> restrict to the C standard, everything is undefined.

Yes, it does - it's implementation-defined in 5.1.1.2 Translation phases,
paragraph 1.1:

    Physical source file multibyte characters are mapped, in an
    implementation-defined manner, to the source character set
    (introducing new-line characters for end-of-line indicators) if
    necessary.  ...

You imply that you are also relying on some other standards or
specifications.  ISO/IEC Directives Part II is quite clear (in 6.2.2)
that they shall be referenced in the ISO standard.  Which ones are you
referring to and why?

If you are claiming that C99 and beyond support only systems that conform
to IEEE 754, then I can tell you that was not the intention of WG21 at
the time and is not a requirement of the standard.  To repeat, how many
other such systems are you familiar with?

The grounds that the UK voted "no" to this aspect was that the whole
'IEEE 754' morass (including "fenv.h") was neither dependent on
__STD_IEC_559__ nor implementation-dependent nor sufficiently explicit
to be interpreted on any non-IEEE system.

> The discussion is going nowhere.

Now, at least that is true.


Regards,
Nick Maclaren.

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[vincent-gcc at vinc17 dot net]

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

--- Comment #30 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Nick Maclaren from comment #29)
> It is not an "explicit definition of BEHAVIOR" (my emphasis),

The pragma is just a directive. It has no additional behavior, so that there is
nothing else to define.

> >Note that the C standard doesn't explicitly say how a source file as a sequence
> >of bytes is to be interpreted as a sequence of character, so that if you just
      ^^^^^
> > restrict to the C standard, everything is undefined.
> 
> Yes, it does - it's implementation-defined in 5.1.1.2 Translation phases,
> paragraph 1.1:
> 
>     Physical source file multibyte characters are mapped, in an
                           ^^^^^^^^^^^^^^^^^^^^
Read again. I'm talking of a sequence of bytes. What your quoting is about a
sequence of multibyte characters. The interpretation of the sequences of bytes
as a sequence of multibyte characters is not defined.

> You imply that you are also relying on some other standards or
> specifications.

Not other standards, just the implementation.
>From gcc-bugs-return-440368-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jan 14 23:20:15 2014
Return-Path: <gcc-bugs-return-440368-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 21373 invoked by alias); 14 Jan 2014 23:20: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 21325 invoked by uid 48); 14 Jan 2014 23:20:11 -0000
From: "dominiq at lps dot ens.fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libfortran/53962] Tab handling with formatted stream output
Date: Tue, 14 Jan 2014 23:20:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libfortran
X-Bugzilla-Version: 4.5.1
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: minor
X-Bugzilla-Who: dominiq at lps dot ens.fr
X-Bugzilla-Status: NEW
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_status cf_reconfirmed_on everconfirmed cf_known_to_fail
Message-ID: <bug-53962-4-QudW0VdouY@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-53962-4@http.gcc.gnu.org/bugzilla/>
References: <bug-53962-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: 2014-01/txt/msg01510.txt.bz2
Content-length: 572

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-01-14
     Ever confirmed|0                           |1
      Known to fail|                            |4.7.4, 4.8.2, 4.9.0

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Confirmed at r206590.

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[jackie.rosen at hushmail dot com]

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

Jackie Rosen <jackie.rosen at hushmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jackie.rosen at hushmail dot com

--- Comment #31 from Jackie Rosen <jackie.rosen at hushmail dot com> ---
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Marked for reference. Resolved as fixed @bugzilla.

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[vincent-gcc at vinc17 dot net]

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

--- Comment #43 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
Note that the effect of changing the rounding mode after a computation, whether
-frounding-math is used or not, is not just that the change of rounding mode
may not be honored. If can yield inconsistencies in a block where the rounding
mode is not changed.

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

#pragma STDC FENV_ACCESS ON

#define CST 0x1p-200

int main (void)
{
  volatile double a = CST;
  double b = a, c = a, d;
  printf ("%a\n", 1.0 - b);
  fesetround (FE_DOWNWARD);
  printf ("%a\n", 1.0 - c);

  if (b == c && b == CST && c == CST)
    {
      printf ("%d\n", 1.0 - b == 1.0 - c);
      printf ("1: %a\n", 1.0 - b);
      printf ("2: %a\n", 1.0 - c);
      d = b == CST ? b : (abort (), 1.0);
      printf ("3: %a\n", 1.0 - d);
      d = b == CST ? b : 1.0;
      printf ("4: %a\n", 1.0 - d);
    }

  return 0;
}

With -std=c17 -frounding-math -O3 -lm, I get:

0x1p+0
0x1.fffffffffffffp-1
0
1: 0x1p+0
2: 0x1.fffffffffffffp-1
3: 0x1p+0
4: 0x1.fffffffffffffp-1

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tkoenig at gcc dot gnu.org

--- Comment #44 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 108318 has been marked as a duplicate of this bug. ***

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=56020

--- Comment #45 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 56020 has been marked as a duplicate of this bug. ***

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[tkoenig at gcc dot gnu.org]

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

--- Comment #46 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
Fortran gets this right:

$ cat set_rounding_mode.f90
module x
  implicit none
  integer, parameter :: wp = selected_real_kind(15)
contains
  subroutine foo(a,b,c)
    use ieee_arithmetic
    real(kind=wp), dimension(4), intent(out) :: a
    real(kind=wp), intent(in) :: b, c
    type (ieee_round_type), dimension(4), parameter :: mode = &
         [ieee_nearest, ieee_to_zero, ieee_up, ieee_down]
    integer :: i
    do i=1,4
       call ieee_set_rounding_mode (mode(i))
       a(i) = b + c
    end do
  end subroutine foo
end module x

program main
  use x
  real(kind=wp), dimension(4) :: a
  call foo(a, 0.1_wp, 0.2_wp)
  print *,a
end program main
$ gfortran -O3 set_rounding_mode.f90
$ ./a.out
  0.30000000000000004       0.29999999999999999       0.30000000000000004      
0.29999999999999999

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |105105

--- Comment #47 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
(In reply to Thomas Koenig from comment #46)
> Fortran gets this right:

... but only by accident. This test case shows that it doesn't:

$ cat y.f90
module y
  implicit none
  integer, parameter :: wp = selected_real_kind(15)
contains
  subroutine foo(a,b,c)
    use ieee_arithmetic
    real(kind=wp), dimension(4), intent(out) :: a
    real(kind=wp), intent(in) :: b, c
    type (ieee_round_type), dimension(4), parameter :: mode = &
         [ieee_nearest, ieee_to_zero, ieee_up, ieee_down]
    call ieee_set_rounding_mode (mode(1))
    a(1) = b + c
    call ieee_set_rounding_mode (mode(2))
    a(2) = b + c
    call ieee_set_rounding_mode (mode(3))
    a(3) = b + c
    call ieee_set_rounding_mode (mode(4))
    a(4) = b + c
  end subroutine foo
end module y

program main
  use y
  real(kind=wp), dimension(4) :: a
  call foo(a, 0.1_wp, 0.2_wp)
  print *,a
end program main
$ gfortran -O  y.f90 && ./a.out
  0.30000000000000004       0.30000000000000004       0.30000000000000004      
0.30000000000000004     
$ gfortran y.f90 && ./a.out
  0.30000000000000004       0.29999999999999999       0.30000000000000004      
0.29999999999999999


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105105
[Bug 105105] [Meta] Fortran IEEE support

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[tkoenig at gcc dot gnu.org]

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

--- Comment #48 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
Clang gets this right, even without the pragma; the original test case is
compiled to

        pushq   %r14
        pushq   %rbx
        subq    $24, %rsp
        movq    %rsi, %r14
        movq    %rdi, %rbx
        movsd   %xmm1, 16(%rsp)                 # 8-byte Spill
        movsd   %xmm0, 8(%rsp)                  # 8-byte Spill
        movl    $1024, %edi                     # imm = 0x400
        callq   fesetround@PLT
        movsd   8(%rsp), %xmm0                  # 8-byte Reload
        divsd   16(%rsp), %xmm0                 # 8-byte Folded Reload
        movsd   %xmm0, (%rbx)
        movl    $2048, %edi                     # imm = 0x800
        callq   fesetround@PLT
        movsd   8(%rsp), %xmm0                  # 8-byte Reload
        divsd   16(%rsp), %xmm0                 # 8-byte Folded Reload
        movsd   %xmm0, (%r14)
        addq    $24, %rsp
        popq    %rbx
        popq    %r14
        retq

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[tkoenig at gcc dot gnu.org]

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

--- Comment #49 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
(In reply to Thomas Koenig from comment #48)
> Clang gets this right, even without the pragma;

The "even without the pragma" part is wrong.

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[vincent at vinc17 dot org]

------- Comment #16 from vincent at vinc17 dot org  2008-10-16 17:39 -------
I was suggesting to improve the behavior by having -frounding-math by default
(at least when the user compiles with -std=c99 -- if he does this, then this
means that he shows some interest in a conforming implementation). This is not
perfect, but would be better than the current behavior.


-- 


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

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[joseph at codesourcery dot com]

------- Comment #15 from joseph at codesourcery dot com  2008-10-16 16:39 -------
Subject: Re:  Optimization generates incorrect code
 with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

On Thu, 16 Oct 2008, vincent at vinc17 dot org wrote:

> The compiler should generate correct code by default, and options like

Sure, it generates correct code for the supported features, and 
<http://gcc.gnu.org/c99status.html>, which is linked from the manual, 
documents the state of support for the features: standard pragmas are 
documented as Missing and IEC 60559 support as Broken, with the 
explanation:

     * IEC 60559 is IEEE 754 floating point. This works if and only if
       the hardware is perfectly compliant, but GCC does not define
       __STDC_IEC_559__ or implement the associated standard pragmas; nor
       do some options such as -frounding-math to enable the pragmas
       globally work in all cases (for example, required exceptions may
       not be generated) and contracting expressions (e.g., using fused
       multiply-add) is not restricted to source-language expressions as
       required by C99.

So you are using features documented not to be fully implemented and 
whether they will work is unpredictable.


-- 


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

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[vincent at vinc17 dot org]

------- Comment #14 from vincent at vinc17 dot org  2008-10-16 14:20 -------
(In reply to comment #12)
> Turning -frounding-math on by default would be a disservice to (most of) our
> users which is why the decision was made (long ago) to not enable this by
> default.

The compiler should generate correct code by default, and options like
-funsafe-math-optimizations are there to allow the users to run the compiler in
a non-conforming mode. So, it would be wise to have -frounding-math by default
and add -fno-rounding-math to the options enabled by
-funsafe-math-optimizations.


-- 


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

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[merkert at comcast dot net]

------- Comment #13 from merkert at comcast dot net  2008-10-16 11:56 -------
Would it make sense to have a function attribute to indicate that rounding mode
was changed as a side effect? This way, one could keep the default rounding
behavior and not incur a performance penalty, but at the same time
setroundingmode would work as expected.


-- 


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

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[rguenth at gcc dot gnu dot org]

------- Comment #12 from rguenth at gcc dot gnu dot org  2008-10-16 09:44 -------
Turning -frounding-math on by default would be a disservice to (most of) our
users which is why the decision was made (long ago) to not enable this by
default.


-- 


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

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[vincent at vinc17 dot org]

------- Comment #11 from vincent at vinc17 dot org  2008-10-15 22:33 -------
(In reply to comment #10)
> The default of -fno-rounding-math is chosen with the reason that this is what
> a compiler can assume if #pragma STDC FENV_ACCESS is not turned on.

The C standard doesn't require a compiler to recognize the FENV_ACCESS pragma,
but if the compiler does not recognize it, then it must assume that this pragma
is ON (otherwise the generated code can be incorrect). That's why I suggested
that -frounding-math should be the default.


-- 


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

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[rguenth at gcc dot gnu dot org]

------- Comment #10 from rguenth at gcc dot gnu dot org  2008-10-15 22:14 -------
The default of -fno-rounding-math is chosen with the reason that this is what
a compiler can assume if #pragma STDC FENV_ACCESS is not turned on.

What you may request instead is an implementation of FENV_ACCESS up to that
point that we issue a fatal error whenever you try to turn it on.  Or at least
a warning by default.


-- 


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

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[vincent at vinc17 dot org]

------- Comment #9 from vincent at vinc17 dot org  2008-10-15 21:29 -------
What was said in bug 37838 but not here is that -frounding-math sometimes fixes
the problem. So, I was suggesting that -frounding-math should be enabled by
default.


-- 


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

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[rguenth at gcc dot gnu dot org]

------- Comment #8 from rguenth at gcc dot gnu dot org  2008-10-15 15:43 -------
*** Bug 37838 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vincent at vinc17 dot org


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

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[joseph at codesourcery dot com]

------- Comment #7 from joseph at codesourcery dot com  2008-01-06 16:28 -------
Subject: Re:  Optimization generates incorrect code
 with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

On Sun, 6 Jan 2008, rguenth at gcc dot gnu dot org wrote:

> I see.  So basically we need to split all floating point operators into two
> variants, one specifying a default rounding mode is used and one specifying the
> rounding mode is unknown.  I suppose the frontend parts would be actually quite
> simple then?

More than two variants, in the end, depending on how you handle all the 
other flags - but eventually, everything about GIMPLE semantics controlled 
by the global flags should be directly represented in the GIMPLE and the 
pragmas, together with the command-line options determining global 
defaults, would map to appropriate choices of operations / flags on those 
operations.  This is desirable for LTO optimizing between objects compiled 
with different options as well.


-- 


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

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[rguenth at gcc dot gnu dot org]

------- Comment #6 from rguenth at gcc dot gnu dot org  2008-01-06 15:57 -------
I see.  So basically we need to split all floating point operators into two
variants, one specifying a default rounding mode is used and one specifying the
rounding mode is unknown.  I suppose the frontend parts would be actually quite
simple then?


-- 


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

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[joseph at codesourcery dot com]

------- Comment #5 from joseph at codesourcery dot com  2008-01-06 15:12 -------
Subject: Re:  Optimization generates incorrect code
 with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

On Sat, 5 Jan 2008, rguenth at gcc dot gnu dot org wrote:

> I wouldn't read the language this way.  Because that will forcefully disable
> all redundancy removing optimizations (which is what happens in this testcase).
> What it currently guards is expression rewriting that changes the outcome if
> a rounding mode different than round-to-nearest is used.

My understanding has always been that -frounding-math should be usable for 
the code that calls rounding-mode-changing functions, rather than having 
no way to compile that code safely with GCC, as well as the code that does 
not call those functions but may execute with non-default rounding modes.  
The FENV_ACCESS pragma does not distinguish between the two.

> The finer-grained control the documentation mentions should not be globbed
> to -frounding-math IMHO.

The pragma would in effect set -frounding-math for particular regions of 
code; it isn't more fine-grained regarding whether the code sets the mode 
or merely runs under a different mode.

It is of course possible that -frounding-math should be split into 
multiple options (more fine-grained than the pragma) as the other related 
flags have been split over time.


-- 


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

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[rguenth at gcc dot gnu dot org]

------- Comment #4 from rguenth at gcc dot gnu dot org  2008-01-05 18:24 -------
I wouldn't read the language this way.  Because that will forcefully disable
all redundancy removing optimizations (which is what happens in this testcase).
What it currently guards is expression rewriting that changes the outcome if
a rounding mode different than round-to-nearest is used.

The finer-grained control the documentation mentions should not be globbed
to -frounding-math IMHO.


-- 


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

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[joseph at codesourcery dot com]

------- Comment #3 from joseph at codesourcery dot com  2008-01-05 17:07 -------
Subject: Re:  Optimization generates incorrect code
 with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

On Sat, 5 Jan 2008, rguenth at gcc dot gnu dot org wrote:

> Sorry, -frounding-math does not help for this case - it assumes the _same_
> rounding mode is in effect everywhere, but doesn't assume it is
> round-to-nearest.

To be clear: this is a bug in the present implementation of 
-frounding-math - it *should* disable all the assumptions of same rounding 
mode (unless it can prove that no function changing the rounding mode is 
called between the two places where it assumes the same mode), but, as 
documented in the manual, it's not yet fully implemented.

#   This option is experimental and does not currently guarantee to
#   disable all GCC optimizations that are affected by rounding mode.


-- 


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

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[merkert at comcast dot net]

------- Comment #2 from merkert at comcast dot net  2008-01-05 15:38 -------
Ok, so how then would one accomplish this in std c without resorting to asm? I
still assume the original code is correct even though the rounding-math doesn't
do what I wanted.

At any rate, I played a little with it and there was hint in the asm manual how
to do it. This seems to work for me, but I'm not sure I'm using the constraints
as efficiently as possible:

#include <fenv.h>

inline void reload(double* x)
{
  asm volatile ("" : "=m"(x) );
}

void xdiv (double x, double y, double* lo, double* hi)
{
  #pragma STDC FENV_ACCESS ON
  fesetround(FE_DOWNWARD);
  *lo = x/y;

  reload(&y);

  fesetround(FE_UPWARD);
  *hi = x/y;
}


-- 


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

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2008-01-05 11:19 -------
Sorry, -frounding-math does not help for this case - it assumes the _same_
rounding mode is in effect everywhere, but doesn't assume it is
round-to-nearest.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-01-05 11:19:52
               date|                            |
            Summary|Optimization generates      |Optimization generates
                   |incorrect code with -       |incorrect code with -
                   |frounding-math option       |frounding-math option
                   |                            |(#pragma STDC FENV_ACCESS
                   |                            |not implemented)


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