[Bug fortran/40443] Elemental procedure in genericl interface incorrectly selected in preference to specific procedure

[jpr at csc dot fi]

--- Comment #2 from jpr at csc dot fi  2009-06-15 08:28 ---
(In reply to comment #1)
> Paul, I CC you as you are our generic-resolution expert.
> 
>  * * *
> 
> gfortran 4.1 to 4.5, NAG f95 5.1, g95, ifort 11, openf95, Sun Studio 12 all
> print the following:
> 
> E
> S, S
> E
> E, E   ! << you expect an "S, S" here
> 

FWIW, Portland and Intel compilers both print 

E
S, S
E
S, S

BR, Juha


-- 


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

[Bug fortran/25262] New: compiler dies, explicit interface, array valued function

[jpr at csc dot fi]

Hi!

The test program (below) kills latest gfortran:

[EMAIL PROTECTED] fem]$ gfortran -v test.f90
Driving: gfortran -v test.f90 -lgfortranbegin -lgfortran -lm -shared-libgcc
Using built-in specs.
Target: i386-linux
Configured with: ../gcc/configure --prefix=/tmp/gfortran-20051205/irun
--enable-languages=c,fortran --host=i386-linux
Thread model: posix
gcc version 4.2.0 20051205 (experimental)
 /home/wrk/jpr/irun/bin/../libexec/gcc/i386-linux/4.2.0/f951 test.f90 -quiet
-dumpbase test.f90 -auxbase test -version -o /tmp/ccZbxhvU.s
GNU F95 version 4.2.0 20051205 (experimental) (i386-linux)
compiled by GNU C version 4.0.2 (Debian 4.0.2-2).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
test.f90: In function 'sub':
test.f90:14: internal compiler error: in gfc_trans_arrayfunc_assign, at
fortran/trans-expr.c:2637
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.



platform:
 uname --all
Linux dhcp-38.csc.fi 2.4.20-43.9.legacysmp #1 SMP Sat Apr 30 19:07:33 EDT 2005
i686 i686 i386 GNU/Linux

test program:

PROGRAM test
   REAL, POINTER :: Quant(:)
   REAL :: Ind(2)

   INTERFACE
 FUNCTION x_InsideResidual( Quant ) RESULT(Indicator)
REAL :: Quant(:), Indicator(2)
  END FUNCTION x_InsideResidual
   END INTERFACE

NULLIFY( Quant )
!   print*, x_InsideResidual( Quant )   ! works
!   ind = x_InsideResidual( Quant ); print*,ind ! works
CALL sub( Quant,x_InsideResidual )

CONTAINS

SUBROUTINE sub( Quant, InsideResidual )
  REAL :: Quant(:)

  INTERFACE
FUNCTION InsideResidual( Quant ) RESULT(Indicator)
   REAL :: Quant(:), Indicator(2)
 END FUNCTION InsideResidual
  END INTERFACE

  REAL :: Ind(2)

! EXTERNAL InsideResidual  ! both cases below work, if you uncomment this.
   ! Other compilers seem to agree that you can't
have it...

 ind = InsideResidual( Quant ); print*,Ind! compiler dies
!print*,InsideResidual( Quant )   ! seg fault at runtime
END SUBROUTINE sub

END PROGRAM Test

FUNCTION x_InsideResidual( quant ) RESULT( Indicator )
REAL :: Quant(:), Indicator(2)

Indicator = 1.0d0
END FUNCTION x_InsideResidual


BTW. Great progress with gfortran in recent months!

Regards, Juha


-- 
   Summary:  compiler dies, explicit interface, array valued
function
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jpr at csc dot fi


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

[Bug fortran/25264] New: write to internal unit from the string itself gives wrong result ?

[jpr at csc dot fi]

Hi!

The following program

program a
   character(len=10) :: str

   str = '123'
   write( str, '(a,i1)' ) trim(str),4
   print*,str
end program a

outputs

[EMAIL PROTECTED] fem]$ gfortran -o a a.f90; ./a
 4

all other compilers i've tried (sun f90, xlf, g95, ifort) seem to agree the
output should be
 1234

Regards, Juha


-- 
   Summary: write to internal unit from the string itself gives
wrong result ?
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jpr at csc dot fi


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

[Bug fortran/25292] New: ASSOCIATED( func() ) rejected ?

[jpr at csc dot fi]

The ASSOCIATED statement with function argument is rejected by gfortran.
ifort, g95, pgf90, pathf90, sunf90, xlf90 all happily accept the (somewhat
silly) program below with expected results?

Regards, Juha

program test
   real, pointer :: a

   allocate(a)
   print*,associated( x(a) )

contains

  function x(a) RESULT(b)
real, pointer :: a,b

b => a
  end function x
end program test

gfortran -v -o ptrf ptrf.f90
Driving: gfortran -v -o ptrf ptrf.f90 -lgfortranbegin -lgfortran -lm
-shared-libgcc
Using built-in specs.
Target: i386-linux
Configured with: ../gcc/configure --prefix=/tmp/gfortran-20051205/irun
--enable-languages=c,fortran --host=i386-linux
Thread model: posix
gcc version 4.2.0 20051205 (experimental)
 /home/wrk/jpr/irun/bin/../libexec/gcc/i386-linux/4.2.0/f951 ptrf.f90 -quiet
-dumpbase ptrf.f90 -auxbase ptrf -version -o /tmp/ccZ3fGqg.s
GNU F95 version 4.2.0 20051205 (experimental) (i386-linux)
compiled by GNU C version 4.0.2 (Debian 4.0.2-2).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
 In file ptrf.f90:5

   print*,associated( x(a) )
1
Error: 'pointer' argument of 'associated' intrinsic at (1) must be a variable


-- 
   Summary: ASSOCIATED( func() ) rejected ?
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jpr at csc dot fi


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

[Bug fortran/25307] New: internal read with end=label aborts

[jpr at csc dot fi]

Hi!

The following program 

program test
   character(len=10) :: str
   str = '123'
   read( str, *, end=10 ) i,x
10 continue
   print*,i
end program test

aborts at runtime with somewhat unexpected  message 

gfortran -v -o file file.f90; ./file
Driving: gfortran -v -o file file.f90 -lgfortranbegin -lgfortran -lm
-shared-libgcc
Using built-in specs.
Target: i386-linux
Configured with: ../gcc/configure --prefix=/tmp/gfortran-20051205/irun
--enable-languages=c,fortran --host=i386-linux
Thread model: posix
gcc version 4.2.0 20051205 (experimental)
 /home/wrk/jpr/irun/bin/../libexec/gcc/i386-linux/4.2.0/f951 file.f90 -quiet
-dumpbase file.f90 -auxbase file -version -o /tmp/ccuEHGgN.s
GNU F95 version 4.2.0 20051205 (experimental) (i386-linux)
compiled by GNU C version 4.0.2 (Debian 4.0.2-2).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
 as -V -Qy -o /tmp/ccqaQsjs.o /tmp/ccuEHGgN.s
GNU assembler version 2.13.90.0.18 (i386-redhat-linux) using BFD version
2.13.90.0.18 20030206
 /home/wrk/jpr/irun/bin/../libexec/gcc/i386-linux/4.2.0/collect2 --eh-frame-hdr
-m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o file /usr/lib/crt1.o
/usr/lib/crti.o /home/wrk/jpr/irun/bin/../lib/gcc/i386-linux/4.2.0/crtbegin.o
-L/home/wrk/jpr/irun/bin/../lib/gcc/i386-linux/4.2.0
-L/home/wrk/jpr/irun/bin/../lib/gcc
-L/home/wrk/jpr/irun/bin/../lib/gcc/i386-linux/4.2.0/../../.. /tmp/ccqaQsjs.o
-lgfortranbegin -lgfortran -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/home/wrk/jpr/irun/bin/../lib/gcc/i386-linux/4.2.0/crtend.o /usr/lib/crtn.o
At line 4 of file file.f90
Fortran runtime error: Success

ifort, g95, sun f90, pgf90, pathf90, xlf90 all treat the end specfier
as i would expect...

Juha


-- 
   Summary: internal read with end=label aborts
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jpr at csc dot fi


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

[Bug fortran/18197] bus error on returning from a function

[jpr at csc dot fi]

