[Bug fortran/27760] New: possible bug for array of strings passed to function

[vivekrao4 at yahoo dot com]

For the following program, compiled on Windows with the 20060504 Mingw gfortran
with the -fbounds-check option, 

program xfoo
integer, parameter   :: n = 3
integer  :: i,istat(n)
character (len=6):: words(n)
character (len=1000) :: text
text = "abcdef ghijkl mnopqr"
read (text,*) words
print*,(words(i)," ",i=1,n)
istat = foo(words)
print*,istat
print*,(words(i)," ",i=1,n)
!
contains
function foo(str) result(istat)
character (len=*), intent(in) :: str(:)
integer   :: istat(size(str))
istat = 0
end function foo
end program xfoo

the output is

 abcdef ghijkl mnopqr 
   0   0 4268384
 abcdef ghijkl mn 

The array "words" changes, but it should not. This
problem occurs only when the -fbounds-check option is
used.

Vivek Rao


-- 
   Summary: possible bug for array of strings passed to function
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: vivekrao4 at yahoo dot com


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

[Bug fortran/38095] New: character ICE

[vivekrao4 at yahoo dot com]

Compiling

module bar
implicit none
contains
!
elemental function trim_append(xx,yy) result(xy)
character (len=*), intent(in) :: xx,yy
character (len=len(xx) + len(yy)) :: xy
xy = trim(xx) // yy
end function trim_append
!
function same(xx) result(yy)
character (len=*), intent(in) :: xx(:)
character (len=len(xx))   :: yy(size(xx))
yy = [xx]
end function same
!
subroutine foo(labels)
character (len=*), intent(in) :: labels(:)
print*,"size(labels)=",size(labels)
end subroutine foo
!
subroutine xmain()
call foo(trim_append(["a"],same(["b"])))
end subroutine xmain
!
end module bar

with

gfortran -c xchar_bug.f90

I get

xchar_bug.f90: In function 'xmain':
xchar_bug.f90:5: 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.

gfortran -v says

