On Fri, Aug 02, 2024 at 06:29:27PM +0200, Mikael Morin wrote:
> I agree with all of that. Sure keeping the condition around would be the
> safest. I'm just afraid of keeping code that would remain dead.
>
> > > > And the pasto fix would guess fix
> > > > aliasing_dummy_5.f90 with
> > > > a
Hi Jerry,
looks ok to me. Thanks for taking care.
- Andre
On Fri, 2 Aug 2024 10:44:58 -0700
Jerry D wrote:
> Hi all,
>
> Doing some catchup here. I plan to commit the following shortly. This is
> one of Steve's patches posted on bugzilla.
>
> I have created a new test case.
>
> Regression test
On Thu, Jul 25, 2024 at 4:47 PM FX Coudert wrote:
> Can you post an updated version of the patch, following the first round of
> review?
>
> FX
Sorry for a delay, done.
I dropped a change to the test file, since you have fixed it appropriately,
and switched to Apple libm convention for flags,
Le 05/08/2024 à 10:59, Jakub Jelinek a écrit :
On Fri, Aug 02, 2024 at 06:29:27PM +0200, Mikael Morin wrote:
I agree with all of that. Sure keeping the condition around would be the
safest. I'm just afraid of keeping code that would remain dead.
And the pasto fix would guess fix
aliasing_dum
Hi Mikael,
I had only a quick glance at this patch, but am a little concerned
about the tests involving nans.
E.g.:
+ subroutine check_all_nans()
+real, allocatable :: a(:,:,:)
+real :: nan
+integer, allocatable :: m(:)
+nan = 0
+nan = nan / nan
+allocate(a(3,3,3), sou
Hello,
Le 05/08/2024 à 21:25, Harald Anlauf a écrit :
Is there a reason you do not use the ieee intrinsic module way
to get a quiet nan? Otherwise, how do you prevent exceptions
to happen, possibly leading to a failing test?
(The test cases need a workaround to run with NAG).
indeed, I didn't
