This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: more fortran test case(s)
- From: Steve Kargl <sgk at troutmask dot apl dot washington dot edu>
- To: "Davis, Jimmie" <jimmied at mail dot smu dot edu>
- Cc: "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 25 Nov 2010 09:03:18 -0800
- Subject: Re: more fortran test case(s)
- References: <00061D6890083E418784FC390A35E43701D49D@SXMB1PG.SYSTEMS.SMU.EDU>
On Sat, Nov 20, 2010 at 01:44:15AM +0000, Davis, Jimmie wrote:
> Here are two more test cases provided for the intent of increasing
> our test suite coverage.
>
> I think one of them points to a defect, while using the flag
> -fno-range-check we are creating an integer divide with a result
> of NaaN to be an error. real and complex in the same situation
> store the NaaN and go on. If someone agrees (perhaps who uses
> the -fno-range-check compiler option), I would be happy to open
> up a PR and submit the rather trivial patch.
>
Bud,
I think that there is ia fundamental difference here. A NaN for
real and complex can be naturally stored in the floating
representation, so continuing makes some sense. IEEE 754 also
defined arithmetic operations involving an NaN. For integer
divide by zero, there isn't a bit pattern available to
encode an integer NaN. I think that we do not need to do
anything special here with -fno-range-check. This option
already asks gfortran to violate the standard, so the user
should be prepared to get what gfortran generates.
--
Steve