MinGW64 GFORTRAN Issues newer versions

[jelanier]

TL;DR Summary

Versions after 5 cause compile errors or compile to exe that doesn't work

http://www.chemroc.com/programs/NEC2Test.zip

I don't understand what has happened with newer versions of GFORTRAN/MinGW64 . This is a very old FORTRAN program that I had edited years ago to compile and run with GFORTRAN. It doesn't work with newer versions. Can anyone help? I included link to test the program. Includes batch to compile and batch to execute. Last version that works is MINGW64 v5.4

Also, The Hollerith warnings..I tried to replace them by quotes like 'example' but program will not compile that way. I also don't understand the loop error with version 8 (MinGW64_V8)

https://sourceforge.net/projects/mi...ilds/installer/mingw-w64-install.exe/download

Any help would be appreciated.

Thanks in advance,

Jim

 

[jelanier]

I have found a way to make it compile. It seems new version doesn't like optimization options on this old code.
gfortran -fno-automatic -ffast-math nec2dxs_JL.f -static -o nec2dxs.exe
This does work. I removed -O. O2 O3 Ofast do not work.

I still have a question about Hollerith data.

Current:
DATA HPOL/6HLINEAR,5HRIGHT,4HLEFT/

I changed it to:
DATA HPOL/'LINEAR','RIGHT','LEFT'/

Will not compile. What is up with that?

Thanks,

Jim

 

[BvU]

Installed gfortran and using gf.bat the thing did compile with warnings about hollerith and this loop issue.
But it crashed when run:

         - MULTIPLE WIRE JUNCTIONS -
 JUNCTION    SEGMENTS  (- FOR END 1, + FOR END 2)
     1        -1  -56 -661
     2         1   -2   -3   -4   -5   -6   -7   -8   -9  -10  -11  -12  -13  -14  -15  -16  -17  -18  -19  -20
             -21  -22  -23  -24  -25  -26  -27  -28  -29  -30  -31  -32  -33  -34  -35  -36  -37  -38  -39  -40
             -41  -42  -43  -44  -45  -46  -47  -48  -49  -50  -51  -52  -53  -54  -55  -56 -661
 CONNECT - SEGMENT CONNECTION ERROR FOR SEGMENT  417

It seems new version doesn't like optimization options on this old code.

I agree, and I find it very annoying that the compiler issues a warning only. It seems to make a mess of the loop

      IF (NY.GT.0) GO TO 11
      MIA=MI
      GO TO 12
11    M=M+1
      MP=MP+1
      MIA=LD+1-M
12    DO 13 IX=1,4
      X(MIA)=XS+XT*S1X+YT*S2X
      Y(MIA)=YS+XT*S1Y+YT*S2Y
      Z(MIA)=ZS+XT*S1Z+YT*S2Z
      BI(MIA)=XA
      T1X(MIA)=S1X
      T1Y(MIA)=S1Y
      T1Z(MIA)=S1Z
      T2X(MIA)=S2X
      T2Y(MIA)=S2Y
      T2Z(MIA)=S2Z
      SALP(MIA)=SALN
      IF (IX.EQ.2) YT=-YT
      IF (IX.EQ.1.OR.IX.EQ.3) XT=-XT
      MIA=MIA-1
13    CONTINUE

Which is no wonder in view of the loop counter being used in IF statements only and MIA in fact secretly doing the actual loop counter work. But even then, the compiler messages are rather useless:

nec2dxs_JL.f:7923:0:

       T1X(MIA)=S1X

Warning: iteration 1 invokes undefined behavior [-Waggressive-loop-optimizations]
nec2dxs_JL.f:7918:0:

 12    DO 13 IX=1,4

note: within this loop

and breaks off abruptly.

Kudos for finding an incantation that works !
(and gives exactly the same result 25% faster)Re:

I changed it to:
DATA HPOL/'LINEAR','RIGHT','LEFT'/

Will not compile. What is up with that?

Can't reproduce that !?.
(the warning for line 130 simply goes away)

$\$

 

[jelanier]

Thanks for looking into this BvU. My warning goes away also, but it does not produce an .exe. If you scroll down a bit you will see an error concerning that Hollerith edit.

BTW, I have a more extensive version of this code where I link to OpenBLAS LAPACK optimized. It increases speed by about 4x. But the base code here needs to be fixed first. I can't seem to figure out the Hollerith issue.

Later,

Jim

 

[BvU]

Sorry, missed that completely (it happens on a later pass, so it isn't the first message any more )

nec2dxs_JL.f:131:12:

    DATA HPOL/'LINEAR','RIGHT','LEFT'/
            1
Error: Incompatible types in DATA statement at (1); attempted conversion of CHARACTER(1) to REAL(8)

In the source code we have

      REAL*8  HPOL,PNET
      DIMENSION HPOL(3)
      DATA HPOL/'LINEAR','RIGHT','LEFT'/

With
character*6 HPOL,PNET
instead of REAL*8

it compiles and runs. I haven't found a way to make this less tedious: it means a you have to find all declarations and determine a size (or bluntly use e.g. character*60 )

 

[jelanier]

I did that earlier this morning with the character definition and had a good result. Some of these are not declared as real, but arrays. This could get ugly. I'll try to figure out how to handle the variable in one of these arrays. I thought arrays had to be declared as a type, but I don't see it.
C***
DIMENSION X2(1), Y2(1), Z2(1), T1X(1), T1Y(1), T1Z(1), T2X(1), T2Y
1(1), T2Z(1), ATST(13), IFX(2), IFY(2), IFZ(2), CAB(1), SAB(1), IPT
2(4)

Also, I tried an experiment on the optimization. I added -O again and removed the loop. It was only 4 passes so I copied it 4 times and incremented the variable. No warning, it compiled and crashed on run. Maybe it is nested.

Thanks again,

Jim