Recent changes to bugs

runtime array bounds exceeded strange behaviour

2007-04-13T20:03:48Z

The G95 compiler does not provide a meaningfull error message (if at all...) when array boundaries are exceeded at runtime. Compiling with -ftrace=full does not change anything.

In addition, the generated executable exhibits different behavior depending on how exactly the code is written although it should apparently not play a role. The bug was tested in MS Windows XP and 2000. The compiler package was the latest self-extracting Windows x86 version (2007-04-10 14:02).

Below are 3 simple programs. The difference between the two first programs is the way the array is initialized. In both cases the array bounds are exceeded in the same way. However, in the first case no error is generated (the extra element is neglected), while in the second case the exception is reported as "Access Violation", and the program crashes. The third program is identical to the second, but with a smaller array. Again the array bounds are exceeded by one element. This time no error is generated and the output is identical to the first case.

Evangelos Bertakis

------------------------------------

integer:: i,array(10)=0

do i=1,11
array(i)=i
write(*,*)array
end do

end

OUTPUT:
1 0 0 0 0 0 0 0 0 0
1 2 0 0 0 0 0 0 0 0
1 2 3 0 0 0 0 0 0 0
1 2 3 4 0 0 0 0 0 0
1 2 3 4 5 0 0 0 0 0
1 2 3 4 5 6 0 0 0 0
1 2 3 4 5 6 7 0 0 0
1 2 3 4 5 6 7 8 0 0
1 2 3 4 5 6 7 8 9 0
1 2 3 4 5 6 7 8 9 10
1 2 3 4 5 6 7 8 9 10

------------------------------------

integer:: i,array(10)

array=0

do i=1,11
array(i)=i
write(*,*)array
end do

end

OUTPUT:
1 0 0 0 0 0 0 0 0 0
1 2 0 0 0 0 0 0 0 0
1 2 3 0 0 0 0 0 0 0
1 2 3 4 0 0 0 0 0 0
1 2 3 4 5 0 0 0 0 0
1 2 3 4 5 6 0 0 0 0
1 2 3 4 5 6 7 0 0 0
1 2 3 4 5 6 7 8 0 0
1 2 3 4 5 6 7 8 9 0
1 2 3 4 5 6 7 8 9 10

------------------------------------

integer:: i,array(5)

array=0

do i=1,6
array(i)=i
write(*,*)array
end do

end

OUTPUT:
1 0 0 0 0
1 2 0 0 0
1 2 3 0 0
1 2 3 4 0
1 2 3 4 5
1 2 3 4 5

------------------------------------

Problem compiling g95 0.90

2006-08-08T20:05:11Z

# make
make all-am
make[1]: Entering directory `/tmp/g95-0.90'
gcc -s -O3 -march=i686 -Wall -Wmissing-prototypes -o
g95 g95-arith.o g95-array.o g95-bbt.o g95-bigint.o
g95-bigreal.o g95-check.o g95-decl.o g95-entry.o
g95-error.o g95-expr.o g95-forall.o g95-format.o
g95-imodule.o g95-interface.o g95-intrinsic.o g95-io.o
g95-iresolve.o g95-kinds.o g95-lang-options.o
g95-match.o g95-matchexp.o g95-misc.o g95-module.o
g95-parse.o g95-primary.o g95-resolve.o g95-scalarize.o
g95-scanner.o g95-select.o g95-simplify.o g95-st.o
g95-symbol.o
g95-lang-options.o: In function `g95_init_options':
lang-options.c:(.text+0x96): undefined reference to
`set_Wall'
collect2: ld returned 1 exit status
make[1]: *** [g95] Error 1
make[1]: Leaving directory `/tmp/g95-0.90'
make: *** [all] Error 2

speed issues

2006-07-28T10:32:36Z

Well, it is not really a bug, but may be of interest.

We run/develop a scientific software package since quite
a few years. We tested and run it an various 32/64 Linux
machines. Our standard compiler is the intel compiler
(ifort).

When I compile with G95, the runtime performace is
significantly lower ... sometimes by a factor of ten.
(in the number crunching routines)

Is there anything, I can do with options? Do the intel
guys mess around with the floating point operations to
spead it up?
Btw. Does G95 avoid multiplication, when a factor is 0.0?
Can the slow down be related to huge arrays and memory
read/write
things?

Interestingly we encountered a similar performance
breakdown with a pgf compiler on a 64 bit machine.

I would appreciate a short note, which might help us.

Problem compiling g95 0.50

2006-07-05T20:11:44Z

# make
make all-am
make[1]: Entering directory `/tmp/g95-0.50'
gcc -s -O3 -march=i686 -Wall -Wmissing-prototypes -o
g95 g95-arith.o g95-array.o g95-bbt.o g95-bigint.o
g95-bigreal.o g95-check.o g95-decl.o g95-entry.o
g95-error.o g95-expr.o g95-forall.o g95-format.o
g95-imodule.o g95-interface.o g95-intrinsic.o g95-io.o
g95-iresolve.o g95-kinds.o g95-lang-options.o
g95-match.o g95-matchexp.o g95-misc.o g95-module.o
g95-parse.o g95-primary.o g95-resolve.o g95-scalarize.o
g95-scanner.o g95-select.o g95-simplify.o g95-st.o
g95-symbol.o
g95-lang-options.o: In function `g95_init_options':
lang-options.c:(.text+0x96): undefined reference to
`set_Wall'
collect2: ld returned 1 exit status
make[1]: *** [g95] Error 1
make[1]: Leaving directory `/tmp/g95-0.50'
make: *** [all] Error 2

