Re: New signaling NaN causes 12 testsuite failures

On Mon, Jan 24, 2022 at 04:44:53PM -0800, Steve Kargl wrote: > % gmake check-fortran RUNTESTFLAGS="ieee.exp=sign\*" > Line 42 of signal_1.f90 looks wrong unless the line is testing conversion on assignment. Should y be x? Instrumented signal_1.f90. Changed if (ieee_class(z) /= ieee_signa

New signaling NaN causes 12 testsuite failures

ution test === gfortran Summary === # of expected passes12 # of unexpected failures12 # of unsupported tests 6 /usr/home/sgk/gcc/objx/gcc/gfortran version 12.0.1 20220124 (experimental) (GCC) -- Steve

Re: [PATCH] Fortran: detect signaling NaNs on targets without issignaling macro in libc

> Yes, it does. > > (There is also some leeway granted to non-release-critical languages > like Fortran. RM approval is only needed once a branch has been > frozen). Thanks Thomas. Pushed: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e89d0befe3ec3238fca6de2cb078eb403b8c7e99 I’m hoping my use

[PATCH] PR fortran/104212 - ICE in transformational_result, at fortran/simplify.cc:466

Dear Fortranners, we lacked a check on the optional DIM argument of the intrinsics PARITY (see pr) and NORM2 (found by scanning check.cc) to verify that it is scalar. I intend to commit the attached fix within 48 hours as obvious unless there are comments. Regtested on x86_64-pc-linux-gnu. Than

Re: [PATCH] Fortran: detect signaling NaNs on targets without issignaling macro in libc

On 24.01.22 15:23, FX via Fortran wrote: Then it’s OK to commit for me, but you will need approval from release managers at this stage. Hum… I submitted it before stage 4 started, does that count? Yes, it does. (There is also some leeway granted to non-release-critical languages like Fortran

Re: FINAL subroutines

Thanks a lot (yes, I suspected both gfortran and intel were wrong, precisely because I could see why you'd need two FINAL calls, but not three). Salvatore On Mon, Jan 24, 2022 at 4:45 PM Andrew Benson wrote: > Hi Salvatore, > > This looks like it's related to some of the missing finalization >

Re: FINAL subroutines

Hi Salvatore, This looks like it's related to some of the missing finalization functionality (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336). Paul has some patches (e.g. https://gcc.gnu.org/pipermail/fortran/2022-January/057415.html) which implement most of the missing functionality. With

Re: FINAL subroutines

And here is the code embedded as text sorry about sending an attachment that was purged - testfinal.f90 - module test_type_mod type :: my_test_type integer, allocatable :: i contains final :: delete_test_type end type my_test_t

Re: [PATCH] Fortran: detect signaling NaNs on targets without issignaling macro in libc

> Then it’s OK to commit for me, but you will need approval from release > managers at this stage. Hum… I submitted it before stage 4 started, does that count? FX

FINAL subroutines

Hi all The attached code compiles and runs fine under both GNU and Intel, but it produces different results, in particular the FINAL subroutine is invoked just once with GNU, three times with Intel. It seems to me that they cannot both be right; I am not sure what the standard is mandating in this

Re: [PATCH] [gfortran] Add support for allocate clause (OpenMP 5.0).

On 24/01/2022 08:45, Tobias Burnus wrote: > On 21.01.22 18:43, Tobias Burnus wrote: >> On 21.01.22 18:15, Thomas Schwinge wrote: >>>     11 | integer(c_int) function is_64bit_aligned (a) bind(C) >>> Warning: Variable ‘a’ at (1) is a dummy argument of the BIND(C) >>> procedure ‘is_64bi

Re: [PATCH] [gfortran] Add support for allocate clause (OpenMP 5.0).

On 21.01.22 18:43, Tobias Burnus wrote: On 21.01.22 18:15, Thomas Schwinge wrote: 11 | integer(c_int) function is_64bit_aligned (a) bind(C) Warning: Variable ‘a’ at (1) is a dummy argument of the BIND(C) procedure ‘is_64bit_aligned’ but may not be C interoperable [-Wc-binding-ty