From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id D7352385C400; Fri, 30 Sep 2022 12:42:25 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D7352385C400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1664541745;
	bh=iqvO44voxkCEc2pwvM5Z//WXibFpEonf6yPxW2siStM=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=URlBnpQ3/Do5iHHGRz7v9R2R6ZByta7Ubs9aYfwBVM9dClx3nZmKvHXc4KzDdcQxl
	 9YafYaiUOkQaWnzZAX1Z59FZ0xkj85kIdS0+m29/1vzjgSWXk0fDYBHHeH2HpM1WqL
	 3IcWf5VKFYww/N5wW4dQU9EBcInafX2i3ezQLkUA=
From: "rearnsha at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/107071] gfortran.dg/ieee/modes_1.f90 fails on
 aarch64-linux
Date: Fri, 30 Sep 2022 12:42:16 +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: 13.0
X-Bugzilla-Keywords: testsuite-fail
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rearnsha at gcc dot gnu.org
X-Bugzilla-Status: NEW
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-107071-4-sTWnoE32us@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-107071-4@http.gcc.gnu.org/bugzilla/>
References: <bug-107071-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
List-Id: <gcc-bugs.sourceware.org>

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

--- Comment #8 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
(In reply to Francois-Xavier Coudert from comment #7)
> @Richard The test in gfortran.dg/ieee/modes_1.f90 is not doing that. It is
> checking that the floating-point modes (rounding mode, underflow mode, and
> halting modes) can be set and restored. It is not actually performing any=
 FP
> operation at all.

This is to do with the trapping, though, isn't it?  The failing test is try=
ing
to test the halting mode setting and restoration.  The code is currently
assuming that because the flag bit exists, it can set and restore it, but
although the bit is defined in the architecture, on some (most) implementat=
ions
it's RAZ/WI (read-as-zero, write-ignored).  So the code that assumes this g=
oes
wrong.

I might be slightly on the wrong lines here, but in the glibc fp support we
have

int
support_fpu_trap (int flag)
{
  return support_fpu_flag (flag);
}

So we're immediately assuming that if we have the flag, we can support the
trap.  And of course, support_fpu_flag only tests that the relevant flag bi=
t is
defined, not if the HW supports changing it.=