--- Comment #8 from jpr at csc dot fi  2005-12-14 06:51 ---
(In reply to comment #7)
> (In reply to comment #6)
> > Working on a patch.
> 
> Posted a pacth here: http://gcc.gnu.org/ml/fortran/2005-12/msg00116.html
> 

Is anyone considering approving (or disapproving) Eriks patch? It would also
clear PR 25262 (tested), except for the part that EXTERNAL keyword propably
should not be allowed for procedures with INTERFACE.

Regards, Juha Ruokolainen


-- 


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

[Bug fortran/25806] New: problems with functions returning array pointers?

[jpr at csc dot fi]

Hi!

This code

program a 
  real, target :: storage(10)
  real :: s(5)

  print*,x(5)
  s = 0
  s = x(5)
  print*,s

contains

 function x(n) result(t)
   integer :: n
   real, pointer :: t(:)
   t => storage(1:n)
!  allocate( t(n) )
   t = (/ (i,i=1,n) /)
 end function x
end program a


prints:
free(): invalid pointer 0x5012a0!
   1.00   2.00   3.00   4.00   5.00
   0.00   0.00   0.00   0.00   0.00

on a x86_64. If you delete s=0 statement, the latter line will contain
values from uninitialized memory. 

gfortran --version
GNU Fortran 95 (GCC) 4.2.0 20060112 (experimental)
Copyright (C) 2005 Free Software Foundation, Inc.

Is this supposed to work?

Regards, Juha


-- 
   Summary: problems with functions returning array pointers?
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jpr at csc dot fi


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

[Bug libfortran/33223] New: libfortran / floating point output broken?

[jpr at csc dot fi]

program t
  print*,huge(1.0d0),tiny(1.0d0)
end program t

gives the output

  1.797693134862316E+30^@  2.225073858507201E-30^@

with latest gfortran binary:

Target: i386-pc-linux-gnu
Configured with: /home/fx/gfortran_nightbuild/trunk/configure
--prefix=/home/fx/gfortran_nightbuild/irun-20070828
--enable-languages=c,fortran --build=i386-pc-linux-gnu
--enable-checking=release --with-gmp=/home/fx/gfortran_nightbuild/software
Thread model: posix
gcc version 4.3.0 20070828 (experimental) [trunk revision 127846] (GCC)

Maybe related to this thread:

http://gcc.gnu.org/ml/fortran/2007-08/msg00476.html

?

Regards, Juha


-- 
   Summary: libfortran / floating point output broken?
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jpr at csc dot fi


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

[Bug fortran/33298] Wrong code for SPREAD on dummy arguments

[jpr at csc dot fi]

--- Comment #1 from jpr at csc dot fi  2007-09-04 07:49 ---
The code is invalid without explicit interface to SUB().
Modified code:

  REAL X(2,3), Y(2)
  Y=[1.,2.]
  CALL SUB(X,Y)
  DO I = 1, 3
 PRINT*,X(:,I)
  ENDDO

CONTAINS

  SUBROUTINE SUB(A,B)
  REAL A(:,:), B(:)
  A(:,:) = SPREAD(B(:),2,SIZE(A,2))
  END SUBROUTINE SUB
  END

works just fine. Alternatively

  REAL X(2,3), Y(2)
  Y=[1.,2.]
  CALL SUB(X,Y,size(y,1),size(y,2))
  DO I = 1, 3
 PRINT*,X(:,I)
  ENDDO
  END

  SUBROUTINE SUB(A,B,n,m)
  INTEGER n,m
  REAL A(n,m), B(n)
  A(:,:) = SPREAD(B(:),2,SIZE(A,2))
  END

also works as expected.

If the main program and SUB are compiled together, the compiler could
of course diagnose this, as e.g. pathscale does:

  SUBROUTINE SUB(A,B)
 ^
pathf95-1277 pathf90: ERROR SUB, File = t.f90, Line = 9, Column = 18
  Procedure "SUB" is referenced at line 3 (t.f90).  It must have an explicit
interface specified.

Regards, Juha


-- 


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

[Bug tree-optimization/33299] New: miscompilation with gfortran -O2 -ffast-math -ftree-vectorize

[jpr at csc dot fi]

The following gets miscompiled with gcc 4.3, works with 4.2.0 & 4.2.1 at least.

PROGRAM test
  REAL(8) :: f,dist(2)
  dist = [1.0_8, 0.5_8]
  PRINT*,f(1.0_8, dist), ' should be: ', MINVAL(dist)
END PROGRAM test

FUNCTION f( x, dist ) RESULT(s)
  REAL(8) :: dist(2), x, s
  s = MINVAL(dist)
  IF( x < 0 ) s = -s
END FUNCTION f



gfortran -v -O2 -ffast-math -ftree-vectorize -o test test.f90
Driving: gfortran -v -O2 -ffast-math -ftree-vectorize -o test test.f90
-lgfortranbegin -lgfortra n -lm -shared-libgcc
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /projects/tob/gcc/configure --enable-languages=c,fortran
--prefix=/projects/tob /gcc-trunk
Thread model: posix
gcc version 4.3.0 20070904 (experimental) [trunk revision 128067] (GCC)
COLLECT_GCC_OPTIONS='-v' '-O2' '-ffast-math' '-ftree-vectorize' '-o' 'test'
'-shared-libgcc' '-m tune=generic'
 /wrk/jpr/gcc-trunk/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/f951
test.f90 -quiet -dump base test.f90 -mtune=generic -auxbase test -O2 -version
-ffast-math -ftree-vectorize -fintrinsic -modules-path
/wrk/jpr/gcc-trunk/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/finclude -o
/tmp/ jpr/ccEvFIMX.s
GNU F95 (GCC) version 4.3.0 20070904 (experimental) [trunk revision 128067]
(x86_64-unknown-linu x-gnu)
compiled by GNU C version 4.3.0 20070904 (experimental) [trunk revision
128067], GMP ver sion 4.2.1, MPFR version 2.2.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
COLLECT_GCC_OPTIONS='-v' '-O2' '-ffast-math' '-ftree-vectorize' '-o' 'test'
'-shared-libgcc' '-m tune=generic'
 as -V -Qy -o /tmp/jpr/ccJEvzPa.o /tmp/jpr/ccEvFIMX.s
GNU assembler version 2.15.92.0.2 (x86_64-redhat-linux) using BFD version
2.15.92.0.2 20040927
COMPILER_PATH=/wrk/jpr/gcc-trunk/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/:/wrk/jpr/gcc
-trunk/bin/../libexec/gcc/
LIBRARY_PATH=/wrk/jpr/gcc-trunk/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/:/wrk/jpr/gcc-trun
k/bin/../lib/gcc/:/v/linux26_x86_64/opt/papi/3.5.0/lib64/../lib64/:/wrk/jpr/gcc-trunk/bin/../lib
/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/v/linu
x26_x86_64/opt/papi/3.5.0/lib64/:/wrk/jpr/gcc-trunk/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.
0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-O2' '-ffast-math' '-ftree-vectorize' '-o' 'test'
'-shared-libgcc' '-m tune=generic'
 /wrk/jpr/gcc-trunk/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/collect2
--eh-frame-hdr -m  elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o
test /usr/lib/../lib64/crt1.o /usr/li b/../lib64/crti.o
/wrk/jpr/gcc-trunk/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/crtbegin.o -L
/wrk/jpr/gcc-trunk/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0
-L/wrk/jpr/gcc-trunk/bin/../lib /gcc
-L/v/linux26_x86_64/opt/papi/3.5.0/lib64/../lib64
-L/wrk/jpr/gcc-trunk/bin/../lib/gcc/x86_6
4-unknown-linux-gnu/4.3.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64
-L/v/linux26_x86 _64/opt/papi/3.5.0/lib64
-L/wrk/jpr/gcc-trunk/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../. ./..
/tmp/jpr/ccJEvzPa.o -lgfortranbegin -lgfortran -lm -lgcc_s -lgcc -lc -lgcc_s
-lgcc /wrk/jpr
/gcc-trunk/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/crtfastmath.o
/wrk/jpr/gcc-trunk/bin/.. /lib/gcc/x86_64-unknown-linux-gnu/4.3.0/crtend.o
/usr/lib/../lib64/crtn.o

./test
   1.00   should be:   0.500

Regrads, Juha


-- 
   Summary: miscompilation with gfortran -O2 -ffast-math -ftree-
    vectorize
       Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jpr at csc dot fi
  GCC host triplet: x86_64 linux


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

[Bug fortran/33386] New: Fortran SELECT statement miscompiles

[jpr at csc dot fi]

Hi,

In my application a wrong CASE is occationally selected in a SELECT statement.
I've not been able to reduce the code to do the wrong jump. However, the
following simple code run through valgrind gives uninitialized variable
warnings, which i think might be the source of the problem:

PROGRAM test
   REAL :: x = 0

   SELECT CASE( getstring() )
   CASE('a')
 x = 1
   CASE('b')
 x = 2
   END SELECT
   PRINT*,x

CONTAINS

  FUNCTION getstring() RESULT(s)
CHARACTER(LEN=1) :: s
s = 'c'
  END FUNCTION getstring

END PROGRAM test


Driving: gfortran -v -O0 -g -o a a.f90 -lgfortranbegin -lgfortran -lm
-shared-libgcc
Using built-in specs.
Target: i386-pc-linux-gnu
Configured with: /home/fx/gfortran_nightbuild/trunk/configure
--prefix=/home/fx/gfortran_nightbuild/irun-20070910
--enable-languages=c,fortran --build=i386-pc-linux-gnu
--enable-checking=release --with-gmp=/home/fx/gfortran_nightbuild/software
Thread model: posix
gcc version 4.3.0 20070910 (experimental) [trunk revision 128320] (GCC)
COLLECT_GCC_OPTIONS='-v' '-O0' '-g' '-o' 'a' '-shared-libgcc' '-mtune=i386'
 /home/wrk/jpr/irun/bin/../libexec/gcc/i386-pc-linux-gnu/4.3.0/f951 a.f90
-quiet -dumpbase a.f90 -mtune=i386 -auxbase a -g -O0 -version
-fintrinsic-modules-path
/home/wrk/jpr/irun/bin/../lib/gcc/i386-pc-linux-gnu/4.3.0/finclude -o
/tmp/ccouIARh.s
GNU F95 (GCC) version 4.3.0 20070910 (experimental) [trunk revision 128320]
(i386-pc-linux-gnu)
compiled by GNU C version 4.3.0 20070910 (experimental) [trunk revision
128320], GMP version 4.2.1, MPFR version 2.2.1.
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64211
COLLECT_GCC_OPTIONS='-v' '-O0' '-g' '-o' 'a' '-shared-libgcc' '-mtune=i386'
 as -V -Qy -o /tmp/ccGk0ias.o /tmp/ccouIARh.s
GNU assembler version 2.15.92.0.2 (i386-redhat-linux) using BFD version
2.15.92.0.2 20040927
COMPILER_PATH=/home/wrk/jpr/irun/bin/../libexec/gcc/i386-pc-linux-gnu/4.3.0/:/home/wrk/jpr/irun/bin/../libexec/gcc/
LIBRARY_PATH=/home/wrk/jpr/irun/bin/../lib/gcc/i386-pc-linux-gnu/4.3.0/:/home/wrk/jpr/irun/bin/../lib/gcc/:/home/wrk/jpr/irun/bin/../lib/gcc/i386-pc-linux-gnu/4.3.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-O0' '-g' '-o' 'a' '-shared-libgcc' '-mtune=i386'
 /home/wrk/jpr/irun/bin/../libexec/gcc/i386-pc-linux-gnu/4.3.0/collect2
--eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o a
/usr/lib/crt1.o /usr/lib/crti.o
/home/wrk/jpr/irun/bin/../lib/gcc/i386-pc-linux-gnu/4.3.0/crtbegin.o
-L/home/wrk/jpr/irun/bin/../lib/gcc/i386-pc-linux-gnu/4.3.0
-L/home/wrk/jpr/irun/bin/../lib/gcc
-L/home/wrk/jpr/irun/bin/../lib/gcc/i386-pc-linux-gnu/4.3.0/../../..
/tmp/ccGk0ias.o -lgfortranbegin -lgfortran -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/home/wrk/jpr/irun/bin/../lib/gcc/i386-pc-linux-gnu/4.3.0/crtend.o
/usr/lib/crtn.o

valgrind ./a
==4319== Memcheck, a memory error detector.
==4319== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==4319== Using LibVEX rev 1575, a library for dynamic binary translation.
==4319== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==4319== Using valgrind-3.1.1, a dynamic binary instrumentation framework.
==4319== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==4319== For more details, rerun with: -v
==4319==
==4319== Conditional jump or move depends on uninitialised value(s)
==4319==at 0x80485CE: MAIN__ (a.f90:4)
==4319==by 0x8048690: main (fmain.c:21)
==4319==
==4319== Conditional jump or move depends on uninitialised value(s)
==4319==at 0x80485D7: MAIN__ (a.f90:4)
==4319==by 0x8048690: main (fmain.c:21)
   0.00
==4319==
==4319== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 17 from 1)
==4319== malloc/free: in use at exit: 0 bytes in 0 blocks.
==4319== malloc/free: 11 allocs, 11 frees, 25,425 bytes allocated.
==4319== For counts of detected errors, rerun with: -v
==4319== All heap blocks were freed -- no leaks are possible.

Adding a default case gets rid of the problems, also for my real application
code.

Regards, Juha


-- 
   Summary: Fortran  SELECT statement miscompiles
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jpr at csc dot fi
  GCC host triplet: i386 linux


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

[Bug libfortran/33386] Fortran SELECT statement miscompiles

[jpr at csc dot fi]

--- Comment #3 from jpr at csc dot fi  2007-09-11 10:42 ---
(In reply to comment #1)
> I'll work on that, I've re-written CHARACTER SELECT recently. However, I can't
> reproduce this on x86_64-linux. Could you run "gfortran -fdump-tree-original
> a.f90" and post the a.f90.003t.original file produced?
> 

Hi,

OK thanks. The .original file below is for this code:

PROGRAM test
   CHARACTER :: c='c'
   REAL :: x = 0

   SELECT CASE(c)
   CASE('a')
 x = 1
   CASE('b')
 x = 2
   END SELECT
   PRINT*,x
END PROGRAM test

with the same valgrind warnings:

MAIN__ ()
{
  static real4 x = 0.0;
  static char c[1:1] = "c";
  static int4 options.0[7] = {68, 127, 0, 0, 0, 1, 0};

  _gfortran_set_options (7, (void *) &options.0);
  {
int4 case_num.2;
static struct _jump_struct jumptable.1[2] = {{.string1=&"a"[1]{lb: 1 sz:
1}, .string1_len=1, .string2=&"a"[1]{lb: 1 sz: 1}, .string2_len=1, .target=0},
{.string1=&"b"[1]{lb: 1 sz: 1}, .string1_len=1, .string2=&"b"[1]{lb: 1 sz: 1},
.string2_len=1, .target=1}};

case_num.2 = _gfortran_select_string ((void *) &jumptable.1, 2, &c[1]{lb: 1
sz: 1}, 1);
switch (case_num.2)
  {
case 0 ... 0:;
x = 1.0e+0;
goto L.1;
case 1 ... 1:;
x = 2.0e+0;
goto L.1;
  }
L.1:;
  }
  {
struct __st_parameter_dt dt_parm.3;

dt_parm.3.common.filename = &"a.f90"[1]{lb: 1 sz: 1};
dt_parm.3.common.line = 11;
dt_parm.3.common.flags = 128;
dt_parm.3.common.unit = 6;
_gfortran_st_write (&dt_parm.3);
_gfortran_transfer_real (&dt_parm.3, &x, 4);
_gfortran_st_write_done (&dt_parm.3);
  }
}


-- 


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

[Bug libfortran/33386] Fortran SELECT statement miscompiles

[jpr at csc dot fi]

--- Comment #5 from jpr at csc dot fi  2007-09-11 12:49 ---
Subject: Re:  Fortran  SELECT statement miscompiles


Yes, this seems to do the trick.
Thanx, Juha

>
>
> --- Comment #4 from fxcoudert at gcc dot gnu dot org  2007-09-11 10:48 
> ---
>> Adding a default case gets rid of the problems, also for my real application
>> code.
>
> If you're in a position to build the compiler yourself, could you try the
> following patch? I think it should fix the problem (thanks Andrew for spotting
> the initialized variable).
>
>
> Index: libgfortran/runtime/select.c
> ===
> --- libgfortran/runtime/select.c(revision 127830)
> +++ libgfortran/runtime/select.c(working copy)
> @@ -53,7 +53,7 @@ select_string (select_struct *table, int
> {
>   select_struct *t;
>   int i, low, high, mid;
> -  int default_jump;
> +  int default_jump = -1;
>
>   if (table_len == 0)
> return -1;
>
>
> -- 
>
> fxcoudert at gcc dot gnu dot org changed:
>
>   What|Removed |Added
> 
>   Keywords||patch
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33386
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
>


-- 


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

[Bug fortran/37580] New: invalid code accepted without notice

[jpr at csc dot fi]

Hi,

following invalid code compiles w/o error with gfortran 4.4.0

program test
  real, pointer :: a(:), b(:)
  a(:) => b(:)
end program test

works as expected with earliear versions.

$ gfortran -v
Using built-in specs.
Target: i586-pc-linux-gnu
Configured with: /home/fx/gfortran_nightbuild/trunk/configure
--prefix=/home/fx/gfortran_nightbuild/irun-20080918
--enable-languages=c,fortran --build=i586-pc-linux-gnu
--enable-checking=release --with-gmp=/home/fx/gfortran_nightbuild/software
Thread model: posix
gcc version 4.4.0 20080918 (experimental) [trunk revision 140443] (GCC)

Regards, Juha


-- 
   Summary: invalid code accepted without notice
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jpr at csc dot fi


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

[Bug fortran/37580] invalid code accepted without notice

[jpr at csc dot fi]

--- Comment #1 from jpr at csc dot fi  2008-09-19 08:20 ---
Small update: this bug is already present in 4.3.1.
The 4.2.x series seems OK.

Juha


-- 


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

[Bug fortran/37580] invalid code accepted without notice

[jpr at csc dot fi]

--- Comment #2 from jpr at csc dot fi  2008-09-19 09:25 ---
This invalid peace of code gives an ICE:

program test
  integer, pointer :: a(:),b(:)
  a(1) => b(1)
end program test


gfortran -c test.f90
test.f90: In function 'test':
test.f90:3: internal compiler error: in gimplify_expr, at gimplify.c:7056
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


-- 

jpr at csc dot fi changed:

   What|Removed |Added

 CC|                    |jpr at csc dot fi


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

[Bug fortran/35064] New: gfortran internal write leaks windows handles & memory

[jpr at csc dot fi]

Hi,

We have a somewhat serious problem with gfortran on x86/mingw32 system:

program test
  implicit none
  character(len=10) :: string
  integer :: m,n

  do m = 1,1000
 do n = 1,1
write(string,*) 'nice'
 end do
 print *,'Check memory and handles and press ENTER...'
 call flush
 read(*,*)
  end do
end program test

Start the task manager and run the small program above to see memory and
windows handle usage (1 / internal write) to skyrocket.

The fortran versions i see this include the latest 4.3 & the mingw 4.2_sjlj
versions at least:

$ gfortran -v
Using built-in specs.
Target: i386-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=i386-pc-mingw32 --enable-libgomp --disable-shared
Thread model: win32
gcc version 4.3.0 20080127 (experimental) [trunk revision 131883] (GCC) 


Regards, Juha


-- 
   Summary: gfortran internal write leaks windows handles & memory
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jpr at csc dot fi
  GCC host triplet: i386-mingw32


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

[Bug fortran/35064] gfortran internal write leaks windows handles & memory

[jpr at csc dot fi]

--- Comment #1 from jpr at csc dot fi  2008-02-03 14:38 ---
Mikko already reported this in 35063.
Sorry about the dup!
Juha

*** This bug has been marked as a duplicate of 35063 ***


-- 

jpr at csc dot fi changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/35063] write statement leaks handles/memory on windows xp

[jpr at csc dot fi]

--- Comment #1 from jpr at csc dot fi  2008-02-03 14:38 ---
*** Bug 35064 has been marked as a duplicate of this bug. ***


-- 

jpr at csc dot fi changed:

   What|Removed |Added

 CC||jpr at csc dot fi


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

[Bug libfortran/35063] I/O leaks handles/memory on Windows XP

[jpr at csc dot fi]

--- Comment #9 from jpr at csc dot fi  2008-02-06 11:31 ---
Subject: Re:  I/O leaks handles/memory on Windows XP


just an observation: if i build gcc with "thread model=single", all seems 
well.

Juha

>
>
> --- Comment #8 from jvdelisle at gcc dot gnu dot org  2008-02-06 01:27 
> ---
> I will work this one.  I think the problem is not in freeing, but in not
> reusing a UNIT structure already open.
>
>
> -- 
>
> jvdelisle at gcc dot gnu dot org changed:
>
>   What|Removed |Added
> 
> AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
>   |dot org |org
> Status|NEW |ASSIGNED
>   Last reconfirmed|2008-02-03 17:36:06 |2008-02-06 01:27:05
>   date||
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063
>
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
>


-- 


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

[Bug libfortran/35063] I/O leaks handles/memory on Windows XP

[jpr at csc dot fi]

--- Comment #11 from jpr at csc dot fi  2008-02-06 20:54 ---
Subject: Re:  I/O leaks handles/memory on Windows XP


I had a look: the problem seems to be with the logic of  mutex->counter in
gcc/config/i386/gthr-win32.c. Libgfortran makes the  following calls 
during an internal write

1) __gthr_win32_mutex_init_function()
   - sets counter=-1
   - creates a semaphore (the windows handle!)

2)__gthr_win32_mutex_lock()
- increments counter (now 0)

3) __gthr_win32_mutex_unlock()
   - decrements counter (now -1 again)
   - would release the semaphore, if counter >= 0 but doesn't...!

