[Bug fortran/55174] New: internal compiler error: Segmentation fault with bad array reference

[john.harper at vuw dot ac.nz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55174



 Bug #: 55174

   Summary: internal compiler error: Segmentation fault with bad

array reference

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: john.har...@vuw.ac.nz





This 4-line Fortran program has an error at line 3, where array(*) is of course

not permitted as an argument of a function.



implicit none

integer:: array(2)=(/42,666/)

print *, size(array(*))

end



Other compilers (g95, ifort) correctly diagnose the error but gfortran 4.8.0 

gives an internal compiler error: Segmentation fault and asks me to tell you.

My compile-time output follows.



cayley[~/Jfh] % /local/scratch/gf/bin/gfortran -v trybadstar.f90

Driving: /local/scratch/gf/bin/gfortran -v trybadstar.f90 -l gfortran -l m

-shared-libgcc

Using built-in specs.

COLLECT_GCC=/local/scratch/gf/bin/gfortran

COLLECT_LTO_WRAPPER=/local/scratch/gf/libexec/gcc/i686-pc-linux-gnu/4.8.0/lto-wrapper

Target: i686-pc-linux-gnu

Configured with: /local/scratch/gcc-4.8-20120701/configure

--prefix=/local/scratch/gf --enable-languages=c,fortran --disable-libada

--with-local-prefix=/local/scratch --with-gmp=/local/scratch

Thread model: posix

gcc version 4.8.0 20120701 (experimental) (GCC) 

COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro'

 /local/scratch/gf/libexec/gcc/i686-pc-linux-gnu/4.8.0/f951 trybadstar.f90

-quiet -dumpbase trybadstar.f90 -mtune=generic -march=pentiumpro -auxbase

trybadstar -version -fintrinsic-modules-path

/local/scratch/gf/lib/gcc/i686-pc-linux-gnu/4.8.0/finclude -o /tmp/cccgAIgM.s

GNU Fortran (GCC) version 4.8.0 20120701 (experimental) (i686-pc-linux-gnu)

compiled by GNU C version 4.8.0 20120701 (experimental), GMP version

5.0.5, MPFR version 3.1.0, MPC version 0.9

warning: GMP header version 5.0.5 differs from library version 5.0.3.

warning: MPFR header version 3.1.0 differs from library version 3.1.0-p3.

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

GNU Fortran (GCC) version 4.8.0 20120701 (experimental) (i686-pc-linux-gnu)

compiled by GNU C version 4.8.0 20120701 (experimental), GMP version

5.0.5, MPFR version 3.1.0, MPC version 0.9

warning: GMP header version 5.0.5 differs from library version 5.0.3.

warning: MPFR header version 3.1.0 differs from library version 3.1.0-p3.

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

f951: internal compiler error: Segmentation fault

Please submit a full bug report,

with preprocessed source if appropriate.

See http://gcc.gnu.org/bugs.html for instructions.

cayley[~/Jfh] %

[Bug fortran/57871] New: gfortran -freal-4-real-16 gives wrong result for selected_real_kind(1)

[john.harper at vuw dot ac.nz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57871

Bug ID: 57871
   Summary: gfortran -freal-4-real-16 gives wrong result for
selected_real_kind(1)
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.harper at vuw dot ac.nz

gfortran 4.8.1 -freal-4-real-16 gives real(16) kind with selected_real_kind(1)
but it ought to give real(8) because that is the smallest decimal precision
available with that compiler option. Same problem with -freal-4-real-10 giving
real(10) instead of real(8). Evidence:

cayley[~/Jfh] % cat testprecision.f90
implicit none
integer,parameter:: p1 = selected_real_kind(1), dp = kind(1d0)
print *,'kind(1.0_p1)',kind(1.0_p1),'precision(1.0_p1)',precision(1.0_p1)
print *,'kind(1.0_dp)',kind(1.0_dp),'precision(1.0_dp)',precision(1.0_dp)
end
cayley[~/Jfh] % /local/scratch/gf/bin/gfortran -freal-4-real-16 -Wall -Wextra
-fno-strict-aliasing -fwrapv testprecision.f90
cayley[~/Jfh] % ./a.out
 kind(1.0_p1)  16 precision(1.0_p1)  33
 kind(1.0_dp)   8 precision(1.0_dp)  15
cayley[~/Jfh] % /local/scratch/gf/bin/gfortran -freal-4-real-10 -Wall -Wextra
-fno-strict-aliasing -fwrapv testprecision.f90
cayley[~/Jfh] % ./a.out 
 kind(1.0_p1)  10 precision(1.0_p1)  18
 kind(1.0_dp)   8 precision(1.0_dp)  15
cayley[~/Jfh] % /local/scratch/gf/bin/gfortran -v
Using built-in specs.
COLLECT_GCC=/local/scratch/gf/bin/gfortran
COLLECT_LTO_WRAPPER=/local/scratch/gf/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /local/scratch/gcc-4.8-20130530/configure
--prefix=/local/scratch/gf --enable-languages=c,fortran --disable-libada
--with-local-prefix=/local/scratch --with-gmp=/local/scratch
Thread model: posix 
gcc version 4.8.1 20130530 (prerelease) (GCC)   
cayley[~/Jfh] %

[Bug fortran/55501] [F03] ICE using MERGE in constant expr

[john.harper at vuw dot ac.nz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55501

john.harper at vuw dot ac.nz changed:

   What|Removed |Added

 CC||john.harper at vuw dot ac.nz

--- Comment #13 from john.harper at vuw dot ac.nz ---
ICE from using MERGE in a constant specification expression, not in this
program an initialization expression because it's an array bound, with gfortran
4.7.2. 
I have tried to install later versions but without success so far. 

cayley[~/Jfh] % cat testmerge3.f90
program testmerge3
  implicit none
  integer,parameter::iarray(merge(2,3,.true.)) = 1, i = size(iarray)
  print (A,99I2),'i,iarray =',i,iarray
end program testmerge3
cayley[~/Jfh] % gfortran -v testmerge3.f90
Driving: gfortran -v testmerge3.f90 -l gfortran -l m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/src/gcc-4.7.2/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--enable-libstdcxx-time --enable-gnu-unique-object --enable-linker-build-id
--with-ppl --enable-cloog-backend=isl --disable-ppl-version-check
--disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default
--enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu
--disable-multilib --disable-libssp --disable-build-with-cxx
--disable-build-poststage1-with-cxx --enable-checking=release
Thread model: posix
gcc version 4.7.2 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/f951 testmerge3.f90 -quiet
-dumpbase testmerge3.f90 -mtune=generic -march=x86-64 -auxbase testmerge3
-version -fintrinsic-modules-path
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/finclude -o /tmp/ccPFQJLT.s
GNU Fortran (GCC) version 4.7.2 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.2, GMP version 5.1.0, MPFR version
3.1.1-p2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran (GCC) version 4.7.2 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.2, GMP version 5.1.0, MPFR version
3.1.1-p2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
f951: internal compiler error: in is_illegal_recursion, at
fortran/resolve.c:1420
Please submit a full bug report,
with preprocessed source if appropriate.
See https://bugs.archlinux.org/ for instructions.
cayley[~/Jfh] %

[Bug fortran/51418] New: Fortran format sp,f0.0 output wrong with NaN and 0.0

[john.harper at vuw dot ac.nz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51418

 Bug #: 51418
   Summary: Fortran format sp,f0.0 output wrong with NaN and 0.0
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: john.har...@vuw.ac.nz


This 6-line program prints  NaN when IMHO it should print NaN and +. when
IMHO it should print +0. 

rimu[~]$ cat gftest.f90
character:: cnan*3 = 'NaN', fmt*13 = '(SP,A,F0.0,A)' 
real xnan
read(cnan,*) xnan
print fmt, '',xnan,''
print fmt, '',0.0 ,''
end
rimu[~]$ gfortran  -v
Using built-in specs.
Target: i386-redhat-linux6E
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --disable-gnu-unique-object
--enable-languages=c,c++,fortran --disable-libgcj
--with-mpfr=/builddir/build/BUILD/gcc-4.4.4-20100726/obj-i386-redhat-linux6E/mpfr-install/
--with-ppl=/builddir/build/BUILD/gcc-4.4.4-20100726/obj-i386-redhat-linux6E/ppl-install
--with-cloog=/builddir/build/BUILD/gcc-4.4.4-20100726/obj-i386-redhat-linux6E/cloog-install
--with-tune=generic --with-arch=i586 --build=i386-redhat-linux6E
Thread model: posix
gcc version 4.4.4 20100726 (Red Hat 4.4.4-13) (GCC) 
rimu[~]$ gfortran gftest.f90
rimu[~]$ ./a.out
 NaN
+.
rimu[~]$ 

The output is the same on another machine:

regent[~/Jfh] % gfortran -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc
--disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu   
Thread model: posix 
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)

[Bug fortran/44022] Spurious 'unused parameter' for a used procedure argument

[john.harper at vuw dot ac.nz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44022

john.harper at vuw dot ac.nz changed:

   What|Removed |Added

 CC||john.harper at vuw dot
   ||ac.nz

--- Comment #3 from john.harper at vuw dot ac.nz 2011-10-06 01:10:36 UTC ---
This gfortran bug happens if the offending subprogram is after CONTAINS in a
main program as well as in a module.

With gfortran -Wall -W this program showed the bug but did print 3.00 

program test
  implicit none 
  intrinsic sqrt
  print (F10.6),find(sqrt,9.0)
contains
  real function find(func,x) ! gfortran -Wall -W warns unused parameter func
real,external  ::func   
real,intent(in):: x 
find = func(x)  
  end function find 
end program test   

I used two versions: gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) and 
gcc version 4.4.4 20100726 (Red Hat 4.4.4-13) (GCC).
I would have installed version 4.6 if I could have.

-- John Harper

[Bug fortran/52062] New: [4.6.2 regression] public generic name, specific functions of private types

[john.harper at vuw dot ac.nz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52062

 Bug #: 52062
   Summary: [4.6.2 regression] public generic name, specific
functions of private types
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: john.har...@vuw.ac.nz


A program that compiles and runs with gfortran 4.4.4 but gives an internal
compiler error with gfortran 4.6.2. IMHO the program is bad f95 but good f2003
because it disobeys a f95 constraint that seems not to be a f2003 constraint.
Evidence: 
rimu[~]$ cat testpublic.f90
! Can a public generic name refer to private specific functions returning
! private types? (F95 standard 5.2.3 R523 3rd constraint: A module procedure 
! that has a dummy argument or function result of a type that has PRIVATE 
! accessibility shall have PRIVATE accessibility and shall not have a 
! generic identifier that has PUBLIC accessibility. That constraint is 
! not in f2003 so this program seems to be valid f2003 but bad f95.)
Module whattype
  private
  public datatype
  interface datatype
 module procedure rtype,chtype
  end interface datatype
  type char1int
 character(9) name
 integer  sort
  end type char1int
  type char2int
 character(9) name
 integer  sort
 integer  leng
  end type char2int
contains
  elemental type(char1int) function rtype(x)
real,intent(in):: x
rtype = char1int('real',kind(x))
  end function rtype

  elemental type(char2int) function chtype(x)
Character(*),intent(in)::  x
chtype = char2int('character',kind(x),len(x))
  end function chtype

end module whattype

program testpublic
  use whattype
  print 999, ' rhubarb is ',datatype(rhubarb)
  print 999, ' 666.0 is ',datatype(666.0)
999 format (2A,' kind = ',I0,:,' len = ',I0)
end program testpublic

rimu[~]$ gfortran -v
Using built-in specs.
Target: i386-redhat-linux6E
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --disable-gnu-unique-object
--enable-languages=c,c++,fortran --disable-libgcj
--with-mpfr=/builddir/build/BUILD/gcc-4.4.4-20100726/obj-i386-redhat-linux6E/mpfr-install/
--with-ppl=/builddir/build/BUILD/gcc-4.4.4-20100726/obj-i386-redhat-linux6E/ppl-install
--with-cloog=/builddir/build/BUILD/gcc-4.4.4-20100726/obj-i386-redhat-linux6E/cloog-install
--with-tune=generic --with-arch=i586 --build=i386-redhat-linux6E
Thread model: posix
gcc version 4.4.4 20100726 (Red Hat 4.4.4-13) (GCC) 
rimu[~]$ gfortran testpublic.f90
rimu[~]$ ./a.out
 rhubarb is character kind = 1 len = 7
 666.0 is real  kind = 4
rimu[~]$ 
rimu[~]$ /tmp/gf/bin/gfortran -v testpublic.f90
Driving: /tmp/gf/bin/gfortran -v testpublic.f90 -l gfortran -l m -shared-libgcc
Using built-in specs.
COLLECT_GCC=/tmp/gf/bin/gfortran
Target: i686-pc-linux-gnu
Configured with: /tmp/gcc-4.6.2/configure --prefix=/tmp/gf
--enable-languages=c,c++,fortran --disable-libada --with-gmp=/home/harperj1
--with-mpfr-include=/home/harperj1/mpfr-3.0.0
--with-mpfr-lib=/home/harperj1/mpfr-3.0.0/.libs
--with-mpc=/home/harperj1/mpc-0.9
Thread model: posix
gcc version 4.6.2 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro'
 /tmp/gf/libexec/gcc/i686-pc-linux-gnu/4.6.2/f951 testpublic.f90 -quiet
-dumpbase testpublic.f90 -mtune=generic -march=pentiumpro -auxbase testpublic
-version -fintrinsic-modules-path finclude -o /tmp/ccTvKzZ1.s
GNU Fortran (GCC) version 4.6.2 (i686-pc-linux-gnu)
compiled by GNU C version 4.6.2, GMP version 4.3.2, MPFR version 3.0.0,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran (GCC) version 4.6.2 (i686-pc-linux-gnu)
compiled by GNU C version 4.6.2, GMP version 4.3.2, MPFR version 3.0.0,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
testpublic.f90: In function âtestpublicâ:
testpublic.f90:37:0: internal compiler error: in transfer_expr, at
fortran/trans-io.c:2166
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

[Bug fortran/52101] New: Obsolescence warning for non-obs. feature character name*length

[john.harper at vuw dot ac.nz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52101

 Bug #: 52101
   Summary: Obsolescence warning for non-obs. feature character
name*length
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: john.har...@vuw.ac.nz


Gfortran 4.6.2 -std=f95 says a declaration character name*length is
obsolescent. IMHO it is not; the obsolescent form is character*length name.
Gfortran 4.4.4 is correct on this matter. See below.

rimu[~]$ cat obschar.f90
! Character*length is obsolescent, not character name*length 
character greet*11
greet = 'Hello world'
print *,greet
end
rimu[~]$ gfortran -v
Using built-in specs.
Target: i386-redhat-linux6E
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --disable-gnu-unique-object
--enable-languages=c,c++,fortran --disable-libgcj
--with-mpfr=/builddir/build/BUILD/gcc-4.4.4-20100726/obj-i386-redhat-linux6E/mpfr-install/
--with-ppl=/builddir/build/BUILD/gcc-4.4.4-20100726/obj-i386-redhat-linux6E/ppl-install
--with-cloog=/builddir/build/BUILD/gcc-4.4.4-20100726/obj-i386-redhat-linux6E/cloog-install
--with-tune=generic --with-arch=i586 --build=i386-redhat-linux6E
Thread model: posix
gcc version 4.4.4 20100726 (Red Hat 4.4.4-13) (GCC) 
rimu[~]$ gfortran -std=f95 obschar.f90
rimu[~]$ ./a.out
 Hello world
rimu[~]$ /tmp/gf/bin/gfortran -v
Using built-in specs.
COLLECT_GCC=/tmp/gf/bin/gfortran
Target: i686-pc-linux-gnu
Configured with: /tmp/gcc-4.6.2/configure --prefix=/tmp/gf
--enable-languages=c,c++,fortran --disable-libada --with-gmp=/home/harperj1
--with-mpfr-include=/home/harperj1/mpfr-3.0.0
--with-mpfr-lib=/home/harperj1/mpfr-3.0.0/.libs
--with-mpc=/home/harperj1/mpc-0.9
Thread model: posix
gcc version 4.6.2 (GCC) 
rimu[~]$ /tmp/gf/bin/gfortran -std=f95 obschar.f90
obschar.f90:2.18:

character greet*11
  1
Warning: Obsolescent feature: Old-style character length at (1)
rimu[~]$

[Bug fortran/79417] New: -Wconversion warns wrongly of real(16) to real(8)

[john.harper at vuw dot ac.nz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79417

Bug ID: 79417
   Summary: -Wconversion warns wrongly of real(16) to real(8)
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.harper at vuw dot ac.nz
  Target Milestone: ---

If array parameters are declared with both quad and double precision, the quad
one triggers a -Wconversion warning but the program's output shows that the
conversion did not happen. (The warning does not occur with a scalar quad
parameter, nor if the double precision ones are commented out.)  


cayley[~/Jfh] % cat realtest2.f90
program tryit
  implicit none
  integer,parameter:: qp = selected_real_kind(30), dp = kind(1d0)
  real(qp),parameter:: q1 = 1, q23(1) = 2*q1/3
  real(dp),parameter:: d1 = 1, d23(1) = real(q23,dp)
  print "(F42.36)",q23
  print "(F24.18)",d23
end program tryit
cayley[~/Jfh] % gfortran -Wconversion realtest2.f90
realtest2.f90:4:39:

   real(qp),parameter:: q1 = 1, q23(1) = 2*q1/3
   1
Warning: Change of value in conversion from ‘REAL(16)’ to ‘REAL(8)’ at (1)
[-Wconversion]
cayley[~/Jfh] % ./a.out
0.6635
0.30
cayley[~/Jfh] % cayley[~/Jfh] % gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --disable-multilib --disable-werror
--enable-checking=release
Thread model: posix
gcc version 6.1.1 20160602 (GCC) 
cayley[~/Jfh] %

[Bug fortran/79312] New: Empty array in assignment not correctly type-checked

[john.harper at vuw dot ac.nz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79312

Bug ID: 79312
   Summary: Empty array in assignment not correctly type-checked
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.harper at vuw dot ac.nz
  Target Milestone: ---

This program violates f2008 syntax rule 7.2.1.2(4) but gfortran 6.1.1 on an
x86-64 system compiles and runs it, printing 0

   program emptyarray5
implicit none
real a(0)
a = [logical::]
print *,size(a)
  end program emptyarray5

! f2008 7.2.1.2 (4) if the variable is polymorphic it shall be type
! compatible with expr ; otherwise the declared types of the variable and
! expr shall conform as specified in Table 7.8,
!
! Table 7.8: Type conformance for the intrinsic assignment statement
!
! Type of the variable | Type of expr
!---+
!   integer|   integer, real, complex   |
! real |   integer, real, complex   |
!   complex|   integer, real, complex   |
!  character   |  character |
!   logical|   logical  |
!  derived type|  same derived type as the variable |
!---+

[Bug fortran/77978] New: stop codes misinterpreted in both f2003 and f2008

[john.harper at vuw dot ac.nz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77978

Bug ID: 77978
   Summary: stop codes misinterpreted in both f2003 and f2008
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.harper at vuw dot ac.nz
  Target Milestone: ---

Stop codes changed from the f2003 standard to f2008. The first of these 2 
programs has a stop code valid in f2003 but not in f2008, the second has a stop
code valid in f2008 but not in f2003. But gfortran 6.1.1 happily compiles and
runs both programs with either -std=f2003 or -f2008.

Here are the program listings, gfortran -v result, and the results of compiling
with the -std options that should not have worked:

cayley[~/Jfh] % cat stopnumber.f90
! stop666 (no space before 666) is valid f95 or f2003 but bad f2008
  implicit none
  stop666
end program
cayley[~/Jfh] % cat stopnumber2.f90
! stop expression is valid f2008 but bad f2003
  implicit none 
  stop merge(667,668,.true.)
end program 
cayley[~/Jfh] % gfortran -v
Using built-in specs.   
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/lto-wrapper  
Target: x86_64-pc-linux-gnu 
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --disable-multilib --disable-werror
--enable-checking=release  
Thread model: posix 
gcc version 6.1.1 20160602 (GCC)
cayley[~/Jfh] % gfortran -std=f2008 stopnumber.f90
cayley[~/Jfh] % ./a.out 
STOP 666
cayley[~/Jfh] % gfortran -std=f2003 stopnumber2.f90 
cayley[~/Jfh] % ./a.out
STOP 667
cayley[~/Jfh] %

[Bug fortran/81027] New: Assumed-shape array reported as deferred.

[john.harper at vuw dot ac.nz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81027

Bug ID: 81027
   Summary: Assumed-shape array reported as deferred.
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.harper at vuw dot ac.nz
  Target Milestone: ---

This program is bad because it has an assumed-shape array in an initialization
expression, but gfortran wrongly diagnoses it as a deferred array. Bug 46299
(in which gfortran accepted a bad program) may be related to this one, in which
a bad program was correctly rejected, but for the wrong reason. Here are the
program and what the compiler did with it.


cayley[~/Jfh] % cat badarray.f90
! is m assumed-shape or deferred-shape?
program badarray
  implicit none
  integer:: j(3) = [1,2,3]
  call doubling(j)
contains
  subroutine doubling(  n)
integer,intent(in)::n(:)
integer::m = size(n)
print *, m
  end subroutine doubling
end program badarray


cayley[~/Jfh] % gfortran -v -std=f2003 badarray.f90
Driving: gfortran -v -std=f2003 badarray.f90 -l gfortran -l m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --disable-multilib --disable-werror
--enable-checking=release
Thread model: posix
gcc version 6.3.1 20170109 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-std=f2003' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/f951 badarray.f90 -quiet -dumpbase
badarray.f90 -mtune=generic -march=x86-64 -auxbase badarray -std=f2003 -version
-fintrinsic-modules-path /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/finclude -o
/tmp/cctXeg2E.s
GNU Fortran (GCC) version 6.3.1 20170109 (x86_64-pc-linux-gnu)
compiled by GNU C version 6.3.1 20170109, GMP version 6.1.2, MPFR
version 3.1.5-p2, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2003 (GCC) version 6.3.1 20170109 (x86_64-pc-linux-gnu)
compiled by GNU C version 6.3.1 20170109, GMP version 6.1.2, MPFR
version 3.1.5-p2, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
badarray.f90:9:22:

 integer::m = size(n)
  1
Error: Deferred array ‘n’ at (1) is not permitted in an initialization
expression
badarray.f90:10:14:

 print *, m
  1
Error: Symbol ‘m’ at (1) has no IMPLICIT type
cayley[~/Jfh] %

[Bug fortran/82243] New: -fcheck=bounds not checking, and behaving differently with different real kinds

[john.harper at vuw dot ac.nz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82243

Bug ID: 82243
   Summary: -fcheck=bounds not checking, and behaving differently
with different real kinds
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.harper at vuw dot ac.nz
  Target Milestone: ---

-fcheck=bounds doesn't complain if LHS and RHS of real array assignments in a
subroutine are different shapes. Gfortran's behaviour depends on kind(s).

! array section assigned to array constructor of wrong shape in subroutine.
! Run-time abort if mp = kind(1d0) but no error message if mp = kind(1.0)
! Should gfortran -fcheck=bounds pick up the error? 

module globals
  implicit none
  integer,parameter::  mp = kind(1d0)
contains
  subroutine finds( n,s) 
integer,intent(in)::n
real(mp),intent(out)::s(0:)
real(mp),dimension(0:n/2+1):: even
integer:: i
even = 1.0_mp
s(0) = even(1)
s(2:n-1:2) = [(even(i),i=1,n/2)]
print *,'Sizes: LHS',size(s(2:n-1:2)),'RHS',size(even(1:n/2))
  end subroutine finds
end module globals

program gfbug3
  use globals, only: mp,finds
  implicit none
  integer:: n = 40 
  real(mp),allocatable:: s(:)
  allocate(s(0:n))
  print *,merge('Single','Double',mp==kind(1.0))//' precision'
  call finds(n,s)
  print "(20F3.0)",s(0::2)
end program gfbug3

The output did reveal the offending line:

cayley[~/Jfh] % gfortran -g -fcheck=bounds gfbug3.f90
cayley[~/Jfh] % ./a.out
 Double precision
*** Error in `./a.out': double free or corruption (!prev): 0x012fb170
***
=== Backtrace: =
/usr/lib/libc.so.6(+0x70c4b)[0x7f1e39b76c4b]
/usr/lib/libc.so.6(+0x76fe6)[0x7f1e39b7cfe6]
/usr/lib/libc.so.6(+0x777de)[0x7f1e39b7d7de]
./a.out[0x400e13]
./a.out[0x401365]
./a.out[0x4015f9]
/usr/lib/libc.so.6(__libc_start_main+0xf1)[0x7f1e39b26291]
./a.out[0x40088a]
=== Memory map: 
0040-00402000 r-xp  00:2b 11619110  
/am/roxy/home/harper/Jfh/a.out
00601000-00602000 r--p 1000 00:2b 11619110  
/am/roxy/home/harper/Jfh/a.out
00602000-00603000 rw-p 2000 00:2b 11619110  
/am/roxy/home/harper/Jfh/a.out
012f8000-01319000 rw-p  00:00 0  [heap]
7f1e3400-7f1e34021000 rw-p  00:00 0 
7f1e34021000-7f1e3800 ---p  00:00 0 
7f1e39b06000-7f1e39c9b000 r-xp  08:03 1221622   
/usr/lib/libc-2.24.so
7f1e39c9b000-7f1e39e9a000 ---p 00195000 08:03 1221622   
/usr/lib/libc-2.24.so
7f1e39e9a000-7f1e39e9e000 r--p 00194000 08:03 1221622   
/usr/lib/libc-2.24.so
7f1e39e9e000-7f1e39ea rw-p 00198000 08:03 1221622   
/usr/lib/libc-2.24.so
7f1e39ea-7f1e39ea4000 rw-p  00:00 0 
7f1e39ea4000-7f1e39ee3000 r-xp  08:03 1222012   
/usr/lib/libquadmath.so.0.0.0
7f1e39ee3000-7f1e3a0e2000 ---p 0003f000 08:03 1222012   
/usr/lib/libquadmath.so.0.0.0
7f1e3a0e2000-7f1e3a0e3000 r--p 0003e000 08:03 1222012   
/usr/lib/libquadmath.so.0.0.0
7f1e3a0e3000-7f1e3a0e4000 rw-p 0003f000 08:03 1222012   
/usr/lib/libquadmath.so.0.0.0
7f1e3a0e4000-7f1e3a0fa000 r-xp  08:03 1221717   
/usr/lib/libgcc_s.so.1
7f1e3a0fa000-7f1e3a2f9000 ---p 00016000 08:03 1221717   
/usr/lib/libgcc_s.so.1
7f1e3a2f9000-7f1e3a2fa000 r--p 00015000 08:03 1221717   
/usr/lib/libgcc_s.so.1
7f1e3a2fa000-7f1e3a2fb000 rw-p 00016000 08:03 1221717   
/usr/lib/libgcc_s.so.1
7f1e3a2fb000-7f1e3a3fe000 r-xp  08:03 1221842   
/usr/lib/libm-2.24.so
7f1e3a3fe000-7f1e3a5fd000 ---p 00103000 08:03 1221842   
/usr/lib/libm-2.24.so
7f1e3a5fd000-7f1e3a5fe000 r--p 00102000 08:03 1221842   
/usr/lib/libm-2.24.so
7f1e3a5fe000-7f1e3a5ff000 rw-p 00103000 08:03 1221842   
/usr/lib/libm-2.24.so
7f1e3a5ff000-7f1e3a72d000 r-xp  08:03 1221728   
/usr/lib/libgfortran.so.3.0.0
7f1e3a72d000-7f1e3a92d000 ---p 0012e000 08:03 1221728   
/usr/lib/libgfortran.so.3.0.0
7f1e3a92d000-7f1e3a92e000 r--p 0012e000 08:03 1221728   
/usr/lib/libgfortran.so.3.0.0
7f1e3a92e000-7f1e3a93 rw-p 0012f000 08:03 1221728   
/usr/lib/libgfortran.so.3.0.0
7f1e3a93-7f1e3a953000 r-xp  08:03 1221559   
/usr/lib/ld-2.24.so
7f1e3ab3-7f1e3ab34000 rw-p  00:00 0 
7f1e3ab51000-7f1e3ab52000 rw-p  00:00 0 
7f1e3ab52000-7f1e3ab53000 r--p 00022000 08:03 1221559   
/usr/lib/ld-2.24.so
7f1e3ab53000-7f1e3ab54000 rw-p 00023000 08:03 1221559   
/usr/lib/ld-2.24.so
7f1e3ab54000-7f1e3ab55000 rw-p  00:00 0 
7f

[Bug fortran/82049] New: ICE with character(*),parameter array constructor

[john.harper at vuw dot ac.nz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82049

Bug ID: 82049
   Summary: ICE with character(*),parameter array constructor
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.harper at vuw dot ac.nz
  Target Milestone: ---

Internal compiler error presumably due to a character parameter array
constructor.

The program (6 lines):

program ice ! f2003
  implicit none
  character(*),parameter:: filename = 'ice', stdout = '*',&
   names(2) = [character(len(filename))::filename,stdout]
  print "(2A4)",adjustr(names)
end program ice

The compile-time result with gfortran 6.3.1:

cayley[~/Jfh] % gfortran -std=f2003 gfortranice7.f90
f951: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://bugs.archlinux.org/> for instructions.
cayley[~/Jfh]

Same bad result with -std=f2008. With 3 other compilers (g95,ifort,Sun), the 
program compiled and ran, printing 

 ice   *

[Bug fortran/82709] New: f2008 complex%re and %im not yet implemented

[john.harper at vuw dot ac.nz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82709

Bug ID: 82709
   Summary: f2008 complex%re and %im not yet implemented
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.harper at vuw dot ac.nz
  Target Milestone: ---

IMHO This program is valid f2008 but gfortran won't compile it. Evidence:

cayley[~/Jfh] % cat cplx.f90
! Works with ifort -stand f95 but not gfortran -std=f2008 
  implicit none
  complex:: z = (1,2)
  print *,z%re
  print *,z%im
end program
cayley[~/Jfh] % /usr/bin/gfortran -std=f2008 cplx.f90 
cplx.f90:4:12:

   print *,z%re
1
Error: Unexpected ‘%’ for nonderived-type variable ‘z’ at (1)
cplx.f90:5:12:

   print *,z%im
1
Error: Unexpected ‘%’ for nonderived-type variable ‘z’ at (1)
cayley[~/Jfh] % /usr/bin/gfortran -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --disable-multilib --disable-werror
--enable-checking=release
Thread model: posix
gcc version 6.3.1 20170109 (GCC) 
cayley[~/Jfh] %

[Bug fortran/86021] New: ICE when initializing a character array

[john.harper at vuw dot ac.nz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86021

Bug ID: 86021
   Summary: ICE when initializing a character array
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.harper at vuw dot ac.nz
  Target Milestone: ---

On compiling this program with gfortran 7.2.1 the error message below it
appears. Is it a duplicate of bug 68155?

cayley[~/Jfh] % cat gfbug8.f90
program testgf
  implicit none
  integer,parameter:: mp=selected_real_kind(14)
  real(mp):: x
  character(precision(x)+5)::labels(3)=['my series ','intrinsic ','difference']
  print *,labels
end program testgf
cayley[~/Jfh] % gfortran gfbug8.f90
gfbug8.f90:7:0:

 end program testgf

internal compiler error: in output_constructor_regular_field, at varasm.c:5031
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://bugs.archlinux.org/> for instructions.

cayley[~/Jfh] % gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 7.2.1 20180116 (GCC) 
cayley[~/Jfh] %

[Bug fortran/88052] New: Format contravening f2008 constraint C1002 permitted

[john.harper at vuw dot ac.nz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88052

Bug ID: 88052
   Summary: Format contravening f2008 constraint C1002 permitted
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.harper at vuw dot ac.nz
  Target Milestone: ---

In the following program, F2008 constraint C1002 requires a comma between A and
F edit descriptors in a format, but the program without it compiled and ran as
if the comma was there. 

cayley[~/ANZIAM] % cat badfmt.f90
! F2008 constraint C1002 requires comma between A and F in a format
program badfmt
  implicit none
  character(40):: fmt = "(AF9.6)"
  print *,fmt
  print fmt, 'pi =',4*atan(1.0)
end program badfmt

cayley[~/ANZIAM] % gfortran badfmt.f90; ./a.out
 (AF9.6) 
pi = 3.141593
cayley[~/ANZIAM] % 


If the second print statement is changed to
  print "(AF9.6)",'pi =',4*atan(1.0)
then the error is correctly diagnosed.

[Bug fortran/100300] New: compile-time infinite loop if using execute_command_line

[john.harper at vuw dot ac.nz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100300

Bug ID: 100300
   Summary: compile-time infinite loop if using
execute_command_line
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.harper at vuw dot ac.nz
  Target Milestone: ---

The program writetest.f90 below writes a file and then uses
execute_command_line to compile readtest.f90, which was supposed to read the
file, but its syntax error drove gfortran into an infinite loop pointing the
error out. Linux system evidence:

cayley[~/Jfh] % gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror
gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (GCC)

cayley[~/Jfh] % cat writetest.f90
! Use execute_command_line to start a second program readtest.f90 that
! reads a file, testfile.txt, written by this program.
  implicit none
  integer u,i
  open(newunit=u,file='testfile.txt',action='WRITE',position='REWIND',&
   form='FORMATTED',access='SEQUENTIAL')
  write(u,"(A,I0)") ('line ',i,i=1,2)
  call execute_command_line('gfortran readtest.f90 ; ./a.out')
end program

cayley[~/Jfh] % cat readtest.f90
  implicit none
  character(40) lines(2)
  integer u
  open(newunit=u,,file='testfile.txt')
  read(u,"(A)") lines(:)
  print  "(A)",'readtest gave '//lines(:)
end program

The second program has a syntax error (,,) correctly found by gfortran but 
compiling it by calling execute_command_line in the first program gave an
infinite loop repeating this 5-line message until I stopped it manually:
quote--
readtest.f90:4:18:

4 |   open(newunit=u,,file='testfile.txt')
  |  1
Error: Syntax error in OPEN statement at (1)
unquote

Correcting the error by removing one of the commas made the program compile
and run.

[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.

[john.harper at vuw dot ac.nz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022

--- Comment #15 from john.harper at vuw dot ac.nz ---
My previous test program tried Ex0.0E0 output but not Ex0.0, where x is 
N,S, or absent. Below is a revised version which includes all 6 cases. 
It also tries EN and ES before trying E, with an error stop if an error
is detected. Below the program is its output from ifort, which I think 
is f2018-compliant, compiled with options -standard-semantics -check all

(All lines of gfortran output after the first appeared to be wrong.)

program testen0es0e0 ! EN0.0,ES0.0 good f2018, E0.0 bad, with E0 or not
   integer,parameter::p1 = kind(1e0), p2 = kind(1d0), &
p3 = selected_real_kind(precision(1.0_p2)+1), &
hp = selected_real_kind(precision(1.0_p3)+1), &
p4 = merge(hp,p3,hp>0) ! in gfortran p4 /= p3, in ifort p4 == p3
   character:: ens(3)*2=["EN","ES"," E"],e0(2)*2=["  ","E0"], fmt*14, &
msg*200
   integer iens,ie0,ios
   write(*,"(A,4(1X,I0))") 'real kinds',p1,p2,p3,p4
   do iens = 1,3
  do ie0 = 1,2
 fmt = "(A,1X,"//ens(iens)//"0.0"//e0(ie0)//")"
 write(*, fmt,iostat=ios,iomsg=msg) 'With '//fmt, 666.0_p1
 if(ios/=0) error stop trim(msg)
 write(*, fmt) 'With '//fmt, 666.0_p2
 write(*, fmt) 'With '//fmt, 666.0_p3
 if(p3/=p4) write(*, fmt) 'With '//fmt, 666.0_p4
  end do
   end do
end program testen0es0e0

real kinds 4 8 16 16
With (A,1X,EN0.0  ) 666.E+00
With (A,1X,EN0.0  ) 666.E+00
With (A,1X,EN0.0  ) 666.E+00
With (A,1X,EN0.0E0) 666.E+0
With (A,1X,EN0.0E0) 666.E+0
With (A,1X,EN0.0E0) 666.E+0
With (A,1X,ES0.0  ) 7.E+02
With (A,1X,ES0.0  ) 7.E+02
With (A,1X,ES0.0  ) 7.E+02
With (A,1X,ES0.0E0) 7.E+2
With (A,1X,ES0.0E0) 7.E+2
With (A,1X,ES0.0E0) 7.E+2
With (A,1X, E0.0  ) *
output conversion error, unit 6, file /dev/pts/0


-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz

[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.

[john.harper at vuw dot ac.nz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022

--- Comment #20 from john.harper at vuw dot ac.nz ---
With the first test case all the EN outputs were 666. but the Fortran 2018
standard 13.7.2.3.4 paragraph 2 requires that EN0.0 produce 666.E+0 but 
Table 13.2 first ENw.d line appears to require either 666.E+00 or 666.+000 
unless my copy of F2018 is out of date. (I note that the F2023 standard 
removed the ambiguity by including "with w > 0" in the offending line of 
Table 13.2.) However F2018 is unambiguous and agrees with F2023 on 
EN0.0E0, requiring 666.E+0

With the second test case, which used 66600, I think all Jerry's outputs 
are correct.

On Mon, 4 Sep 2023, jvdelisle at gcc dot gnu.org wrote:

> Date: Mon, 4 Sep 2023 17:12:30 +
> From: jvdelisle at gcc dot gnu.org 
> To: John Harper 
> Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too
>  high.
> Resent-Date: Tue, 5 Sep 2023 05:12:45 +1200 (NZST)
> Resent-From: 
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
>
> --- Comment #18 from Jerry DeLisle  ---
> With Johns test case from Comment #15 and the patch in Comment #17 I get the
> following:
>
> $ ./a.out
> real kinds 4 8 10 16
> With (A,1X,EN0.0  ) 666.
> With (A,1X,EN0.0  ) 666.
> With (A,1X,EN0.0  ) 666.
> With (A,1X,EN0.0  ) 666.
> With (A,1X,EN0.0E0) 666.
> With (A,1X,EN0.0E0) 666.
> With (A,1X,EN0.0E0) 666.
> With (A,1X,EN0.0E0) 666.
> With (A,1X,ES0.0  ) 7.E+2
> With (A,1X,ES0.0  ) 7.E+2
> With (A,1X,ES0.0  ) 7.E+2
> With (A,1X,ES0.0  ) 7.E+2
> With (A,1X,ES0.0E0) 7.E+2
> With (A,1X,ES0.0E0) 7.E+2
> With (A,1X,ES0.0E0) 7.E+2
> With (A,1X,ES0.0E0) 7.E+2
> ERROR STOP Scale factor out of range in format specifier 'E' or 'D'
>
> Notice that the width of exponents is also minimized and where the exponent is
> zero it is not shown at all.  If I do specify an exponent width it shown. For
> example with exponent width of 4 and changing the value to 66600 I get:
>
> $ ./a.out
> real kinds 4 8 10 16
> With (A,1X,EN0.0  ) 67.E+3
> With (A,1X,EN0.0  ) 67.E+3
> With (A,1X,EN0.0  ) 67.E+3
> With (A,1X,EN0.0  ) 67.E+3
> With (A,1X,EN0.0E4) 67.E+0003
> With (A,1X,EN0.0E4) 67.E+0003
> With (A,1X,EN0.0E4) 67.E+0003
> With (A,1X,EN0.0E4) 67.E+0003
> With (A,1X,ES0.0  ) 7.E+4
> With (A,1X,ES0.0  ) 7.E+4
> With (A,1X,ES0.0  ) 7.E+4
> With (A,1X,ES0.0  ) 7.E+4
> With (A,1X,ES0.0E4) 7.E+0004
> With (A,1X,ES0.0E4) 7.E+0004
> With (A,1X,ES0.0E4) 7.E+0004
> With (A,1X,ES0.0E4) 7.E+0004
> ERROR STOP Scale factor out of range in format specifier 'E' or 'D'
>
> This seems reasonable to me. Other opinions?
>
> -- 
> You are receiving this mail because:
> You reported the bug.
>


-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz

[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.

[john.harper at vuw dot ac.nz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022

--- Comment #23 from john.harper at vuw dot ac.nz ---
Jerry

I agree that that's what the standard says, though I find it odd that it
allows neither 666E0 nor 666E+0 nor 666+0 in output, because any of the 
three would be valid input of the real value 666. But you are editing a 
compiler to comply with the standard, and neither of us is editing the 
standard itself :-)

John

On Sun, 15 Oct 2023, jvdelisle at gcc dot gnu.org wrote:

> Date: Sun, 15 Oct 2023 02:12:25 +
> From: jvdelisle at gcc dot gnu.org 
> To: John Harper 
> Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too
>  high.
> Resent-Date: Sun, 15 Oct 2023 15:13:03 +1300 (NZDT)
> Resent-From: 
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
>
> --- Comment #22 from Jerry DeLisle  ---
> Sorry for delays.  I am back looking at this.
>
> My take on the table 13.2 for the case: EN0.0E0
>
> No matter what the E for the exponent must be shown.
>
> If the exponent is 0 then a plus sign must be shown.
>
> The value for 666. then must be 666.E+0
>
> -- 
> You are receiving this mail because:
> You reported the bug.
>


-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz

[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.

[john.harper at vuw dot ac.nz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022

--- Comment #5 from john.harper at vuw dot ac.nz ---
True. I reported the bug because in ESw.dEe output format all 3 of w,d,e 
may be 0, but gfortran then gave the right numerical result in the wrong 
format with my test programs. (I'm told NAG hasn't yet implemented ES0.0E0 
but ifort has got it right.)

  On Wed, 16 Aug 2023, jvdelisle at gcc dot gnu.org wrote:

> Date: Wed, 16 Aug 2023 03:39:58 +
> From: jvdelisle at gcc dot gnu.org 
> To: John Harper 
> Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too
>  high.
> Resent-Date: Wed, 16 Aug 2023 15:40:09 +1200 (NZST)
> Resent-From: 
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
>
> --- Comment #4 from Jerry DeLisle  ---
> The relative text in the standard is:
>
> 13.7.2.1 General rules
> --- snip ---
> (6) On output, with I, B, O, Z, D, E, EN, ES, EX, F, and G editing, the
> specified value of the field width w may be zero. In such cases, the processor
> selects the smallest positive actual field width that does not result in a
> field filled with asterisks. The specified value of w shall not be zero on
> input.
>
> -- 
> You are receiving this mail because:
> You reported the bug.
>


-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz

[Bug fortran/111022] New: ES0.0E0 format gave ES0.dE0 output with d too high.

[john.harper at vuw dot ac.nz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022

Bug ID: 111022
   Summary: ES0.0E0 format gave ES0.dE0 output with d too high.
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.harper at vuw dot ac.nz
  Target Milestone: ---

This 3-line Fortran program:

  print "(ES0.0E0)", -666e0
  print "(ES0.0E0)", -666d0
  end program

printed

-6.66000E+2
-6.66000E+2

but I think it should have printed 

-7.E+2
-7.E+2

which is what ifort printed with the same program.

[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.

[john.harper at vuw dot ac.nz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022

--- Comment #11 from john.harper at vuw dot ac.nz ---
Jerry's test program is identical with mine. 
Because E format is supposed to give no digits before the decimal point 
except possibly a leading zero, E0.0 and E0.0E0 are both pointless, and 
Steve Lionel pointed out in Fortran Discourse that the standard forbids 
them because they would generate an illegal value of k for the kP edit
descriptor (which happens not to be explicitly used here.) So I think
gfortran ought to give a run-time error for it. If I compiled the program 
with ifort and more warning options, the first 2 write statements gave

real kinds 4 8 16 16
With (A,1X, E0.0E0)  *
forrtl: error (63): output conversion error, unit 6, file /dev/pts/1

The ES result from gfortran was correct and standard-conforming. The EN
one should have said 666.E+0 not 666.

  On Sun, 27 Aug 2023, jvdelisle at gcc dot gnu.org wrote:

> Date: Sun, 27 Aug 2023 15:38:33 +
> From: jvdelisle at gcc dot gnu.org 
> To: John Harper 
> Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too
>  high.
> Resent-Date: Mon, 28 Aug 2023 03:38:51 +1200 (NZST)
> Resent-From: 
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
>
> --- Comment #9 from Jerry DeLisle  ---
> I am using this:
>
> program teste0es0en0
>  integer,parameter::p1 = kind(1e0), p2 = kind(1d0), &
>   p3 = selected_real_kind(precision(1.0_p2)+1), &
>   hp = selected_real_kind(precision(1.0_p3)+1), &
>   p4 = merge(hp,p3,hp>0) ! in gfortran p4 /= p3, in ifort p4 == p3
>  character(*),parameter:: fmt(3) = "(A,1X,"//[" E","ES","EN"]//"0.0E0) "
>  integer ifmt
>  write(*,"(A,4(1X,I0))") 'real kinds',p1,p2,p3,p4
>  do ifmt = 1,3
> write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p1
> write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p2
> write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p3
> if(p3/=p4) write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p4
>  end do
> end program teste0es0en0
>
> And I get the following output with some test patching:
>
> $ ./a.out
> real kinds 4 8 10 16
> With (A,1X, E0.0E0)  1.E+3
> With (A,1X, E0.0E0)  1.E+3
> With (A,1X, E0.0E0)  1.E+3
> With (A,1X, E0.0E0)  1.E+3
> With (A,1X,ES0.0E0)  7.E+2
> With (A,1X,ES0.0E0)  7.E+2
> With (A,1X,ES0.0E0)  7.E+2
> With (A,1X,ES0.0E0)  7.E+2
> With (A,1X,EN0.0E0)  666.
> With (A,1X,EN0.0E0)  666.
> With (A,1X,EN0.0E0)  666.
> With (A,1X,EN0.0E0)  666.
>
> -- 
> You are receiving this mail because:
> You reported the bug.
>


-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz

[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.

[john.harper at vuw dot ac.nz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022

--- Comment #13 from john.harper at vuw dot ac.nz ---
Hmmm. If I read anlauf correctly, our versions of ifort differ when 
writing ES0.0E0 and EN0.0E0 with the value 666.0. Both give the same 
correct numerical values but one version omits the E in the output. 
Omitting it does write the value in the shortest possible space but 
disobeys the F2018 and F2023 standards, where 13.7.2.3.4 Table 13.2 and 
13.7.2.3.5 Table 13.3 require ENw.dE0 and ESw.dE0 to include E in the 
output.

  On Sun, 27 Aug 2023, anlauf at gcc dot gnu.org wrote:

> Date: Sun, 27 Aug 2023 19:41:10 +
> From: anlauf at gcc dot gnu.org 
> To: John Harper 
> Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too
>  high.
> Resent-Date: Mon, 28 Aug 2023 07:41:23 +1200 (NZST)
> Resent-From: 
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
>
> --- Comment #10 from anlauf at gcc dot gnu.org ---
> (In reply to Jerry DeLisle from comment #9)
>> I am using this:
>>
>> program teste0es0en0
>>   integer,parameter::p1 = kind(1e0), p2 = kind(1d0), &
>>p3 = selected_real_kind(precision(1.0_p2)+1), &
>>hp = selected_real_kind(precision(1.0_p3)+1), &
>>p4 = merge(hp,p3,hp>0) ! in gfortran p4 /= p3, in ifort p4 == p3
>>   character(*),parameter:: fmt(3) = "(A,1X,"//[" E","ES","EN"]//"0.0E0) "
>>   integer ifmt
>>   write(*,"(A,4(1X,I0))") 'real kinds',p1,p2,p3,p4
>>   do ifmt = 1,3
>>  write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p1
>>  write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p2
>>  write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p3
>>  if(p3/=p4) write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p4
>>   end do
>> end program teste0es0en0
>>
>> And I get the following output with some test patching:
>>
>> $ ./a.out
>> real kinds 4 8 10 16
>> With (A,1X, E0.0E0)  1.E+3
>> With (A,1X, E0.0E0)  1.E+3
>> With (A,1X, E0.0E0)  1.E+3
>> With (A,1X, E0.0E0)  1.E+3
>> With (A,1X,ES0.0E0)  7.E+2
>> With (A,1X,ES0.0E0)  7.E+2
>> With (A,1X,ES0.0E0)  7.E+2
>> With (A,1X,ES0.0E0)  7.E+2
>> With (A,1X,EN0.0E0)  666.
>> With (A,1X,EN0.0E0)  666.
>> With (A,1X,EN0.0E0)  666.
>> With (A,1X,EN0.0E0)  666.
>
> Intel does not like E0.0E0, thus running with do ifmt = 2,3 gives:
>
> real kinds 4 8 16 16
> With (A,1X,ES0.0E0) 7.+2
> With (A,1X,ES0.0E0) 7.+2
> With (A,1X,ES0.0E0) 7.+2
> With (A,1X,EN0.0E0) 666.+0
> With (A,1X,EN0.0E0) 666.+0
> With (A,1X,EN0.0E0) 666.+0
>
> -- 
> You are receiving this mail because:
> You reported the bug.
>


-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz

[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.

[john.harper at vuw dot ac.nz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022

--- Comment #14 from john.harper at vuw dot ac.nz ---
To add to my email copied below, you may find a reference to the standards 
helpful. k is the scale factor referred to in F2018 or F2023 13.7.2.3.3. 
The last paragraph of that says that in Ew.d and Ew.dE0 output format, one 
of these two inequalities must be satisfied: -d < k <= 0 or 0 < k < d+2.
With either E0.0 or E0.0E0 the value of k is not permitted.

On Sun, 27 Aug 2023, john.harper at vuw dot ac.nz wrote:

> Date: Sun, 27 Aug 2023 21:40:58 +
> From: john.harper at vuw dot ac.nz 
> To: John Harper 
> Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too
>  high.
> Resent-Date: Mon, 28 Aug 2023 09:41:10 +1200 (NZST)
> Resent-From: 
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
>
> --- Comment #11 from john.harper at vuw dot ac.nz ---
> Jerry's test program is identical with mine.
> Because E format is supposed to give no digits before the decimal point
> except possibly a leading zero, E0.0 and E0.0E0 are both pointless, and
> Steve Lionel pointed out in Fortran Discourse that the standard forbids
> them because they would generate an illegal value of k for the kP edit
> descriptor (which happens not to be explicitly used here.) So I think
> gfortran ought to give a run-time error for it. If I compiled the program
> with ifort and more warning options, the first 2 write statements gave
>
> real kinds 4 8 16 16
> With (A,1X, E0.0E0)  *
> forrtl: error (63): output conversion error, unit 6, file /dev/pts/1
>
> The ES result from gfortran was correct and standard-conforming. The EN
> one should have said 666.E+0 not 666.
>
>  On Sun, 27 Aug 2023, jvdelisle at gcc dot gnu.org wrote:
>
>> Date: Sun, 27 Aug 2023 15:38:33 +
>> From: jvdelisle at gcc dot gnu.org 
>> To: John Harper 
>> Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d 
>> too
>>  high.
>> Resent-Date: Mon, 28 Aug 2023 03:38:51 +1200 (NZST)
>> Resent-From: 
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
>>
>> --- Comment #9 from Jerry DeLisle  ---
>> I am using this:
>>
>> program teste0es0en0
>>  integer,parameter::p1 = kind(1e0), p2 = kind(1d0), &
>>   p3 = selected_real_kind(precision(1.0_p2)+1), &
>>   hp = selected_real_kind(precision(1.0_p3)+1), &
>>   p4 = merge(hp,p3,hp>0) ! in gfortran p4 /= p3, in ifort p4 == p3
>>  character(*),parameter:: fmt(3) = "(A,1X,"//[" E","ES","EN"]//"0.0E0) "
>>  integer ifmt
>>  write(*,"(A,4(1X,I0))") 'real kinds',p1,p2,p3,p4
>>  do ifmt = 1,3
>> write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p1
>> write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p2
>> write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p3
>> if(p3/=p4) write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p4
>>  end do
>> end program teste0es0en0
>>
>> And I get the following output with some test patching:
>>
>> $ ./a.out
>> real kinds 4 8 10 16
>> With (A,1X, E0.0E0)  1.E+3
>> With (A,1X, E0.0E0)  1.E+3
>> With (A,1X, E0.0E0)  1.E+3
>> With (A,1X, E0.0E0)  1.E+3
>> With (A,1X,ES0.0E0)  7.E+2
>> With (A,1X,ES0.0E0)  7.E+2
>> With (A,1X,ES0.0E0)  7.E+2
>> With (A,1X,ES0.0E0)  7.E+2
>> With (A,1X,EN0.0E0)  666.
>> With (A,1X,EN0.0E0)  666.
>> With (A,1X,EN0.0E0)  666.
>> With (A,1X,EN0.0E0)  666.
>>
>> --
>> You are receiving this mail because:
>> You reported the bug.
>>
>
>
> -- John Harper, School of Mathematics and Statistics
> Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
> e-mail john.har...@vuw.ac.nz
>
> -- 
> You are receiving this mail because:
> You reported the bug.
>


-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz

[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.

[john.harper at vuw dot ac.nz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022

--- Comment #8 from john.harper at vuw dot ac.nz ---
I couldn't see the program teste0es0en0.f90 that is in your bugzilla but 
I could see that it does have 691 bytes. So does one of the two versions 
that I now have in my own computer. The attachment to this email contains 
that version and what ifort did with it. (Of course E0.0E0 is illegal 
Fortran but ES0.0E0 and EN0.0E0 are OK according to both the f2018 and 
f2023 standards.)

On Sat, 26 Aug 2023, jvdelisle at gcc dot gnu.org wrote:

> Date: Sat, 26 Aug 2023 04:26:51 +
> From: jvdelisle at gcc dot gnu.org 
> To: John Harper 
> Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too
>  high.
> Resent-Date: Sat, 26 Aug 2023 16:27:07 +1200 (NZST)
> Resent-From: 
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
>
> Jerry DeLisle  changed:
>
>   What|Removed |Added
> 
> Status|NEW |ASSIGNED
>
> --- Comment #7 from Jerry DeLisle  ---
> I don't have ifort installed at the moment. Would someone post the output from
> ifort with teste0es0en0.f90 attached to this PR? Much appreciated.
>
> -- 
> You are receiving this mail because:
> You reported the bug.
>


-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz

[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.

[john.harper at vuw dot ac.nz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022

--- Comment #2 from john.harper at vuw dot ac.nz ---
Further information on this bug: it affects all four real kinds with all 
three of E0.0E0, ES0.0E0 and EN0.0E0 formats. My 15-line test program for 
that is attached. I hope it helps.

  On Tue, 15 Aug 2023, anlauf at gcc dot gnu.org wrote:

> Date: Tue, 15 Aug 2023 19:45:06 +
> From: anlauf at gcc dot gnu.org 
> To: John Harper 
> Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too
>  high.
> Resent-Date: Wed, 16 Aug 2023 07:45:16 +1200 (NZST)
> Resent-From: 
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
>
> anlauf at gcc dot gnu.org changed:
>
>   What|Removed |Added
> 
> Status|UNCONFIRMED |NEW
> Ever confirmed|0   |1
> CC||jvdelisle at gcc dot gnu.org
>  Component|fortran |libfortran
>   Keywords||wrong-code
>   Last reconfirmed||2023-08-15
>
> --- Comment #1 from anlauf at gcc dot gnu.org ---
> Confirmed.
>
> @Jerry: can you have a look?  F2008 did not specify w=0 for the ES format;
> this was added in F2018.
>
> -- 
> You are receiving this mail because:
> You reported the bug.
>


-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz

[Bug fortran/105473] New: semicolon allowed when list-directed read integer with decimal='point'

[john.harper at vuw dot ac.nz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473

Bug ID: 105473
   Summary: semicolon allowed when list-directed read integer with
decimal='point'
   Product: gcc
   Version: 9.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.harper at vuw dot ac.nz
  Target Milestone: ---

List-directed reading of a number should give an error if it reads a semicolon
and decimal is not COMMA but this 9-line program gave the output shown below
it.
(The ifort compiler gave a positive value of ios, which I believe was correct.)

! Does list-directed reading an integer allow some non-integer input?
  implicit none
  integer n,ios
  character(1):: testinput = ';'
  print *,'testinput = "',testinput,'"'
  read(testinput,*,decimal='point',iostat=ios) n
  print *,'n=',n,' ios=',ios
  if(ios>0) print *,'testinput was not an integer'
end program

john@johns-laptop:~/Jfh$ ./a.out
 testinput = ";"
 n=  1458129152  ios=   0
john@johns-laptop:~/Jfh$

[Bug fortran/107874] merge not using all its arguments

[john.harper at vuw dot ac.nz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874

--- Comment #21 from john.harper at vuw dot ac.nz ---
I now have a new test case that avoids the possibility of recursive I/O
by tstuff and fstuff doing internal writes to two different character 
variables. It still reveals the merge problem. It compiles and runs with
gfortran-12 and ifort, giving different outputs.

! Must merge evaluate all 3 arguments?
program testmerge10
   implicit none
   character(7):: string(2) = ' '
   logical:: x(2) = [.true., .false.], y
   integer i
   do i = 1,2
  y = merge(tstuff(),fstuff(),x(i))
  print *,y,string
  string = ' '
   end do
contains

logical function tstuff()
 write(string(1),"(A)") ' tstuff'
 tstuff = .true.
   end function tstuff

   logical function fstuff()
 write(string(2),"(A)") ' fstuff'
 fstuff = .false.
   end function fstuff
end program testmerge10

Good luck with your bughunt!
John H

On Fri, 2 Dec 2022, anlauf at gcc dot gnu.org wrote:

> Date: Fri, 2 Dec 2022 21:05:43 +
> From: anlauf at gcc dot gnu.org 
> To: John Harper 
> Subject: [Bug fortran/107874] merge not using all its arguments
> Resent-Date: Sat, 3 Dec 2022 10:05:53 +1300 (NZDT)
> Resent-From: 
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
>
> --- Comment #19 from anlauf at gcc dot gnu.org ---
> (In reply to john.harper from comment #18)
>> An interesting problem! But I thought my original test case did not have
>> recursive I/O because tstuff and fstuff each print something in the
>> statement
>> y = merge(tstuff(),fstuff(),x(i))
>> but y itself is printed only in the next statement,
>> print *,y
>
> John, your original testcase in comment#0 was fine.
> I tried to extend it to check for constant as well as non-constant mask,
> and as you see I made a mistake by trying to make it smaller.  Bad idea.
>
>> Or does evaluating merge allow each of tstuff and fstuff to be evaluated
>> at the same time? I was thinking of tstuff and fstuff being evaluated
>> in succession but could there be systems in which they are evaluated
>> simultaneously?
>
> I don't recall having seen a mentioning in the standard of the order of
> evaluation of different function (or subroutine) arguments.  Do you?
>
> (Of course, if side-effects happen during that evaluation, such as I/O,
> unexpected things may happen.)
>
>> If so, whether the program is valid Fortran depends on the
>> kind of system on which it is being executed.
>
> Well, even if the print in tstuff/fstuff were a problem, one could construct
> other testcases with side-effects that might be conforming.
>
> -- 
> You are receiving this mail because:
> You reported the bug.
>


-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz phone +64(0) 4 463 5276

[Bug fortran/107874] merge not using all its arguments

[john.harper at vuw dot ac.nz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874

--- Comment #18 from john.harper at vuw dot ac.nz ---
An interesting problem! But I thought my original test case did not have 
recursive I/O because tstuff and fstuff each print something in the 
statement
y = merge(tstuff(),fstuff(),x(i))
but y itself is printed only in the next statement,
print *,y

Or does evaluating merge allow each of tstuff and fstuff to be evaluated
at the same time? I was thinking of tstuff and fstuff being evaluated
in succession but could there be systems in which they are evaluated 
simultaneously? If so, whether the program is valid Fortran depends on the
kind of system on which it is being executed.

John Harper

On Fri, 2 Dec 2022, anlauf at gcc dot gnu.org wrote:

> Date: Fri, 2 Dec 2022 20:22:23 +
> From: anlauf at gcc dot gnu.org 
> To: John Harper 
> Subject: [Bug fortran/107874] merge not using all its arguments
> Resent-Date: Sat, 3 Dec 2022 09:22:36 +1300 (NZDT)
> Resent-From: 
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
>
> --- Comment #17 from anlauf at gcc dot gnu.org ---
> (In reply to Jerry DeLisle from comment #16)
>> (In reply to anlauf from comment #15)
>> --- snip ---
>>> Can you please verify?
>>
>> Yes, this fixes the test case.
>
> OK, thanks for confirming.
>
>> However if the orginal test case is valid
>> fortran we probably need to fix something else. Paul Thomas was noticing a
>> similar problem with his Finalization patches.  He was doing the
>> finalization inside trans_transfer or similar so it was blocking on a mutex
>> trying to finalize in the middle of an I/O operation.
>>
>> So in this case, my guess is the merge expression needs to be resolved
>> before the translation phase.
>
> If I interprete the tree-dump correctly, we have e.g.:
>
>  _gfortran_st_write (_parm.2);
>  {
>logical(kind=4) D.4279;
>logical(kind=4) D.4280;
>logical(kind=4) D.4281;
>logical(kind=4) D.4282;
>
>D.4279 = tstuff ();
>D.4280 = fstuff ();
>D.4281 = x[(integer(kind=8)) i + -1];
>D.4282 = D.4281 ? D.4279 : D.4280;
>_gfortran_transfer_logical_write (_parm.2, , 4);
>  }
>  _gfortran_st_write_done (_parm.2);
>
> so we start the write, then evaluate the merge(), which is tstuff()/fstuff(),
> and which does its own I/O, and then return to continue with the transfer.
>
> So this might be non-conforming code, see
>
> F2018:12.12 Restrictions on input/output statements
>
> (2) An input/output statement that is executed while another input/output
> statement is being executed is a recursive input/output statement.
> A recursive input/output statement shall not identify an external unit that
> is identified by another input/output statement being executed except that
> a child data transfer statement may identify its parent data transfer
> statement external unit.
>
> I am not sure I fully understand the last sentence in this paragraph,
> but I think the pushed testcase might be invalid and should be replaced.
>
> If you agree, I'll simply do this.
>
> -- 
> You are receiving this mail because:
> You reported the bug.
>


-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz phone +64(0) 4 463 5276

[Bug fortran/107874] New: merge not using all its arguments

[john.harper at vuw dot ac.nz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874

Bug ID: 107874
   Summary: merge not using all its arguments
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.harper at vuw dot ac.nz
  Target Milestone: ---

The F2018 standard 15.5.3 requires all actual arguments in a function reference
to be evaluated.

In the program below, merge has three scalar arguments; ifort evaluates
all three, gfortran evaluates only the useful two, which violates 15.5.3.

program testmerge9
  implicit none
  integer i
  logical:: x(2)=(/.true., .false./), y ! avoiding [ ] allows f95 option
  do i = 1,2
 y = merge(tstuff(),fstuff(),x(i))
 print *,y
  end do
contains
  logical function tstuff()
print *,'tstuff'
tstuff = .true.
  end function tstuff

  logical function fstuff()
print *,'fstuff'
fstuff = .false.
  end function fstuff
end program testmerge9

Steve Kargl said "Looks like a bug. Feel free to send a bug report with this
patch."

diff --git a/gcc/fortran/trans-intrinsic.cc b/gcc/fortran/trans-intrinsic.cc
index bb938026828..c5b63d356e1 100644
--- a/gcc/fortran/trans-intrinsic.cc
+++ b/gcc/fortran/trans-intrinsic.cc
@@ -7538,9 +7538,9 @@ gfc_conv_intrinsic_merge (gfc_se * se, gfc_expr * expr)
   gfc_conv_intrinsic_function_args (se, expr, args, num_args);
   if (expr->ts.type != BT_CHARACTER)
 {
-  tsource = args[0];
-  fsource = args[1];
-  mask = args[2];
+  tsource = gfc_evaluate_now (args[0], >pre);
+  fsource = gfc_evaluate_now (args[1], >pre);
+  mask = gfc_evaluate_now (args[2], >pre);
 }
   else
 {

[Bug fortran/109186] New: nearest(huge(x),-1.0_kind(x)) half of correct value

[john.harper at vuw dot ac.nz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109186

Bug ID: 109186
   Summary: nearest(huge(x),-1.0_kind(x)) half of correct value
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.harper at vuw dot ac.nz
  Target Milestone: ---

With all four real kinds available in gfortran_12 nearest(x,y) with x = huge
and y = -1 this program gave about half the correct result. Ifort gave correct
results for the 3 different kinds it has: sp,dp,qp.

The program:

  implicit none
  integer,parameter::sp = kind(1.0), dp=kind(1d0), ncases = 2, &
   ep = selected_real_kind(18),qp = selected_real_kind(33)
  character(*),parameter:: fmt(4) = &
   "(A,ES"//["16.08E2","26.17E3","30.20E4","44.34E4"]//")"
  character(24),dimension(2):: splist,dplist,eplist,qplist 
  integer n
  real(sp),parameter::sp1 = 1.0_sp
  real(sp):: spx(ncases) = [huge(sp1),nearest(huge(sp1),-sp1)]
  data splist/'huge(sp1)','nearest(huge(sp1),-sp1)'/
  real(dp),parameter::dp1 = 1.0_dp
  real(dp):: dpx(ncases) = [huge(dp1),nearest(huge(dp1),-dp1)]
  data dplist/'huge(dp1)','nearest(huge(dp1),-dp1)'/
  real(ep),parameter::ep1 = 1.0_ep
  real(ep):: epx(ncases) = [huge(ep1),nearest(huge(ep1),-ep1)]
  data eplist/'huge(ep1)','nearest(huge(ep1),-ep1)'/
  real(qp),parameter::qp1 = 1.0_qp
  real(qp):: qpx(ncases) = [huge(qp1),nearest(huge(qp1),-qp1)]
  data qplist/'huge(qp1)','nearest(huge(qp1),-qp1)'/

  print fmt(1),(splist(n),spx(n),n=1,ncases)
  print fmt(2),(dplist(n),dpx(n),n=1,ncases)
  print fmt(3),(eplist(n),epx(n),n=1,ncases)
  print fmt(4),(qplist(n),qpx(n),n=1,ncases)
end program

The output on ubuntu (Linux 86_64)
huge(sp1) 3.40282347E+38
nearest(huge(sp1),-sp1)   1.70141173E+38
huge(dp1) 1.79769313486231571E+308
nearest(huge(dp1),-dp1)   8.98846567431157854E+307
huge(ep1) 1.18973149535723176502E+4932
nearest(huge(ep1),-ep1)   5.94865747678615882511E+4931
huge(qp1) 1.1897314953572317650857593266280070E+4932
nearest(huge(qp1),-qp1)   5.9486574767861588254287966331400351E+4931

[Bug fortran/109186] nearest(huge(x),-1.0_kind(x)) half of correct value

[john.harper at vuw dot ac.nz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109186

--- Comment #2 from john.harper at vuw dot ac.nz ---
The results I expected were that

nearest(huge(sp1),-sp1) would be near huge(sp1)/(1+epsilon(sp1)),
nearest(huge(dp1),-dp1) would be near huge(dp1)/(1+epsilon(dp1)),
nearest(huge(ep1),-ep1) would be near huge(ep1)/(1+epsilon(ep1)),
nearest(huge(qp1),-qp1) would be near huge(qp1)/(1+epsilon(qp1)).

The results from gfortran were different from those by a factor near 2.
On compiling with ifort I got results close to what I had expected, which
is why I thought the bug was not in my program. The g95 compiler (now 
about 10 years old) gave results identical to those of ifort except
for ep = selected_real_kind(18) which ifort treats as if it were 
selected_real_kind(33) because ifort has only three real kinds.

By the way I thought I was using gfortran 12.0. Compiling with -v said
GNU Fortran (Ubuntu 12.1.0-2ubuntu1~22.04) version 12.1.0 
(x86_64-linux-gnu)
I wish to apologise for that error in my bug report. I got the same output
on another machine with GNU Fortran (GCC) version 12.2.0 
(x86_64-pc-linux-gnu)

The factor 2 discrepancies become clearer in this version of my program,
which has 4 more lines printing huge/nearest for the 4 real kinds.

program nearesttest3
   implicit none
   integer,parameter::sp = kind(1.0), dp=kind(1d0), ncases = 2, &
ep = selected_real_kind(18),qp = selected_real_kind(33)
   character(*),parameter:: fmt(4) = &
"(A,ES"//["16.08E2","26.17E3","30.20E4","44.34E4"]//")"
   character(24),dimension(2):: splist,dplist,eplist,qplist
   integer n
   real(sp),parameter::sp1 = 1.0_sp
   real(sp):: spx(ncases) = [huge(sp1),nearest(huge(sp1),-sp1)]
   data splist/'huge(sp1)','nearest(huge(sp1),-sp1)'/
   real(dp),parameter::dp1 = 1.0_dp
   real(dp):: dpx(ncases) = [huge(dp1),nearest(huge(dp1),-dp1)]
   data dplist/'huge(dp1)','nearest(huge(dp1),-dp1)'/
   real(ep),parameter::ep1 = 1.0_ep
   real(ep):: epx(ncases) = [huge(ep1),nearest(huge(ep1),-ep1)]
   data eplist/'huge(ep1)','nearest(huge(ep1),-ep1)'/
   real(qp),parameter::qp1 = 1.0_qp
   real(qp):: qpx(ncases) = [huge(qp1),nearest(huge(qp1),-qp1)]
   data qplist/'huge(qp1)','nearest(huge(qp1),-qp1)'/

   print fmt(1),(splist(n),spx(n),n=1,ncases)
   print fmt(1),'huge/nearest = ',huge(sp1)/nearest(huge(sp1),-sp1)
   print fmt(2),(dplist(n),dpx(n),n=1,ncases)
   print fmt(2),'huge/nearest = ',huge(dp1)/nearest(huge(dp1),-dp1)
   print fmt(3),(eplist(n),epx(n),n=1,ncases)
   print fmt(3),'huge/nearest = ',huge(ep1)/nearest(huge(ep1),-ep1)
   print fmt(4),(qplist(n),qpx(n),n=1,ncases)
   print fmt(4),'huge/nearest = ',huge(qp1)/nearest(huge(qp1),-qp1)
end program nearesttest3

Its gfortran output:

huge(sp1) 3.40282347E+38
nearest(huge(sp1),-sp1)   1.70141173E+38
huge/nearest =   2.E+00
huge(dp1) 1.79769313486231571E+308
nearest(huge(dp1),-dp1)   8.98846567431157854E+307
huge/nearest =   2.0E+000
huge(ep1) 1.18973149535723176502E+4932
nearest(huge(ep1),-ep1)   5.94865747678615882511E+4931
huge/nearest =   2.E+
huge(qp1) 1.1897314953572317650857593266280070E+4932
nearest(huge(qp1),-qp1)   5.9486574767861588254287966331400351E+4931
huge/nearest =   2.00E+

Its g95 output:

uge(sp1) 3.40282347E+38
nearest(huge(sp1),-sp1)   3.40282326E+38
huge/nearest =   1.0012E+00
huge(dp1) 1.79769313486231571E+308
nearest(huge(dp1),-dp1)   1.79769313486231551E+308
huge/nearest =   1.00022E+000
huge(ep1) 1.18973149535723176502E+4932
nearest(huge(ep1),-ep1)   1.18973149535723176496E+4932
huge/nearest =   1.0011E+
huge(qp1) 1.1897314953572317650857593266280070E+4932
nearest(huge(qp1),-qp1)   1.1897314953572317650857593266280069E+4932
huge/nearest =   1.02E+

On Sun, 19 Mar 2023, jvdelisle at gcc dot gnu.org wrote:

> Date: Sun, 19 Mar 2023 05:06:47 +
> From: jvdelisle at gcc dot gnu.org 
> To: John Harper 
> Subject: [Bug fortran/109186] nearest(huge(x),
> -1.0_kind(x)) half of correct value
> Resent-Date: Sun, 19 Mar 2023 18:06:59 +1300 (NZDT)
> Resent-From: 
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109186
>
> Jerry DeLisle  changed:
>
>   What|Removed |Added
> 
> CC||jvdelisle at gcc dot gnu.org
>
> --- Comment #1 from Jerry DeLisle  ---
> Can you clarify what you expect the correct results should be that you expect?
>
> -- 
> You are receiving this mail because:
> You reported the bug.
>


-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz phone +64(0) 4 463 5276

[Bug fortran/109662] New: bad namelist input but gfortran accepted it

[john.harper at vuw dot ac.nz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662

Bug ID: 109662
   Summary: bad namelist input but gfortran accepted it
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.harper at vuw dot ac.nz
  Target Milestone: ---

This program compiled and ran with the std=f2018 option though it has a comma
between the namelist group name and the variable name, which I and ifort
believe is non-standard. The program:

program testnmlread
  use iso_fortran_env,only: compiler_version,compiler_options,output_unit
  implicit none
  character(16) :: list = ', n = 666/'
  integer   :: n
  namelist/stuff/n
  print *,'Compiler version = ',trim(compiler_version())
  print *,'Compiler options = ',trim(compiler_options())
  read(list,nml=stuff)
  write(output_unit,nml=stuff)
end program testnmlread

The output:

 Compiler version = GCC version 12.1.0
 Compiler options = -mtune=generic -march=x86-64 -g -std=f2018
-fpre-include=/usr/include/finclude/math-vector-fortran.h

 N=666,
 /

Result of gfortran -v :

Using built-in specs.
COLLECT_GCC=gfortran-12
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
12.1.0-2ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-12-sZcx2y/gcc-12-12.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-sZcx2y/gcc-12-12.1.0/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (Ubuntu 12.1.0-2ubuntu1~22.04)

[Bug libfortran/109662] bad namelist input but gfortran accepted it

[john.harper at vuw dot ac.nz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662

--- Comment #6 from john.harper at vuw dot ac.nz ---
OK by me but I'm not in charge of gfortran!

On Thu, 4 May 2023, jvdelisle at gcc dot gnu.org wrote:

> Date: Thu, 4 May 2023 03:05:49 +
> From: jvdelisle at gcc dot gnu.org 
> To: John Harper 
> Subject: [Bug libfortran/109662] bad namelist input but gfortran accepted it
> Resent-Date: Thu, 4 May 2023 15:05:59 +1200 (NZST)
> Resent-From: 
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662
>
> --- Comment #5 from Jerry DeLisle  ---
> Is this acceptable:
>
> $ ./a.out
> Compiler version = GCC version 14.0.0 20230424 (experimental)
> Compiler options = -mtune=generic -march=x86-64 -Wpedantic
> -fpre-include=/usr/include/finclude/math-vector-fortran.h
> At line 9 of file pr109662.f90
> Fortran runtime error: Comma after namelist name not allowed
>
> Should I allow it with -std=legacy?
>
> -- 
> You are receiving this mail because:
> You reported the bug.
>


-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz phone +64(0) 4 463 5276

[Bug libfortran/109662] bad namelist input but gfortran accepted it

[john.harper at vuw dot ac.nz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662

--- Comment #7 from john.harper at vuw dot ac.nz ---
I hadn't thought about -std=gnu in this context but it would make sense
for std=gnu to give a warning for comma after namelist name if 
std=legacy is going to allow it without one. You wouldn't then have to 
change the gfortran manual page.

John

On Thu, 4 May 2023, John Harper wrote:

> Date: Thu, 4 May 2023 16:59:31 +1200 (NZST)
> From: John Harper 
> To: jvdelisle at gcc dot gnu.org 
> Subject: Re: [Bug libfortran/109662] bad namelist input but gfortran accepted
> it
> 
> OK by me but I'm not in charge of gfortran!
>
> On Thu, 4 May 2023, jvdelisle at gcc dot gnu.org wrote:
>
>> Date: Thu, 4 May 2023 03:05:49 +
>> From: jvdelisle at gcc dot gnu.org 
>> To: John Harper 
>> Subject: [Bug libfortran/109662] bad namelist input but gfortran accepted 
>> it
>> Resent-Date: Thu, 4 May 2023 15:05:59 +1200 (NZST)
>> Resent-From: 
>> 
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662
>> 
>> --- Comment #5 from Jerry DeLisle  ---
>> Is this acceptable:
>> 
>> $ ./a.out
>> Compiler version = GCC version 14.0.0 20230424 (experimental)
>> Compiler options = -mtune=generic -march=x86-64 -Wpedantic
>> -fpre-include=/usr/include/finclude/math-vector-fortran.h
>> At line 9 of file pr109662.f90
>> Fortran runtime error: Comma after namelist name not allowed
>> 
>> Should I allow it with -std=legacy?
>> 
>> -- 
>> You are receiving this mail because:
>> You reported the bug.
>> 
>
>
> -- John Harper, School of Mathematics and Statistics
> Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
> e-mail john.har...@vuw.ac.nz phone +64(0) 4 463 5276
>


-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz phone +64(0) 4 463 5276

[Bug libfortran/109662] bad namelist input but gfortran accepted it

[john.harper at vuw dot ac.nz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662

--- Comment #11 from john.harper at vuw dot ac.nz ---
What about std=2008 ?

On Sat, 6 May 2023, jvdelisle at gcc dot gnu.org wrote:

> Date: Sat, 6 May 2023 14:45:39 +
> From: jvdelisle at gcc dot gnu.org 
> To: John Harper 
> Subject: [Bug libfortran/109662] bad namelist input but gfortran accepted it
> Resent-Date: Sun, 7 May 2023 02:45:51 +1200 (NZST)
> Resent-From: 
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662
>
> Jerry DeLisle  changed:
>
>   What|Removed |Added
> 
> Status|NEW |RESOLVED
> Resolution|--- |FIXED
>
> --- Comment #10 from Jerry DeLisle  ---
> This is fixed on trunk.
>
> To clarify, the comma is accepted as before with -std=legacy and -std=gnu.
>
> It is rejected with -std=f95, -std=2003, and -std=f2018.
>
> Cheers!
>
> -- 
> You are receiving this mail because:
> You reported the bug.
>


-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz phone +64(0) 4 463 5276

[Bug libfortran/109662] bad namelist input but gfortran accepted it

[john.harper at vuw dot ac.nz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662

--- Comment #14 from john.harper at vuw dot ac.nz ---
Rejecting a semicolon after the namelist name even if the decimal edit 
mode is COMMA makes sense because COMMA was first allowed in f2003, 
provided that semicolons in namelist were a pre-f2003 legacy possibility.

John H

On Sun, 7 May 2023, jvdelisle at gcc dot gnu.org wrote:

> Date: Sun, 7 May 2023 18:14:23 +
> From: jvdelisle at gcc dot gnu.org 
> To: John Harper 
> Subject: [Bug libfortran/109662] bad namelist input but gfortran accepted it
> Resent-Date: Mon, 8 May 2023 06:14:37 +1200 (NZST)
> Resent-From: 
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662
>
> --- Comment #12 from Jerry DeLisle  ---
> A additional adjustment to reject the semi-colon always.
>
> diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
> index 78bfd9e8787..db3330060ce 100644
> --- a/libgfortran/io/list_read.c
> +++ b/libgfortran/io/list_read.c
> @@ -3598,9 +3598,9 @@ find_nml_name:
>
>   /* A trailing space is required, we allow a comma with std=gnu.  */
>   c = next_char (dtp);
> -  if (c == ',' && !(compile_options.allow_std & GFC_STD_GNU))
> +  if ((c == ',' && !(compile_options.allow_std & GFC_STD_GNU)) || c == ';')
> generate_error (>common, LIBERROR_READ_VALUE,
> -   "Comma after namelist name not allowed");
> +   "Non blank after namelist name not allowed");
>
>   if (!is_separator(c) && c != '!')
> {
>
> -- 
> You are receiving this mail because:
> You reported the bug.
>


-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz phone +64(0) 4 463 5276

[Bug libfortran/109662] bad namelist input but gfortran accepted it

[john.harper at vuw dot ac.nz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662

--- Comment #15 from john.harper at vuw dot ac.nz ---
Sorry: what I should have said was that

If and only if a comma after a namelist name was a pre-2003 possibility 
for gfortran then it makes sense to reject a semicolon there when the 
decimal edit mode is COMMA, which first got into the standard with f2003.

John H

On Sun, 7 May 2023, john.harper at vuw dot ac.nz wrote:

> Date: Sun, 7 May 2023 21:46:33 +
> From: john.harper at vuw dot ac.nz 
> To: John Harper 
> Subject: [Bug libfortran/109662] bad namelist input but gfortran accepted it
> Resent-Date: Mon, 8 May 2023 09:46:44 +1200 (NZST)
> Resent-From: 
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662
>
> --- Comment #14 from john.harper at vuw dot ac.nz ---
> Rejecting a semicolon after the namelist name even if the decimal edit
> mode is COMMA makes sense because COMMA was first allowed in f2003,
> provided that semicolons in namelist were a pre-f2003 legacy possibility.
>
> John H
>
> On Sun, 7 May 2023, jvdelisle at gcc dot gnu.org wrote:
>
>> Date: Sun, 7 May 2023 18:14:23 +
>> From: jvdelisle at gcc dot gnu.org 
>> To: John Harper 
>> Subject: [Bug libfortran/109662] bad namelist input but gfortran accepted it
>> Resent-Date: Mon, 8 May 2023 06:14:37 +1200 (NZST)
>> Resent-From: 
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662
>>
>> --- Comment #12 from Jerry DeLisle  ---
>> A additional adjustment to reject the semi-colon always.
>>
>> diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
>> index 78bfd9e8787..db3330060ce 100644
>> --- a/libgfortran/io/list_read.c
>> +++ b/libgfortran/io/list_read.c
>> @@ -3598,9 +3598,9 @@ find_nml_name:
>>
>>   /* A trailing space is required, we allow a comma with std=gnu.  */
>>   c = next_char (dtp);
>> -  if (c == ',' && !(compile_options.allow_std & GFC_STD_GNU))
>> +  if ((c == ',' && !(compile_options.allow_std & GFC_STD_GNU)) || c == ';')
>> generate_error (>common, LIBERROR_READ_VALUE,
>> -   "Comma after namelist name not allowed");
>> +   "Non blank after namelist name not allowed");
>>
>>   if (!is_separator(c) && c != '!')
>> {
>>
>> --
>> You are receiving this mail because:
>> You reported the bug.
>>
>
>
> -- John Harper, School of Mathematics and Statistics
> Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
> e-mail john.har...@vuw.ac.nz phone +64(0) 4 463 5276
>
> -- 
> You are receiving this mail because:
> You reported the bug.
>


-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz phone +64(0) 4 463 5276

[Bug libfortran/109662] bad namelist input but gfortran accepted it

[john.harper at vuw dot ac.nz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662

--- Comment #16 from john.harper at vuw dot ac.nz ---
Saw this only after my previous 2 replies, A semicolon in a namelist is 
not a separator between Fortran statements, but it takes the place of a 
comma between values when decimal='COMMA' in an open, read or write 
statement according to f2003 10.9 and 10.10, and 9.5.1 C928 says decimal= 
and nml= may both appear in a data transfer statement.

John

On Sun, 7 May 2023, jvdelisle at gcc dot gnu.org wrote:

> Date: Sun, 7 May 2023 18:35:46 +
> From: jvdelisle at gcc dot gnu.org 
> To: John Harper 
> Subject: [Bug libfortran/109662] bad namelist input but gfortran accepted it
> Resent-Date: Mon, 8 May 2023 06:36:00 +1200 (NZST)
> Resent-From: 
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662
>
> --- Comment #13 from Jerry DeLisle  ---
> (In reply to Jerry DeLisle from comment #12)
>
> That recent patch regression tests fine. I should mention, there is one of our
> original test cases in gfortran.dg that does use a comma. We definitely have
> see the comma used, but I have never seen a semi-colon.  I think because it is
> a newer feature allowing semicoln separators between FORTRAN statements on a
> single line. (?)
>
> Regardless, I am ready to push this out to trunk.
>
> -- 
> You are receiving this mail because:
> You reported the bug.
>


-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz phone +64(0) 4 463 5276

[Bug fortran/113313] New: execute_command_line hangs at run time

[john.harper at vuw dot ac.nz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313

Bug ID: 113313
   Summary: execute_command_line hangs at run time
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.harper at vuw dot ac.nz
  Target Milestone: ---

This program compiles and executes as expected with 3 other compilers (ifort,
ifx, flang). With gfortran 13.1.0 it compiles happily but prints nothing and
hangs at run time. My operating system is ubuntu1~22.04.

program test
! f2008 using execute_command_line and assuming Linux
  implicit none
  print "(A,L2)",'I am john',iam('john')
  print "(A,L2)",'I am JOHN',iam('JOHN')

contains

  logical function iam(  name)
character(*),intent(in)::name
integer estat
character(len(name)+38):: cmd
cmd = 'if [ `whoami` != "'//name//'" ]; then exit 1; fi'
call execute_command_line(cmd,exitstat=estat)
iam = (estat==0)
  end function iam
end program test

The other compilers all printed

I am john T
I am JOHN F

[Bug libfortran/113313] execute_command_line hangs at run time

[john.harper at vuw dot ac.nz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313

--- Comment #2 from john.harper at vuw dot ac.nz ---
Thank you! You may wish to know that in my Ubuntu system the program 
runs properly if the function iam is used in an assignment statement not a 
print statement. (Fortran Discourse gave me the idea.) Revised program:

program test2
! f2008 using execute_command_line and assuming Linux
   implicit none
   logical foo(2)
   foo = [iam('john'),iam('JOHN')]
   print "(A,L2)",'I am john',foo(1)
   print "(A,L2)",'I am JOHN',foo(2)

contains

   logical function iam(  name)
 character(*),intent(in)::name
 integer estat
 character(len(name)+38):: cmd
 cmd = 'if [ `whoami` != "'//name//'" ]; then exit 1; fi'
 call execute_command_line(cmd,exitstat=estat)
 iam = (estat==0)
   end function iam
end program test2

  On Thu, 11 Jan 2024, kargl at gcc dot 
gnu.org wrote:

> Date: Thu, 11 Jan 2024 05:49:10 +
> From: kargl at gcc dot gnu.org 
> To: John Harper 
> Subject: [Bug libfortran/113313] execute_command_line hangs at run time
> Resent-Date: Thu, 11 Jan 2024 18:49:26 +1300 (NZDT)
> Resent-From: 
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313
>
> kargl at gcc dot gnu.org changed:
>
>   What|Removed |Added
> 
> CC||kargl at gcc dot gnu.org
>
> --- Comment #1 from kargl at gcc dot gnu.org ---
> Created attachment 57034
>  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57034=edit
> patch to execute_command_line.c
>
> Code compiles and runs on FreeBSD.  That said, I see
>
> % gfcx -o z a.f90 -g && ./z
> I am john F
> I am JOHN F
> % valgrind ./z
> ==18812== Memcheck, a memory error detector
> ==18812== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
> ==18812== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
> ==18812== Command: ./z
> ==18812==
> ==18812== Conditional jump or move depends on uninitialised value(s)
> ==18812==at 0x4B0AD79: _gfortran_execute_command_line_i4
> (execute_command_line.c:203)
> ==18812==by 0x400B2A: iam.0 (a.f90:15)
> ==18812==by 0x400BE1: MAIN__ (a.f90:5)
> ==18812==by 0x400CEF: main (a.f90:6)
> ==18812==
> I am john F
> ==18812== Conditional jump or move depends on uninitialised value(s)
> ==18812==at 0x4B0AD79: _gfortran_execute_command_line_i4
> (execute_command_line.c:203)
> ==18812==by 0x400B2A: iam.0 (a.f90:15)
> ==18812==by 0x400C8B: MAIN__ (a.f90:6)
> ==18812==by 0x400CEF: main (a.f90:6)
> ==18812==
> I am JOHN F
> ==18812==
> ==18812== HEAP SUMMARY:
> ==18812== in use at exit: 0 bytes in 0 blocks
> ==18812==   total heap usage: 26 allocs, 26 frees, 9,873 bytes allocated
>
> Looking at the code around line 203 suggests that there may be some confusion
> with setting the error status.  The attached patch allows the code to
> run without the valgrind warnings.
>
> -- 
> You are receiving this mail because:
> You reported the bug.
>


-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz

[Bug libfortran/113313] execute_command_line hangs at run time

[john.harper at vuw dot ac.nz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313

--- Comment #3 from john.harper at vuw dot ac.nz ---
I suspect that valgrind complained because I had not given an else part 
for the variable cmd. In my system the valgrind error message went away 
when I declared and evaluated cmd as follows:

character(len(name)+50):: cmd
cmd = 'if [ `whoami` != "'//name//'" ]; then exit 1; else exit 0; fi'

On Thu, 11 Jan 2024, john.harper at vuw dot ac.nz wrote:

> Date: Thu, 11 Jan 2024 07:03:05 +
> From: john.harper at vuw dot ac.nz 
> To: John Harper 
> Subject: [Bug libfortran/113313] execute_command_line hangs at run time
> Resent-Date: Thu, 11 Jan 2024 20:03:22 +1300 (NZDT)
> Resent-From: 
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313
>
> --- Comment #2 from john.harper at vuw dot ac.nz ---
> Thank you! You may wish to know that in my Ubuntu system the program
> runs properly if the function iam is used in an assignment statement not a
> print statement. (Fortran Discourse gave me the idea.) Revised program:
>
> program test2
> ! f2008 using execute_command_line and assuming Linux
>   implicit none
>   logical foo(2)
>   foo = [iam('john'),iam('JOHN')]
>   print "(A,L2)",'I am john',foo(1)
>   print "(A,L2)",'I am JOHN',foo(2)
>
> contains
>
>   logical function iam(  name)
> character(*),intent(in)::name
> integer estat
> character(len(name)+38):: cmd
> cmd = 'if [ `whoami` != "'//name//'" ]; then exit 1; fi'
> call execute_command_line(cmd,exitstat=estat)
> iam = (estat==0)
>   end function iam
> end program test2
>
>  On Thu, 11 Jan 2024, kargl at gcc dot
> gnu.org wrote:
>
>> Date: Thu, 11 Jan 2024 05:49:10 +
>> From: kargl at gcc dot gnu.org 
>> To: John Harper 
>> Subject: [Bug libfortran/113313] execute_command_line hangs at run time
>> Resent-Date: Thu, 11 Jan 2024 18:49:26 +1300 (NZDT)
>> Resent-From: 
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313
>>
>> kargl at gcc dot gnu.org changed:
>>
>>   What|Removed |Added
>> 
>> CC||kargl at gcc dot gnu.org
>>
>> --- Comment #1 from kargl at gcc dot gnu.org ---
>> Created attachment 57034
>>  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57034=edit
>> patch to execute_command_line.c
>>
>> Code compiles and runs on FreeBSD.  That said, I see
>>
>> % gfcx -o z a.f90 -g && ./z
>> I am john F
>> I am JOHN F
>> % valgrind ./z
>> ==18812== Memcheck, a memory error detector
>> ==18812== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
>> ==18812== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
>> ==18812== Command: ./z
>> ==18812==
>> ==18812== Conditional jump or move depends on uninitialised value(s)
>> ==18812==at 0x4B0AD79: _gfortran_execute_command_line_i4
>> (execute_command_line.c:203)
>> ==18812==by 0x400B2A: iam.0 (a.f90:15)
>> ==18812==by 0x400BE1: MAIN__ (a.f90:5)
>> ==18812==by 0x400CEF: main (a.f90:6)
>> ==18812==
>> I am john F
>> ==18812== Conditional jump or move depends on uninitialised value(s)
>> ==18812==at 0x4B0AD79: _gfortran_execute_command_line_i4
>> (execute_command_line.c:203)
>> ==18812==by 0x400B2A: iam.0 (a.f90:15)
>> ==18812==by 0x400C8B: MAIN__ (a.f90:6)
>> ==18812==by 0x400CEF: main (a.f90:6)
>> ==18812==
>> I am JOHN F
>> ==18812==
>> ==18812== HEAP SUMMARY:
>> ==18812== in use at exit: 0 bytes in 0 blocks
>> ==18812==   total heap usage: 26 allocs, 26 frees, 9,873 bytes allocated
>>
>> Looking at the code around line 203 suggests that there may be some confusion
>> with setting the error status.  The attached patch allows the code to
>> run without the valgrind warnings.
>>
>> --
>> You are receiving this mail because:
>> You reported the bug.
>>
>
>
> -- John Harper, School of Mathematics and Statistics
> Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
> e-mail john.har...@vuw.ac.nz
>
> -- 
> You are receiving this mail because:
> You reported the bug.
>


-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz

[Bug libfortran/113313] execute_command_line hangs at run time

[john.harper at vuw dot ac.nz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313

--- Comment #6 from john.harper at vuw dot ac.nz ---
I know nothing about either applying gfortran patches or MatterMost but 
I'm willing to try.

On Thu, 11 Jan 2024, jvdelisle at gcc dot gnu.org wrote:

> Date: Thu, 11 Jan 2024 20:18:36 +
> From: jvdelisle at gcc dot gnu.org 
> To: John Harper 
> Subject: [Bug libfortran/113313] execute_command_line hangs at run time
> Resent-Date: Fri, 12 Jan 2024 09:18:48 +1300 (NZDT)
> Resent-From: 
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313
>
> Jerry DeLisle  changed:
>
>   What|Removed |Added
> 
> CC||jvdelisle at gcc dot gnu.org
>
> --- Comment #4 from Jerry DeLisle  ---
> I just started looking at this today. I will give the patch a spin in the next
> few days and if tests OK I can commit.
>
> John, are you able tp apply Steve's patch and try it? If not would you like to
> learn how?  I can show people the ropes.  We have a MatterMost workspace you
> can join and I can linkup with you there. (I will send you an invite, just let
> me know.)
>
> -- 
> You are receiving this mail because:
> You reported the bug.
>


-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz

[Bug libfortran/113313] execute_command_line hangs at run time

[john.harper at vuw dot ac.nz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313

--- Comment #9 from john.harper at vuw dot ac.nz ---
This variant of my test program (now called test4) hangs with gfortran 
but not with other compilers if iam is written to output_unit (like the 
original version) or to a file with a different positive unit number, but 
it does not hang if written to a file with a negative unit number obtained 
by opening it with newunit=u. Its user has those 3 choices at run time.

I hope it helps you explore this oddity of gfortran.

program test4
   use iso_fortran_env, only: output_unit
! Linux with f2008 (newunit=, execute_command_line, allocatable scalar)
   implicit none
   integer:: u = output_unit+20
   character:: ch*1, line(2)*80
   print "(A)",'Output from iam will go to unit u;', &
' u=output_unit if you enter a, or',&
' unit=u (u>0)  if you enter b, or',&
' newunit=u (u<0) if you enter anything else.'
   read "(A)", ch
   if(ch=='a') then
  u = output_unit
   else if(ch=='b') then
  open(   unit=u,file='test4.out')
   else
  open(newunit=u,file='test4.out')
   end if
   print "(A,I0)",'Output from iam will be written to unit ',u
   write(u,"(A,L2)")'I am john',iam('john')
   write(u,"(A,L2)")'I am JOHN',iam('JOHN')
   if(u/=output_unit) then
  rewind u
  read(u,"(A)") line
  print  "(A)", line
  close(u,status='delete')
   end if
contains

   logical function iam(  name)
 character(*),intent(in)::name
 integer estat
 character(:),allocatable:: cmd
 cmd = 'if [ `whoami` != "'//name//'" ]; then exit 1; else exit 0; fi'
 call execute_command_line(cmd,exitstat=estat)
 iam = (estat==0)
   end function iam
end program test4

-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz

[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.

[john.harper at vuw dot ac.nz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022

--- Comment #25 from john.harper at vuw dot ac.nz ---
With that program Intel's two compilers (ifort and ifx) both print

  >.30D+01<
  >.30E+01<

If your program removes the d0.2 stuff and changes e0.2 to es0.2e0, i.e.

   character(20) :: fmt
   character(9) :: buffer
   fmt = "(1a1,es0.2e0,1a1)"
   write(buffer,fmt) ">", 3.0, "<"
   print *, buffer
   end

then both Intel compilers print what you seem to have hoped for:

  >3.00E+0<

but my gfortran, gcc version 13.1.0 (Ubuntu 13.1.0-8ubuntu1~22.04), prints

  >3.00<

I won't argue about the difference between gfortran's >0.30D+1< 
and Intel's >.30D+01< because I have been caught before by whether the 
zero before the decimal point and the zero after the D are optional. 
The f2018 standard is not easy to read on this.

I tried aocc-flang on your original program, and I ought to send them a 
bug report because it printed

  ><
  ><

I don't have access to the NAG compiler or anyone else's flang.

John


On Thu, 25 Jan 2024, jvdelisle at gcc dot gnu.org wrote:

> Date: Thu, 25 Jan 2024 22:21:01 +
> From: jvdelisle at gcc dot gnu.org 
> To: John Harper 
> Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too
>  high.
> Resent-Date: Fri, 26 Jan 2024 11:21:15 +1300 (NZDT)
> Resent-From: 
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
>
> --- Comment #24 from Jerry DeLisle  ---
> Currently gfortran does the following:
>
> character(20) :: fmt
> character(9) :: buffer
> fmt = "(1a1,d0.2,1a1)"
> write(buffer,fmt) ">", 3.0, "<"
> print *, buffer
> fmt = "(1a1,e0.2,1a1)"
> write(buffer,fmt) ">", 3.0, "<"
> print *, buffer
> end
>
>
> $ gfc question.f90
> $ ./a.out
> >0.30D+1<
> >0.30E+1<
>
> Why not:
>
> $ ./a.out
> >3.00D+0<
> >3.00E+0<
>
> What does Intel do?
>
> -- 
> You are receiving this mail because:
> You reported the bug.
>


-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz

[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'

[john.harper at vuw dot ac.nz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473

--- Comment #30 from john.harper at vuw dot ac.nz ---
Thank you!

On Fri, 8 Mar 2024, jvdelisle at gcc dot gnu.org wrote:

> Date: Fri, 8 Mar 2024 00:30:51 +
> From: jvdelisle at gcc dot gnu.org 
> To: John Harper 
> Subject: [Bug fortran/105473] semicolon allowed when list-directed read
> integer with decimal='point'
> Resent-Date: Fri, 8 Mar 2024 13:31:02 +1300 (NZDT)
> Resent-From: 
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
>
> --- Comment #29 from Jerry DeLisle  ---
> Backported to 13 and closing.
>
> -- 
> You are receiving this mail because:
> You reported the bug.
>


-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz