headers
Janne Blomqvist | 17 May 2013 14:18
Picon

[fortran, doc] Improve random_seed example

Hi,

the example we provide for the usage of the random_seed intrinsic
could be better. At least one user has already been tripped over by
the fact that on some targets the first call to system_clock returns
0, resulting in a poor seed. Below is an improved(?!) example program.

Ok for trunk/4.8/4.7? (Changelog + patch is of course trivial once
there is agreement on the code itself)

! Seed the random generator with some random input
module rseed_rand
contains
  subroutine rseed()
    implicit none
    integer, allocatable :: seed(:)
    integer :: i, n, un, istat, dt(8), pid, t(2), s
    integer(8) :: count, tms

    call random_seed(size = n)
    allocate(seed(n))
    ! First try if the OS provides a random number generator
    open(newunit=un, file="/dev/urandom", access="stream", &
         form="unformatted", iostat=istat)
    if (istat == 0) then
       read(un) seed
       close(un)
    else
       ! Fallback to XOR:ing the current time and pid. The PID is
       ! useful in case one launches multiple instances of the same
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tobias Burnus | 17 May 2013 08:45
Picon

[Patch, Fortran] PR48858/55465 - permit multiple bind(C) declarations (but not definitions) for the same proc

Followup (and depending on) to the C binding patches for
* COMMON: http://gcc.gnu.org/ml/fortran/2013-05/msg00048.html
* Procedures: http://gcc.gnu.org/ml/fortran/2013-05/msg00051.html
which honour Fortran 2008, where the Fortran name is no longer a global 
identifier if a binding name has been specified.

The main reason for this patch is a build failure of Open MPI (requires 
!gcc$ attributes no_arg_check, i.e. it only affects GCC 4.9). Open MPI 
uses somethine like:
   interface
     subroutine pmpi_something() bind(C,name="MPI_something")
   ...
and in a different module:
   interface
     subroutine mpi_something() bind(C,name="MPI_something")
   ...

Currently, gfortran rejects it because it only permits one 
definition/declaration per translation unit. However, there is no reason 
why multiple INTERFACE blocks shouldn't be permitted.

Remarks:

a) Better argument checks if definition and declaration are in the same 
file. (see INTENT patch in a test case)

b) Currently, no check is done regarding the characteristic of procedure 
declarations. Of course, the declaration has to be compatible with the C 
procedure. However, there seems to be the wish* to permit compatible 
input - even if the Fortran characteristic is different. For instance
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bud Davis | 17 May 2013 05:22
Picon
Favicon

[patch,fortran] PR50405 - Statement function with itself as argument SEGV's

Not to much to add beyond the title and the patch.
The test file fails before (eventually, when you run out of stack) and passes after the patch is applied. 
No new testsuite failures.

--bud

Index: gcc/gcc/fortran/resolve.c
===================================================================
--- gcc/gcc/fortran/resolve.c    (revision 198955)
+++ gcc/gcc/fortran/resolve.c    (working copy)
 <at>  <at>  -306,6 +306,14  <at>  <at> 
            && !resolve_procedure_interface (sym))
     return;

+      if (strcmp (proc->name,sym->name) == 0)
+        {
+       gfc_error ("Self referential argument "
+       "'%s' at %L is not allowed", sym->name,
+       &proc->declared_at);
+       return;
+        }
+
       if (sym->attr.if_source != IFSRC_UNKNOWN)
     resolve_formal_arglist (sym);

!{ dg-do compile }
! submitted by zeccav <at> gmail.com
!{ dg-prune-output "Obsolescent feature: Statement function at" }
       f(f) = 0 ! { dg-error "Self referential argument" }
       end
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrew Benson | 16 May 2013 20:53
Favicon
Gravatar

ICE on valid

The following causes an ICE with gfortran 4.9.0 r198983:

module t
  type :: c
  end type c
  type(c), target :: cd
  class(c), public, pointer :: cc => cd
end module t

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-unknown-
linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools 
--enable-languages=c,c++,fortran --disable-multilib --with-
gmp=/home/abenson/Galacticus/Tools
Thread model: posix
gcc version 4.9.0 20130516 (experimental) (GCC) 

$ gfortran -c bug.F90 -o bug.o
bug.F90:7:0: internal compiler error: in gfc_conv_structure, at fortran/trans-
expr.c:6027
   class(c), public, pointer :: cc => cd
 ^
