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

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

[Joost.VandeVondele at mat dot ethz.ch]

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

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

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-08-14
                 CC|                            |kargl at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from kargl at gcc dot gnu.org ---
This is a really weird bug.

This reduced test produces the error:

function foo(bar)
   integer(8)             :: foo
   integer(4), intent(in) :: bar
   integer(4), parameter  :: huge_4 = huge(0_4)
   foo = (huge_4 - int(bar,kind=8))
end function

This reduced test does not produce the error:

function foo(bar)
   integer(8)             :: foo
   integer(4), intent(in) :: bar
   integer(4), parameter  :: huge_4 = huge(0_4)
   foo = huge_4 - int(bar,kind=8)
end function


The only difference is the outer ( ) in the assignment
to foo.

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

[dominiq at lps dot ens.fr]

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

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

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

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
There is no warning with r224160, but I get it with r224647, likely r 224190.

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

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |6.0

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

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
The backtrace shows where this comes from:

#0  gfc_warning_now (opt=201, gmsgid=0x1437d10 "Change of value in conversion
from %qs to %qs at %L") at ../../trunk/gcc/fortran/error.c:1187
#1  0x000000000061a05d in gfc_int2real (src=0x1ea1de0, kind=4) at
../../trunk/gcc/fortran/arith.c:2079
#2  0x00000000006971b0 in match_sym_complex_part (result=0x7fffffffce60) at
../../trunk/gcc/fortran/primary.c:1286
#3  match_complex_part (result=0x7fffffffce60) at
../../trunk/gcc/fortran/primary.c:1311
#4  0x0000000000697262 in match_complex_constant
(result=result@entry=0x7fffffffd0f0) at ../../trunk/gcc/fortran/primary.c:1344
#5  0x0000000000697448 in gfc_match_literal_constant
(result=result@entry=0x7fffffffd0f0, signflag=signflag@entry=0)
    at ../../trunk/gcc/fortran/primary.c:1448
#6  0x0000000000675c33 in match_primary (result=0x7fffffffd0f0) at
../../trunk/gcc/fortran/matchexp.c:149
#7  match_level_1 (result=<synthetic pointer>) at
../../trunk/gcc/fortran/matchexp.c:211

Seems like the gfc_warning_now isn't appropriate here.  I will see what happens
when this is converted to gfc_warning.

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

[tkoenig at gcc dot gnu.org]

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

--- Comment #5 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
So, the problem is that if we have matched

( integer_const

but no comma after that.  When integer_const is converted, a warning is issued,
but the result is later discarded.

We probably need something like the error push/pop mechanism for warnings for
this.

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

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4