public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/67219] New: [6 Regression] Incorrect conversion warning
@ 2015-08-14 15:55 Joost.VandeVondele at mat dot ethz.ch
2015-08-14 16:59 ` [Bug fortran/67219] " kargl at gcc dot gnu.org
` (5 more replies)
0 siblings, 6 replies; 7+ messages in thread
From: Joost.VandeVondele at mat dot ethz.ch @ 2015-08-14 15:55 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/67219] [6 Regression] Incorrect conversion warning
2015-08-14 15:55 [Bug fortran/67219] New: [6 Regression] Incorrect conversion warning Joost.VandeVondele at mat dot ethz.ch
@ 2015-08-14 16:59 ` kargl at gcc dot gnu.org
2015-08-15 12:10 ` dominiq at lps dot ens.fr
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: kargl at gcc dot gnu.org @ 2015-08-14 16:59 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/67219] [6 Regression] Incorrect conversion warning
2015-08-14 15:55 [Bug fortran/67219] New: [6 Regression] Incorrect conversion warning Joost.VandeVondele at mat dot ethz.ch
2015-08-14 16:59 ` [Bug fortran/67219] " kargl at gcc dot gnu.org
@ 2015-08-15 12:10 ` dominiq at lps dot ens.fr
2015-08-17 7:31 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: dominiq at lps dot ens.fr @ 2015-08-15 12:10 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/67219] [6 Regression] Incorrect conversion warning
2015-08-14 15:55 [Bug fortran/67219] New: [6 Regression] Incorrect conversion warning Joost.VandeVondele at mat dot ethz.ch
2015-08-14 16:59 ` [Bug fortran/67219] " kargl at gcc dot gnu.org
2015-08-15 12:10 ` dominiq at lps dot ens.fr
@ 2015-08-17 7:31 ` rguenth at gcc dot gnu.org
2015-08-30 9:58 ` tkoenig at gcc dot gnu.org
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-08-17 7:31 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/67219] [6 Regression] Incorrect conversion warning
2015-08-14 15:55 [Bug fortran/67219] New: [6 Regression] Incorrect conversion warning Joost.VandeVondele at mat dot ethz.ch
` (2 preceding siblings ...)
2015-08-17 7:31 ` rguenth at gcc dot gnu.org
@ 2015-08-30 9:58 ` tkoenig at gcc dot gnu.org
2015-08-30 19:16 ` tkoenig at gcc dot gnu.org
2015-10-16 8:34 ` rguenth at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2015-08-30 9:58 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/67219] [6 Regression] Incorrect conversion warning
2015-08-14 15:55 [Bug fortran/67219] New: [6 Regression] Incorrect conversion warning Joost.VandeVondele at mat dot ethz.ch
` (3 preceding siblings ...)
2015-08-30 9:58 ` tkoenig at gcc dot gnu.org
@ 2015-08-30 19:16 ` tkoenig at gcc dot gnu.org
2015-10-16 8:34 ` rguenth at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2015-08-30 19:16 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/67219] [6 Regression] Incorrect conversion warning
2015-08-14 15:55 [Bug fortran/67219] New: [6 Regression] Incorrect conversion warning Joost.VandeVondele at mat dot ethz.ch
` (4 preceding siblings ...)
2015-08-30 19:16 ` tkoenig at gcc dot gnu.org
@ 2015-10-16 8:34 ` rguenth at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-10-16 8:34 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-10-16 8:34 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-08-14 15:55 [Bug fortran/67219] New: [6 Regression] Incorrect conversion warning Joost.VandeVondele at mat dot ethz.ch
2015-08-14 16:59 ` [Bug fortran/67219] " kargl at gcc dot gnu.org
2015-08-15 12:10 ` dominiq at lps dot ens.fr
2015-08-17 7:31 ` rguenth at gcc dot gnu.org
2015-08-30 9:58 ` tkoenig at gcc dot gnu.org
2015-08-30 19:16 ` tkoenig at gcc dot gnu.org
2015-10-16 8:34 ` rguenth at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).