Weird variable behaviour...maybe bug

Weird variable behaviour...maybe bug

Hello.

I've been having some problems with how a counter is being added up.... This counter is used as an index in a couple of arrays, and because its been behaving strangely I've had a lot of problems.

To better illustrate this I wrote a simple program that adds the counter as in my subroutine, and it has been appended at the end.

This program returns the following output:

 Output first run:          32          24
q 8
q 9
q 14
q 15
Output second run: 24 24

The second run output is the correct one because the value of q must be 24 at the end. What I don't understand is why the first cycle (without the WRITE statement) acts so strangely so as to return such an erroneous value for q. Any suggestions or ideas?

The program has been compiled like this:

$ ifort nonesense.f90

My computer has Linux CentOS 4.2 installed, and is a Dell Inspiron 8100 laptop. With PIII processor (1 GHz), and 512MB of RAM.

I should notice that when compiled with gfortran (http://gcc.gnu.org/fortran/) I got the correct solutions in both cycles.

So is this maybe a bug????

Any input will be very much appreciated!

thanks,
Rodrigo.
PROGRAM nonsense
IMPLICIT NONE

INTEGER, PARAMETER :: nt = 4, nc = 3, nq = nt*(nc + 3)
INTEGER :: i, q, k

q = 1
DO i = 1, nc-1
q = q + 1
END DO

q = q + 1
q = q + 1
q = q + 1
q = q + 1

DO k = 2, nt-1
DO i = 1, nc-1
q = q + 1
END DO
q = q + 1
q = q + 1
q = q + 1
q = q + 1
END DO

DO i = 1, nc
q = q + 1
END DO
q = q + 1
q = q + 1

WRITE (*,*) 'Output first run:',q, nq

q = 1
DO i = 1, nc-1
q = q + 1
END DO

q = q + 1
q = q + 1
q = q + 1
q = q + 1

DO k = 2, nt-1
DO i = 1, nc-1
q = q + 1
WRITE(6,*) 'q',q
END DO
q = q + 1
q = q + 1
q = q + 1
q = q + 1
END DO

DO i = 1, nc
q = q + 1
END DO
q = q + 1
q = q + 1

WRITE (*,*) 'Output second run:',q, nq
END PROGRAM nonsense
9 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Hi,

seems to be a bug in optimization. -g gives correct results.

Report to intel premier support.

Hans

It may not even be optimization - I see the same problem with -O0. Please do report it. Thanks.

Retired 12/31/2016

Ok... I've reported it to intel premier support.
thanks to all.

Rodrigo,Any news yet from Premier Intel?The latestversion (Build 20060222 Package ID: l_fc_c_9.0.033) has the same behaviour.Seems that it is not solved yet.Please keep us up to date.Thanks,Arnold

I can't locate Rodrigo's support request, but the current update was built before he would have reported it.

Retired 12/31/2016

Hi everyone,

I did report the bug. I got issued the number 353876. I reported the problem with version 9.0.031. I haven't upgraded since, so I don't know if the newer vesions have the same behaviour. The only reply I've got from Intel Premier is at the end of this post.

Cheers,
rodrigo

_________________________

Hi Rodrigo,

Thank you for contacting about this incorrect result. My initial testing suggests our compiler is incorrectly optimizing variable q in the first run which leads to the incorrect result of 32. If you disable optimization by compiling your program with -O0 the results for the first run match the expected result as returned for the second run.

I will investigate this further and direct it to the proper compiler development team and keep you updated on their investigation and any fix that may result.

If this test case was derived from a larger subroutine, as a work-around, you can compile that subroutine without optimization, -O0, for now.

Thank you,
Kevin Davis
Intel Compiler Support

Message Edited by soyrush@gmail.com on 04-12-200612:22 PM

Steve,

It seems issue Q353876 is still not solved. What are your ideas concerning this bug. Will it be solved in a future release?

Thanks,

Arnold

Sorry, I have no new information on this issue. If we get any, either I or Kevin will let you know.

Retired 12/31/2016

Leave a Comment

Please sign in to add a comment. Not a member? Join today