[Bug fortran/37794] New: Fortran module overloading regression

2008-10-10 Thread J dot Hogg at rl dot ac dot uk 
If we overload symbols from modules with specific names I can cause an ICE.
Works fine with earlier versions of gfortran and an old build of gcc-4.4.0.

This error occurs with a build of svn version  number 141030

gfortran-4.4  -c -o hsl_of01d.o hsl_of01d.f90
gfortran-4.4  -c -o hsl_of01i.o hsl_of01i.f90
gfortran-4.4  -c -o test.o test.f90
f951: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
make: *** [test.o] Error 1

Files:

! hsl_of01d.f90
module hsl_of01_double
  implicit none

  type of01_data_private
real :: foo
  end type of01_data_private

  type of01_data
type (of01_data_private) :: private
  end type of01_data
end module hsl_of01_double

! hsl_of01i.f90
module hsl_of01_integer
  implicit none

  type of01_data_private
integer :: youngest
  end type of01_data_private
end module hsl_of01_integer

! test.f90
module test_mod
  use hsl_of01_double, of01_rdata = of01_data
  use hsl_of01_integer, of01_idata = of01_data

  implicit none
end module test_mod


-- 
   Summary: Fortran module overloading regression
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: J dot Hogg at rl dot ac dot uk
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug fortran/37794] [4.3/4.4 Regression] Fortran module overloading regression

2008-10-10 Thread J dot Hogg at rl dot ac dot uk 


--- Comment #2 from J dot Hogg at rl dot ac dot uk  2008-10-10 11:38 ---
I agree code is invalid Fortran and should be rejected [though it can be made
valid quite easily by supplying the missing type].

Works fine on both 4.3 and 4.3.1 on this machine.


-- 


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

[Bug fortran/36821] New: Flush denormals to Zero Flag

2008-07-14 Thread J dot Hogg at rl dot ac dot uk 
On current x86 and x86_64 processors denormal numbers are handled as a special
case and very slowly. This can have a detrimental impact on the performance of
numerical programs. A common fix for this problem, at the cost of some
numerical stability, is to set the processor flag to flush denormals to zero.

This can be achieved in C with the following on SSE machines:
   _MM_SET_FLUSH_ZERO_MODE (_MM_FLUSH_ZERO_ON);

However it is not desirable to include C in a fortran program or library. Other
compiler tackle this by adding flags (ifort, NAG f95) or environment variables
(g95) which set this flush mode during program initialization. It would be good
if gfortran offered a similar facility (I have not been able to locate any
reference to one at the moment).


-- 
   Summary: Flush denormals to Zero Flag
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: J dot Hogg at rl dot ac dot uk


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

[Bug fortran/36821] Flush denormals to Zero Flag

2008-07-14 Thread J dot Hogg at rl dot ac dot uk 


--- Comment #2 from J dot Hogg at rl dot ac dot uk  2008-07-14 11:34 ---
-ffast-math also enables other (even more unsafe?) optimizations which may not
be desirable.


-- 


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

[Bug fortran/36153] New: ICE on size with kind parameter

2008-05-06 Thread J dot Hogg at rl dot ac dot uk 
Use of an optional kind parameter on a call to the intrinsic size was added in
Fortran 2003, and is essential to avoid overflow when dealing with arrays
bigger than huge(0). The following example provides test code and demonstrates
this.
gfortran should warn that this is non-standard fortran 90/95 and fail
gracefully, and/or work as per the F2003 spec.

Thanks,
Jonathan.

[EMAIL PROTECTED] ~/bugs/gfortran-4.3/size_kind  $ gfortran-4.3 -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --program-suffix=-4.3
Thread model: posix
gcc version 4.3.0 (GCC)
[EMAIL PROTECTED] ~/bugs/gfortran-4.3/size_kind  $ gfortran-4.3 test_64.f90 
f951: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[EMAIL PROTECTED] ~/bugs/gfortran-4.3/size_kind  $ cat test_64.f90 
program test_64
   implicit none

   integer, parameter :: long = selected_int_kind(18)
   integer, parameter :: short = kind(0)

   integer(long), parameter :: big_sz = huge(0_short)+1000_long
   integer(long), parameter :: max_32 = huge(0_short)
   integer, dimension(:), allocatable :: array

   integer(long) :: i

   print *, 2**31  = , 2_long**31
   print *, max_32 = , max_32
   print *, big_sz = , big_sz

   allocate(array(big_sz))
   print *, sz = , size(array)
   print *, sz = , size(array, kind=long)
end program


-- 
   Summary: ICE on size with kind parameter
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: J dot Hogg at rl dot ac dot uk
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug fortran/35962] New: Should warn about precision loss on integer conversions in fortran