not a libfortran bug after all(?)


>
>
> --- Comment #10 from Jerry_V_DeLisle at rl dot gov  2008-02-06 20:25 
> ---
> Reply to comment #9:
>
> This is a very important observation.  I have checked the code and we have 
> code
> that free's the internal unit (free_internal_unit) and I have confirmed that 
> it
> is called correctly after every write.
>
> My current thinking now is that we are not locking/unlocking the unit 
> correctly
> and maybe it is this lock that is leaving behind a windows handle.  Stay 
> tuned,
> and thanks for reporting this observation.
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063
>
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
>


-- 


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

[Bug libfortran/35063] I/O leaks handles/memory on Windows XP

[jpr at csc dot fi]

--- Comment #13 from jpr at csc dot fi  2008-02-07 05:07 ---
Subject: Re:  I/O leaks handles/memory on Windows XP


>
> --- Comment #12 from tkoenig at gcc dot gnu dot org  2008-02-06 
21:49 ---
> Just wondering... is this a regression?

At least g77 runs the two examples (in comments #1 & #7) without 
problems...

Reading  windows  docs: somewhere windows CloseHandle() should be called 
to close the Semaphore created by CreateSemaphore() called by 
__gthr_win32_mutex_init_function().

Otherwise the __gthr_win32.c code might be OK (ReleaseSemaphore() only 
modifies the semaphore usage count... i thought something else.)


-- 


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

[Bug libfortran/35063] [Regression wrt g77] I/O leaks handles/memory on Windows XP

[jpr at csc dot fi]

--- Comment #16 from jpr at csc dot fi  2008-02-07 09:19 ---
Subject: Re:  [Regression wrt g77] I/O leaks handles/memory
 on Windows XP


Well, the internal write case is anyway a regression introduced by this 
patch

http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00717.html


>
>
> --- Comment #15 from kargl at gcc dot gnu dot org  2008-02-07 06:26 
> ---
> (In reply to comment #14)
>> Yes this is a regression wrt g77 and I have noted this in the summary.  I 
>> have
>> attempted to insert a mutex_unlock in the right place and it has no effect.  
>> I
>> think jpr's assessment is correct, there needs to be a close_handle call
>> somewhere in the code path.  There is no close_handle call in gthr-win32.c
>>
>
> It's not a regression wrt to g77 because g77 isn't thread safe.
> In fact, if comment #11 is accurate, this isn't a libgfortran
> bug. It's a target bug.
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063
>
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
>


-- 


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

[Bug libfortran/35063] [Regression wrt g77] I/O leaks handles/memory on Windows XP

[jpr at csc dot fi]

--- Comment #22 from jpr at csc dot fi  2008-02-08 05:29 ---
Subject: Re:  [Regression wrt g77] I/O leaks handles/memory
 on Windows XP



> So if the above is really at fault then the
> leak should not manifest on Cygwin at all.

The logic there is ok i guess, as i already noted later in the thread.
As the handles also leak using posix threads under cygwin,  i guess the 
posix thread implementation does something similiar. The  problem is that 
when the mutex is done with pthread_mutex_destroy() should be called. 
gcc's gthread interface used in libfortran however does not however have 
this functionality as far as i can tell from the sources.

Anyway, Jerry idea of reusing the internal unit structure would 
effectively solve this problem, being also a good thing otherwise IMO.

Juha

> This gthr-win32 stuff should only be run if --enable-threads=win32.
> That is not the case with Cygwin which should be using pthreads
> (--enable-threads=posix).  So if the above is really at fault then the
> leak should not manifest on Cygwin at all.
>
> Brian
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063
>
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
>


-- 


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

[Bug libfortran/35063] [Regression wrt g77] I/O leaks handles/memory on Windows XP

[jpr at csc dot fi]

--- Comment #24 from jpr at csc dot fi  2008-02-08 12:12 ---
Subject: Re:  [Regression wrt g77] I/O leaks handles/memory
 on Windows XP


> This might be desirable for other reasons, but it will not fix the problem
> completely.

Yeah well, the easy way out here would be to include 
"__gthread_mutex_destroy" in the gthread-api. This should call 
CloseHandle() (or a new __gthr_win32_mutex_destroy() with a call to 
CloseHandle()) for the win32 threads and pthread_mutex_destroy() for the 
posix threads,  etc... and call the new  function in a few relevant places 
in libgfortran...


-- 


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

[Bug libfortran/35063] [Regression wrt g77] I/O leaks handles/memory on Windows XP

[jpr at csc dot fi]

--- Comment #32 from jpr at csc dot fi  2008-02-09 06:46 ---
Subject: Re:  [Regression wrt g77] I/O leaks handles/memory
 on Windows XP


hi,

the patch looks good to me, although from the clarity point of view and 
to avoid potential problem with other thread models, i'd go all the way 
and introduce the __gthread_mutex_destroy() function in the  gcc/gthr*.h 
files.

juha

>
>
> --- Comment #29 from jvdelisle at gcc dot gnu dot org  2008-02-08 18:10 
> ---
> Created an attachment (id=15118)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15118&action=view)
> --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15118&action=view)
> Proposed patch, needs testing on mingw
>
> Here is the patch.  I have tested this on Cygwin, but not mingw.  It is
> regression testing on x86-64.  A previous version passed regression testing,
> but I am retesting after clean-up.
>
> I would appreciate if others would review/test this patch.
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063
>
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
>


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[jpr at csc dot fi]

