g:07c60b8e33c614a6cdd9fe3de7f409319b6a239a, gcc-12-6498-g07c60b8e33 make -k check-gcc-fortran RUNTESTFLAGS="dg.exp=gfortran.dg/boz_15.f90" FAIL: gfortran.dg/boz_15.f90 -O0 execution test FAIL: gfortran.dg/boz_15.f90 -O1 execution test FAIL: gfortran.dg/boz_15.f90 -O2 execution test FAIL: gfortran.dg/boz_15.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/boz_15.f90 -O3 -g execution test FAIL: gfortran.dg/boz_15.f90 -Os execution test # of expected passes 6 # of unexpected failures 6 commit 07c60b8e33c614a6cdd9fe3de7f409319b6a239a (HEAD) Author: Jakub Jelinek <jakub@redhat.com> Date: Tue Jan 4 10:37:48 2022 +0100 fortran, libgfortran: -mabi=ieeelongdouble I/O At line 20 of file /home/seurer/gcc/git/gcc-12-test/gcc/testsuite/gfortran.dg/boz_15.f90 Fortran runtime error: Bad value during integer read Error termination. Backtrace: #0 0x7fffa583af03 in formatted_transfer_scalar_read at /home/seurer/gcc/git/gcc-12-test/libgfortran/io/transfer.c:1513 #1 0x7fffa583c307 in formatted_transfer at /home/seurer/gcc/git/gcc-12-test/libgfortran/io/transfer.c:2339 #2 0x7fffa5836f47 in wrap_scalar_transfer at /home/seurer/gcc/git/gcc-12-test/libgfortran/io/transfer.c:2382 #3 0x100104d3 in ??? #4 0x10010ce3 in ??? #5 0x7fffa5237f2b in ??? #6 0x7fffa5238107 in ??? #7 0xffffffffffffffff in ??? FAIL: gfortran.dg/boz_15.f90 -O0 execution test This occurs with the compiler configured with --with-long-double-format=ieee on a distro (Fedora 36) which also used --with-long-double-format=ieee.
Confirmed.
Created attachment 53381 [details] gcc13-pr106079.patch Untested fix.
I tried the patch on trunk and it fixed the failure. I am trying a full make check there and with gcc 12.
The patch causes a bunch of new failures: FAIL: gfortran.dg/c-interop/allocatable-dummy.f90 -Os execution test FAIL: gfortran.dg/c-interop/allocate-errors.f90 -O0 execution test FAIL: gfortran.dg/c-interop/argument-association-assumed-rank-7.f90 -O1 execution test FAIL: gfortran.dg/c-interop/argument-association-assumed-rank-7.f90 -O2 execution test FAIL: gfortran.dg/c-interop/cf-descriptor-3.f90 -O2 execution test FAIL: gfortran.dg/c-interop/cf-descriptor-7.f90 -Os execution test FAIL: gfortran.dg/c-interop/contiguous-3.f90 -O0 execution test Though it did fix these: FAIL: gfortran.dg/c-interop/fc-descriptor-6.f90 -O1 execution test FAIL: gfortran.dg/boz_15.f90 -O0 execution test FAIL: gfortran.dg/boz_15.f90 -O1 execution test FAIL: gfortran.dg/boz_15.f90 -O2 execution test FAIL: gfortran.dg/boz_15.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/boz_15.f90 -O3 -g execution test FAIL: gfortran.dg/boz_15.f90 -Os execution test
Strange, in my 12 branch distro (scratch) build the only differences with the patch are: -FAIL: gfortran.dg/boz_15.f90 -O0 execution test -FAIL: gfortran.dg/boz_15.f90 -O1 execution test -FAIL: gfortran.dg/boz_15.f90 -O2 execution test -FAIL: gfortran.dg/boz_15.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test -FAIL: gfortran.dg/boz_15.f90 -O3 -g execution test -FAIL: gfortran.dg/boz_15.f90 -Os execution test and nothing else.
And on the box I was working on this fix (Fedora 34, glibc 2.33) without the fix I see in ../configure --enable-languages=c,c++,fortran --with-long-double-format=ieee --with-long-double-128 make check-gfortran RUNTESTFLAGS='dg.exp=boz* c-interop.exp' Running /home/jakub/gcc/gcc/testsuite/gfortran.dg/c-interop/c-interop.exp ... Running /home/jakub/gcc/gcc/testsuite/gfortran.dg/dg.exp ... FAIL: gfortran.dg/boz_15.f90 -O0 execution test FAIL: gfortran.dg/boz_15.f90 -O1 execution test FAIL: gfortran.dg/boz_15.f90 -O2 execution test FAIL: gfortran.dg/boz_15.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/boz_15.f90 -O3 -g execution test FAIL: gfortran.dg/boz_15.f90 -Os execution test === gfortran Summary === # of expected passes 1963 # of unexpected failures 6 # of unsupported tests 12 and with the change: Running /home/jakub/gcc/gcc/testsuite/gfortran.dg/c-interop/c-interop.exp ... Running /home/jakub/gcc/gcc/testsuite/gfortran.dg/dg.exp ... === gfortran Summary === # of expected passes 1969 # of unsupported tests 12 For the latter <CFI_cdesc_t base_addr=(nil) elem_len=16 version=1 rank=0 type=CFI_type_struct attribute=CFI_attribute_allocatable> PASS: gfortran.dg/c-interop/allocatable-dummy.f90 -Os execution test CFI_allocate: Base address of C descriptor must be NULL. CFI_allocate: The object of the C descriptor must be a pointer or allocatable variable. CFI_deallocate: Base address is already NULL. PASS: gfortran.dg/c-interop/allocate-errors.f90 -O0 execution test PASS: gfortran.dg/c-interop/argument-association-assumed-rank-7.f90 -O1 execution test PASS: gfortran.dg/c-interop/argument-association-assumed-rank-7.f90 -O2 (test for excess errors) <CFI_cdesc_t base_addr=(nil) elem_len=8 version=1 rank=0 type=CFI_type_struct attribute=CFI_attribute_allocatable> <CFI_cdesc_t base_addr=(nil) elem_len=8 version=1 rank=0 type=CFI_type_struct attribute=CFI_attribute_pointer> <CFI_cdesc_t base_addr=0x1000e341910 elem_len=8 version=1 rank=0 type=CFI_type_struct attribute=CFI_attribute_allocatable> <CFI_cdesc_t base_addr=0x1000e341930 elem_len=8 version=1 rank=0 type=CFI_type_struct attribute=CFI_attribute_pointer> PASS: gfortran.dg/c-interop/cf-descriptor-3.f90 -O2 execution test <CFI_cdesc_t base_addr=0x7ffffbbdb4a0 elem_len=8 version=1 rank=2 type=CFI_type_struct attribute=CFI_attribute_other dim=[<CFI_dim_t lower_bound=0 extent=10 sm=8>, <CFI_dim_t lower_bound=0 extent=5 sm=80>]> <CFI_cdesc_t base_addr=0x7ffffbbdb4a0 elem_len=4 version=1 rank=2 type=CFI_type_int attribute=CFI_attribute_pointer dim=[<CFI_dim_t lower_bound=0 extent=10 sm=8>, <CFI_dim_t lower_bound=0 extent=5 sm=80>]> <CFI_cdesc_t base_addr=0x7ffffbbdb4a4 elem_len=4 version=1 rank=2 type=CFI_type_int attribute=CFI_attribute_pointer dim=[<CFI_dim_t lower_bound=0 extent=10 sm=8>, <CFI_dim_t lower_bound=0 extent=5 sm=80>]> PASS: gfortran.dg/c-interop/cf-descriptor-7.f90 -Os execution test <CFI_cdesc_t base_addr=0x7fffd08bb074 elem_len=4 version=1 rank=1 type=CFI_type_int attribute=CFI_attribute_other dim=[<CFI_dim_t lower_bound=0 extent=5 sm=8>]> <CFI_cdesc_t base_addr=0x7fffd08bb074 elem_len=4 version=1 rank=1 type=CFI_type_int attribute=CFI_attribute_other dim=[<CFI_dim_t lower_bound=0 extent=5 sm=8>]> <CFI_cdesc_t base_addr=0x7fffd08bb080 elem_len=4 version=1 rank=1 type=CFI_type_int attribute=CFI_attribute_other dim=[<CFI_dim_t lower_bound=0 extent=5 sm=12>]> <CFI_cdesc_t base_addr=0x7fffd08bb080 elem_len=4 version=1 rank=1 type=CFI_type_int attribute=CFI_attribute_other dim=[<CFI_dim_t lower_bound=0 extent=5 sm=12>]> PASS: gfortran.dg/c-interop/contiguous-3.f90 -O0 execution test in the log. So, I can't really reproduce the above. Not really clear how it could be related though, e.g. contiguous-3.f90 doesn't have anything real/complex related in it. C_LONG_DOUBLE is only present in typecodes-array-longdouble.f90 and typecodes-scalar-longdouble.f90.
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:82ac4cd213867be939aedee15347e8fd3f200b6a commit r13-1913-g82ac4cd213867be939aedee15347e8fd3f200b6a Author: Jakub Jelinek <jakub@redhat.com> Date: Mon Aug 1 08:26:03 2022 +0200 libfortran: Fix up boz_15.f90 on powerpc64le with -mabi=ieeelongdouble [PR106079] The boz_15.f90 test FAILs on powerpc64le-linux when -mabi=ieeelongdouble is used (either default through --with-long-double-format=ieee or when used explicitly). The problem is that the read/write transfer routines are called with BT_REAL (or BT_COMPLEX) type and kind 17 which is magic we use to say it is the IEEE quad real(kind=16) rather than the IBM double double real(kind=16). For the floating point input/output we then handle kind 17 specially, but for B/O/Z we just treat the bytes of the floating point value as binary blob and using 17 in that case results in unexpected behavior, for write it means we don't estimate right how many chars we'll need and print ******************** etc. rather than what we should, and even with explicit size we'd print one further byte than intended. For read it would even mean overwriting some unrelated byte after the floating point object. Fixed by using 16 instead of 17 in the read_radix and write_{b,o,z} calls. 2022-08-01 Jakub Jelinek <jakub@redhat.com> PR libfortran/106079 * io/transfer.c (formatted_transfer_scalar_read, formatted_transfer_scalar_write): For type BT_REAL with kind 17 change kind to 16 before calling read_radix or write_{b,o,z}.
The fix worked fine in my testing on trunk. Thanks!
The releases/gcc-12 branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:4e5ca7ff8c9afd3c38245aa6b939cd3ae49bf1fe commit r12-8653-g4e5ca7ff8c9afd3c38245aa6b939cd3ae49bf1fe Author: Jakub Jelinek <jakub@redhat.com> Date: Mon Aug 1 08:26:03 2022 +0200 libfortran: Fix up boz_15.f90 on powerpc64le with -mabi=ieeelongdouble [PR106079] The boz_15.f90 test FAILs on powerpc64le-linux when -mabi=ieeelongdouble is used (either default through --with-long-double-format=ieee or when used explicitly). The problem is that the read/write transfer routines are called with BT_REAL (or BT_COMPLEX) type and kind 17 which is magic we use to say it is the IEEE quad real(kind=16) rather than the IBM double double real(kind=16). For the floating point input/output we then handle kind 17 specially, but for B/O/Z we just treat the bytes of the floating point value as binary blob and using 17 in that case results in unexpected behavior, for write it means we don't estimate right how many chars we'll need and print ******************** etc. rather than what we should, and even with explicit size we'd print one further byte than intended. For read it would even mean overwriting some unrelated byte after the floating point object. Fixed by using 16 instead of 17 in the read_radix and write_{b,o,z} calls. 2022-08-01 Jakub Jelinek <jakub@redhat.com> PR libfortran/106079 * io/transfer.c (formatted_transfer_scalar_read, formatted_transfer_scalar_write): For type BT_REAL with kind 17 change kind to 16 before calling read_radix or write_{b,o,z}. (cherry picked from commit 82ac4cd213867be939aedee15347e8fd3f200b6a)
Fixed for 12.2 and later.