NEC2 compilieren: FORTRAN-Frage

[Jörg W. (dl8dtl) (Moderator)]

Ich habe den FORTRAN-Code von NEC2 vor Jahren mal unter FreeBSD
compiliert, und das Compilat dann für ein paar Berechnungen benutzt.
Jetzt wollte ich das alles nochmal auf einem Linux-Rechner
compilieren, und dort stirbt mir das mit Segfaults ab, die jeweils
dann geschmissen werden, wenn ein subroutine-Parameter auf sich selbst
zugewiesen wird, so in der Art:

      SUBROUTINE SOLVES(A,B,Y,NEQ,NP,N,MP,M,IP,NRH,IFL1,IFL2,LD2,
     1 IRESRV)
C
C     SUBROUTINE SOLVES, FOR SYMMETRIC STRUCTURES, HANDLES THE
C     TRANSFORMATION OF THE RIGHT HAND SIDE VECTOR AND SOLUTION OF THE
C     MATRIX EQ.
C
      COMMON/SMAT/ SSX(16,16)
      INTEGER*4 NPEQ,NROW,NEQ,NP,N,MP,M
...
C**
C     D      WRITE(*,*) '   SOLVES: START IFL1=',IFL1,' IFL2=',IFL2
      IRESRV=IRESRV   <-------- hier
C**
      NPEQ=NP+2*MP
...

Wenn ich die entsprechende Zeile auskommentiere, dann läuft es.  Sowas
gibt's in einem halben Dutzend Dateien.

Meine Fragen dabei sind:

* Warum zum Geier schreibt man so eine Zuweisung überhaupt hin?
  (IRESRV wird anschließend nirgends mehr in der subroutine benutzt.)

* Könnte das Auskommentieren noch irgendeinen negativen Seiteneffekt
  haben?

Ja, ich weiß, es gibt inzwischen auch einen C-Rewrite, den werde ich
vielleicht auch mal ausprobieren, das hier würde mich trotzdem noch
interessieren.

[skua (Gast)]

Seltsam


Jörg Wunsch schrieb:
> IRESRV wird anschließend nirgends mehr in der subroutine benutzt.

Wenn das so ist sehe ich auch keine Probleme.
Selbst wenn nicht.

Wahrscheinlich Überreste von Test und Debugging.

In einer FORTRAN 90 Source die ich mal kurz überflogen habe ist auch 
nichts dergleichen zu sehen.

Ansonsten mal vorsichtshalber
IRESRV=IRESRV*1
Probieren.

MfG

[Jörg W. (dl8dtl) (Moderator)]

skua schrieb:
> Seltsam

Ja, das dachte ich mir auch. ;-)  Auch seltsam, warum es unter FreeBSD
geht, aber möglicherweise ist das mit einer älteren Version von
GNU-f77 compiliert worden.  Oder die auf dem Linux ist verwanzt.

> Ansonsten mal vorsichtshalber
> IRESRV=IRESRV*1
> Probieren.

Ändert auch nichts, so viel wird wahrscheinlich sogar schon unter
FORTRAN optimiert. ;-)

Ich lass das mal auskommentiert, das berechnete Ergebnis scheint
brauchbar.

[Karl H. (kbuchegg)]

Wenn das ein seltsames COMMON Konstrukt gewesen wäre, hätte es eventuell 
einen Sinn gehabt.

In Fortran konnte man Folgendes machen:
In einem COMMON einen String mit sich selbst so überlagern, dass es um 1 
Zeichen nach links oder rechts verschoben war.
Die Zuweisung hat dann bewirkt, dass man den String um 1 Zeichen 
geshiftet hat.

Das war aber in den 80-er Jahren. Ob das mit heutigen FORTRANs noch 
geht, weiß ich nicht.

Bei Integer Variablen fällt mir überhaupt nichts ein, warum man auf sich 
selbst zuweisen sollte.

[Yalu X. (yalu) (Moderator)]

Jörg Wunsch schrieb:
> Wenn ich die entsprechende Zeile auskommentiere, dann läuft es.  Sowas
> gibt's in einem halben Dutzend Dateien.

Da scheint etwas mit dem Compiler im Argen zu liegen. Ich nehme an, du
nimmst den GNU-Fortran-Compiler. Folgender Code

      program ftest
      print *, "hello"
      call sub(0.0)
      end

      subroutine sub(x)
      x = x
      end

mit -O0 kompiliert segfaultet bei der Ausführung. Kompiliert man ihn mit
-O2, segfaultet schon der Compiler:

ftest.f: In function ‘ftest’:
ftest.f:7:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://bugs.archlinux.org/> for instructions.

Mit -O1 läuft alles korrekt.

Ich habe Version 4.6.1.

> Meine Fragen dabei sind:
>
> * Warum zum Geier schreibt man so eine Zuweisung überhaupt hin?
>   (IRESRV wird anschließend nirgends mehr in der subroutine benutzt.)

Wahrscheinlich, um "Unused dummy argument"-Warnungen zu vermeiden. Die
überflüssigen Argumente sind vermutlich aus historischen Gründen da.

> * Könnte das Auskommentieren noch irgendeinen negativen Seiteneffekt
>   haben?

Ziemlich sicher nicht. Ich habe vor langer Zeit recht viel in Fortran
programmiert, aber dieses Konstrukt ist mir nie begegnet. Es würde mich
auch wundern, wenn es eine semantische Bedeutung hätte. Die Frage ist
halt, ob der obige Compiler-Bug nicht noch weitere Einflüsse auf die
Funktion des Programms hat.