--- Comment #27 from jpr at csc dot fi  2008-02-14 08:12 ---

I think that the test program shown in comment #25 is invalid, as the main
program does not know about the call interface of the check_integer4_rank1()
function. If you add the module related lines in the comments, all is well (at
least on a i686-linux machine).


-- 


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

[Bug tree-optimization/41212] New: miscompilation at -O2

[jpr at csc dot fi]

The program below is miscompiled using
gfortran -O2 -o m m.f90; ./m
gives:
y=   0.60653065945526063   2*y=   2.

(the second of the printed numbers should equal twice the first). Using
gfortran -fno-inline -O2 -o m m.f90
works OK.

The compiler is:

Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /home/jerry/gcc/trunk/configure --prefix=/usr/local/gfortran
--enable-languages=c,fortran --disable-libmudflap --enable-libgomp
--disable-shared
Thread model: posix
gcc version 4.5.0 20090831 (experimental) [trunk revision 151238] (GCC)



program m

   double precision :: y,z

   call b(1.0d0,y,z)
   print*,'y= ', y, ' 2*y=', z

contains

 subroutine b( x, y, z)
   implicit none

   double precision :: x,y,z

   integer :: i, k
   double precision :: h, r

   y = 1.0d0
   z = 0.0d0

   h = 0
   DO k = 1,10
  h = h + 1.0d0/k

  r = 1
  DO i = 1,k
 r = (x/(2*i) ) * r
  END DO

  y = y + (-1)**k * r
  z = z + (-1)**(k+1) * h * r

  IF ( ABS(2*k/x*r) < 1d-6 ) EXIT
   END DO

   z = 2*y
 end subroutine b
