Re: New signaling NaN causes 12 testsuite failures
On 25.01.22 21:56, FX via Fortran wrote: What I wonder is: if those conditions failed, then the struct they define should have been empty, and therefore the code shouldn’t compile anyway (that was the intent). Wouldn't it make more sense to add '#else' / '#error ""' in that case? Tobias - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
Re: New signaling NaN causes 12 testsuite failures
On Wed, Jan 26, 2022 at 11:47:27AM +0100, Tobias Burnus wrote: > On 25.01.22 21:56, FX via Fortran wrote: > > What I wonder is: if those conditions failed, then the struct they define > > should have been empty, and therefore the code shouldn’t compile anyway > > (that was the intent). > > Wouldn't it make more sense to add '#else' / '#error ""' in that case? > AFAICT, the first condition does not fail due to the missing trailing underscores. #if __FLOAT_WORD_ORDER == __BIG_ENDIAN becomes (I believe) #if 0 == 0 so FreeBSD was using big endian in FX's issignaling_fallback when it needed little endian. PS: Thanks FX for your patch! -- Steve
Re: New signaling NaN causes 12 testsuite failures
> AFAICT, the first condition does not fail due to the missing > trailing underscores. > > #if __FLOAT_WORD_ORDER == __BIG_ENDIAN > > becomes (I believe) > > #if 0 == 0 > > so FreeBSD was using big endian in FX's issignaling_fallback > when it needed little endian. Yeah that makes total sense. FX
[PATCH] PR fortran/84784 - ICEs: verify_gimple failed with -fdefault-integer-8
Dear Fortranners,
the use of -fdefault-integer-8 exhibits several cases where
we missed to convert the result of an intrinsic from the
declared to the effective resulting type.
The attached obvious patch fixes this for IMAGE_STATUS,
TEAM_NUMBER, and POPCNT/POPPAR.
OK for mainline if regtesting passes on x86_64-pc-linux-gnu?
Thanks,
Harald
From af5cb1f0ec1cacb47acc8c2b0c0629cf3808e1af Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 26 Jan 2022 21:50:41 +0100
Subject: [PATCH] Fortran: add missing conversions for result of intrinsics to
result type
gcc/fortran/ChangeLog:
PR fortran/84784
* trans-intrinsic.cc (conv_intrinsic_image_status): Convert result
to resulting (default) integer type.
(conv_intrinsic_team_number): Likewise.
(gfc_conv_intrinsic_popcnt_poppar): Likewise.
gcc/testsuite/ChangeLog:
PR fortran/84784
* gfortran.dg/pr84784.f90: New test.
---
gcc/fortran/trans-intrinsic.cc| 13 +++--
gcc/testsuite/gfortran.dg/pr84784.f90 | 22 ++
2 files changed, 29 insertions(+), 6 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/pr84784.f90
diff --git a/gcc/fortran/trans-intrinsic.cc b/gcc/fortran/trans-intrinsic.cc
index fccf0a9b229..da854fad89d 100644
--- a/gcc/fortran/trans-intrinsic.cc
+++ b/gcc/fortran/trans-intrinsic.cc
@@ -2620,7 +2620,7 @@ conv_intrinsic_image_status (gfc_se *se, gfc_expr *expr)
else
gcc_unreachable ();
- se->expr = tmp;
+ se->expr = fold_convert (gfc_get_int_type (gfc_default_integer_kind), tmp);
}
static void
@@ -2662,7 +2662,7 @@ conv_intrinsic_team_number (gfc_se *se, gfc_expr *expr)
else
gcc_unreachable ();
- se->expr = tmp;
+ se->expr = fold_convert (gfc_get_int_type (gfc_default_integer_kind), tmp);
}
@@ -7255,12 +7255,13 @@ gfc_conv_intrinsic_popcnt_poppar (gfc_se * se, gfc_expr *expr, int parity)
/* Combine the results. */
if (parity)
- se->expr = fold_build2_loc (input_location, BIT_XOR_EXPR, result_type,
-call1, call2);
+ se->expr = fold_build2_loc (input_location, BIT_XOR_EXPR,
+integer_type_node, call1, call2);
else
- se->expr = fold_build2_loc (input_location, PLUS_EXPR, result_type,
-call1, call2);
+ se->expr = fold_build2_loc (input_location, PLUS_EXPR,
+integer_type_node, call1, call2);
+ se->expr = convert (result_type, se->expr);
return;
}
diff --git a/gcc/testsuite/gfortran.dg/pr84784.f90 b/gcc/testsuite/gfortran.dg/pr84784.f90
new file mode 100644
index 000..48dd4dd4b0a
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr84784.f90
@@ -0,0 +1,22 @@
+! { dg-do compile }
+! { dg-options "-fcoarray=lib -fdefault-integer-8" }
+! { dg-require-effective-target fortran_integer_16 }
+! PR fortran/84784 - ICEs: verify_gimple failed with -fdefault-integer-8
+
+ use iso_fortran_env, only : team_type, STAT_FAILED_IMAGE
+ implicit none
+ type(team_type) :: team
+ integer :: new_team
+ new_team = mod(this_image(),2)+1
+ form team (new_team,team)
+change team (team)
+if (team_number() /= new_team) STOP 1
+ end team
+ if (image_status (1) == STAT_FAILED_IMAGE) ERROR STOP "cannot recover"
+ if (runtime_popcnt(0_16) /= 0) STOP 2
+contains
+ integer function runtime_popcnt (i)
+integer(kind=16), intent(in) :: i
+runtime_popcnt = popcnt(i)
+ end function
+end
--
2.31.1
Re: FINAL subroutines
Is there any reason these patches can not be applied and use this test as a test case? Regards, Jerry On 1/24/22 8:11 AM, Salvatore Filippone via Fortran wrote: 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 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 those patches incorporated your code gives the following output with gfortran: $ ./testfinal Allocating wrapper Calling new_outer_type Assigning outer%test_item Called delete_test_type End of new_outer_type DeAllocating wrapper Called delete_test_type So there is one more call to the finalizer than you found - I haven't checked carefully but I would guess this is a deallocation of LHS on assignment. In testing these patches using the Intel compiler we found that it seems to call the finalization wrapper more than it should, sometimes on objects that have already been deallocated. Your code, compiled with the Intel compiler and then run under valgrind shows the following: $ valgrind ./testfinal ==7340== Memcheck, a memory error detector ==7340== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==7340== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==7340== Command: ./testfinal ==7340== ==7340== Conditional jump or move depends on uninitialised value(s) ==7340==at 0x493A51: __intel_sse2_strcpy (in /home/abensonca/Scratch/ ifortTests/testfinal) ==7340==by 0x45D70E: for__add_to_lf_table (in /home/abensonca/Scratch/ ifortTests/testfinal) ==7340==by 0x4410CB: for__open_proc (in /home/abensonca/Scratch/ ifortTests/testfinal) ==7340==by 0x423A64: for__open_default (in /home/abensonca/Scratch/ ifortTests/testfinal) ==7340==by 0x4305A9: for_write_seq_lis (in /home/abensonca/Scratch/ ifortTests/testfinal) ==7340==by 0x4047E1: MAIN__ (testfinal.f90:62) ==7340==by 0x403CE1: main (in /home/abensonca/Scratch/ifortTests/ testfinal) ==7340== Allocating wrapper Calling new_outer_type Assigning outer%test_item Called delete_test_type ==7340== Conditional jump or move depends on uninitialised value(s) ==7340==at 0x40572A: do_alloc_copy (in /home/abensonca/Scratch/ifortTests/ testfinal) ==7340==by 0x406B9A: do_alloc_copy (in /home/abensonca/Scratch/ifortTests/ testfinal) ==7340==by 0x4084ED: for_alloc_assign_v2 (in /home/abensonca/Scratch/ ifortTests/testfinal) ==7340==by 0x404474: target_mod_mp_new_outer_type_ (testfinal.f90:48) ==7340==by 0x40485E: MAIN__ (testfinal.f90:65) ==7340==by 0x403CE1: main (in /home/abensonca/Scratch/ifortTests/ testfinal) ==7340== Called delete_test_type End of new_outer_type DeAllocating wrapper Called delete_test_type ==7340== ==7340== HEAP SUMMARY: ==7340== in use at exit: 48 bytes in 1 blocks ==7340== total heap usage: 14 allocs, 13 frees, 12,879 bytes allocated ==7340== ==7340== LEAK SUMMARY: ==7340==definitely lost: 48 bytes in 1 blocks ==7340==indirectly lost: 0 bytes in 0 blocks ==7340== possibly lost: 0 bytes in 0 blocks ==7340==still reachable: 0 bytes in 0 blocks ==7340== suppressed: 0 bytes in 0 blocks ==7340== Rerun with --leak-check=full to see details of leaked memory ==7340== ==7340== For counts of detected and suppressed errors, rerun with: -v ==7340== Use --track-origins=yes to see where uninitialised values come from ==7340== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) so there are some cases of what look like incorrect accesses (and some leaked memory). Your code compiled with gfortran (with Paul's patches in place) shows no errors or leaks from valgrind. So, in summary, in this case I think the current gfortran is missing some finalizations (which are fixed by Paul's patches), and ifort is likely doing something wrong and probably calling the finalizer more times than it should. -Andrew On Monday, January 24, 2022 6:49:23 AM PST Salvatore Filippone via Fortran wrote: 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_type interface my_test_type module procedure new_test_type_object end interface my_test_type contains subroutine delete_test_type(this) type(my_test_type) :: this write(*,*) 'Called delete_test_type' if (allocated(this%i)) deallocate(this%i) end subroutine delete_test_type function new_test_type_object(item) result(res) type(my_tes
Re: FINAL subroutines
Hi Jerry, I am trying to fix the failure of my latest patch with this very test case. Otherwise it fixes most of the remaining dependencies in PR37336. At a pinch, I could submit the earlier patch that Andrew mentions and work from there. However, you will note that it does miss one of the finalizations. This is critical because function results, which should be finalized, are not. I'll keep an eye on the state of the branch. By and large, release occurs 3-4 months after the start of stage 4. I will leave 2 months maximum. Best regards Paul On Wed, 26 Jan 2022 at 21:29, Jerry D via Fortran wrote: > Is there any reason these patches can not be applied and use this test > as a test case? > > Regards, > > Jerry > > On 1/24/22 8:11 AM, Salvatore Filippone via Fortran wrote: > > 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 < > aben...@carnegiescience.edu> > > wrote: > > > >> 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 those patches > >> incorporated > >> your code gives the following output with gfortran: > >> > >> $ ./testfinal > >> Allocating wrapper > >> Calling new_outer_type > >> Assigning outer%test_item > >> Called delete_test_type > >> End of new_outer_type > >> DeAllocating wrapper > >> Called delete_test_type > >> > >> So there is one more call to the finalizer than you found - I haven't > >> checked > >> carefully but I would guess this is a deallocation of LHS on assignment. > >> > >> In testing these patches using the Intel compiler we found that it seems > >> to > >> call the finalization wrapper more than it should, sometimes on objects > >> that > >> have already been deallocated. Your code, compiled with the Intel > compiler > >> and > >> then run under valgrind shows the following: > >> > >> $ valgrind ./testfinal > >> ==7340== Memcheck, a memory error detector > >> ==7340== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. > >> ==7340== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright > info > >> ==7340== Command: ./testfinal > >> ==7340== > >> ==7340== Conditional jump or move depends on uninitialised value(s) > >> ==7340==at 0x493A51: __intel_sse2_strcpy (in > /home/abensonca/Scratch/ > >> ifortTests/testfinal) > >> ==7340==by 0x45D70E: for__add_to_lf_table (in > /home/abensonca/Scratch/ > >> ifortTests/testfinal) > >> ==7340==by 0x4410CB: for__open_proc (in /home/abensonca/Scratch/ > >> ifortTests/testfinal) > >> ==7340==by 0x423A64: for__open_default (in /home/abensonca/Scratch/ > >> ifortTests/testfinal) > >> ==7340==by 0x4305A9: for_write_seq_lis (in /home/abensonca/Scratch/ > >> ifortTests/testfinal) > >> ==7340==by 0x4047E1: MAIN__ (testfinal.f90:62) > >> ==7340==by 0x403CE1: main (in /home/abensonca/Scratch/ifortTests/ > >> testfinal) > >> ==7340== > >> Allocating wrapper > >> Calling new_outer_type > >> Assigning outer%test_item > >> Called delete_test_type > >> ==7340== Conditional jump or move depends on uninitialised value(s) > >> ==7340==at 0x40572A: do_alloc_copy (in > >> /home/abensonca/Scratch/ifortTests/ > >> testfinal) > >> ==7340==by 0x406B9A: do_alloc_copy (in > >> /home/abensonca/Scratch/ifortTests/ > >> testfinal) > >> ==7340==by 0x4084ED: for_alloc_assign_v2 (in > /home/abensonca/Scratch/ > >> ifortTests/testfinal) > >> ==7340==by 0x404474: target_mod_mp_new_outer_type_ > (testfinal.f90:48) > >> ==7340==by 0x40485E: MAIN__ (testfinal.f90:65) > >> ==7340==by 0x403CE1: main (in /home/abensonca/Scratch/ifortTests/ > >> testfinal) > >> ==7340== > >> Called delete_test_type > >> End of new_outer_type > >> DeAllocating wrapper > >> Called delete_test_type > >> ==7340== > >> ==7340== HEAP SUMMARY: > >> ==7340== in use at exit: 48 bytes in 1 blocks > >> ==7340== total heap usage: 14 allocs, 13 frees, 12,879 bytes allocated > >> ==7340== > >> ==7340== LEAK SUMMARY: > >> ==7340==definitely lost: 48 bytes in 1 blocks > >> ==7340==indirectly lost: 0 bytes in 0 blocks > >> ==7340== possibly lost: 0 bytes in 0 blocks > >> ==7340==still reachable: 0 bytes in 0 blocks > >> ==7340== suppressed: 0 bytes in 0 blocks > >> ==7340== Rerun with --leak-check=full to see details of leaked memory > >> ==7340== > >> ==7340== For counts of detected and suppressed errors, rerun with: -v > >> ==7340== Use --track-origins=yes to see where uninitialised values come > >> from > >> ==7340== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) > >> > >> so there are some cases of what
Re: FINAL subroutines
One more data point: Cray FTN issues TWO calls to the FINAL. Which begs the question: what is the correct number of calls one, two or three? Salvatore fsalvato@daint102:/project/prce01/fsalvato/NUMERICAL/PSBLAS/V4/psblas4/test/newstuff> ftn --version Cray Fortran : Version 11.0.0 fsalvato@daint102:/project/prce01/fsalvato/NUMERICAL/PSBLAS/V4/psblas4/test/newstuff> ftn -o testfinal testfinal.f90 fsalvato@daint102:/project/prce01/fsalvato/NUMERICAL/PSBLAS/V4/psblas4/test/newstuff> ./testfinal Allocating wrapper Calling new_outer_type Assigning outer%test_item Called delete_test_type End of new_outer_type DeAllocating wrapper Called delete_test_type On Wed, Jan 26, 2022 at 11:59 PM Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi Jerry, > > I am trying to fix the failure of my latest patch with this very test > case. Otherwise it fixes most of the remaining dependencies in PR37336. > > At a pinch, I could submit the earlier patch that Andrew mentions and work > from there. However, you will note that it does miss one of the > finalizations. This is critical because function results, which should be > finalized, are not. > > I'll keep an eye on the state of the branch. By and large, release occurs > 3-4 months after the start of stage 4. I will leave 2 months maximum. > > Best regards > > Paul > > > On Wed, 26 Jan 2022 at 21:29, Jerry D via Fortran > wrote: > >> Is there any reason these patches can not be applied and use this test >> as a test case? >> >> Regards, >> >> Jerry >> >> On 1/24/22 8:11 AM, Salvatore Filippone via Fortran wrote: >> > 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 < >> aben...@carnegiescience.edu> >> > wrote: >> > >> >> 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 those patches >> >> incorporated >> >> your code gives the following output with gfortran: >> >> >> >> $ ./testfinal >> >> Allocating wrapper >> >> Calling new_outer_type >> >> Assigning outer%test_item >> >> Called delete_test_type >> >> End of new_outer_type >> >> DeAllocating wrapper >> >> Called delete_test_type >> >> >> >> So there is one more call to the finalizer than you found - I haven't >> >> checked >> >> carefully but I would guess this is a deallocation of LHS on >> assignment. >> >> >> >> In testing these patches using the Intel compiler we found that it >> seems >> >> to >> >> call the finalization wrapper more than it should, sometimes on objects >> >> that >> >> have already been deallocated. Your code, compiled with the Intel >> compiler >> >> and >> >> then run under valgrind shows the following: >> >> >> >> $ valgrind ./testfinal >> >> ==7340== Memcheck, a memory error detector >> >> ==7340== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et >> al. >> >> ==7340== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright >> info >> >> ==7340== Command: ./testfinal >> >> ==7340== >> >> ==7340== Conditional jump or move depends on uninitialised value(s) >> >> ==7340==at 0x493A51: __intel_sse2_strcpy (in >> /home/abensonca/Scratch/ >> >> ifortTests/testfinal) >> >> ==7340==by 0x45D70E: for__add_to_lf_table (in >> /home/abensonca/Scratch/ >> >> ifortTests/testfinal) >> >> ==7340==by 0x4410CB: for__open_proc (in /home/abensonca/Scratch/ >> >> ifortTests/testfinal) >> >> ==7340==by 0x423A64: for__open_default (in /home/abensonca/Scratch/ >> >> ifortTests/testfinal) >> >> ==7340==by 0x4305A9: for_write_seq_lis (in /home/abensonca/Scratch/ >> >> ifortTests/testfinal) >> >> ==7340==by 0x4047E1: MAIN__ (testfinal.f90:62) >> >> ==7340==by 0x403CE1: main (in /home/abensonca/Scratch/ifortTests/ >> >> testfinal) >> >> ==7340== >> >> Allocating wrapper >> >> Calling new_outer_type >> >> Assigning outer%test_item >> >> Called delete_test_type >> >> ==7340== Conditional jump or move depends on uninitialised value(s) >> >> ==7340==at 0x40572A: do_alloc_copy (in >> >> /home/abensonca/Scratch/ifortTests/ >> >> testfinal) >> >> ==7340==by 0x406B9A: do_alloc_copy (in >> >> /home/abensonca/Scratch/ifortTests/ >> >> testfinal) >> >> ==7340==by 0x4084ED: for_alloc_assign_v2 (in >> /home/abensonca/Scratch/ >> >> ifortTests/testfinal) >> >> ==7340==by 0x404474: target_mod_mp_new_outer_type_ >> (testfinal.f90:48) >> >> ==7340==by 0x40485E: MAIN__ (testfinal.f90:65) >> >> ==7340==by 0x403CE1: main (in /home/abensonca/Scratch/ifortTests/ >> >> testfinal) >> >> ==7340== >> >> Called delete_test_type >> >> End of new_outer_type >> >> DeAlloc