2008-04-17 Thread J dot Hogg at rl dot ac dot uk 
If I assign a long integer to a short integer gfortran should warn about
possible loss of precision, such as g95 does.

Thanks,
Jonathan.

Full test case:
[EMAIL PROTECTED] ~/bugs/gfortran-4.3/ls_prec  $ gfortran-4.3 -Wall -pedantic 
-o test
test.f90 
[EMAIL PROTECTED] ~/bugs/gfortran-4.3/ls_prec  $ ./test 
 lvar =8589934592
 svar =0
 lvar =1073741824
 svar =   1073741824
[EMAIL PROTECTED] ~/bugs/gfortran-4.3/ls_prec  $ gfortran-4.3 -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --program-suffix=-4.3
Thread model: posix
gcc version 4.3.0 (GCC)
[EMAIL PROTECTED] ~/bugs/gfortran-4.3/ls_prec  $ cat test.f90 
program test
   implicit none

   integer, parameter :: short = kind(0)
   integer, parameter :: long = selected_int_kind(18)

   integer(short) :: svar
   integer(long) :: lvar

   lvar = 2_long**33
   svar = lvar

   print *, lvar = , lvar
   print *, svar = , svar

   lvar = 2_long**30
   svar = lvar

   print *, lvar = , lvar
   print *, svar = , svar
end program


-- 
   Summary: Should warn about precision loss on integer conversions
in fortran
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: J dot Hogg at rl dot ac dot uk
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug fortran/35962] Should warn about precision loss on integer conversions in fortran

2008-04-17 Thread J dot Hogg at rl dot ac dot uk 


--- Comment #2 from J dot Hogg at rl dot ac dot uk  2008-04-17 09:33 ---
That seems to fix the original complaint with the following output:
[EMAIL PROTECTED] ~/bugs/gfortran-4.3/ls_prec  $ gfortran-4.3 -Wall -pedantic
-Wconversion -o test test.f90 
test.f90:10.20:

   lvar = 2_long**33
   1
Warning: Conversion from INTEGER(4) to INTEGER(8) at (1)
test.f90:16.20:

   lvar = 2_long**30
   1
Warning: Conversion from INTEGER(4) to INTEGER(8) at (1)
test.f90:11.10:

   svar = lvar
 1
Warning: Conversion from INTEGER(8) to INTEGER(4) at (1)
test.f90:17.10:

   svar = lvar
 1
Warning: Conversion from INTEGER(8) to INTEGER(4) at (1)

Apologies for wasting your time in that respect, though as you say it is a
little verbose and a happy medium between the two would be appreciated.


-- 


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

[Bug fortran/35945] New: Complex module-based overloading fails

2008-04-15 Thread J dot Hogg at rl dot ac dot uk 
If a type is renamed on import and then an unrenamed copy is also imported, and
overloaded functions are called then gfortran fails to compile with a blocked
by an incompatible object error. The code compiles cleanly with {NAG, ifort,
g95}.

Not sure if this is a bug or non-standard code, though I suspect the former.

Thanks,
Joanthan Hogg

Full test case:
[EMAIL PROTECTED] ~/bugs/gfortran-4.3/import_rename  $ make
gfortran-4.3  -c stype.f90
gfortran-4.3  -c dtype.f90
gfortran-4.3  -c test.f90
test.f90:15.29:

   subroutine fred(sval, dval)
1
test.f90:16.15:

  use stype
  2
Error: The type 'overloaded_type' cannot be host associated at (1) because it
is blocked by an incompatible object of the same name declared at (2)
make: *** [test.o] Error 1
[EMAIL PROTECTED] ~/bugs/gfortran-4.3/import_rename  $ gfortran-4.3 -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --program-suffix=-4.3
Thread model: posix
gcc version 4.3.0 (GCC)
[EMAIL PROTECTED] ~/bugs/gfortran-4.3/import_rename  $ cat test.f90 
program test
   use stype, overloaded_type_s = overloaded_type
   use dtype, overloaded_type_d = overloaded_type
   implicit none

   type(overloaded_type_s) :: sval
   type(overloaded_type_d) :: dval

   sval%part = 1
   dval%part = 2

   call fred(sval, dval)

contains
   subroutine fred(sval, dval)
  use stype

  type(overloaded_type_s), intent(in) :: sval
  type(overloaded_type_d), intent(in) :: dval

  call overloaded_sub(sval)
  call overloaded_sub(dval)
   end subroutine
end program
[EMAIL PROTECTED] ~/bugs/gfortran-4.3/import_rename  $ cat stype.f90 
module stype
   implicit none

   type overloaded_type
  real :: part
   end type

   interface overloaded_sub
  module procedure overloaded_sub_s
   end interface

contains
   subroutine overloaded_sub_s(otype)
  type(overloaded_type), intent(in) :: otype

  print *, s type = , otype%part
   end subroutine