0x5be449 gfc_conv_structure(gfc_se*, gfc_expr*, int)
        ../../gcc-trunk/gcc/fortran/trans-expr.c:6027
0x5be610 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, 
bool, bool)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steve Westenbroek | 10 May 2013 23:00
Picon
Favicon

gfortran compiled executable - memory use skyrockets: 4.7.2 to 4.8.0 to 4.9.0

Greetings all,

I am running into strange memory issues that I don't know the cause of. 
I'll gladly put together a short test case, assuming that I can 
reproduce the behavior.

Briefly, when I compile the same chunk of code and run it on the 
identical test case, I obtain the following memory usage during the run:

4.7.2                          : 25MB committed
4.8.0 2013.02.17 (experimental) : 1898MB committed
4.9.0 2013.04.21 (experimental) : 1898MB committed

gfortran versions mentioned above are the 64-bit MinGW versions, 
compiled by equation.com. Compilation flags were identical for each 
gfortran version.

Again, I'd love to help out by generating a short test case, but I don't 
even know where to begin. Let me know if you'd like more specifics or if 
you have suggestions regarding the apparent memory use increase.

Thanks, - Steve
Permalink | Reply | 2 comments |
headers
Mike Stump | 10 May 2013 21:56
Picon

aliasing bug of some sort in select_type_4.f90

So, I was tracking down a bug in gfortran.dg/select_type_4.f90 and it turns out that if I reschedule (I do
this after loop optimizations and before web) the code, the code then fails at runtime.  If I compile with
-fno-strict-aliasing, the problem goes away.  The change is to hoist a load up to the top of the basic block. 
I believe that that alias information is likely wrong.  insn 231 is the hoisted load.  I'm hoping a hand
review of the source by a fortran expert and the alias sets involved { , 3, 12} can identify the part that went wrong.

(code_label 218 213 219 14 21 "" [1 uses])
(note 219 218 231 14 [bb 14] NOTE_INSN_BASIC_BLOCK)
(insn 231 219 232 14 (set (reg:DI 742 [ MEM[(struct __class_poly_list_Node_type &)&node]+8 ])
        (mem/c:DI (plus:DI (reg/f:DI 1053)
                (const_int 8 [0x8])) [12 MEM[(struct __class_poly_list_Node_type &)&node]+8 S8 A64])) t.f90:37 5 {*load}
     (expr_list:REG_DEAD (reg/f:DI 1053)
        (nil)))
(insn 232 231 220 14 (set (mem:DI (plus:DI (reg/v/f:DI 602 [ integer_node ])
                (const_int 8 [0x8])) [3 MEM[(struct node_type *)integer_node_19].next+8 S8 A64])
        (reg:DI 742 [ MEM[(struct __class_poly_list_Node_type &)&node]+8 ])) t.f90:37 65 {*store}
     (expr_list:REG_DEAD (reg/v/f:DI 602 [ integer_node ])
        (nil)))
(insn 220 232 247 14 (set (mem/f/c:DI (plus:DI (reg/f:DI 2134 IN2)
                (const_int -560 [0xfffffffffffffdd0])) [3 MEM[(struct __class_poly_list_Node_type_p *)&node]+0 S8 A128])
        (reg/f:DI 603 [ node ])) t.f90:37 65 {*store}
     (nil))
(insn 247 220 774 14 (set (mem/c:DI (plus:DI (reg/f:DI 1046)
                (const_int 8 [0x8])) [3 list.tail+8 S8 A64])
        (reg:DI 742 [ MEM[(struct __class_poly_list_Node_type &)&node]+8 ])) t.f90:38 65 {*store}
     (expr_list:REG_DEAD (reg:DI 742 [ MEM[(struct __class_poly_list_Node_type &)&node]+8 ])
        (nil)))