data type ordering

2006-06-02T20:49:21Z

The previous versions did not have a problem with
defined data types being out of order. I downloaded the
newest version yesterday and it gives me the following
error:

TYPE(Component_Array), DIMENSION ( : ),
ALLOCATABLE :: SubComp

1
Error: Derived type 'component_array' at (1) is being
used before it is defined

The TYPE definition for the Component_Array is
immediately after the TYPE decleration in which it is
called (which used to compile just fine). This now
occurs for all of my derived data types which are out
of sequence in the module.

Internal error: Unexpected array assignment statement

2005-10-06T03:58:27Z

environment: winXPsp2, cygwin 1.5.18, using precompiled
g95 4.0.2 binaries

when the attached source file, brook_module.f90, is
compiled, I encounter an internal error:

$ g95 -c brook_module.f90
In file brook_module.f90:5966

iPTR = SHAPE(VARIABLE)
1
Internal error: Unexpected array assignment statement
at (1)

apologies for submitting such a large chunk of source -
I tried to narrow down the problem but was unsuccessful

I'll try to upload the unprocessed (.F) source and an
include file (.fpp) used to generate the actual source
file (.f90), but not sure if sf will let me upload more
than one file - if successful, the commands to generate
the .f90 are:

$ cp brook_module.F brook_module.c
$ gcc -traditional -E -P brook_module.c | grep -v "^$"
| grep -v "^#" > brook_module.f90

thanks in advance for taking a look at this...

-John Turner

Mixed data type issues with ABS and conditional test.

2005-05-13T17:18:08Z

When using mixed data types (complex , real) with the
intrinsic function ABS in a conditional expression
yields incorrect results. Attached is a short code
that displays the problem.

Seg fault at building LAPACK

2005-02-06T22:59:25Z

When building LAPACK on i686-pc-linux-gnu platform with
g95 binary from
http://g95.sourceforge.net/g95-x86-linux.tgz
(2005-02-05 10:13), I get the following error at the
very first test:

<...>
Testing REAL LAPACK linear equation routines
./xlintsts < stest.in > stest.out 2>&1
make[1]: *** [stest.out] Error 139
make[1]: Leaving directory
`/coast1/sakov/source/external/LAPACK/TESTING'
make: *** [testing] Error 2

Running xlintsts under gdb shows a segmentation fault:

Program received signal SIGSEGV, Segmentation fault.
0x081600ef in slarnv_ (idist=0xbffd9dec,
iseed=0xbffd9fa0, n=0xbffd9fd0,
x=0xc81bd1b0) at slarnv.f:100

Here is the make.inc I used:

<BEGIN>
####################################################################
# LAPACK make include file.
#
# LAPACK, Version 3.0
#
# June 30, 1999
#
####################################################################
#
SHELL = /bin/sh
#
# The machine (platform) identifier to append to the
library names
#
PLAT =
#
# Modify the FORTRAN and OPTS definitions to refer to the
# compiler and desired compiler options for your
machine. NOOPT
# refers to the compiler options desired when NO
OPTIMIZATION is
# selected. Define LOADER and LOADOPTS to refer to
the loader and
# desired load options for your machine.
#
FORTRAN = g95
OPTS = -g -Wall
DRVOPTS = $(OPTS)
NOOPT = -g -Wall
LOADER = g95
LOADOPTS =
#
# The archiver and the flag(s) to use when building
archive (library)
# If you system has no ranlib, set RANLIB = echo.
#
ARCH = ar
ARCHFLAGS= cr
RANLIB = ranlib
#
# The location of the libraries to which you will
link. (The
# machine-specific, optimized BLAS library should be
used whenever
# possible.)
#
BLASLIB = ../../blas$(PLAT).a
LAPACKLIB = lapack$(PLAT).a
TMGLIB = tmglib$(PLAT).a
EIGSRCLIB = eigsrc$(PLAT).a
LINSRCLIB = linsrc$(PLAT).a
<END>

Cheers
Pavel

move of overlapping sections of array fails

2004-11-29T09:47:27Z

Move of overlapping sections of an array fails when
array is a member of a derived type.

That is true whether the array is of type "integer" or
"character(len=1)" (at least).

With SGI or Intel compilers a code like
"a(2:4) = a(1:3)" works.

And that is stated in many books (I don't have the
standard texts with me): right hand side should/is
evaluated first in any case.

leandre.brault@framatome-anp.com

Issue with READ statement

2004-10-19T17:32:18Z

We use some parts of an old f77 package called CHEMKIN
Libray, from SANDIA lab.
It includes manipulation of binary files, opened this way :
open (UNIT=LINC, FILE=name, STATUS='OLD',
& FORM='UNFORMATTED',ERR=9010)
(Note: ACCESS='sequential' was removed, since he was not
accepted by g77).

THe 2 first I/O instructions are :
REWIND LINC
READ (LINC, ERR=999) VERS, PREC, KERR
(VERS and PREC are CHARACTER*16, KERR is logical).

These few lines works fine when compiling with g77 : VERS
and PREC are perfectly read.
Using g95 and running the code with the same binary file, the
read instruction is not effective.

The rest of the code works fine !!

thanks

Marc TRUSCELLI
Realix technologies
Ingénierie scientifique
marc.truscelli@realix.fr