Discussion :

[François L.]

Bonjour à tous,
l'un de mes étudiants a rencontré un plantage bizarre, avec gfortran (celui livré avec Code::Blocks) sous windows.

Le code suivant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
program hello
    implicit none
integer,parameter::nL=2,nC=1
REAL(8)::tab(nL,nC),ChercheMin
 
tab(1,1)=1.d0
tab(2,1)=2.d0
write(*,*)"min=",ChercheMin(nL,nC,tab)
 
end program
 
function ChercheMin(nl,nc,tab)
implicit none
integer::nl,nc
REAL(8)::tab(nl,nc),ChercheMin
 
! SI on décommente la ligne suivante, ça buggue...
!write(*,*) "Coucou"
 
ChercheMin=tab(1,1)+tab(2,1)
end function

fonctionne parfaitement. Sauf si on décommente le WRITE dans la fonction.

Or, il ne me semble pas qu'il soit interdit de mettre des E/S dans les fonctions... L'étudiant a eu la bonne idée d'essayer un compilo en ligne, qui, lui, fonctionne...

D'après vous, serait-ce un bug de gfortran, ou un respect strict d'une partie de la norme que j'avoue ignorer?

Vos avis éclairés sont les bienvenus

[vmagnin]

Bonjour,

ça semble effectivement anormal. Le programme fonctionne avec Intel ifort et Intel ifx. Mais il plante (en tout cas il se fige) avec GFortran 11.2.0 et GFortran 12.1.0 (testé sous Linux Ubuntu).

A noter que si dans le programme principal j'enlève le write et que je mets le résultat de la fonction dans une variable, ça marche, "Coucou" est affiché. Je vais en parler à quelqu'un de l'équipe GFortran.

A part ça, si je peux me permettre, plutôt que de déclarer la fonction après END PROGRAM, je préconiserais plutôt d'utiliser CONTAINS :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
program hello
...
contains

function ChercheMin(nl,nc,tab)
 ...
end function

end program hello

Ca évite de devoir redéclarer le type de la fonction dans le programme principal et ça améliore le diagnostique du compilateur.

Enfin, il faut éviter REAL(8) : la plupart des compilateurs considèrent que c'est 8 octets mais pas tous. Le 8 est un juste un numéro, un KIND, ce n'est pas la taille en octets. Depuis Fortran 2008, on peut utiliser la constante real64 du module intrinsèque iso_fortran_env. Là, c'est normalisé, donc sans surprise :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
  use, intrinsic :: iso_fortran_env, only: dp=>real64
...
  real(dp) :: tab(nL,nC)
 
  tab(1,1) = 1.0_dp

Voir https://fortran-lang.org/fr/learn/qu...oint-precision

[vmagnin]

Or, il ne me semble pas qu'il soit interdit de mettre des E/S dans les fonctions... L'étudiant a eu la bonne idée d'essayer un compilo en ligne, qui, lui, fonctionne...

Après discussion, il est possible que ce soit lié au paragraphe suivant de la norme Fortran :

12.12 Restrictions on input/output statements

• 2 An input/output statement that is executed while another input/output statement is being executed is a recursive input/output statement...

J'ai en effet constaté qu'avec GFortran on peut faire un write() dans la fonction, à condition que le résultat de la fonction ne soit pas lui-même directement utilisé dans un write() ! Sinon ça semble effectivement provoquer une sorte de récursivité infinie... Le programme ne s'arrête pas mais semble tourner en boucle.

Les compilateurs Intel se comportent autrement. Ca suggère donc que ce genre de chose ne serait donc pas garanti par la norme Fortran, et donc à éviter.

Je posterai d'autres messages ici si en poursuivant mes discussions en ligne j'obtiens d'autres informations.

[vmagnin]

Après discussion avec quelques experts, je confirme qu'il ne faut pas mettre un write dans une fonction utilisée dans un write... du moins s'ils utilisent la même unité de sortie, si je comprend le paragraphe complet de la norme Fortran :

2 An input/output statement that is executed while another input/output statement is being executed is a recursive input/output statement. A recursive input/output statement shall not identify an external unit that is identified by another input/output statement being executed except that a child data transfer statement may identify its parent data transfer statement external unit.

Dans le cas de GFortran, le write du programme principal crée un verrou sur la sortie standard *, et dans la fonction le write attend que le verrou soit levé... D'où l'attente que l'on constate en exécutant le programme. Intel Fortran gère la situation différemment.

[vmagnin]

On peut contourner le problème en utilisant les output_unit et error_unit définies dans le module intrinsèque iso_fortran_env (Fortran 2008), puisque ce sont deux unités différentes (en tout cas sur mon système Linux) même si elles sortent toutes les deux sur le terminal :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
program hello
  use, intrinsic :: iso_fortran_env, only: output_unit, error_unit
  implicit none
 
  write(output_unit,*) "myfunction = ", myfunction(1)
 
  contains
 
  integer function myfunction(n)
    integer :: n
 
    write(error_unit,*) "Hello"
 
    myfunction = 2*n
  end function
 
end program

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
$ gfortran bug3.f90 -Wall -Wextra -pedantic -std=f2018 && ./a.out
 Hello
 myfunction =            2

A noter que la ligne 2 peut être écrite :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

use iso_fortran_env

si on veut faire simple et ne pas perturber l'apprentissage.

[François L.]

Un très grand merci! Je vais prendre en considération les remarques annexes également, même si je ne suis pas sûr de les appliquer pour le cours d'info que nous dispensons (le coup du REAL(8) en particulier )

Je clos la discussion