From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E272E385E009; Fri, 27 Mar 2020 10:50:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E272E385E009 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1585306247; bh=jeeUYAdCiR8JJmSa/kvpjhSMCX1FE5CPxy84SriyrCk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=WnMk0KpFVbj5/wOThL+JztcbdCLsqQqE5DNcaVtVU2NEL1R5r13Jx+sfcUJ+u5isH 5MsK6qCyw5YhR8j6Yr9yOEOMR0VDz2BF0Yghhr3YO/te0ZUFoQ/3vlDOgPPVyhxJbh mGuVfU3EC+LVri+0HhmoP+1W6JKs2YBda70MVYXc= From: "burnus at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/94324] [10 regression] gfortran.dg/default_format_1.f90 etc. FAIL on 32-bit Solaris/x86 Date: Fri, 27 Mar 2020 10:50:47 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: burnus at gcc dot gnu.org 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: 10.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 10:50:48 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94324 Tobias Burnus changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |burnus at gcc dot gnu.org, | |jvdelisle at gcc dot gnu.o= rg, | |tkoenig at gcc dot gnu.org --- Comment #1 from Tobias Burnus --- (In reply to Rainer Orth from comment #0) > I just remembered that between 20191031 (r277679) and 20191101 (r277705) a > couple of Fortran tests regressed on 32-bit Solaris/x86: Hmm, that's odd. If I look at this range, there was no libgfortran change a= nd under gcc/ only an OpenMP change and gcc/config/aarch64. > However, given that I know nothing about fortran, it would be very helpful > to have some guidance on where to look. I hope the following notes help. * * * > +FAIL: gfortran.dg/default_format_1.f90 -O0 execution test This test is rather old (Feb 2018) =E2=80=94 however, there were changes re= cently, especially to the "g0" output. > Note: The following floating-point exceptions are signalling: > IEEE_UNDERFLOW_FLAG > STOP 6 if (test (1.0_8, 0) /=3D 0) STOP 6 Here, 1.0 (double-prevision) is run as: do i =3D 0, count write (s,*) x read (s,*) y if (y /=3D x) res =3D res + 1 x =3D nearest(x,huge(x)) end do Namely: the variable is written out (with default output precision) into the string "s" and read-in again. =E2=80=93 The test passes if the written-rea= d variable and the original variable compare equal. For count=3D200 steps, the same is repeated for the next higher variable [nearest() =3D POSIX's nextafter()]. =E2=80=93 Seemingly, one of those fail= s. Suggestion: Add (after the "read"): print *, i, s, x =3D=3D y print *, x print *, y and - to stop directly after the first fail - if (y /=3D x) stop and have a look at the output. * * * > +FAIL: gfortran.dg/fmt_g0_1.f08 -O0 execution test > STOP 3 >=20 > #2 0x0805143d in MAIN__ () > at /vol/gcc/src/hg/master/local/gcc/testsuite/gfortran.dg/fmt_g0_1.f0= 8:11 > 11 if (buffer.ne.":0.33333333333333331:") STOP 3 > (gdb) p buffer > $1 =3D ':0.', '3' , '2:', ' ' This is also an older test (Feb 2018). write(buffer, string) ':',1.0_8/3.0_8,':' if (buffer.ne.":0.33333333333333331:") STOP 3 This test case writes a ':' + 1./3. in double-precision + ':' to buffer. For each input, "g0" is used. The expected output is ':' followed by the printed number + ':' (plus paddi= ng by spaces on the right). The assumption is=20 ":0.33333333333333331:" - this output ":0.33333333333333332:" - you get which also sounds fine. =E2=80=94 I don't know whether it has to be '1' or = whether '2' is acceptable as well, one would have to look at the bit representation. I personally would be fine to accept ...2 as well. @ Jerry + Thomas: What do you think? * * * > +FAIL: gfortran.dg/round_4.f90 -Os execution test > STOP 15 ref10u =3D 0.1000000000000000000014_xp round =3D 'nearest' call t() if (rnd10 .and. (r10p /=3D ref10u .or. r10m /=3D -ref10u)) STOP 15 which does: str =3D "0.1 0.1 0.1 0.1" read (str, *,round=3Dround) r4p, r8p, r10p, r16p str =3D "-0.1 -0.1 -0.1 -0.1" read (str, *,round=3Dround) r4m, r8m, r10m, r16m Namely, the string '0.1' and '-0.1' is read in as 80-bit floating type ("lo= ng double", x87 floating-type number.) [Or actually: it a this if both 80 bit and 128 bit floating-point numbers a= re available; otherweise it is either a 32bit (non available) or 64bit (either available) number. But as the previous test passes, I assume that it is a 8= 0bit number in you case.] 0.1 is not representable in binary floating-point numbers and round=3D"near= est" means: "the value resulting from conversion shall be the closer of the two nearest representable values if one is closer than the other. If the two nearest representable values are equidistant from the original value, it is9process= or dependent which one of them is chosen." The code assume that '0.1' becomes 0.1000000000000000000014 '-0.1' becomes -0.1000000000000000000014 while you get: 0.100000000000000005551 -0.100000000000000005551 this number is suspiciously close to the expected value for a 64bit floating-point number: 0.10000000000000001 Thus, either 80bit FP numbers are not properly supported or the output of 80bit FP numbers does not work. However, the reference value could properly be stored, hmm. > #2 0x08051f41 in MAIN__ () > at /vol/gcc/src/hg/master/local/gcc/testsuite/gfortran.dg/round_4.f90= :100 > 100 if (rnd10 .and. (r10p /=3D ref10u .or. r10m /=3D -ref10u)) STOP 15 >=20 > (gdb) p rnd10 > $1 =3D .TRUE. > (gdb) p r10p > $2 =3D 0.100000000000000005551 > (gdb) p ref10u > $3 =3D 0.100000000000000000001 > (gdb) p r10m > $4 =3D -0.100000000000000005551 > (gdb) p ref10u > $5 =3D 0.100000000000000000001=