end module
[EMAIL PROTECTED] ~/bugs/gfortran-4.3/import_rename  $ cat dtype.f90 
module dtype
   implicit none

   type overloaded_type
  double precision :: part
   end type

   interface overloaded_sub
  module procedure overloaded_sub_d
   end interface

contains
   subroutine overloaded_sub_d(otype)
  type(overloaded_type), intent(in) :: otype

  print *, d type = , otype%part
   end subroutine
end module


-- 
   Summary: Complex module-based overloading fails
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: J dot Hogg at rl dot ac dot uk
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug fortran/35882] New: Miscounted continuation lines when interspersed with data

2008-04-09 Thread J dot Hogg at rl dot ac dot uk 
gfortran seems to misreport a warning about exceeding the number of
continuation lines limit (39 lines of continuation) in certain cases when
compiled with -pedantic.

We found the bug when using a very long write statement, with alternating
continuation lines of string literals and data. The bug does not appear if only
string literals are used.

The bug results in reporting the wrong line as the first invalid continuation
line (if there are indeed more than 39) or that there are too many (in the case
where there are 39 or fewer).

Thanks,
Jonathan.

Full test case:
[EMAIL PROTECTED] ~/bugs/gfortran-4.3/continuation  $ gfortran-4.3 -pedantic -o 
test
test.f90 
test.f90:23:

  Line 15, 
1
Warning: Limit of 39 continuations exceeded in statement at (1)
[EMAIL PROTECTED] ~/bugs/gfortran-4.3/continuation  $ gfortran-4.3 -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --program-suffix=-4.3
Thread model: posix
gcc version 4.3.0 (GCC)
[EMAIL PROTECTED] ~/bugs/gfortran-4.3/continuation  $ cat test.f90
program test_mod
   implicit none

   integer, dimension(50) :: array

   array = 1

   print (a, i8), 
  Line 1, 
  array(2), 
  Line 3, 
  array(4), 
  Line 5, 
  array(6), 
  Line 7, 
  array(8), 
  Line 9, 
  array(10), 
  Line 11, 
  array(12), 
  Line 13, 
  array(14), 
  Line 15, 
  array(16), 
  Line 17, 
  array(18), 
  Line 19, 
  array(20), 
  Line 21, 
  array(22), 
  Line 23, 
  array(24), 
  Line 25, 
  array(26), 
  Line 27, 
  array(28), 
  Line 29, 
  array(30), 
  Line 31, 
  array(32), 
  Line 33, 
  array(34), 
  Line 35, 
  array(36), 
  Line 37, 
  array(38), 
  Line 39, 
  array(40), 
  Line 41, 
  array(42), 
  Line 43
end program


-- 
   Summary: Miscounted continuation lines when interspersed with
data
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: J dot Hogg at rl dot ac dot uk
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug fortran/35786] New: OpenMP Fortran PRIVATE on parameter gives error in gfc_finish_var_decl

2008-04-01 Thread J dot Hogg at rl dot ac dot uk 
Using the parameter ONE in the PRIVATE stanza of the parallel do in the below
code produces the shown error. This error only occurs if the subroutine is in a
module file.

[EMAIL PROTECTED] $ gfortran-4.3 -fopenmp -c test.f90
test.f90: In function ‘test’:
test.f90:8: internal compiler error: in gfc_finish_var_decl, at
fortran/trans-decl.c:510
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[EMAIL PROTECTED] $ cat test.f90
module testmod
  implicit none

  real, parameter :: one = 1.0

contains

subroutine test
integer i

real, dimension(4) :: a = (/ 1, 2, 3, 4 /)
real, dimension(4) :: b

!$OMP PARALLEL DO PRIVATE(I, ONE)
do i = 1,size(a)
  b(i) = one*a(i)
end do
!$OMP END PARALLEL DO

print *, b = , b
end subroutine test
end module
[EMAIL PROTECTED] $ gfortran-4.3 -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --program-suffix=-4.3
Thread model: posix
gcc version 4.3.0 (GCC)


-- 
   Summary: OpenMP Fortran PRIVATE on parameter gives error in
gfc_finish_var_decl
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: J dot Hogg at rl dot ac dot uk
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug fortran/35786] OpenMP Fortran PRIVATE on parameter gives error in gfc_finish_var_decl

2008-04-01 Thread J dot Hogg at rl dot ac dot uk 


--- Comment #2 from J dot Hogg at rl dot ac dot uk  2008-04-01 14:13 ---
(In reply to comment #1)
 Thanks for the report; the internal compiler error is definitely a compiler
 bug. However, I believe the program is invalid.

I know the program is invalid (thought that went without saying, I should
probably be more verbose in the future), it was more of a feature request for a
nice error message.

Thanks for your help,
Jonathan.


-- 


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