(insn 774 247 248 14 (set (reg/f:DI 735)
        (reg/f:DI 1045)) t.f90:37 3335 {mymovdi}
     (expr_list:REG_EQUAL (symbol_ref:DI ("__poly_list_MOD___vtab_poly_list_Node_type") [flags 0x2]
(Continue reading)

Permalink | Reply | 1 comment |
headers
Romeu Braz Pereira Gomes Filho | 10 May 2013 13:36
Picon

Maximum rank - Fortran 2008

Dear gfortran developers,

I would like to know when gfortran will suport a maximum rank of 15 for arrays.

Best regards,

Romeu.
Permalink | Reply | 1 comment |
headers
Peng Yu | 9 May 2013 17:51
Picon

Why does gfortran treat files with different suffix differently?

Hi,

The following shows that gfortran treat .f and .f90 files differently.
But I don't find this documented in the man page. Could anybody let me
know where this is documented? Thanks.

~/linux/test/fortran/bin/gfortran/suffix$ cat main.sh
#!/usr/bin/env bash

set -v
gfortran -fimplicit-none -o main.exe main.f
gfortran -fimplicit-none -o main1.exe main1.f90

~/linux/test/fortran/bin/gfortran/suffix$ cat main.f
      program main
        implicit none
        real:: a
        a = 3.0 + 4.0 + &
          13.0
        print *, a
      end program
~/linux/test/fortran/bin/gfortran/suffix$ cat main1.f90
      program main
        implicit none
        real:: a
        a = 3.0 + 4.0 + &
          13.0
        print *, a
      end program
~/linux/test/fortran/bin/gfortran/suffix$ diff main.f  main1.f90
(Continue reading)

Permalink | Reply | 1 comment |
headers
Diego Novillo | 9 May 2013 17:16
Picon
Favicon

GNU Tools Cauldron 2013 - An update on presentations


An update on this year's Cauldron.  We are getting close to the
limit on the presentations and BoFs, so if you are interested in
organizing a BoF or giving a presentation, please send us an
abstract soon.

We will still accept presentations and/or BoFs on-site the first
day of the workshop.  However, those will likely need to run in
parallel with the existing sessions.

We still do not have a formal schedule, but we are expecting to
have 3 pretty full days, starting on Fri 12/Jul.  I will send
details on the schedule as soon as we finalize it.

Please visit the wiki for more info http://gcc.gnu.org/wiki/cauldron2013

Diego.
Permalink | Reply | 0 comments |
headers
Tobias Burnus | 7 May 2013 18:53
Picon

[Fortran-Dev, committed] Fix SIZE call - and, hence, 3 regressions

This is another trivial patch, which fixes three regressions. The 
following four regressions remain:

gfortran.dg/mvbits_7.f90
gfortran.dg/mvbits_8.f90
gfortran.dg/subref_array_pointer_2.f90
gfortran.dg/unlimited_polymorphic_1.f03

Committed as Rev. 198688 - after building and regtesting on 
x86-64-gnu-linux.

(Actually, that's not quite true: The last merge from the trunk also 
imported some 
regressions:http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00352.html - 
but ignoring those, there are only 4 regression left on the branch :-)

* * *

I think the mvbits regressions are related to elem_len != sm, i.e. since 
dtype's size (now: elem_len) no longer matches stride multiplier, it 
fails. But maybe that's the wrong assessment.

TODO:
- Fix the 4 regressions
- Remove the "offset" field/component from the descriptor
- Set lower_bound == 0 for the args to a nonpointer/nonalloc dummy argument.
- Handle elem_len != n*stride throughout the code
- Audit the use of elem_len, stride/sm, ubound, type, attribute for 
correctness and performance optimization (e.g. making use of the 
lower_bound==0 knowledge)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dominique Dhumieres | 7 May 2013 18:38
Picon
Picon
Favicon

[Fortran-Dev, committed] Set elem_len and use proper element size for stride handling

Dear Tobias,

First, The bootstrap problem I have seen seems to be gone.
I have posted the results for the gfortran test suite at

http://gcc.gnu.org/ml/gcc-testresults/2013-05/msg00675.html

with revision 198627 reverted. I don't see any failure for
gfortran.dg/mvbits_8.f90, but valgrins complains.
I also see

FAIL: gfortran.dg/coarray_12.f90  -O   scan-tree-dump-times original "a.dim.0..extent = MAX_EXPR
<.*nn, 0>;" 1

with -m32 and if I grep for MAX_EXPR in the dump, I see

        a.dim[0].extent = MAX_EXPR <NON_LVALUE_EXPR <nn>, 0>;

Cheers,

Dominique
Permalink | Reply | 0 comments |

Gmane