Release mode executable problem

[Haoping_H_]

I wrote a simple and short program which ran well in debug mode. However, it went wrong in release mode. Values were assigned in an array, but they changed to some funny number when they were used. 

[Yuan_C_Intel]

Hi, Haoping

Could you share your small program? Optimization in release mode may make a difference, but we still need to review the code to root cause the problem.

Thanks

[Haoping_H_]

Please let me know how to send the code. I tried to send by replying your email, but it was an unmonitored mail box.

[Arjen_Markus]

You ought to be able to use the "Browse" button under the text "Attach media"

[Haoping_H_]

It does not allow to add data file. You need data files to test the code.

[Haoping_H_]

Thank you for reminding me that optimization in release mode may make a difference. I changed the setting from Maximize Speed to Minimize Size (/O1) and it worked. Actually, it is a large program, but the problem is only related to one subroutine. I wrote a mainline program to call it. The problem is still there, which occurs at Lines 247 and 258. In release mode (Optimization=Maximize Speed), the array iMTRxNum went wrong. I attached the code and data files.

[mecej4]

You have a bug in your program. In subroutine MERGEING, you call subroutine ROTXY with the expression -ANGLEZTEM as the second argument, but in subroutine ROTXY that second argument gets a value assigned to it. An expression used as an argument is not "definable". How the compiler handles code with such an error can be quite variable, depending on the options used.

[Haoping_H_]

The second argument would be assigned a value ONLY zero passed into the subroutine. It is not the case for this program. The program did not go through the if(k==0)then ... endif block. I deleted the if-endif block, and compiled/ran the program. The same problem was still there.

[DavidWhite]

Also, your main program has Linenum declared as Character*50, but your subroutine has the same argument as Character*10.

David

[Yuan_C_Intel]

Hi, Haoping

What's your compiler version?

I cannot reproduce the problem with either 15.0 or 16.0. Both for debug and release configurations, I will get:

stn01.data
L1060.EMdata
Well done! Press enter to exit

Thanks.

[Haoping_H_]

My version is 11.1.048 purchased in 2013.

The problem can be seen in the output file. Since iMTRxNum had a wrong number in release mode, the write sentences did not executed. Thus, the output file is small (6 kb). It should be 57 kb as yielded from debug mode. Also, it did not work when optimization was Maximize Speed.

[Yuan_C_Intel]

Hi, Haoping

If you purchased the license in 2013, you probably can upgrade the compiler to 13.0 or 14.0 depending on your license expiration date.

Could you consider upgrade your compiler? Possibly a compiler bug and fixed in a later version.

Thanks.

[mecej4]

I'm afraid that changing compilers and compiler options is an ineffective and undependable remedy.

Among other questionable coding practices, some which have been noted above, the presented Fortran code has the following defect: Subroutine RotXY has the declaration

SUBROUTINE ROTXY(n, theta, x, y, xr, yr)

where x, y are input arrays and xr, yr are output arrays. However, in Subroutine Mergeing the call to this subroutine reads

CALL rotxy(nmtsite, -angleztem, xmt, ymt, xmt, ymt)

Thus, the input and output arrays are aliased to one another, which is in violation of the Fortran standard. With such code, it is very likely that higher levels of optimization (or newer versions of compilers with higher optimization capabilities) can give incorrect and unpredictable results. There exists a compiler option, "/assume:dummy_aliases", that may be helpful in this case, but it would be far better to fix the code by removing the aliasing. Here is a question to help move the O.P. in that direction: you observed the problem because the output file was shortened as a result of the error. Suppose the length had been correct but the contents wrong in just a few places. How many years could pass in which the incorrect results were unwittingly taken to be correct?

See https://software.intel.com/en-us/blogs/2009/07/10/doctor-fortran-in-ive-come-here-for-an-argument-side-2 for related problems.

[Haoping_H_]

This is not the cause of my problem. I revised the codes as

...

real*8 xxMT(1),yyMT(1)             !nMTsite=1 in this case

...

call Rotxy(nMTsite,-angleZTEM,xMT,yMT,xxMT,yyMT)

do i=1,nMTsite

xMT(i)=xxMT(i)

yMT(i)=yyMT(i)

enddo

The problem is still there.

[mecej4]

There is an optimizer bug in the current version (15.0.4.221) of the compiler, which I have reported separately at https://software.intel.com/en-us/forums/topic/586092 .

You have several instances of inner DO loops such as

        do j=1,nMTFreq
            if(k==j)then
                iMTFreqNum(i)=indexMTfreq(j)
            endif
        enddo

which trigger the optimizer bug. You can sidestep the bug and make your code more efficient by replacing the loop by the much simpler equivalent

iMTFreqNum(i)=indexMTfreq(k)

I do not find that optimizer bug in the 11.1.070 compiler. For your convenience, I have attached a modified version of your subroutine Mergeing which works correctly with the current compiler whether or not optimization is used.

[Yuan_C_Intel]

Hi, all

Sorry I should have read your comments more carefully.

Yes, even with latest compiler, the output length does not match for debug and release build executables.

mecej4 is correct. This triggered a compiler bug when vectorizing the loop.

To keep the semantic consistent with original code, I would make below changes to line 191-195:

!      do j=1,nMTsite
!            if(k==j)then
!               iMTRxNum(i)=indexMTsite(j)
!            endif
!      enddo
        if (k>=1 .AND. k<=nMTsite) then
            iMTRxNum(i)=indexMTsite(k)
        endif

Similar changes are made to loops at 158-162, 166-170, 197-201.

After that I can get identical output for debug and release mode executables. I have attached my updated "Test.f90".

Haoping, could you have a try with 11.1.048, see if it corrects the problem as a work-around?

Thanks.

[Haoping_H_]

Hi Yolanda, mecej4,

I have a try with 11.1.048. It works.

mecej4 modified code also works.

Thanks.