end program m


-- 
   Summary: miscompilation  at  -O2
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jpr at csc dot fi


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

[Bug tree-optimization/41213] New: miscompilation at -O2

[jpr at csc dot fi]

The program below is miscompiled using
gfortran -O2 -o m m.f90; ./m
gives:
y=   0.60653065945526063   2*y=   2.

(the second of the printed numbers should equal twice the first). Using
gfortran -fno-inline -O2 -o m m.f90
works OK.

The compiler is:

Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /home/jerry/gcc/trunk/configure --prefix=/usr/local/gfortran
--enable-languages=c,fortran --disable-libmudflap --enable-libgomp
--disable-shared
Thread model: posix
gcc version 4.5.0 20090831 (experimental) [trunk revision 151238] (GCC)



program m

   double precision :: y,z

   call b(1.0d0,y,z)
   print*,'y= ', y, ' 2*y=', z

contains

 subroutine b( x, y, z)
   implicit none

   double precision :: x,y,z

   integer :: i, k
   double precision :: h, r

   y = 1.0d0
   z = 0.0d0

   h = 0
   DO k = 1,10
  h = h + 1.0d0/k

  r = 1
  DO i = 1,k
 r = (x/(2*i) ) * r
  END DO

  y = y + (-1)**k * r
  z = z + (-1)**(k+1) * h * r

  IF ( ABS(2*k/x*r) < 1d-6 ) EXIT
   END DO

   z = 2*y
 end subroutine b
end program m


-- 
   Summary: miscompilation  at  -O2
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jpr at csc dot fi


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

[Bug tree-optimization/41212] miscompilation at -O2

[jpr at csc dot fi]

--- Comment #1 from jpr at csc dot fi  2009-09-01 12:15 ---
*** Bug 41213 has been marked as a duplicate of this bug. ***


-- 


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

[Bug tree-optimization/41213] miscompilation at -O2

[jpr at csc dot fi]

--- Comment #1 from jpr at csc dot fi  2009-09-01 12:15 ---
Sorry about the duplicate...

*** This bug has been marked as a duplicate of 41212 ***


-- 

jpr at csc dot fi changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/41212] [4.5 Regression] miscompilation at -O2

[jpr at csc dot fi]

--- Comment #4 from jpr at csc dot fi  2009-09-03 07:10 ---
FWIW: I had a look at the -fdump-tree-all files.
All seems well (to my untrained eyes), until


:
  D.1412_51 = y;
  D.1430_52 = D.1412_51 * 2.0e+0;
  z = D.1430_52;
in m.f90.060t.phiprop

is transformed to
:
  D.1412_51 = 1.0e+0;
  D.1430_52 = 2.0e+0;
  z = D.1430_52;
in m.f90.061t.fre

Regards,Juha


-- 

jpr at csc dot fi changed:

   What|Removed |Added

 CC||jpr at csc dot fi


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

[Bug tree-optimization/41212] [4.5 Regression] miscompilation at -O2

[jpr at csc dot fi]

--- Comment #5 from jpr at csc dot fi  2009-09-03 10:40 ---
Adding -fstrict-aliasing to -O1 breaks the code:

gfortran -o m m.f90 -O1; ./m
 y=   0.60653065945526063   2*y=   1.2130613189105213

gfortran -o m m.f90 -O1 -fstrict-aliasing ; ./m
 y=   0.60653065945526063   2*y=   2.

and equally adding -fno-strict-aliasing to -O2 saves the day

gfortran -o m m.f90 -O2; ./m
 y=   0.60653065945526063   2*y=   2.

gfortran -o m m.f90 -O2 -fno-strict-aliasing;./m
 y=   0.60653065945526063   2*y=   1.2130613189105213

Juha


-- 


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

[Bug fortran/47583] [4.6 Regression] Inquire affected by previous read

[jpr at csc dot fi]

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

jpr at csc dot fi changed:

   What|Removed |Added

 CC||jpr at csc dot fi

--- Comment #5 from jpr at csc dot fi 2011-02-02 07:12:16 UTC ---

Possible (untested) fix. The ext.dt field in io/match_inquire()'s code
variable is a leftover from previous io matching (set in match_io_element()).
This triggers the bug in resolve_transfer(). There is even a comment there, 
that indicates that this field should be null for INQUIRE (iolength), thus:


Index: io.c
===
--- io.c(revision 169506)
+++ io.c(working copy)
@@ -3933,6 +3933,7 @@

   new_st.block = gfc_get_code ();
   new_st.block->op = EXEC_IOLENGTH;
+  code->ext.dt = NULL;
   terminate_io (code);
   new_st.block->next = code;
   return MATCH_YES;

[Bug fortran/47583] [4.6 Regression] Inquire affected by previous read

[jpr at csc dot fi]

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

--- Comment #7 from jpr at csc dot fi 2011-02-02 12:48:37 UTC ---
(In reply to comment #6)
> (In reply to comment #5)
> Thanks a lot, at least for me this patch seems to solve the problem.

Well, that patch did break the direct_io_1.f90 test case however,
as the ext.dt member setting overwrote the ext.iterator member (when
there was implied do loop in the inquire(iolength=) statement). 

This might be better:

Index: io.c
===
--- io.c(revision 169506)
+++ io.c(working copy)
@@ -3091,7 +3091,8 @@
   cp = gfc_get_code ();
   cp->op = EXEC_TRANSFER;
   cp->expr1 = expr;
-  cp->ext.dt = current_dt;
+  if (k != M_INQUIRE)
+cp->ext.dt = current_dt;

   *cpp = cp;
   return MATCH_YES;

[Bug fortran/50173] New: ICE when allocating derived type with allocatable component(s) and specifying lower bound

[jpr at csc dot fi]

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

 Bug #: 50173
   Summary: ICE when allocating derived type with allocatable
component(s) and specifying lower bound
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@csc.fi


With the following piece of code, current trunk gfortran ICEs for me on a
i386-linux. The trobule must be only a few days old:

SUBROUTINE c(n)
  INTEGER :: i,n

   TYPE t
 INTEGER, ALLOCATABLE :: g(:)
   END TYPE t
   TYPE(t), ALLOCATABLE :: buf(:)

   ALLOCATE( buf(1:n) )
END SUBROUTINE c

works if:

a) using POINTER instead of ALLOCATABLE for g(:)
b) making upper bound constant: ALLOCATE(buf(1:4))
c) omitting the lower bound in allocation: ALLOCATE(buf(n))

As written produces this:

% gfortran -v -c t.f90
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/wrk/jpr/gcc-4.7/bin/../libexec/gcc/i686-pc-linux-gnu/4.7.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++,fortran
--disable-bootstrap --prefix=/wrk/jpr/gcc-4.7 --with-gmp=/wrk/jpr/extralib
--with-mpfr=/wrk/jpr/extralib
Thread model: posix
gcc version 4.7.0 20110823 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' '-march=pentiumpro'
 /home/wrk/jpr/gcc-4.5/bin/../libexec/gcc/i686-pc-linux-gnu/4.7.0/f951 t.f90
