[Bug fortran/67219] New: [6 Regression] Incorrect conversion warning

["Joost.VandeVondele at mat dot ethz.ch" <gcc-bugzilla@gcc.gnu.org>]

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

            Bug ID: 67219
           Summary: [6 Regression] Incorrect conversion warning
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: Joost.VandeVondele at mat dot ethz.ch
  Target Milestone: ---

The following testcase leads to an incorrect conversion warning (and a failed
CP2K build) with gcc 6.0, while 5.1 compiles fine

> cat bug.f90
MODULE kinds
  IMPLICIT NONE
  INTEGER, PARAMETER :: int_4 = SELECTED_INT_KIND(5)
  INTEGER, PARAMETER :: int_8 = SELECTED_INT_KIND(10)
  INTEGER, PARAMETER :: valt = int_8
END MODULE
MODULE foo
  USE kinds
  IMPLICIT NONE
CONTAINS
  ELEMENTAL FUNCTION kg_get_value(dsat, degree) RESULT(value)
    INTEGER, INTENT(IN)                      :: dsat, degree
    INTEGER(KIND=valt)                       :: value
    INTEGER, PARAMETER                       :: huge_4 = HUGE(0_int_4)
    value = (huge_4 - INT(dsat,KIND=int_8)) * huge_4 + huge_4-degree
  END FUNCTION
END MODULE

> gfortran -c -Wconversion -Werror bug.f90
bug.f90:14:56:

     INTEGER, PARAMETER                       :: huge_4 = HUGE(0_int_4)
                                                        1
Error: Change of value in conversion from ‘INTEGER(4)’ to ‘REAL(4)’ at (1)
[-Werror=conversion]
f951: all warnings being treated as errors

There are no REAL(4) in this statement, AFAICT.
>From gcc-bugs-return-494845-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 14 16:28:30 2015
Return-Path: <gcc-bugs-return-494845-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 84860 invoked by alias); 14 Aug 2015 16:28:30 -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 84820 invoked by uid 55); 14 Aug 2015 16:28:27 -0000
From: "joseph at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/61441] ARM aarch64 fails to quiet signaling NaN
Date: Fri, 14 Aug 2015 16:28:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
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: joseph at codesourcery dot com
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:
Message-ID: <bug-61441-4-7QyrB0l8Rh@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61441-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61441-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: 2015-08/txt/msg00987.txt.bz2
Content-length: 3805

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

--- Comment #7 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Fri, 14 Aug 2015, ssaraswati at gmail dot com wrote:

> --- Comment #6 from Sujoy <ssaraswati at gmail dot com> ---
> (In reply to joseph@codesourcery.com from comment #5)
> 
> > With -fno-signaling-nans we don't really care about the result value.
> 
> I am not sure about this. -fno-signaling-nans is default and the original issue
> mentions that "under default exception handling, any operation signaling an
> invalid operation exception and for which a floating-point result is to be
> delivered shall deliver a quiet NaN". If we have to honor the default exception
> handling case, we need to convert the sNaN to qNaN here. Let me know if I
> missed something.

With -fno-signaling-nans, signaling NaN representations are trap 
representations - the compiler can assume that nothing ever manipulated as 
a floating-point value has such a representation.  (It cannot assume 
anything about unions of floating-point and other types where the 
floating-point field is not accessed.  But 58416 is a bug even in the 
absence of -fsignaling-nans.)

> 1) -fno-trapping-math and -fno-signaling-nans
> 2) -ftrapping-math and -fno-signaling-nans (default)
> 3) -ftrapping-math and -fsignaling-nans
> 
> Here is my understanding -
> 
> For case 1, we can go ahead with optimizations that may remove operations that
> may lead to exceptions, as we don't care about them. Also, we convert sNaN to
> qNaN since -fno-signaling-nans is on.
> 
> For case 2, we can do the transformation like folding and they should convert
> sNaN to qNaN since -fno-signaling-nans is on.

In both these cases, we formally don't care about the result (but if 
folding, it still would seem odd to fold incorrectly, so may as well fold 
to a qNaN).

> > The *number* of exceptions isn't relevant, only the set raised at any 
> > point (e.g. function call) where the raised exceptions may be tested or 
> > modified; it's valid to change one nonzero number of times raising a given 
> > exception between two such points to a different nonzero number of times 
> > raising that exception.
> 
> Thanks for this information. Does this mean that the man page description of
> -fsignaling-nans is too restrictive? 

This point is nothing to do with -fsignaling-nans.  It's a simple matter 
of C11 F.9.1 paragraph 3, "This specification does not require support for 
trap handlers that maintain information about the order or count of 
floating-point exceptions...." (which TS 18661-1:2014, adding support for 
signaling NaNs, doesn't change).  But it's true that any references to a 
number of exceptions should make clear it's only referring to the 
distinction between zero and nonzero numbers.

> I was referring to the Annex F of C99 ISO IEC 9899 1999, it says -
> "An operation on constants that raises no floating-point exception can be
> folded during translation, except, if the state of the FENV_ACCESS pragma is
> ‘‘on’..."
> 
> What is the equivalent of checking FENV_ACCESS on within gcc?

-ftrapping-math -frounding-math (but as I noted, -ftrapping-math doesn't 
really cover everything it should for that purpose, and something that did 
might not be suitable for enabling by default).

> As for this issue, do you think modifying gcc to handle the default case would
> be the right start?

Local fixes for particular signaling NaNs issues seem reasonable (as in: 
if you fold an operation involving a signaling NaN, you may as well quiet 
it in the process, even though signaling NaNs aren't meant to occur in any 
mode where folding them is likely to be safe).
>From gcc-bugs-return-494846-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 14 16:30:14 2015
Return-Path: <gcc-bugs-return-494846-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 3364 invoked by alias); 14 Aug 2015 16:30: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 1651 invoked by uid 55); 14 Aug 2015 16:30:12 -0000
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/67133] [6 Regression] ICE at -Os and above on x86_64-linux-gnu in gimple_op, at gimple.h:2274
Date: Fri, 14 Aug 2015 16:30: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: 6.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mpolacek at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: mpolacek at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 6.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-67133-4-GXIa0L7bSK@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67133-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67133-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/msg00988.txt.bz2
Content-length: 621

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

--- Comment #25 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Author: mpolacek
Date: Fri Aug 14 16:29:38 2015
New Revision: 226896

URL: https://gcc.gnu.org/viewcvs?rev"6896&root=gcc&view=rev
Log:
        PR middle-end/67133
        * gimple.c (infer_nonnull_range_by_attribute): Check that the
        nonnull argument position is not outside function arguments.

        * gcc.dg/torture/pr67133.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/torture/pr67133.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/gimple.c
    trunk/gcc/testsuite/ChangeLog