From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10163 invoked by alias); 14 Aug 2015 15:55:29 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 10136 invoked by uid 48); 14 Aug 2015 15:55:27 -0000 From: "Joost.VandeVondele at mat dot ethz.ch" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/67219] New: [6 Regression] Incorrect conversion warning Date: Fri, 14 Aug 2015 15:55:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 6.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: Joost.VandeVondele at mat dot ethz.ch X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: 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/msg00986.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D67219 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 fail= ed CP2K build) with gcc 6.0, while 5.1 compiles fine > cat bug.f90 MODULE kinds IMPLICIT NONE INTEGER, PARAMETER :: int_4 =3D SELECTED_INT_KIND(5) INTEGER, PARAMETER :: int_8 =3D SELECTED_INT_KIND(10) INTEGER, PARAMETER :: valt =3D 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=3Dvalt) :: value INTEGER, PARAMETER :: huge_4 =3D HUGE(0_int_4) value =3D (huge_4 - INT(dsat,KIND=3Dint_8)) * huge_4 + huge_4-degree END FUNCTION END MODULE > gfortran -c -Wconversion -Werror bug.f90 bug.f90:14:56: INTEGER, PARAMETER :: huge_4 =3D HUGE(0_int_4) 1 Error: Change of value in conversion from =E2=80=98INTEGER(4)=E2=80=99 to = =E2=80=98REAL(4)=E2=80=99 at (1) [-Werror=3Dconversion] 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: 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: List-Archive: List-Post: List-Help: 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" 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: In-Reply-To: References: 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=3D61441 --- Comment #7 from joseph at codesourcery dot com --- On Fri, 14 Aug 2015, ssaraswati at gmail dot com wrote: > --- Comment #6 from Sujoy --- > (In reply to joseph@codesourcery.com from comment #5) >=20 > > With -fno-signaling-nans we don't really care about the result value. >=20 > 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 exc= eption > 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=20 representations - the compiler can assume that nothing ever manipulated as= =20 a floating-point value has such a representation. (It cannot assume=20 anything about unions of floating-point and other types where the=20 floating-point field is not accessed. But 58416 is a bug even in the=20 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 >=20 > Here is my understanding - >=20 > 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 sNa= N to > qNaN since -fno-signaling-nans is on. >=20 > For case 2, we can do the transformation like folding and they should con= vert > sNaN to qNaN since -fno-signaling-nans is on. In both these cases, we formally don't care about the result (but if=20 folding, it still would seem odd to fold incorrectly, so may as well fold=20 to a qNaN). > > The *number* of exceptions isn't relevant, only the set raised at any=20 > > point (e.g. function call) where the raised exceptions may be tested or= =20 > > modified; it's valid to change one nonzero number of times raising a gi= ven=20 > > exception between two such points to a different nonzero number of time= s=20 > > raising that exception. >=20 > Thanks for this information. Does this mean that the man page description= of > -fsignaling-nans is too restrictive?=20 This point is nothing to do with -fsignaling-nans. It's a simple matter=20 of C11 F.9.1 paragraph 3, "This specification does not require support for= =20 trap handlers that maintain information about the order or count of=20 floating-point exceptions...." (which TS 18661-1:2014, adding support for=20 signaling NaNs, doesn't change). But it's true that any references to a=20 number of exceptions should make clear it's only referring to the=20 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 > =E2=80=98=E2=80=98on=E2=80=99..." >=20 > What is the equivalent of checking FENV_ACCESS on within gcc? -ftrapping-math -frounding-math (but as I noted, -ftrapping-math doesn't=20 really cover everything it should for that purpose, and something that did= =20 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:=20 if you fold an operation involving a signaling NaN, you may as well quiet=20 it in the process, even though signaling NaNs aren't meant to occur in any= =20 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: 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: List-Archive: List-Post: List-Help: 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" 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: In-Reply-To: References: 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?id=67133 --- Comment #25 from Marek Polacek --- Author: mpolacek Date: Fri Aug 14 16:29:38 2015 New Revision: 226896 URL: https://gcc.gnu.org/viewcvs?rev=226896&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