-quiet -dumpbase t.f90 -mtune=generic -march=pentiumpro -auxbase t -version
-fintrinsic-modules-path
/home/wrk/jpr/gcc-4.7/bin/../lib/gcc/i686-pc-linux-gnu/4.7.0/finclude -o
/tmp/cccpGv05.s
GNU Fortran (GCC) version 4.7.0 20110823 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 3.4.6 20060404 (Red Hat 3.4.6-11), GMP
version 4.3.1, MPFR version 2.4.1, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran (GCC) version 4.7.0 20110823 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 3.4.6 20060404 (Red Hat 3.4.6-11), GMP
version 4.3.1, MPFR version 2.4.1, MPC version 0.8
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  for instructions.


Regards, Juha

[Bug fortran/50050] [4.6/4.7 Regression] Internal compiler error free_expr0 at expr.c:3709 via gfc_done_2

[jpr at csc dot fi]

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

jpr at csc dot fi changed:

   What|Removed |Added

 CC||jpr at csc dot fi

--- Comment #9 from jpr at csc dot fi 2011-08-24 06:12:58 UTC ---
*** Bug 50173 has been marked as a duplicate of this bug. ***

[Bug fortran/50173] ICE when allocating derived type with allocatable component(s) and specifying lower bound

[jpr at csc dot fi]

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

jpr at csc dot fi changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from jpr at csc dot fi 2011-08-24 06:12:58 UTC ---
Hi,

this seems a duplicate of the PR50050, and the suggested fix in
http://gcc.gnu.org/ml/fortran/2011-08/msg00199.html
works for me.
Juha

*** This bug has been marked as a duplicate of bug 50050 ***

[Bug fortran/51055] New: deferred length character allocation: allocate(character(len=i)::s) rejected

[jpr at csc dot fi]

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

 Bug #: 51055
   Summary: deferred length character allocation:
allocate(character(len=i)::s) rejected
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@csc.fi


Hi,

I think the program below is valid, but rejected by gfortran 


program a
  character(len=:), allocatable :: s
  integer :: i=10
  allocate(character(len=i)::s)
end program a


gfortran -v -o s s.f90
Driving: gfortran -v -o s s.f90 -l gfortran -l m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/wrk/jpr/gcc-4.7/bin/../libexec/gcc/i686-pc-linux-gnu/4.7.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++,fortran
--disable-bootstrap --prefix=/wrk/jpr/gcc-4.7 --with-gmp=/wrk/jpr/extralib
--with-mpfr=/wrk/jpr/extralib
Thread model: posix
gcc version 4.7.0 20110927 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-o' 's' '-shared-libgcc' '-mtune=generic'
'-march=pentiumpro'
 /home/wrk/jpr/gcc-4.7/bin/../libexec/gcc/i686-pc-linux-gnu/4.7.0/f951 s.f90
-quiet -dumpbase s.f90 -mtune=generic -march=pentiumpro -auxbase s -version
-fintrinsic-modules-path
/home/wrk/jpr/gcc-4.7/bin/../lib/gcc/i686-pc-linux-gnu/4.7.0/finclude -o
/tmp/cc1PUv7g.s
GNU Fortran (GCC) version 4.7.0 20110927 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 3.4.6 20060404 (Red Hat 3.4.6-11), GMP
version 4.3.1, MPFR version 2.4.1, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran (GCC) version 4.7.0 20110927 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 3.4.6 20060404 (Red Hat 3.4.6-11), GMP
version 4.3.1, MPFR version 2.4.1, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
s.f90:4.25:

  allocate(character(len=i)::s)
 1
Error: Variable 'i' cannot appear in the expression at (1)

[Bug fortran/51055] deferred length character allocation: allocate(character(len=i)::s) rejected

[jpr at csc dot fi]

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

--- Comment #2 from jpr at csc dot fi 2011-11-10 06:09:07 UTC ---
OK, i found and lost the PR that included this. However, 
your workaround doesn't seem to work either:

program a
 character(len=:),allocatable::s
 integer::j=2
 s=repeat(' ',j)
 print*,len(s),len(repeat(' ',j))
end program a

gfortran -o a a.f90; ./a
 2846708   2

[Bug libfortran/42420] New: libgfortran fails to open large files on MINGW32

[jpr at csc dot fi]

Program bigfile
  open( 1,file='bigfile',position='append')
End program bigfile

fails if size of the bigfile is > 2GB. This is due to
the struct stat holding 32 bit st_size field in this
platform. The following fix worked for me
(libgfortran/io/...)

Index: unix.c
===
--- unix.c  (revision 155325)
+++ unix.c  (working copy)
@@ -781,7 +781,11 @@
 static stream *
 fd_to_stream (int fd, int prot)
 {
+#ifdef __MINGW32__
+  struct _stati64 statbuf;
+#else
   struct stat statbuf;
+#endif
   unix_stream *s;

   s = get_mem (sizeof (unix_stream));
@@ -795,7 +799,11 @@

   /* Get the current length of the file. */

+#ifdef __MINGW32__
   fstat (fd, &statbuf);
+#else
+  _fstati64 (fd, &statbuf);
+#endif

   if (lseek (fd, 0, SEEK_CUR) == (gfc_offset) -1)
 s->file_length = -1;

Juha


-- 
   Summary: libgfortran fails to open large files on MINGW32
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: jpr at csc dot fi


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

[Bug libfortran/42420] libgfortran fails to open large files on MINGW32

[jpr at csc dot fi]

--- Comment #1 from jpr at csc dot fi  2009-12-18 00:35 ---
or rather this


Index: unix.c
===
--- unix.c  (revision 155325)
+++ unix.c  (working copy)
@@ -781,7 +781,11 @@
 static stream *
 fd_to_stream (int fd, int prot)
 {
+#ifdef __MINGW32__
+  struct _stati64 statbuf;
+#else
   struct stat statbuf;
+#endif
   unix_stream *s;

   s = get_mem (sizeof (unix_stream));
@@ -795,7 +799,11 @@

   /* Get the current length of the file. */

+#ifdef __MINGW32__
+  _fstati64 (fd, &statbuf);
+#else
   fstat (fd, &statbuf);
+#endif

   if (lseek (fd, 0, SEEK_CUR) == (gfc_offset) -1)
 s->file_length = -1;


-- 


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

[Bug libfortran/42420] libgfortran fails to open large files on MINGW32

[jpr at csc dot fi]

--- Comment #3 from jpr at csc dot fi  2009-12-18 05:43 ---
No, 

this was the trunk from yesterday. Some wrinkeles seem to remain...

Juha


-- 

jpr at csc dot fi changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED


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

[Bug fortran/48746] Matmul with allocate on assignment

[jpr at csc dot fi]

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

jpr at csc dot fi changed:

   What|Removed |Added

 CC||jpr at csc dot fi

--- Comment #1 from jpr at csc dot fi 2011-04-27 05:56:57 UTC ---
Problem here is that the return array "dtype" field is uninitialized when
lhs is (unallocated) allocatable. Due to this there are also similiar
problems in other intrinsics such as reshape(), etc...

[Bug middle-end/45694] New: fortran host associated variables+optimization==failure?

[jpr at csc dot fi]

Hi,
(i first reported this to mingw32-w64's bug tracker:
http://sourceforge.net/tracker/?func=detail&aid=3067541&group_id=202880&atid=983354
and was forwarded here)

The attached fortran program aborts() (a host associated variable
changes value from host to hostee without asking) using
gfortran -O1 -o fail fail.f90; ./fail
on a 64bit windows 7 (mingw32-w64) platform.

Very probably platform dependent as i can't reproduce this elsewhere.
Also 32bit compile on the same platform works as does unoptimized
compilation.

On a larger application i see sevaral failures of the same kind, seems
to depend also on the number and/or size of the local variables in the
procedures..

Regards, Juha

PS. I entered middle-end as the bugs 'component' as  an optimization flag seems
to be needed to trigger this...


-- 
   Summary: fortran host associated variables+optimization==failure?
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jpr at csc dot fi
GCC target triplet: x86_64-w64-mingw32


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

[Bug middle-end/45694] fortran host associated variables+optimization==failure?

[jpr at csc dot fi]

--- Comment #1 from jpr at csc dot fi  2010-09-16 19:31 ---
Created an attachment (id=21812)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21812&action=view)
failing fortran code


-- 


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

[Bug target/45694] fortran host associated variables+optimization==failure?

[jpr at csc dot fi]

--- Comment #2 from jpr at csc dot fi  2010-09-20 06:54 ---
Created an attachment (id=21842)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21842&action=view)
somewhat reduced testcase

Hi,

I tried debugging this more. Attached is a somewhat reduced testcase. I also 
had a look at the assembler generated by 
"x86_64-w64-mingw32-gfortran -save-temps -O1 fail1.f90".

The loadinp looks like  