gfortran -v
Built by Equation Solution (http://www.Equation.com).
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../gcc-4.4-20081107-mingw/configure --host=i386-pc-mingw32
--build=x86_64-unknown-linux-gnu --target=i386-pc-mingw32
--prefix=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gcc/4.4-20081107
--with-gcc --with-gnu-ld --with-gnu-as --disable-shared --disable-nls
--disable-tls
--with-gmp=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gmp
--with-mpfr=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/mpfr
--enable-languages=c,c++,fortran
--with-sysroot=/home/gfortran/gcc-home/binary/mingw32/cross/x86_32/gcc/4.4-20081107
--enable-libgomp --enable-threads=win32 --disable-win32-registry :
(reconfigured) ../gcc-4.4-20081107-mingw/configure --host=i386-pc-mingw32
--build=x86_64-unknown-linux-gnu --target=i386-pc-mingw32
--prefix=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gcc/4.4-20081107
--with-gcc --with-gnu-ld --with-gnu-as --disable-shared --disable-nls
--disable-tls
--with-gmp=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gmp
--with-mpfr=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/mpfr
--enable-languages=c,c++,fortran
--with-sysroot=/home/gfortran/gcc-home/binary/mingw32/cross/x86_32/gcc/4.4-20081107
--enable-libgomp --enable-threads=win32 --disable-win32-registry :
(reconfigured) ../gcc-4.4-20081107-mingw/configure --host=i386-pc-mingw32
--build=x86_64-unknown-linux-gnu --target=i386-pc-mingw32
--prefix=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gcc/4.4-20081107
--with-gcc --with-gnu-ld --with-gnu-as --disable-shared --disable-nls
--disable-tls
--with-gmp=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gmp
--with-mpfr=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/mpfr
--enable-languages=c,c++,fortran
--with-sysroot=/home/gfortran/gcc-home/binary/mingw32/cross/x86_32/gcc/4.4-20081107
--enable-libgomp --enable-threads=win32 --disable-win32-registry
Thread model: win32
gcc version 4.4.0 20081107 (experimental) (GCC)


-- 
   Summary: character ICE
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vivekrao4 at yahoo dot com


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

[Bug fortran/38095] character ICE

[vivekrao4 at yahoo dot com]

--- Comment #5 from vivekrao4 at yahoo dot com  2008-11-12 22:12 ---
(In reply to comment #4)
> > Whoop, it is valid Fortran 2003.  I forgot that
> > Lahey's checker does not understand the F2003 array syntax.
> I was about to say that the code is compiled by ifort and g95.

I hope someone will mark the bug as "confirmed".


-- 


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

[Bug fortran/38538] New: ICE with elemental character function

[vivekrao4 at yahoo dot com]

For the code below stored in xtemp.f90

module abc
implicit none
contains
subroutine xmain()
call foo(func("_"//bar()))
end subroutine xmain
!
function bar() result(yy)
character (len=1) :: yy(1)
yy = ""
end function bar
!
elemental function func(yy) result(xy)
character (len=*), intent(in) :: yy
character (len=len(yy)) :: xy
xy = yy
end function func
!
subroutine foo(cc)
character (len=*), intent(in) :: cc(:)
print*,cc
end subroutine foo
end module abc

gfortran -c xtemp.f90 gives

xtemp.f90: In function 'xmain':
xtemp.f90:8: internal compiler error: in gfc_conv_function_call, at
fortran/trans-expr.c:2846
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

gfortran -v gives

Built by Equation Solution (http://www.Equation.com).
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../gcc-4.4-20081212-mingw/configure --host=i386-pc-mingw32
--build=x86_64-unknown-linux-gnu --target=i386-pc-mingw32
--prefix=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gcc/4.4-20081212
--with-gcc --with-gnu-ld --with-gnu-as --disable-shared --disable-nls
--disable-tls
--with-gmp=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gmp
--with-mpfr=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/mpfr
--enable-languages=c,fortran,c++
--with-sysroot=/home/gfortran/gcc-home/binary/mingw32/cross/x86_32/gcc/4.4-20081212
--enable-libgomp --enable-threads=win32 --disable-win32-registry
Thread model: win32
gcc version 4.4.0 20081212 (experimental) (GCC)


-- 
   Summary: ICE with elemental character function
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: vivekrao4 at yahoo dot com


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

[Bug fortran/29459] New: Spurious warning about uninitialized optional arguments

[vivekrao4 at yahoo dot com]

gfortran -c -Wall -O1 gfort_warnings.f90 

using gcc version 4.2.0 20061011 (experimental) on Windows XP

for the code

module foo_mod
implicit none
contains
subroutine print_sub(fmt_acf,iu,labels)
character (len=*), intent(in), optional :: fmt_acf
integer  , intent(in), optional :: iu
character (len=*), intent(in), optional :: labels(:)
if (present(iu)) then
   print*,iu
end if
if (present(fmt_acf)) then
   print*,fmt_acf
end if
if (present(labels)) then
   write (*,*) labels
end if
end subroutine print_sub
!
end module foo_mod

produces the spurious warnings
gfort_warnings.f90: In function 'print_sub':
gfort_warnings.f90:4: warning: 'stride.1' may be used uninitialized in this
function
gfort_warnings.f90:4: warning: 'ubound.0' may be used uninitialized in this
function
gfort_warnings.f90:4: warning: 'labels.0' may be used uninitialized in this
function
gfort_warnings.f90:4: warning: '' may be used uninitialized in this
function


-- 
   Summary: Spurious warning about uninitialized optional arguments
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vivekrao4 at yahoo dot com


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

[Bug fortran/29464] New: problem with duplicate USE, ONLY of procedure in INTERFACE

[vivekrao4 at yahoo dot com]

For the program

module foo_mod
implicit none
interface twice
   module procedure twice_real
end interface twice
contains
real function twice_real(x)
real :: x
twice_real = 2*x
end function twice_real
end module foo_mod

program xfoo
use foo_mod, only: twice,twice
implicit none
print*,twice(2.3)
end program xfoo

version gcc version 4.2.0 20061011 (experimental)
of gfortran on Windows XP says

 In file xduplicate_use.f90:14

use foo_mod, only: twice,twice
1
Error: Symbol 'twice' referenced at (1) not found in
module 'foo_mod'

In the thread "USE, ONLY question" in
comp.lang.fortran, most people thought that repetition
in a USE, ONLY statement was standard-conforming.

If "twice" is replaced with "twice_real" in program
xfoo, it compiles and runs, giving the expected
output.

Vivek Rao


-- 
   Summary: problem with duplicate USE, ONLY of procedure in
INTERFACE
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vivekrao4 at yahoo dot com


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

[Bug fortran/30668] New: catch function of wrong type

[vivekrao4 at yahoo dot com]

In the following program it would be nice if gfortran reported that two() has
type REAL in the main program because of implicit typing but actually has type
DOUBLE PRECISION. Below is what gfortran says and then what g95 says for
comparison.

U:\vrao\fortran>type bug_print.f90 
double precision function two()
two = 2.0d0
end function two

program xx
print*,two(),kind(two())
end program xx

U:\vrao\fortran>gfortran -v 
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../trunk/configure --prefix=/mingw
--enable-languages=c,fortran --with-gmp=/home/coudert/local --disable-nls
--with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror
--enable-bootstrap --enable-threads --host=i386-pc-mingw32 --disable-shared
--enable-libgomp
Thread model: win32
gcc version 4.3.0 20061021 (experimental)

U:\vrao\fortran>gfortran -W -Wall -pedantic-errors -std=f2003 -fbounds-check
-Werror bug_print.f90 

U:\vrao\fortran>a.exe
   2.00   4

U:\vrao\fortran>g95 -v 
Using built-in specs.
Target: 
Configured with: /src/G95/gcc-4.0-20060302/configure --with-gcc --with-gnu-ld
--with-ld=/mingw/bin/ld --with-gnu-as --with-as=/mingw/bin/as --host=mingw32
--target=mingw32 --prefix=/mingw --enable-threads --disable-nls
--enable-languages=c --disable-win32-registry --disable-shared --without-x
--disable-libmudflap --disable-libssp
Thread model: win32
gcc version 4.0.3 (g95 0.91!) Jan 23 2007

U:\vrao\fortran>g95 -Wall -pedantic -fbounds-check -ftrace=full bug_print.f90 
In file bug_print.f90:1

double precision function two()
  1
In file bug_print.f90:6

print*,two(),kind(two())
   2
Error: FUNCTION 'two' is of type REAL(8) at (1) and type REAL(4) at (2)

This program was discussed in the gg95 newsgroup in a thread "bug with double
precision function" at
http://groups.google.com/group/gg95/browse_frm/thread/73ea96b2925195f0?hl=en


-- 
   Summary: catch function of wrong type
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: vivekrao4 at yahoo dot com


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

[Bug fortran/30681] New: "obsolescent" vs. "obsolete"

[vivekrao4 at yahoo dot com]

For a code with an arithmetic IF, for example

program xx
implicit none
integer :: i
i = 0
if (i) 10,20,30
10 print*,"negative"
stop
20 print*,"zero"
stop
30 print*,"positive"
stop
end program xx

mingw gfortran 4.3.0 20061021 says

 In file xarithmetic_if.f90:5

if (i) 10,20,30
  1
Warning: Obsolete: arithmetic IF statement at (1)

According to the Fortran 95 Handbook the arithmetic IF is "obsolescent", not
"obsolete".

The Fortran 2003 standard lists the following features as "obsolescent" in
section B.2, "Obsolescent features".

5 (1) Arithmetic IF — use the IF statement (8.1.2.4) or IF construct (8.1.2).
6 (2) Shared DO termination and termination on a statement other than END DO or
CON7
TINUE — use an END DO or a CONTINUE statement for each DO statement.
8 (3) Alternate return — see B.2.1.
9 (4) Computed GO TO statement — see B.2.2.
10 (5) Statement functions — see B.2.3.
11 (6) DATA statements amongst executable statements — see B.2.4.
12 (7) Assumed length character functions — see B.2.5.
13 (8) Fixed form source — see B.2.6.
14 (9) CHARACTER* form of CHARACTER declaration — see B.2.7.

Gfortran should use the term "obsolescent" rather than "obsolete" for all of
these features. I have only looked at arithmetic IF.


-- 
   Summary: "obsolescent" vs. "obsolete"
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
     Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vivekrao4 at yahoo dot com


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

[Bug fortran/30681] "obsolescent" vs. "obsolete"

[vivekrao4 at yahoo dot com]

--- Comment #1 from vivekrao4 at yahoo dot com  2007-02-05 14:05 ---
Compiling the code above with

gfortran -std=f2003 

gives

 In file xarithmetic_if.f90:5

if (i) 10,20,30
  1
Error: Obsolete: arithmetic IF statement at (1)

which is incorrect, because the arithmetic IF is part of standard Fortran 2003
and 95.


-- 

vivekrao4 at yahoo dot com changed:

   What|Removed |Added

Summary|"obsolescent" vs. "obsolete"|"obsolescent" vs. "obsolete"


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

[Bug fortran/31053] New: print file name when file cannot be opened for writing

[vivekrao4 at yahoo dot com]

On Windows, if a file is open in Excel, one cannot write to it in a Fortran
program. So if "junk.csv" is opened in Excel and I compile and run the code

program xopen
! check what happens when program tries to open file already open
implicit none
integer, parameter :: iu = 20
character (len=*), parameter :: xfile="junk.csv"
open (unit=iu,file=xfile,action="write",status="replace")
end program xopen

gfortran
Target: i386-pc-mingw32
Configured with: ../trunk/configure --prefix=/mingw
--enable-languages=c,fortran --with-gmp=/home/coudert/local --disable-nls
--with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror
--enable-bootstrap --enable-threads --host=i386-pc-mingw32 --disable-shared
--enable-libgomp
Thread model: win32
gcc version 4.3.0 20061021 (experimental)

says

At line 6 of file xopen_error.f90
Fortran runtime error: Permission denied

I'd like it to say that file "junk.csv" could not be opened, to make debugging
easier for the user. For example, Intel Visual Fortran says

forrtl: The process cannot access the file because it is being used by another
process.
forrtl: severe (30): open failure, unit 20, file U:\vrao\fortran\junk.csv
Image  PCRoutineLineSource 
ifort_xopen_error  0044382E  Unknown   Unknown  Unknown
ifort_xopen_error  00440AEC  Unknown   Unknown  Unknown
ifort_xopen_error  00405DFA  Unknown   Unknown  Unknown
ifort_xopen_error  00405A17  Unknown   Unknown  Unknown
ifort_xopen_error  00401C81  Unknown   Unknown  Unknown
ifort_xopen_error  0040106F  _MAIN__ 6  xopen_error.f90
ifort_xopen_error  00449970  Unknown   Unknown  Unknown
ifort_xopen_error  0042EBB8  Unknown   Unknown  Unknown
kernel32.dll   7C816FD7  Unknown   Unknown  Unknown


-- 
   Summary: print file name when file cannot be opened for writing
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vivekrao4 at yahoo dot com


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

[Bug fortran/31059] New: Detect nonconforming assignment of allocatable arrays

[vivekrao4 at yahoo dot com]

Gfortran does not report an error if an allocatable array is set to an array of
larger size, for example in the code below.

program xalloc_words
! shows error with nonconformant assignment of an allocatable array
! not caught by most compilers
character (len=1), allocatable :: w(:)
integer, allocatable :: ivec(:)
integer :: jvec(2)
allocate (w(2),ivec(2))
w = ["1","2","3"]
write (*,*) "size(w)=",size(w),"w =",w
ivec = [1,2,3]
write (*,*) "size(ivec)=",size(w),"ivec =",ivec
! error in line below IS caught if not commented
! jvec = [1,2,3]
end program xalloc_words

U:\vrao\fortran>gfortran -v
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../trunk/configure --prefix=/mingw
--enable-languages=c,fortran --with-gmp=/home/coudert/local --disable-nls
--with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror
--enable-bootstrap --enable-threads --host=i386-pc-mingw32 --disable-shared
--enable-libgomp
Thread model: win32
gcc version 4.3.0 20061021 (experimental)

U:\vrao\fortran>gfortran -W -Wall -pedantic-errors  -std=f2003  -fbounds-check
-Werror xalloc_words.f90
 In file xalloc_words.f90:6

integer :: jvec(2)
 1
Warning: Unused variable jvec declared at (1)

U:\vrao\fortran>a
 size(w)=   2 w =12
 size(ivec)=   2 ivec =   1   2


Vivek Rao


-- 
   Summary: Detect nonconforming assignment of allocatable arrays
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
    AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vivekrao4 at yahoo dot com


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

[Bug fortran/31148] New: optional argument of elemental function

[vivekrao4 at yahoo dot com]

Since ivec is not passed to sub, I think the two calls
to set_optional should be equivalent, but gfortran crashes
upon the second call. 

u:\vrao\fortran type xopt_bug.f90 
module sub_mod
contains
elemental subroutine set_optional(i,idef,iopt)
! set i to (iopt,idef) if iopt (is,is not) PRESENT
integer, intent(out)  :: i
integer, intent(in)   :: idef
integer, intent(in), optional :: iopt
if (present(iopt)) then
   i = iopt
else
   i = idef
end if
end subroutine set_optional
!
subroutine sub(ivec)
integer  , intent(in), optional :: ivec(:)
integer :: ivec_(2)
call set_optional(ivec_,(/1,2/))
print*,"ivec_=",ivec_
call set_optional(ivec_,(/1,2/),ivec)
print*,"ivec_=",ivec_
end subroutine sub
end module sub_mod

program main
use sub_mod, only: sub
call sub()
end program main

U:\vrao\fortran>gfortran -v 
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../trunk/configure --prefix=/mingw
--enable-languages=c,fortran --with-gmp=/home/coudert/local --disable-nls
--with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror
--enable-bootstrap --enable-threads --host=i386-pc-mingw32 --disable-shared
--enable-libgomp
Thread model: win32
gcc version 4.3.0 20061021 (experimental)

U:\vrao\fortran>gfortran -W -Wall -pedantic-errors -std=f2003 -fbounds-check
-Werror xopt_bug.f90 

U:\vrao\fortran>a.exe
Fortran runtime error: Array bound mismatch, size mismatch for dimension 1 of
array 'ivec' (in file 'xopt_bug.f90', at line 20)
 ivec_=   1   2


-- 
   Summary: optional argument of elemental function
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vivekrao4 at yahoo dot com


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

[Bug fortran/31190] New: minimum field width list-directed output

[vivekrao4 at yahoo dot com]

A feature of g95 I find convenient is that
list-directed output is printed in the minimum amount
of space required, making it more readable IMO. For
example, for

print*,(i,i=1,6)
end

g95 gives

 1 2 3 4 5 6

and gfortran gives

   1   2   3   4   5   6

A compiler option that used a minimal width for output
for list directed WRITEs would be convenient.

I know that for fine control of output I should use
explicit formats such as i0 or f0.6, but for
quick-and-dirty output it's nice to have list-directed
WRITEs give very readable output.

Vivek Rao


-- 
   Summary: minimum field width list-directed output
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vivekrao4 at yahoo dot com


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

[Bug fortran/31190] minimum field width list-directed output

[vivekrao4 at yahoo dot com]

--- Comment #3 from vivekrao4 at yahoo dot com  2007-03-19 21:55 ---
I agree with comments #1 and #2 that minimal width and fixed width
list-directed I/O can be useful, and I don't think gfortran should change its
default list-directed output, because some people may be relying, unwisely on a
particular format. But an OPTION for minimal width list-directed output could
be useful.


-- 


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

[Bug fortran/31270] New: print subscript value and array bounds when out-of-bounds error occurs

[vivekrao4 at yahoo dot com]

For the code

program xcheck
implicit none
integer :: i,ivec(2)
ivec = 0
do i=1,3
   if (i**2 < 10) print*,ivec(i)
end do
end program xcheck

gfortran -Wall -fbounds-check

for mingw 4.3.0 20070315

gives at run time

Fortran runtime error: Array reference out of bounds for array 'ivec', upper
bound of dimension 1 exceeded (in file 'xbounds_check.f90', at line 6)
   0
   0

This is good, but g95 is a little more informative, identifyng the value of the
out-of-bound subscript and the relevant dimension of the array, saying

 0
 0
At line 6 of file xbounds_check.f90 (Unit 6)
Traceback: not available, compile with -ftrace=frame or -ftrace=full
Fortran runtime error: Array element out of bounds: 3 in (1:2), dim=1

Vivek Rao


-- 
   Summary: print subscript value and array bounds when out-of-
bounds error occurs
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: vivekrao4 at yahoo dot com


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

[Bug fortran/31318] New: terminate program when un-allocated array is used

[vivekrao4 at yahoo dot com]

For the illegal code

integer, allocatable :: ivec(:)
print*,"shape(ivec)=",shape(ivec)
end

gcc version 4.3.0 20070315 (experimental)

gfortran -W -Wall -pedantic-errors -std=f2003 -fbounds-check -Werror
xshape_alloc.f90

gives

 shape(ivec)= 4298784

It would be nice if a run-time error message about the use of array that has
not been allocated were emitted. A fairly common mistake I make is to pass an
array that is allocatable in the caller, before having
allocated it, to a procedure as an argument which is
not allocatable. Within the procedure, applying SIZE
or SHAPE will give strange results.


-- 
   Summary: terminate program when un-allocated array is used
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vivekrao4 at yahoo dot com


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

[Bug fortran/31404] New: ICE len_trim(array) in initialization

[vivekrao4 at yahoo dot com]

U:\vrao\fortran>type xlen_trim.f90 
integer :: ic(1) = len_trim((/"a"/))
print*,"ic=",ic
end

U:\vrao\fortran>gfortran -v 
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../trunk/configure --prefix=/mingw
--enable-languages=c,fortran --with-gmp=/home/coudert/local --disable-nls
--with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror
--enable-bootstrap --enable-threads --build=i386-pc-mingw32 --disable-shared
--enable-libgomp
Thread model: win32
gcc version 4.3.0 20070329 (experimental)

U:\vrao\fortran>gfortran -W -Wall -pedantic-errors -std=f2003 -fbounds-check
-Werror xlen_trim.f90 
xlen_trim.f90: In function 'MAIN__':
xlen_trim.f90:1: internal compiler error: in gfc_conv_array_initializer, at
fortran/trans-array.c:3693
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

Vivek Rao


-- 
   Summary: ICE len_trim(array) in initialization
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: vivekrao4 at yahoo dot com


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

[Bug fortran/31447] New: set intent(out) arguments to uninitialized

[vivekrao4 at yahoo dot com]

It would be nice if gfortran had an option to set intent(out) arguments to NaN
or some random values, so that code mistakenly relying on intent(out) arguments
starting with the same value as in the caller would be detected. This is
related to the question of detecting on uninitialized variables.

For example, the code

subroutine unset(i)
integer, intent(out) :: i
i = i*2
end subroutine unset

program xunset
integer :: i
i = 1
call unset(i)
print*,"i=",i
end program xunset

gives "i = 2" but the standard does not require that it do so, since argument i
has intent(out).

Vivek Rao


-- 
   Summary: set intent(out) arguments to uninitialized
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vivekrao4 at yahoo dot com


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

[Bug fortran/31461] New: warn about entities in USE, ONLY statement not later used

[vivekrao4 at yahoo dot com]

I request that gfortran optionally warn about entities appearing in a USE, ONLY
statement that are not later referenced in the program block where the USE
appears. For example, for the code

module util_mod
integer :: i,j
end module util_mod

program main
use util_mod, only: i,j
j = 1
print*,"j=",j
end program main

g95 -Wall -Wextra -c 

says

In file xunused_simple.f90:6

use util_mod, only: i,j
  1
Warning (136): Module variable 'i' at (1) is never used
In file xunused_simple.f90:6

use util_mod, only: i,j
  1
Warning (109): ONLY variable 'i' USE-d at (1) is never used or set


-- 
   Summary: warn about entities in USE, ONLY statement not later
used
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: vivekrao4 at yahoo dot com


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

[Bug fortran/31519] New: spurious ICE messages when module does not compile

[vivekrao4 at yahoo dot com]

For the program

module foo
intger :: i ! intger should be integer
end module foo

program xfoo
use foo, only: i
end program xfoo

gfortran -c -v gfbug.f90

gives

Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../trunk/configure --prefix=/mingw
--enable-languages=c,fortran,c++,objc,obj-c++ --with-gmp=/home/coudert/local
--disable-nls --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror
--enable-bootstrap --enable-threads --build=i386-pc-mingw32 --disable-shared
--enable-libgomp
Thread model: win32
gcc version 4.3.0 20070406 (experimental)
 c:/programs/gfortran/bin/../libexec/gcc/i386-pc-mingw32/4.3.0/f951.exe
gfbug.f90 -quiet -dumpbase gfbug.f90 -mtune=i386 -auxbase gfbug -version
-fintrinsic-modules-path
c:/programs/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0/finclude -o
C:\DOCUME~1\vrao\LOCALS~1\Temp/ccASnAoX.s
GNU F95 version 4.3.0 20070406 (experimental) (i386-pc-mingw32)
compiled by GNU C version 4.3.0 20070406 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
gfbug.f90:2:

intger :: i ! intger should be integer
1
Error: Unclassifiable statement at (1)
gfbug.f90:6.16:

use foo, only: i
   1
Fatal Error: Can't open module file 'foo.mod' for reading at (1): No such file
or directory
gfortran: Internal error: Aborted (program f951)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html> for instructions.

Gfortran should "be quiet" after the "Fatal Error" message and not ask the user
to submit a bug report.


-- 
   Summary: spurious ICE messages when module does not compile
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: vivekrao4 at yahoo dot com


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

[Bug fortran/31519] spurious ICE messages when module does not compile

[vivekrao4 at yahoo dot com]

--- Comment #2 from vivekrao4 at yahoo dot com  2007-04-10 19:38 ---
This bug was discussed in a Feb 2006 thread "suggestion regarding spurious(?)
"internal error" message" 
http://gcc.gnu.org/ml/fortran/2006-02/msg00445.html . No one in that thread
said they submitted it to bugzilla.


-- 


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

[Bug fortran/31519] spurious ICE messages when module does not compile

[vivekrao4 at yahoo dot com]

--- Comment #3 from vivekrao4 at yahoo dot com  2007-04-10 23:51 ---
It appears that spurious ICE messages are a general problem with GCC. The site
"Managing Bugs (Bugzilla and the testsuite)" at
http://www.gnu.org/software/gcc/bugs/management.html says

'Bugs with keyword "ice-on-invalid-code", where GCC emits a sensible error
message before issuing an ICE (the ICE will be replaced by the message
"confused by earlier errors, bailing out" in release versions) should get
"minor" severity and the additional keyword "error-recovery".'


-- 


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

[Bug fortran/31629] New: option to make module entities PRIVATE by default

[vivekrao4 at yahoo dot com]

I prefer (but the Fortran standard does NOT require) that all module entities
used outside the module should be explicitly declared
PUBLIC.

g95 has an option -fmodule-private such that

g95 -fmodule-private for the code

module foo_mod
implicit none
! public :: i
integer :: i
end module foo_mod

program main
use foo_mod, only: i
i = 1
print*,"i=",i
end program main

gives

In file xmod_private.f90:8

use foo_mod, only: i
   1
Error: Symbol 'i' referenced at (1) not found in
module 'foo_mod'

I'd like a similar option in gfortran.

Vivek Rao


-- 
   Summary: option to make module entities PRIVATE by default
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: vivekrao4 at yahoo dot com


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

[Bug fortran/31637] New: warn about implicit conversion causing loss of precision

[vivekrao4 at yahoo dot com]

For the program

program main
implicit none
real :: xx
double precision :: yy
call random_seed()
call random_number(yy)
xx = yy ! assign double to single
print*,"yy =",yy
print*,"xx =",xx
end program main

g95 -Wall -Wextra says

In file xreal_dp.f90:7

xx = yy
 1
Warning (140): Implicit conversion at (1) may cause
precision loss

I request a similar warning from gfortran. None is currently given when
compiling with 

gfortran -Wall -pedantic -std=f2003 xreal_dp.f90 .

Vivek Rao


-- 
   Summary: warn about implicit conversion causing loss of precision
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vivekrao4 at yahoo dot com


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

[Bug fortran/47722] New: problem with -static option on Windows

[vivekrao4 at yahoo dot com]

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

   Summary: problem with -static option on Windows
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vivekr...@yahoo.com


For any program, such as 

program xhello
implicit none
print*,"hello world!"
end program xhello

Compiling with the -static option fails, as shown below. Compiling and running
without -static works fine.

Vivek Rao

gfortran -v -static xhello.f90
Driving: gfortran -v -static xhello.f90 -l gfortran
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=c:/programs/gfortran/bin/../libexec/gcc/i586-pc-mingw32/4.6.0/lto-wrapper.exe
Target: i586-pc-mingw32
Configured with: ../gcc-trunk/configure --prefix=/mingw
--enable-languages=c,fortran --with-gmp=/home/brad/gfortran/dependencies
--disable-werror --enable-threads --disable-nls --build=i586-pc-mingw32
--enable-libgomp --enable-shared --disable-win32-registry --with-dwarf2
--disable-sjlj-exceptions --enable-lto
Thread model: win32
gcc version 4.6.0 20110209 (experimental) [trunk revision 169959] (GCC) 
COLLECT_GCC_OPTIONS='-v' '-static' '-mtune=pentium' '-march=pentium'
 c:/programs/gfortran/bin/../libexec/gcc/i586-pc-mingw32/4.6.0/f951.exe
xhello.f90 -quiet -dumpbase xhello.f90 -mtune=pentium -march=pentium -auxbase
xhello -version -fintrinsic-modules-path
c:/programs/gfortran/bin/../lib/gcc/i586-pc-mingw32/4.6.0/finclude -o
C:\DOCUME~1\Vivek\LOCALS~1\Temp\cc0RLq4i.s
GNU Fortran (GCC) version 4.6.0 20110209 (experimental) [trunk revision 169959]
(i586-pc-mingw32)
compiled by GNU C version 4.6.0 20110209 (experimental) [trunk revision
169959], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran (GCC) version 4.6.0 20110209 (experimental) [trunk revision 169959]
(i586-pc-mingw32)
compiled by GNU C version 4.6.0 20110209 (experimental) [trunk revision
169959], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
COLLECT_GCC_OPTIONS='-v' '-static' '-mtune=pentium' '-march=pentium'
 as -o C:\DOCUME~1\Vivek\LOCALS~1\Temp\ccuaIfDx.o
C:\DOCUME~1\Vivek\LOCALS~1\Temp\cc0RLq4i.s
Reading specs from
c:/programs/gfortran/bin/../lib/gcc/i586-pc-mingw32/4.6.0/../../../libgfortran.spec
rename spec lib to liborig
COLLECT_GCC_OPTIONS='-v' '-static' '-mtune=pentium' '-march=pentium'
COMPILER_PATH=c:/programs/gfortran/bin/../libexec/gcc/i586-pc-mingw32/4.6.0/;c:/programs/gfortran/bin/../libexec/gcc/
LIBRARY_PATH=c:/programs/gfortran/bin/../lib/gcc/i586-pc-mingw32/4.6.0/;c:/programs/gfortran/bin/../lib/gcc/;C:/g95/lib/;c:/programs/gfortran/bin/../lib/gcc/i586-pc-mingw32/4.6.0/../../../
COLLECT_GCC_OPTIONS='-v' '-static' '-mtune=pentium' '-march=pentium'
 c:/programs/gfortran/bin/../libexec/gcc/i586-pc-mingw32/4.6.0/collect2.exe
-Bstatic C:/g95/lib/crt2.o
c:/programs/gfortran/bin/../lib/gcc/i586-pc-mingw32/4.6.0/crtbegin.o
-Lc:/programs/gfortran/bin/../lib/gcc/i586-pc-mingw32/4.6.0
-Lc:/programs/gfortran/bin/../lib/gcc -LC:/g95/lib
-Lc:/programs/gfortran/bin/../lib/gcc/i586-pc-mingw32/4.6.0/../../..
C:\DOCUME~1\Vivek\LOCALS~1\Temp\ccuaIfDx.o -lgfortran -lmingw32 -lgcc_eh -lgcc
-lmoldname -lmingwex -lmsvcrt -lquadmath -lm -lmingw32 -lgcc_eh -lgcc
-lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32
-lmingw32 -lgcc_eh -lgcc -lmoldname -lmingwex -lmsvcrt
c:/programs/gfortran/bin/../lib/gcc/i586-pc-mingw32/4.6.0/crtend.o
C:\programs\gfortran\bin/ld.exe: Dwarf Error: Offset (3262982616) greater than
or equal to .debug_abbrev size (1301).
c:/programs/gfortran/bin/../lib/gcc/i586-pc-mingw32/4.6.0/../../..\libgfortran.a(transfer.o):transfer.c:(.text$sprintf+0x1b):
undefined reference to `__mingw_vsprintf'
C:\programs\gfortran\bin/ld.exe: Dwarf Error: Offset (3663100) greater than or
equal to .debug_abbrev size (615).
c:/programs/gfortran/bin/../lib/gcc/i586-pc-mingw32/4.6.0/../../..\libgfortran.a(main.o):main.c:(.text$sprintf+0x1b):
undefined reference to `__mingw_vsprintf'
C:\programs\gfortran\bin/ld.exe: Dwarf Error: Offset (1656724012) greater than
or equal to .debug_abbrev size (1266).
c:/programs/gfortran/bin/../lib/gcc/i586-pc-mingw32/4.6.0/../../..\libgfortran.a(unix.o):unix.c:(.text$sprintf+0x1b):
undefined reference to `__mingw_vsprintf'
C:\programs\gfortran\bin/ld.exe: Dwarf Error: Offset (2588113216) greater than
or equal to .debug_abbrev size (1148).
c:/programs/gfortran/bin/../lib/gcc/i586-pc-mingw32/4.6.0/../../..\libgfortran.a(format.o):format.c:(.text$sprintf+0x1b):
undefined reference to `__mingw_vsprintf'
C:\programs\gfortran\bin/ld.exe: Dwarf Error: Offset (4154058048) greater than
or equal to .debug_abbrev size (1323).
c:/programs/gfortran/bin/../lib/gcc/i586-pc-mingw32/4.6.0/../../..\libgfortran.a(list_read.o):list_read.c:(.

[Bug fortran/31879] New: ICE with function having array of character variables argument

[vivekrao4 at yahoo dot com]

module str_mod
contains
function copy_str(xx) result(yy)
character (len=*), intent(in) :: xx(:)
character (len=1)   :: yy(size(xx))
yy = (/xx/)
end function copy_str
subroutine print_vec(labels)
character (len=*), intent(in) :: labels(:)
print*,labels
end subroutine print_vec
!
function ccopy(yy) result(xy)
character (len=*), intent(in) :: yy(:)
character (len=1) :: xy(size(yy))
xy = yy
end function ccopy
end module str_mod
!
program xx
use str_mod, only: print_vec,ccopy,copy_str
implicit none
call print_vec(ccopy("_"//copy_str(["a"])))
end program xx

gfortran -c -v xxgfortran_bug.f90

Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../trunk/configure --prefix=/mingw
--enable-languages=c,fortran --with-gmp=/home/coudert/local --disable-nls
--with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror
--enable-bootstrap --enable-threads --build=i386-pc-mingw32 --disable-shared
--enable-libgomp
Thread model: win32
gcc version 4.3.0 20070506 (experimental)
 c:/programs/gfortran/bin/../libexec/gcc/i386-pc-mingw32/4.3.0/f951.exe
xxgfortran_bug.f90 -quiet -dumpbase xxgfortran_bug.f90 -mtune=i386 -auxbase
xxgfortran_bug -version -fintrinsic-modules-path
c:/programs/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0/finclude -o
C:\DOCUME~1\vrao\LOCALS~1\Temp/ccB1NNxN.s
GNU F95 version 4.3.0 20070506 (experimental) (i386-pc-mingw32)
compiled by GNU C version 4.3.0 20070506 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

xxgfortran_bug.f90: In function 'MAIN__':
xxgfortran_bug.f90:20: internal compiler error: in gfc_conv_expr_descriptor, at
fortran/trans-array.c:4474
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.


-- 
   Summary: ICE with function having array of character variables
argument
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: vivekrao4 at yahoo dot com


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

[Bug fortran/31879] ICE with function having array of character variables argument

[vivekrao4 at yahoo dot com]

--- Comment #1 from vivekrao4 at yahoo dot com  2007-05-09 16:41 ---
A simpler program exhibiting the same bug:

module str_mod
contains
function ccopy(yy) result(xy)
character (len=*), intent(in) :: yy(:)
character (len=1) :: xy(size(yy))
xy = yy
end function ccopy
end module str_mod
!
program xx
use str_mod, only: ccopy
implicit none
print*,ccopy("_"//["a"])
end program xx

gfortran -c -v xxgfortran_bug.f90
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../trunk/configure --prefix=/mingw
--enable-languages=c,fortran --with-gmp=/home/coudert/local --disable-nls
--with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror
--enable-bootstrap --enable-threads --build=i386-pc-mingw32 --disable-shared
--enable-libgomp
Thread model: win32
gcc version 4.3.0 20070506 (experimental)
 c:/programs/gfortran/bin/../libexec/gcc/i386-pc-mingw32/4.3.0/f951.exe
xxgfortran_bug.f90 -quiet -dumpbase xxgfortran_bug.f90 -mtune=i386 -auxbase
xxgfortran_bug -version -fintrinsic-modules-path
c:/programs/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0/finclude -o
C:\DOCUME~1\vrao\LOCALS~1\Temp/ccGUWtbU.s
GNU F95 version 4.3.0 20070506 (experimental) (i386-pc-mingw32)
compiled by GNU C version 4.3.0 20070506 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

xxgfortran_bug.f90: In function 'MAIN__':
xxgfortran_bug.f90:10: internal compiler error: in gfc_conv_expr_descriptor, at
fortran/trans-array.c:4474
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.


-- 


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

[Bug fortran/32702] New: crash when printing big character variable

[vivekrao4 at yahoo dot com]

For the code

program main
character (len=1) :: word
word = "dog"
print*,"word =",word
end program main

compiled with

U:\vrao\fortran>gfortran -v xbug.f90
Driving: gfortran -v xbug.f90 -lgfortranbegin -lgfortran
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../trunk/configure --prefix=/mingw
--enable-languages=c,fortran --with-gmp=/home/coudert/local --disable-nls
--with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror
--enable-bootstrap --enable-threads --build=i386-pc-mingw32 --disable-shared
--enable-libgomp
Thread model: win32
gcc version 4.3.0 20070706 (experimental)
 c:/programs/gfortran/bin/../libexec/gcc/i386-pc-mingw32/4.3.0/f951.exe
xbug.f90 -quiet -dumpbase xbug.f90 -mtune=i386 -auxbase xbug -version
-fintrinsic-modules-path
c:/programs/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0/finclude -o
C:\DOCUME~1\vrao\LOCALS~1\Temp/ccfHwMra.s
GNU F95 version 4.3.0 20070706 (experimental) (i386-pc-mingw32)
compiled by GNU C version 4.3.0 20070706 (experimental), GMP version
4.2.1, MPFR version 2.2.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
 as -o C:\DOCUME~1\vrao\LOCALS~1\Temp/cc1pIAXq.o
C:\DOCUME~1\vrao\LOCALS~1\Temp/ccfHwMra.s
 c:/programs/gfortran/bin/../libexec/gcc/i386-pc-mingw32/4.3.0/collect2.exe
-Bdynamic c:/programs/g95/lib/crt2.o
c:/programs/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0/crtbegin.o
-Lc:/programs/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0
-Lc:/programs/gfortran/bin/../lib/gcc -Lc:/programs/g95/lib
-Lc:/programs/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0/../../..
C:\DOCUME~1\vrao\LOCALS~1\Temp/cc1pIAXq.o -lgfortranbegin -lgfortran -lmingw32
-lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32
-lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt
c:/programs/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0/crtend.o

the program on Windows XP prints "word =dog" but then crashes with a pop-up
message

"a.exe has encountered a problem and needs to close".

The program runs fine with the LEN is reduced to 8000.


-- 
   Summary: crash when printing big character variable
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: vivekrao4 at yahoo dot com


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

[Bug fortran/32703] New: ICE with [trim(character_variable)]

[vivekrao4 at yahoo dot com]

For the program

program array_char
implicit none
character (len=1) :: x
x = "a"
print*,[trim(x)]
end program array_char

compiling on Windows XP with

gfortran -v xconcat.f90

produces an ICE:

Driving: gfortran -v xconcat.f90 -lgfortranbegin -lgfortran
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../trunk/configure --prefix=/mingw
--enable-languages=c,fortran --with-gmp=/home/coudert/local --disable-nls
--with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror
--enable-bootstrap --enable-threads --build=i386-pc-mingw32 --disable-shared
--enable-libgomp
Thread model: win32
gcc version 4.3.0 20070706 (experimental)
 c:/programs/gfortran/bin/../libexec/gcc/i386-pc-mingw32/4.3.0/f951.exe
xconcat.f90 -quiet -dumpbase xconcat.f90 -mtune=i386 -auxbase xconcat -version
-fintrinsic-modules-path
c:/programs/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0/finclude -o
C:\DOCUME~1\vrao\LOCALS~1\Temp/cc8grzTr.s
GNU F95 version 4.3.0 20070706 (experimental) (i386-pc-mingw32)
compiled by GNU C version 4.3.0 20070706 (experimental), GMP version
4.2.1, MPFR version 2.2.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
xconcat.f90: In function 'MAIN__':
xconcat.f90:4: 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.

The program works if the line

print*,[trim(x)]

is replaced with

print*,[x]

or 

print*,trim(x)


-- 
   Summary: ICE with [trim(character_variable)]
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: vivekrao4 at yahoo dot com


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

[Bug fortran/32707] New: mismatched character lengths in array

[vivekrao4 at yahoo dot com]

For the following invalid code

program xtrim_array
implicit none
character (len=4) :: xx(2)
xx = [trim("boy "),trim("girl")] ! invalid -- elements have different lengths
print*,"xx = '" // xx(1) // "' '" // xx(2) // "'" 
end program xtrim_array

compiling and running with gfortran gives

gfortran -v -O0 -Wall -fbounds-check -static -g xtrim_array.f90
Driving: gfortran -v -O0 -Wall -fbounds-check -static -g xtrim_array.f90
-lgfortranbegin -lgfortran
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../trunk/configure --prefix=/mingw
--enable-languages=c,fortran --with-gmp=/home/coudert/local --disable-nls
--with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror
--enable-bootstrap --enable-threads --build=i386-pc-mingw32 --disable-shared
--enable-libgomp
Thread model: win32
gcc version 4.3.0 20070706 (experimental)
 c:/programs/gfortran/bin/../libexec/gcc/i386-pc-mingw32/4.3.0/f951.exe
xtrim_array.f90 -quiet -dumpbase xtrim_array.f90 -mtune=i386 -auxbase
xtrim_array -g -O0 -Wall -version -fbounds-check -fintrinsic-modules-path
c:/programs/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0/finclude -o
C:\DOCUME~1\vrao\LOCALS~1\Temp/ccaETULf.s
GNU F95 version 4.3.0 20070706 (experimental) (i386-pc-mingw32)
compiled by GNU C version 4.3.0 20070706 (experimental), GMP version
4.2.1, MPFR version 2.2.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
 as -o C:\DOCUME~1\vrao\LOCALS~1\Temp/ccg74eom.o
C:\DOCUME~1\vrao\LOCALS~1\Temp/ccaETULf.s
 c:/programs/gfortran/bin/../libexec/gcc/i386-pc-mingw32/4.3.0/collect2.exe
-Bstatic c:/programs/g95/lib/crt2.o
c:/programs/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0/crtbegin.o
-Lc:/programs/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0
-Lc:/programs/gfortran/bin/../lib/gcc -Lc:/programs/g95/lib
-Lc:/programs/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0/../../..
C:\DOCUME~1\vrao\LOCALS~1\Temp/ccg74eom.o -lgfortranbegin -lgfortran -lmingw32
-lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32
-lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt
c:/programs/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0/crtend.o

U:\vrao\fortran>a
 xx = 'boy ' 'girl'

It would be nice if gfortran gave a compile-time or run-time error.

Mingw G95 Jun 30 2007 with the default options says

In file xtrim_array.f90:4

xx = [trim("boy "),trim("girl")] ! invalid -- elements have different lengths
   1
Error: Element in character array constructor at (1) has length 4 instead of 3


-- 
   Summary: mismatched character lengths in array
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
     Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vivekrao4 at yahoo dot com


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

[Bug fortran/32707] mismatched character lengths in array

[vivekrao4 at yahoo dot com]

--- Comment #1 from vivekrao4 at yahoo dot com  2007-07-09 19:05 ---
Gfortran also does not warn about the simpler code

program xtrim_array
! check if compiler catches character array constructor with elements of
different sizes
implicit none
character (len=4) :: xx(2)
xx = ["boy","girl"]
print*,"xx = '" // xx(1) // "' '" // xx(2) // "'" 
end program xtrim_array


-- 


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

[Bug fortran/83192] ICE for printing derived type

[vivekrao4 at yahoo dot com]

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

--- Comment #2 from Vivek Rao  ---
Using GNU Fortran (GCC) 8.0.1 20180408 (experimental) from equation.com the
code now compiles, so there may have been a bug in their previous build. I
suggest closing this report.

[Bug fortran/86626] New: ICE

[vivekrao4 at yahoo dot com]

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

Bug ID: 86626
   Summary: ICE
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vivekrao4 at yahoo dot com
  Target Milestone: ---

For the code

module xyz
implicit none
interface repeat
   module procedure bar
end interface repeat
contains
pure function foo(xx) result(tf)
logical, intent(in), optional :: xx
logical   :: tf
if (present(xx)) then
   tf = .not. xx
else
   tf = .false.
end if
end function foo
!
function bar(n,xx,alternate) result(yy)
integer  , intent(in) :: n
character (len=*), intent(in) :: xx(:)
logical  , intent(in), optional :: alternate
character (len=len(xx))   :: yy(n*size(xx))
integer   :: i,j
if (foo(alternate)) then
   yy = (/((xx(j),i=1,n),j=1,size(xx))/)
else
   yy = (/(xx,i=1,n)/)
end if
end function bar
!
subroutine abc(labels)
character (len=*), intent(in) :: labels(:)
end subroutine abc
!
elemental function tappend(xx,yy) result(xy)
character (len=*), intent(in) :: xx,yy
character (len=len(xx) + len(yy)) :: xy
xy = trim(xx) // yy
end function tappend
end module xyz
!
program main
use xyz
implicit none
call abc(labels=tappend(["a"],"_"//repeat(1,["a"])))
end program main

compiling gfortran -c xbase_system_bug.f90 using GNU Fortran (GCC) 9.0.0
20180715 (experimental) from equation.com on Windows 10 gives

xbase_system_bug.f90:44:0:

 call abc(labels=tappend(["a"],"_"//repeat(1,["a"])))

internal compiler error: Segmentation fault

and gfortran 4.8.4 on Windows sub-system for Linux gives the same result.

[Bug fortran/88079] New: warn about procedure arguments without INTENT

[vivekrao4 at yahoo dot com]

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

Bug ID: 88079
   Summary: warn about procedure arguments without INTENT
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vivekrao4 at yahoo dot com
  Target Milestone: ---

I think all new Fortran code should have the INTENT specified for the arguments
of all procedures. I request that gfortran add a warning for code not doing
this. If a warning is added, users who agree with my style recommendation can
use a -Werror flag to force them to fix code without INTENTs for all arguments.

This is, of course, an enhancement request, not a bug report.

[Bug fortran/88080] New: Add warning if IMPLICIT NONE is missing

[vivekrao4 at yahoo dot com]

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

Bug ID: 88080
   Summary: Add warning if IMPLICIT NONE is missing
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vivekrao4 at yahoo dot com
  Target Milestone: ---

I think new Fortran code should have IMPLICIT NONE in every procedure or
preferably at the beginning of a program or MODULE. I request that gfortran add
an option that warns when this is not the case. Users who want IMPLICIT NONE in
all code can convert such a warning to an error.

This is, of course, an enhancement request and not a bug report.

[Bug fortran/83192] New: ICE for printing derived type

[vivekrao4 at yahoo dot com]

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

Bug ID: 83192
   Summary: ICE for printing derived type
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vivekrao4 at yahoo dot com
  Target Milestone: ---

For GNU Fortran (GCC) 8.0.0 20170430 (experimental) on Windows 10, compiling
the code

module xyz_mod
implicit none
type, public :: bar 
   integer :: i
end type bar
contains
!
subroutine efg()
character (len=100) :: fmt_
type(bar) :: foo
foo = bar(1)
fmt_ = "(i0)"
write (*,fmt_) foo
end subroutine efg
end module xyz_mod

gives output

c:\fortran\2015>gfortran -c date_series_stats_bug.f90
f951.exe: internal compiler error: Segmentation fault
libbacktrace could not find executable to open

[Bug fortran/46917] New: ICE

[vivekrao4 at yahoo dot com]

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

   Summary: ICE
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vivekr...@yahoo.com


For the code 

module random_integer_mod
implicit none
contains
function vec_block(ivec,block_size) result(jvec)
integer, intent(in) :: ivec(:)
integer, intent(in) :: block_size
integer :: jvec(size(ivec)*block_size)
jvec = 1
end function vec_block
!
function permute_blocks(nitems,block_size) result(ivec)
integer, intent(in)  :: block_size,nitems
integer  :: ivec(nitems)
integer  :: nblocks
integer, allocatable :: jvec(:)
nblocks = 1
allocate (jvec(nblocks*block_size))
jvec = vec_block(permutation(nblocks),block_size)
ivec = 1
end function permute_blocks
!
function permutation(n) result(ivec)
integer, intent(in) :: n
integer :: ivec(n)
ivec = 1
end function permutation
end module random_integer_mod

Compiling gives

gfortran -c -v random_integer_gf_ice.f90
Built by Equation Solution .
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=c:/fsf/bin/../libexec/gcc/i686-pc-mingw32/4.6.0/lto-wrapper.exe
Target: i686-pc-mingw32
Thread model: win32
gcc version 4.6.0 20101211 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-c' '-v' '-mtune=generic' '-march=pentiumpro'
 c:/fsf/bin/../libexec/gcc/i686-pc-mingw32/4.6.0/f951.exe
random_integer_gf_ice.f90 -quiet -dumpbase random_integer_gf_ice.f90
-mtune=generic -march=pentiumpro -auxbase random_integer_gf_ice -version
-fintrinsic-modules-path c:/fsf/bin/../lib/gcc/i686-pc-mingw32/4.6.0/finclude
-o C:\DOCUME~1\Vivek\LOCALS~1\Temp\ccZNOJh6.s
GNU Fortran (GCC) version 4.6.0 20101211 (experimental) (i686-pc-mingw32)
compiled by GNU C version 4.6.0 20101211 (experimental), GMP version 5.0.1,
MPFR version 3.0.0, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran (GCC) version 4.6.0 20101211 (experimental) (i686-pc-mingw32)
compiled by GNU C version 4.6.0 20101211 (experimental), GMP version 5.0.1,
MPFR version 3.0.0, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
random_integer_gf_ice.f90: In function 'permute_blocks':
random_integer_gf_ice.f90:18:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug fortran/36795] New: crash with character allocatable array argument

[vivekrao4 at yahoo dot com]

For the code

program main
implicit none
character (len=10), allocatable :: xx(:)
character (len=10)  :: yy
print*,"(5)"
allocate (xx(1))
xx(1)  = "dog"
call foo((xx),xx)
contains
subroutine foo(xx,yy)
character (len=*), intent(in)   :: xx(:)
character (len=*), intent(out), allocatable :: yy(:)
allocate (yy(size(xx)))
yy = xx
end subroutine foo
end program main

the program compiled by gfortran with the default options crashes at run time
with a pop-up box saying "An unhandled win32 exception occurred in a.exe
[55596]"

gfortran -v says

Using built-in specs.
Target: i586-pc-mingw32
Configured with: ../trunk/configure --prefix=/mingw
--enable-languages=c,fortran --with-gmp=/home/FX/local --with-ld=/mingw/bin/ld
--with-as=/mingw/bin/as --disable-werror --enable-bootstrap --enable-threads
--disable-nls --build=i586-pc-mingw32 --enable-libgomp --disable-shared
Thread model: win32
gcc version 4.4.0 20080603 (experimental) [trunk revision 136333] (GCC)


-- 
   Summary: crash with character allocatable array argument
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: vivekrao4 at yahoo dot com


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

[Bug fortran/19759] New: ICE caused by an elemental character function

[vivekrao4 at yahoo dot com]

Compiling the following code on Windows causes an ICE:

program xx
implicit none
write (*,*) tf_char((/.true./),"#")
contains
elemental function tf_char(tf,char_true) result(cc)
logical  , intent(in)  :: tf
character (len=*), intent(in)  :: char_true
character (len=len(char_true)) :: cc
! works if line above replaced with line below
! character (len=1) :: cc
cc = ""
end function tf_char
end program xx

gfortran -v -c -Wall -std=f95 --free-form xx_elem_bug.f 
Using built-in specs.
Configured with: ../gcc/configure --prefix=/mingw --enable-languages=c,f95
Thread model: win32
gcc version 4.0.0 20050120 (experimental)
 c:/programs/gfortran/bin/../libexec/gcc/i686-pc-mingw32/4.0.0/f951.exe 
xx_elem_bug.f -quiet -dumpbase xx_elem_bug.f -mtune=pentiumpro -auxbase 
xx_elem_bug -Wall -std=f95 -version -ffree-form -o C:\DOCUME~1\rao\LOCALS~1
\Temp/ccw5.s
GNU F95 version 4.0.0 20050120 (experimental) (i686-pc-mingw32)
compiled by GNU C version 4.0.0 20050117 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
xx_elem_bug.f: In function 'tf_char':
xx_elem_bug.f:3: warning: unused variable 'tf'
xx_elem_bug.f: In function 'MAIN__':
xx_elem_bug.f:3: internal compiler error: in gfc_conv_function_call, at 
fortran/trans-expr.c:1104
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

-- 
   Summary: ICE caused by an elemental character function
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vivekrao4 at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug fortran/19760] New: wrong results or crash from PURE function

[vivekrao4 at yahoo dot com]

program xx
implicit none
real :: x(1)
x = f((/1.0/))
print*,x
! commenting the above 3 lines and uncommenting the next causes a crash
! write (*,*) f((/4.0/))
contains
pure function f(xx) result(xsum)
real, intent(in) :: xx(:)
real :: xsum(size(xx))
xsum = 1.0
end function f
end program xx

gfortran -o xpure_bug.exe -v --free-form -Wall xpure_bug.f  
Driving: gfortran -o xpure_bug.exe -v -ffree-form -Wall xpure_bug.f -
lgfortranbegin -lgfortran
Using built-in specs.
Configured with: ../gcc/configure --prefix=/mingw --enable-languages=c,f95
Thread model: win32
gcc version 4.0.0 20050120 (experimental)
 c:/programs/gfortran/bin/../libexec/gcc/i686-pc-mingw32/4.0.0/f951.exe 
xpure_bug.f -quiet -dumpbase xpure_bug.f -mtune=pentiumpro -auxbase xpure_bug -
Wall -version -ffree-form -o C:\DOCUME~1\rao\LOCALS~1\Temp/ccaW.s
GNU F95 version 4.0.0 20050120 (experimental) (i686-pc-mingw32)
compiled by GNU C version 4.0.0 20050117 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
 as -o C:\DOCUME~1\rao\LOCALS~1\Temp/ccaIbaaa.o C:\DOCUME~1\rao\LOCALS~1
\Temp/ccaW.s
 ld -Bdynamic -o xpure_bug.exe c:/programs/gfortran/bin/../lib/gcc/i686-pc-
mingw32/4.0.0/../../../crt2.o -Lc:/programs/gfortran/bin/../lib/gcc/i686-pc-
mingw32/4.0.0 -Lc:/programs/gfortran/bin/../lib/gcc -
Lc:/programs/gfortran/bin/../lib/gcc/i686-pc-mingw32/4.0.0/../../.. C:\DOCUME~1
\rao\LOCALS~1\Temp/ccaIbaaa.o -lgfortranbegin -lgfortran -lmingw32 -lgcc -
lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -
lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt

running xpure_bug.exe
  7.9179282E+33

-- 
   Summary: wrong results or crash from PURE function
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vivekrao4 at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug fortran/19766] New: wrong results or crash from PURE function

[vivekrao4 at yahoo dot com]

program xx
implicit none
real :: x(1)
x = f((/1.0/))
print*,x
! commenting the above 3 lines and uncommenting the next causes a crash
! write (*,*) f((/4.0/))
contains
pure function f(xx) result(xsum)
real, intent(in) :: xx(:)
real :: xsum(size(xx))
xsum = 1.0
end function f
end program xx

gfortran -o xpure_bug.exe -v --free-form -Wall xpure_bug.f  
Driving: gfortran -o xpure_bug.exe -v -ffree-form -Wall xpure_bug.f -
lgfortranbegin -lgfortran
Using built-in specs.
Configured with: ../gcc/configure --prefix=/mingw --enable-languages=c,f95
Thread model: win32
gcc version 4.0.0 20050120 (experimental)
 c:/programs/gfortran/bin/../libexec/gcc/i686-pc-mingw32/4.0.0/f951.exe 
xpure_bug.f -quiet -dumpbase xpure_bug.f -mtune=pentiumpro -auxbase xpure_bug -
Wall -version -ffree-form -o C:\DOCUME~1\rao\LOCALS~1\Temp/ccaW.s
GNU F95 version 4.0.0 20050120 (experimental) (i686-pc-mingw32)
compiled by GNU C version 4.0.0 20050117 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
 as -o C:\DOCUME~1\rao\LOCALS~1\Temp/ccaIbaaa.o C:\DOCUME~1\rao\LOCALS~1
\Temp/ccaW.s
 ld -Bdynamic -o xpure_bug.exe c:/programs/gfortran/bin/../lib/gcc/i686-pc-
mingw32/4.0.0/../../../crt2.o -Lc:/programs/gfortran/bin/../lib/gcc/i686-pc-
mingw32/4.0.0 -Lc:/programs/gfortran/bin/../lib/gcc -
Lc:/programs/gfortran/bin/../lib/gcc/i686-pc-mingw32/4.0.0/../../.. C:\DOCUME~1
\rao\LOCALS~1\Temp/ccaIbaaa.o -lgfortranbegin -lgfortran -lmingw32 -lgcc -
lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -
lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt

running xpure_bug.exe
  7.9179282E+33

-- 
   Summary: wrong results or crash from PURE function
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vivekrao4 at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug fortran/18537] New: no warning about tabs with std=f95 option

[vivekrao4 at yahoo dot com]

Tabs in source code are not standard Fortran but are accepted by many 
compilers. Gfortran should at least warn about the use of tabs when invoked 
with the -std=f95 option. The Compaq Visual Fortran and Intel compilers do so.

-- 
   Summary: no warning about tabs with std=f95 option
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vivekrao4 at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug fortran/30319] New: internal error in gfc_resolve_expr() for character parameter

[vivekrao4 at yahoo dot com]

U:\vrao\fortran>type gfort_bug_returns.f90
module amod
character (len=1), parameter :: aa = "z", bb(1) = (/aa/)
end module amod

U:\vrao\fortran>gfortran -v
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../trunk/configure --prefix=/mingw
--enable-languages=c,fortran --with-gmp=/home/coudert/local --disable-nls
--with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror
--enable-bootstrap --enable-threads --host=i386-pc-mingw32 --disable-shared
--enable-libgomp
Thread model: win32
gcc version 4.3.0 20061021 (experimental)

U:\vrao\fortran>gfortran -c gfort_bug_returns.f90
 In file gfort_bug_returns.f90:3

end module amod
  1
 Internal Error at (1):
 gfc_resolve_expr(): Bad expression type


-- 
   Summary: internal error in gfc_resolve_expr() for character
parameter
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: vivekrao4 at yahoo dot com


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

[Bug fortran/30320] New: program crash for SUM applied to zero-size array

[vivekrao4 at yahoo dot com]

U:\vrao\fortran>gfortran -v
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../trunk/configure --prefix=/mingw
--enable-languages=c,fortran --with-gmp=/home/coudert/local --disable-nls
--with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror
--enable-bootstrap --enable-threads --host=i386-pc-mingw32 --disable-shared
--enable-libgomp
Thread model: win32
gcc version 4.3.0 20061021 (experimental)

U:\vrao\fortran>type xzero_size_array.f90
program xzero
implicit none
integer :: ii(1,0)
ii = 1
print*,"sum(ii,dim=1) =",sum(ii,dim=1)
end program xzero

U:\vrao\fortran>gfortran xzero_size_array.f90

U:\vrao\fortran>a.exe

program crashes (Windows pop-up: a.exe has encountered a problem and needs to
close)


-- 
   Summary: program crash for SUM applied to zero-size array
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: vivekrao4 at yahoo dot com


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

[Bug fortran/30321] New: program crash for SUM applied to zero-size array

[vivekrao4 at yahoo dot com]

U:\vrao\fortran>gfortran -v
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../trunk/configure --prefix=/mingw
--enable-languages=c,fortran --with-gmp=/home/coudert/local --disable-nls
--with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror
--enable-bootstrap --enable-threads --host=i386-pc-mingw32 --disable-shared
--enable-libgomp
Thread model: win32
gcc version 4.3.0 20061021 (experimental)

U:\vrao\fortran>type xzero_size_array.f90
program xzero
implicit none
integer :: ii(1,0)
ii = 1
print*,"sum(ii,dim=1) =",sum(ii,dim=1)
end program xzero

U:\vrao\fortran>gfortran xzero_size_array.f90

U:\vrao\fortran>a.exe

program crashes (Windows pop-up: a.exe has encountered a problem and needs to
close)


-- 
   Summary: program crash for SUM applied to zero-size array
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: vivekrao4 at yahoo dot com


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

[Bug fortran/98290] New: run-time error with optional character arguments

[vivekrao4 at yahoo dot com via Gcc-bugs]

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

Bug ID: 98290
   Summary: run-time error with optional character arguments
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vivekrao4 at yahoo dot com
  Target Milestone: ---

With GNU Fortran (GCC) 11.0.0 20200927 (experimental) on Windows from
equation.com, compiling and running the code

function c(x1,x2) result(vec)
! return array of present character variable arguments
character (len=*) , intent(in), optional :: x1,x2
character (len=10), allocatable  :: vec(:)
character (len=10), allocatable  :: vec_(:)
integer  :: n
allocate (vec_(2))
vec = ""
if (present(x1)) vec_(1) = x1
if (present(x2)) vec_(2) = x2
n = count([present(x1),present(x2)])
allocate (vec(n))
if (n > 0) vec = vec_(:n)
end function c
end module util_mod
!
program xc
use util_mod, only: c
implicit none
print*,c("girl","boy")
end program xc

gives

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x
#1  0x
#2  0x
#3  0x
#4  0x
#5  0x
#6  0x
#7  0x
#8  0x
#9  0x
#10  0x
#11  0x
#12  0x
#13  0x
#14  0x

but 

gives

 girl  boy   

with g95 and Intel Fortran.

[Bug fortran/98290] run-time error with optional character arguments

[vivekrao4 at yahoo dot com via Gcc-bugs]

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

Vivek Rao  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Vivek Rao  ---
Sorry, never mind. When I remove the code

vec = ""

which is illegal because vec has not yet been allocated, the code runs fine
with gfortran.

[Bug fortran/105038] New: Improve error message for recursive type

[vivekrao4 at yahoo dot com via Gcc-bugs]

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

Bug ID: 105038
   Summary: Improve error message for recursive type
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vivekrao4 at yahoo dot com
  Target Milestone: ---

For the code

module m
implicit none
type :: t
   integer :: i
   type(t) :: x
end type t
end module m

gfortran says

recursive_type.f90:5:15:

5 |type(t) :: x
  |   1
Error: Component at (1) must have the POINTER attribute

but the code compiles if x has either the POINTER or ALLOCATABLE attribute, and
the error message should reflect this.

[Bug fortran/104096] New: ICE with parameterized derived type (PDT)

[vivekrao4 at yahoo dot com via Gcc-bugs]

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

Bug ID: 104096
   Summary: ICE with parameterized derived type (PDT)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vivekrao4 at yahoo dot com
  Target Milestone: ---

gfortran-11 --version
GNU Fortran (Ubuntu 11.1.0-1ubuntu1~20.04) 11.1.0


(base) /mnt/c/fortran/test$ cat pdt_sub.f90
module m 
implicit none
type :: t(n) 
  integer, len :: n = 0
  integer :: vec(n)
end type t
contains
subroutine disp(dt)
type(t(n=*)), intent(in) :: dt
print*,dt%vec
end subroutine disp
end module m
!
program main
use m, only: t, disp
implicit none
integer, parameter :: n = 3
type(t(n)) :: x
x%vec = [1,4,9]
print*,x%vec
call disp(x)
end program main

(base) /mnt/c/fortran/test$ gfortran-11 pdt_sub.f90
f951: internal compiler error: gfc_compare_array_spec(): Array spec clobbered
0x14f8018 gfc_internal_error(char const*, ...)
???:0
0x14a723b gfc_compare_array_spec(gfc_array_spec*, gfc_array_spec*)
???:0
0x14fb98a gfc_compare_derived_types(gfc_symbol*, gfc_symbol*)
???:0
0x15014b0 gfc_compare_actual_formal(gfc_actual_arglist**, gfc_formal_arglist*,
int, int, bool, locus*)
???:0
0x150283b gfc_procedure_use(gfc_symbol*, gfc_actual_arglist**, locus*)
???:0
0x1591c97 gfc_resolve_code(gfc_code*, gfc_namespace*)
???:0
0x1572ad1 gfc_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/104097] New: parameterized derived type (PDT) with type-bound procedure

[vivekrao4 at yahoo dot com via Gcc-bugs]

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

Bug ID: 104097
   Summary: parameterized derived type (PDT) with type-bound
procedure
   Product: gcc
   Version: og11 (devel/omp/gcc-11)
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vivekrao4 at yahoo dot com
  Target Milestone: ---

The code

module m 
implicit none
type :: t(n) 
  integer, len :: n = 0
  integer :: vec(n)
  contains
procedure :: disp
end type t
contains
subroutine disp(dt)
class(t(n=*)), intent(in) :: dt
print*,dt%vec
end subroutine disp
end module m
!
program main
use m
implicit none
integer, parameter :: n = 3
type(t(n)) :: x
x%vec = [1,4,9]
print*,x%vec
call x%disp()
end program main

compiles and runs with Intel Fortran, giving output 

   1   4   9
   1   4   9

but with gfortran I get

(base) /mnt/c/fortran/test$ gfortran-11 --version
GNU Fortran (Ubuntu 11.1.0-1ubuntu1~20.04) 11.1.0


(base) /mnt/c/fortran/test$ gfortran-11 pdt_tbp.f90
pdt_tbp.f90:7:13:

7 | procedure :: disp
  | 1
Error: Argument ‘dt’ of ‘disp’ with PASS(dt) at (1) must be of the derived-type
‘t’
pdt_tbp.f90:17:5:

   17 | use m
  | 1
Fatal Error: Cannot open module file ‘m.mod’ for reading at (1): No such file
or directory
compilation terminated.

[Bug fortran/104309] New: Elemental character function should not return array of character variables of different lengths.

[vivekrao4 at yahoo dot com via Gcc-bugs]

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

Bug ID: 104309
   Summary: Elemental character function should not return array
of character variables of different lengths.
   Product: gcc
   Version: fortran-dev
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vivekrao4 at yahoo dot com
  Target Milestone: ---

As discussed at
https://fortran-lang.discourse.group/t/elemental-character-function/2697 ,
gfortran compiles and runs

module m
contains
elemental function mytrim(x) result(y)
character (len=*), intent(in) :: x
character (len=len_trim(x))   :: y
y = trim(x)
end function mytrim
end module m
!
program test_mytrim
use m
print "(a,'_')", mytrim(["Fortran","Julia  "])
end program test_mytrim

giving output

Fortran_
Julia_

but I think g95 is correct in saying

In file mytrim.f90:5

character (len=len_trim(x))   :: y
1
Error: Dummy variable 'x' at (1) of an ELEMENTAL procedure cannot appear in a
specification expression

[Bug fortran/104346] New: Problem with overloaded assignment when LHS is allocatable array

[vivekrao4 at yahoo dot com via Gcc-bugs]

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

Bug ID: 104346
   Summary: Problem with overloaded assignment when LHS is
allocatable array
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vivekrao4 at yahoo dot com
  Target Milestone: ---

For the code 

module assignment_mod
implicit none
interface assignment(=)
   module procedure int_from_char
end interface
contains
elemental subroutine int_from_char(i,s)
integer, intent(out) :: i
character (len=*), intent(in) :: s
read (s,*) i
end subroutine int_from_char
end module assignment_mod
!
program test_assignment
use assignment_mod, only: assignment(=)
implicit none
integer :: j,k(2)
integer, allocatable :: ialloc(:)
j = "4"
print*,"j=",j
k = ["4","9"]
print*,"k=",k
ialloc = ["4","9"]
print*,"ialloc=",ialloc
end program test_assignment

compiling with GNU Fortran (GCC) 12.0.0 20211024 (experimental) from
equation.com and running gives

 j=   4
 k=   4   9

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Intel Fortran also has trouble with the code:
https://community.intel.com/t5/Intel-Fortran-Compiler/Problem-with-overloaded-assignment-when-LHS-is-allocatable-array/m-p/1356724/emcs_t/S2h8ZW1haWx8dG9waWNfc3Vic2NyaXB0aW9ufEtaNVBQV1dXUDkxOTBHfDEzNTY3MjR8U1VCU0NSSVBUSU9OU3xoSw#M159809
.

[Bug fortran/104346] Problem with overloaded assignment when LHS is allocatable array

[vivekrao4 at yahoo dot com via Gcc-bugs]

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

--- Comment #1 from Vivek Rao  ---
It is explained at
https://community.intel.com/t5/Intel-Fortran-Compiler/Problem-with-overloaded-assignment-when-LHS-is-allocatable-array/m-p/1356757/highlight/true#M159812
that the code is not conforming, so this issue can be closed.

"In this case, the standard essentially places the onus on the program (and by
extension its author) to conform, the processor (compiler being part of it) is
not required to issue diagnostics.

And the issue is this: with the defined assignment as specified, the standard
semantics requires the 'ialloc` to be allocated to the right shape prior to
assignment on line 23: "ialloc = ["4","9"]".

You can retry with `allocate( ialloc(2) )` statement preceding the above
assignment and check the program response."

[Bug fortran/56670] Allocatable-length character var causes bogus warning with -Wuninitialized

[vivekrao4 at yahoo dot com via Gcc-bugs]

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

Vivek Rao  changed:

   What|Removed |Added

 CC||vivekrao4 at yahoo dot com

--- Comment #13 from Vivek Rao  ---
Many warnings that I think are spurious for the code

program main
implicit none
character (len=:), allocatable :: words(:)
words = ["dog","cat"]
print*,words
end program main

compiled with gfortran -Wall xalloc_char.f90
using GNU Fortran (GCC) 12.0.0 20211024 (experimental) from equation.com on
Windows gives

xalloc_char.f90:3:42:

3 | character (len=:), allocatable :: words(:)
  |  ^
Warning: '.words' is used uninitialized [-Wuninitialized]
xalloc_char.f90:1:12:

1 | program main
  |^
note: '.words' was declared here
xalloc_char.f90:4:21:

4 | words = ["dog","cat"]
  | ^
Warning: 'words.offset' is used uninitialized [-Wuninitialized]
xalloc_char.f90:3:42:

3 | character (len=:), allocatable :: words(:)
  |  ^
note: 'words' declared here
xalloc_char.f90:4:21:

4 | words = ["dog","cat"]
  | ^
Warning: 'words.dim[0].lbound' is used uninitialized [-Wuninitialized]
xalloc_char.f90:3:42:

3 | character (len=:), allocatable :: words(:)
  |  ^
note: 'words' declared here
xalloc_char.f90:4:21:

4 | words = ["dog","cat"]
  | ^
Warning: 'words.dim[0].ubound' is used uninitialized [-Wuninitialized]
xalloc_char.f90:3:42:

3 | character (len=:), allocatable :: words(:)
  |  ^
note: 'words' declared here
xalloc_char.f90:4:21:

4 | words = ["dog","cat"]
  | ^
Warning: 'words.dim[0].lbound' may be used uninitialized
[-Wmaybe-uninitialized]
xalloc_char.f90:3:42:

3 | character (len=:), allocatable :: words(:)
  |  ^
note: 'words' declared here
xalloc_char.f90:4:21:

4 | words = ["dog","cat"]
  | ^
Warning: 'words.dim[0].ubound' may be used uninitialized
[-Wmaybe-uninitialized]
xalloc_char.f90:3:42:

3 | character (len=:), allocatable :: words(:)
  |  ^
note: 'words' declared here
xalloc_char.f90:4:21:

4 | words = ["dog","cat"]
  | ^
Warning: 'words.dim[0].ubound' may be used uninitialized
[-Wmaybe-uninitialized]
xalloc_char.f90:3:42:

3 | character (len=:), allocatable :: words(:)
  |  ^
note: 'words' declared here
xalloc_char.f90:4:21:

4 | words = ["dog","cat"]
  | ^
Warning: 'words.dim[0].lbound' may be used uninitialized
[-Wmaybe-uninitialized]
xalloc_char.f90:3:42:

3 | character (len=:), allocatable :: words(:)
  |  ^
note: 'words' declared here

[Bug fortran/102638] New: Add warning for implicit save

[vivekrao4 at yahoo dot com via Gcc-bugs]

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

Bug ID: 102638
   Summary: Add warning for implicit save
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vivekrao4 at yahoo dot com
  Target Milestone: ---

I request that a -Wimplicit-save option be added and made part of -Wall and
-Wextra. Within a procedure, a declaration such as

integer :: i = 0

would trigger the warning. To silence it, the user would have to write

integer, save :: i = 0

Implicit save is a bad feature of Fortran that often surprises and perplexes
newcomers to the language. Gfortran must implement the standard, but it can
nudge users toward better practices with a -Wimplicit-save option.

[Bug fortran/102638] Add warning for implicit save

[vivekrao4 at yahoo dot com via Gcc-bugs]

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

--- Comment #1 from Vivek Rao  ---
I meant to say that -Wimplicit-save would be part of -Wall *or* -Wextra.

[Bug fortran/119579] New: Derived type not initialized correctly with array sections

[vivekrao4 at yahoo dot com via Gcc-bugs]

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

Bug ID: 119579
   Summary: Derived type not initialized correctly with array
sections
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vivekrao4 at yahoo dot com
  Target Milestone: ---

For the code

module dataframe_mod
  implicit none
  private
  public :: DataFrame, display, subset_stride

  type :: DataFrame
 real(kind=4), allocatable :: values(:,:)
  end type DataFrame

contains

  subroutine display(self)
class(DataFrame) :: self
integer :: i
do i = 1, UBOUND(self%values,dim=1)
   write(*,"(1x,A,I1,*(1x,f10.4))") "row: ", i, self%values(i,:)
end do
  end subroutine display

  function subset_stride(df) result(df_new)
type(DataFrame) :: df
type(DataFrame) :: df_new
!...suspect below ...
df_new = DataFrame(values  = df%values(1:8:3, :))
!...can fix this by explicitly setting result df_new
! uncomment_for_working_testcase 
!allocate(df_new%values(3,2))
!df_new%values(1,:) = [ 1.1, 1.2 ]
!df_new%values(2,:) = [ 4.1, 4.2 ]
!df_new%values(3,:) = [ 7.1, 7.2 ]
  end function subset_stride

end module dataframe_mod

program xxdataframe
  use dataframe_mod
  implicit none
  type(DataFrame) :: df, df_new
  allocate(df%values(8,2) )
   df%values(1,:) = [ 1.1, 1.2 ]
   df%values(2,:) = [ 2.1, 2.2 ]
   df%values(3,:) = [ 3.1, 3.2 ]
   df%values(4,:) = [ 4.1, 4.2 ]
   df%values(5,:) = [ 5.1, 5.2 ]
   df%values(6,:) = [ 6.1, 6.2 ]
   df%values(7,:) = [ 7.1, 7.2 ]
   df%values(8,:) = [ 8.1, 8.2 ]
  write(*,*) "display initial values of df"
   call display(df)
  write(*,*)

  df_new = subset_stride(df)
  write(*,*) "print df_new, should have rows 1, 4, 7 "
  write(*,*) "shape(df_new%values)", shape(df_new%values)
  write(*,*) "bounds of df_new%values, dim 1: ", LBOUND(df_new%values,1),
UBOUND(df_new%values,1)
  write(*,*) "bounds of df_new%values, dim 2: ", LBOUND(df_new%values,2),
UBOUND(df_new%values,2)
  call display(df_new)
end program xxdataframe

from
https://fortran-lang.discourse.group/t/derived-type-initialized-with-array-sections-giving-unexpected-results/9470/5?u=beliavsky

gfortran gives incorrect output

 display initial values of df
 row: 1 1.1000 1.2000
 row: 2 2.1000 2.2000
 row: 3 3.1000 3.2000
 row: 4 4.1000 4.2000
 row: 5 5.1000 5.2000
 row: 6 6.1000 6.2000
 row: 7 7.1000 7.2000
 row: 8 8.1000 8.2000

 print df_new, should have rows 1, 4, 7 
 shape(df_new%values)   3   2
 bounds of df_new%values, dim 1:1   3
 bounds of df_new%values, dim 2:1   2
 row: 1 1.1000 1.2000
 row: 2 2.1000 2.2000
 row: 3 3.1000 3.2000