...
loadinp_:
subq$56, %rsp
movl$1952671091, 32(%rsp)
movw$28521, 36(%rsp)
movb$110, 38(%rsp)
leaq32(%rsp), %r10
callparse_sect.1525
... so it stores the  'section' string to stack and loads %r10 with
the stack address and calls the parse_sect:

parse_sect.1525:
pushq   %rdi
pushq   %rsi
pushq   %rbx
movl$4032, %eax
call___chkstk
movq%r10, %rsi
   
which then uses the stack address in %r10. The thing is that the 
__chkstk() call  seems to change the contents of the
%r10. At least doing
...
movq %r10,%r12
call __chkstk
movq %r12,%r10
...
seems to cure the example. What is really going on, anyone?

Br, Juha


-- 


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

[Bug target/45694] [MinGW64] fortran host associated variables+optimization==failure?

[jpr at csc dot fi]

--- Comment #3 from jpr at csc dot fi  2010-09-20 11:05 ---
Even simpler testcase, now in C.


#include 
#include 

void a()
{
  char s[2];

  void b() {
char p[4096];

if ( strcmp(s,"s")!=0 ) abort();
strcpy( p,"p");
  }

  strcpy( s,"s" );
  b();
}

main()
{
  a();
}


-- 


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

[Bug target/45694] [MinGW64] fortran host associated variables+optimization==failure?

[jpr at csc dot fi]

--- Comment #4 from jpr at csc dot fi  2010-09-20 11:12 ---
For the testcase in comment #3 the ___chkstk call is also 
generated with -O0 (and trying to use %r10 across the call...)

Juha


-- 


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

[Bug target/45694] [MinGW64] fortran host associated variables+optimization==failure?

[jpr at csc dot fi]

--- Comment #5 from jpr at csc dot fi  2010-09-20 11:36 ---
And still reduced testcase, fails at -O0.

void main()
{
  char s;
  void b() {
char p[4096];
if ( s!='s' ) abort();
  }
  s='s';
  b();
}


-- 


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

[Bug target/45694] [MinGW64] fortran host associated variables+optimization==failure?

[jpr at csc dot fi]

--- Comment #7 from jpr at csc dot fi  2010-09-20 11:46 ---
Hi,
yes the stack size is relevant here, because otherwise gcc does not
call ___chkstk(), which seems to be the trouble here. 4K stack usage
is not very big IMHO.
-Juha

(In reply to comment #6)
> (In reply to comment #3)
> > Even simpler testcase, now in C.
> > 
> > 
> > #include 
> > #include 
> > 
> > void a()
> > {
> >   char s[2];
> > 
> >   void b() {
> > char p[4096];
> You deliberately use a very large storage for a very little data.
> And it fails on m64 and not m32 which is rather weird and odd.
> So I went to the bottom of this number which appears to be 3920.
> 3920 = ok
> Any number beyond 3920 fails on m64 wtf?
> I have no idea what is going on.
> It just seems to me interesting to test out your case...
> Yes O0 fails also... who knows...
> > 
> > if ( strcmp(s,"s")!=0 ) abort();
> > strcpy( p,"p");
> >   }
> > 
> >   strcpy( s,"s" );
> >   b();
> > }
> > 
> > main()
> > {
> >   a();
> > }
> > 
> 


-- 


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

[Bug fortran/45744] New: internal compiler error: in gfc_conv_expr_op, at fortran/trans-expr.c:1366

[jpr at csc dot fi]

Hi,

the following fortran code hits an assert() in fortran/trans-expr.c:1366

MODULE m
CONTAINS
  FUNCTION rnd(n)
INTEGER, INTENT(in) :: n
REAL(8), DIMENSION(n) :: rnd
CALL RANDOM_NUMBER(rnd)
  END FUNCTION rnd

  SUBROUTINE GeneticOptimize(parsize )
INTEGER :: parsize

REAL(8) :: popcross=0
LOGICAL, ALLOCATABLE :: mask(:)

allocate(mask(parsize))
mask = (rnd(parsize) < popcross)
  END SUBROUTINE GeneticOptimize
END MODULE m



gfortran -O1 -v a.f90
Driving: gfortran -O1 -v a.f90 -l gfortran -l m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/wrk/jpr/gcc-4.5/bin/../libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++,fortran
--disable-bootstrap --prefix=/wrk/jpr/gcc-4.5 --with-gmp=/wrk/jpr/extralib
--with-mpfr=/wrk/jpr/extralib
Thread model: posix
gcc version 4.6.0 20100921 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-O1' '-v' '-shared-libgcc' '-mtune=generic'
'-march=pentiumpro'
 /home/wrk/jpr/gcc-4.5/bin/../libexec/gcc/i686-pc-linux-gnu/4.6.0/f951 a.f90
-quiet -dumpbase a.f90 -mtune=generic -march=pentiumpro -auxbase a -O1 -version
-fintrinsic-modules-path
/home/wrk/jpr/gcc-4.5/bin/../lib/gcc/i686-pc-linux-gnu/4.6.0/finclude -o
/tmp/ccrHZk23.s
GNU Fortran (GCC) version 4.6.0 20100921 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 3.4.6 20060404 (Red Hat 3.4.6-11), GMP
version 4.3.1, MPFR version 2.4.1, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran (GCC) version 4.6.0 20100921 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 3.4.6 20060404 (Red Hat 3.4.6-11), GMP
version 4.3.1, MPFR version 2.4.1, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
a.f90: In function 'geneticoptimize':
a.f90:internal compiler error: in gfc_conv_expr_op, at
fortran/trans-expr.c:1366
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

Regards, Juha


-- 
   Summary: internal compiler error: in gfc_conv_expr_op, at
fortran/trans-expr.c:1366
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
    AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jpr at csc dot fi


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

[Bug fortran/45744] internal compiler error: in gfc_conv_expr_op, at fortran/trans-expr.c:1366

[jpr at csc dot fi]

--- Comment #1 from jpr at csc dot fi  2010-09-22 04:48 ---
P.S. don't mind my directory naming. This is trunk gfortran
from ~6 hours ago.


-- 


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

[Bug fortran/45744] internal compiler error: in gfc_conv_expr_op, at fortran/trans-expr.c:1366

[jpr at csc dot fi]

--- Comment #2 from jpr at csc dot fi  2010-09-22 04:52 ---
somewhat simpler testcase:

MODULE m
CONTAINS
  FUNCTION rnd(n)
INTEGER, INTENT(in) :: n
REAL(8), DIMENSION(n) :: rnd
CALL RANDOM_NUMBER(rnd)
  END FUNCTION rnd

  SUBROUTINE GeneticOptimize(n)
INTEGER :: n
LOGICAL :: mask(n)
REAL(8) :: popcross=0
mask = (rnd(n) < popcross)
  END SUBROUTINE GeneticOptimize
END MODULE m


-- 


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

[Bug fortran/45828] New: No default initialization of derived type members?

[jpr at csc dot fi]

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

   Summary: No default initialization of derived type members?
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@csc.fi


Hi,

program fail
  type a
 integer :: i
  end type a

  type b
type(a), pointer :: a => null()
  end type b

  type(b), pointer :: c(:)
  print*,0.0
  allocate(c(201))

  do i=1,201
if ( associated(c(i) % a)) call abort()
  end do
end program fail


the attached program misbehaves using gfortran 4.6 (i think). The
supposed output is:
   0.000
using gfortran 4.6 i get
   0.000
   5 T
   6 T
  10 T
Note that the output depends on trashing the stack (which is why
the first print is there), and may depend on your setup.

The trouble seems to be that no derived type default initialization
code is generated after the ALLOCATE() by 4.6 as opposed to f.ex. 
4.1.2, 4.3.2 & 4.4.3. At least this is my reading of the
"fail.f90.003t.original" file. Also, this file is identical even if
you remove the default initialization from the structure member.

The program below also fails:

program fail1
   type a
  integer :: i
   end type a

   type b
 type(a) :: acomp = a(5)
   end type b

   type(b), allocatable :: c(:)

   allocate(c(1))
   if (c(1) % acomp % i /= 5) call abort()
end program fail1


Sorry, if i'm missing something...

Regards, Juha

gfortran -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/wrk/jpr/gcc-4.6/bin/../libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++,fortran
--disable-bootstrap --prefix=/wrk/jpr/gcc-4.6 --with-gmp=/wrk/jpr/extralib
--with-mpfr=/wrk/jpr/extralib
Thread model: posix
gcc version 4.6.0 20100928 (experimental) (GCC)

[Bug fortran/45828] [4.6 Regression] No default initialization of derived type members?

[jpr at csc dot fi]

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

--- Comment #1 from jpr at csc dot fi 2010-09-29 11:20:40 UTC ---
>the attached program misbehaves using gfortran 4.6 (i think). The
>supposed output is:
>   0.000
>using gfortran 4.6 i get
>   0.000
>   5 T
>   6 T
>  10 T

as the example was finally posted, the expected result is
of course not to abort()...

[Bug fortran/45828] [4.6 Regression] No default initialization of derived type members?

[jpr at csc dot fi]

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

--- Comment #3 from jpr at csc dot fi 2010-09-30 04:50:05 UTC ---
Hi,

the problem seems to be in expr.c (called from resolve.c:
resolve_allocate_expr())

bool gfc_has_default_initializer (gfc_symbol *der)
{
  gfc_component *c;

  gcc_assert (der->attr.flavor == FL_DERIVED);
  for (c = der->components; c; c = c->next)
if (c->ts.type == BT_DERIVED)
  {
if (!c->attr.pointer
 && gfc_has_default_initializer (c->ts.u.derived))
  return true;
  }
else
  {
if (c->initializer)
  return true;
  }

  return false;
}

if a derived type has a derived type component it only checks whether
that components components have default initializers, not the component
itself. Additionally the pointer case is masked away. Adding 
|| c->initializer to the conditions solves this trouble but propably 
breaks something else, as the resolving allocate() is not the only place
this gets called.

Juha

[Bug fortran/45828] [4.6 Regression] No default initialization of derived type members?

[jpr at csc dot fi]

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

--- Comment #4 from jpr at csc dot fi 2010-09-30 05:12:10 UTC ---
This is the patch introducing the call to gfc_has_default_initializer()
from resolve_allocate_expr():

http://gcc.gnu.org/viewcvs?view=revision&revision=164305
2010-09-15  Janus Weil  

PR fortran/45577
* resolve.c (resolve_allocate_expr): Do default initialization via
EXEC_INIT_ASSIGN.

and indeed in rev. 164304 the default initialization loop reappears.

Juha

[Bug tree-optimization/29798] New: -O2 gives wrong results

[jpr at csc dot fi]

Hi,

-O2 gives wrong results. Assingment to a variable (rho) directly affects
value of another (oldrho). Look at the code at the end of the message (it's
modified from the *.102t.final_cleanup of a fortran code, in case you wonder).

gcc-version:

Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /home/fxcoudert/gfortran_nightbuild/trunk/configure
--prefix=/home/fxcoudert/gfortran_nightbuild/irun-20061109
--enable-languages=c,fortran
--with-gmp=/home/fxcoudert/gfortran_nightbuild/software
Thread model: posix
gcc version 4.3.0 20061109 (experimental)

Regards, Juha



void main()
{
  double temp167;
  double temp157;
  double rho;
  double D1530;
  double D1537;
  double D1568;
  double D1576;
  double D1578;
  double D1591;
  double alpha;
  double residual;
  int iter_count;
  double beta;
  double oldrho;
  double val19;
  double val24;
  double D1453;
  double xvec[2];
  double rhsvec[2];
  double work[8];

  xvec[0]= 0.0;
  rhsvec[0]  = 1.0e+0;
  xvec[1]= 0.0;
  rhsvec[1]  = 2.0e+0;
  work[6]= xvec[0];
  work[7]= xvec[1] * 5.0e-1;
  work[6]= rhsvec[0] - work[6];
  work[7]= rhsvec[1] - work[7];
  iter_count = 1;

while(1) {
  work[4] = work[6];
  work[5] = work[7];
  work[0] = work[4];
  D1530 = work[5];
  work[1] = D1530;
  D1537 = work[0];

  fprintf( stderr, "1: %d %g\n", iter_count, oldrho );
  rho = work[6] * D1537 + D1530 * work[7];
  fprintf( stderr, "2: %d %g\n\n", iter_count, oldrho );

  if (iter_count == 1) {
work[2] = D1537;
work[3] = work[1];
  } else {
beta = rho / oldrho;
work[2] = D1537 + beta * work[2];
work[3] = work[1] + beta * work[3];
  }

  work[4] = work[2];
  D1568 = work[3] * 5.0e-1;
  work[5] = D1568;
  D1576 = work[2];
  D1578 = work[4];
  val19 = D1576 * D1578 + 0.0;
  temp167 = work[3];
  alpha = rho / (val19 + D1568 * temp167);
  xvec[0] = xvec[0] + D1576 * alpha;
  D1591 = xvec[1] + temp167 * alpha;
  xvec[1] = D1591;
  work[6] = work[6] - alpha * D1578;
  work[7] = work[7] - alpha * work[5];
  work[0] = xvec[0];
  work[1] = D1591 * 5.0e-1;
  work[0] = work[0] - rhsvec[0];
  temp157 = work[1] - rhsvec[1];
  work[1] = temp157;
  D1453 = work[0];
  val24 = D1453 * D1453;

  residual = sqrt (val24 + temp157 * temp157);
  if (residual < 1e-12) break;

  iter_count = iter_count + 1;
  if (iter_count == 20) break;

  oldrho = rho;
}

  fprintf( stderr, "%d %g %g\n", iter_count, xvec[0], xvec[1] );
  return;
}


-- 
   Summary: -O2 gives wrong results
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jpr at csc dot fi
  GCC host triplet: x86 linux


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

[Bug rtl-optimization/29798] [4.3 Regression] -O2 gives wrong results

[jpr at csc dot fi]

--- Comment #4 from jpr at csc dot fi  2006-11-11 19:16 ---
Subject: Re:  [4.3 Regression] -O2 gives wrong
 results


Note however that the prints inside the main loop are not needed
to trigger the problem in the oroginal test code. You may freely
remove them and the problem remains. I just added the prints to 
further demonstrate the problem...

Juha
>
>
> --- Comment #2 from pinskia at gcc dot gnu dot org  2006-11-11 14:11 
> ---
> If we don't use it when the variable is uninitialized, we get the desired
> result (note how I did not say the correct result as I think this code is
> undefined and what we are getting is allowed by the C standard).
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29798
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
>


-- 


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

[Bug rtl-optimization/29798] [4.3 Regression] -O2 gives wrong results

[jpr at csc dot fi]

--- Comment #7 from jpr at csc dot fi  2006-11-12 13:24 ---
Subject: Re:  [4.3 Regression] -O2 gives wrong
 results


In reply to comment #6)
> mine, but please can you give me the correct output?  i don't see the
> regressions (comparing to a 4.1.2 compiler).

In the original testcase xvec should contain xvec[0]=1, xvec[1]=4 after 
the loop and it should only take 2 iterations to get there.

Juha


-- 


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

[Bug rtl-optimization/29798] [4.3 Regression] -O2 gives wrong results

[jpr at csc dot fi]

--- Comment #9 from jpr at csc dot fi  2006-11-13 08:45 ---
Subject: Re:  [4.3 Regression] -O2 gives wrong
 results


Hi,

i get the same with -O0 & -O1, but -O2 gives the output

1: 1 nan
2: 1 5

1: 2 5
2: 2 0.56

1: 3 0.56
2: 3 0.546798

1: 4 0.546798
2: 4 0.450496

1: 5 0.450496
2: 5 0.349347

1: 6 0.349347
2: 6 0.27989

1: 7 0.27989
2: 7 0.235831

1: 8 0.235831
2: 8 0.20784

1: 9 0.20784
2: 9 0.190072

1: 10 0.190072
2: 10 0.179228

1: 11 0.179228
2: 11 0.173471

1: 12 0.173471
2: 12 0.171803

1: 13 0.171803
2: 13 0.173738

1: 14 0.173738
2: 14 0.179119

1: 15 0.179119
2: 15 0.187993

1: 16 0.187993
2: 16 0.200468

1: 17 0.200468
2: 17 0.216452

1: 18 0.216452
2: 18 0.235121

1: 19 0.235121
2: 19 0.25404

20 0.50373 4.29738


Juha

>
>
> --- Comment #8 from bonzini at gnu dot org  2006-11-13 08:14 ---
> Please enlighten me. :-(
>
> research:~/gcc-test-pr29798/peak-gcc-src/gcc bonzinip$ svn info
> Path: .
> URL: svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk/gcc
> Repository Root: svn+ssh://[EMAIL PROTECTED]/svn/gcc
> Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
> Revision: 118720
> Node Kind: directory
> Schedule: normal
> Last Changed Author: sayle
> Last Changed Rev: 118718
> Last Changed Date: 2006-11-12 03:57:10 +0100 (Sun, 12 Nov 2006)
> Properties Last Updated: 2006-08-04 18:44:20 +0200 (Fri, 04 Aug 2006)
>
> research:~/gcc-test-pr29798/peak-gcc-build/gcc bonzinip$ gcc test.c -o foook
> -lm && ./foook
> 1: 1 4.87384e-270
> 2: 1 4.87384e-270
>
> 1: 2 5
> 2: 2 5
>
> 2 1 4
>
> research:~/gcc-test-pr29798/peak-gcc-build/gcc bonzinip$ ./xgcc -B. test.c -o
> foo -lm && ./foo
> 1: 1 4.87387e-270
> 2: 1 4.87387e-270
>
> 1: 2 5
> 2: 2 5
>
> 2 1 4
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29798
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
>


-- 


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