vectorization bug on 11.0.074 (Linux-intel64)

[andrpapp]

I believe I found a bug in the Fortran compiler 11.0 (Linux).
Our lab is a licensed user of the product and I opened an issue on the Intel Premier
Account Interface before, but received no immediate help.
I have example code for the problem, which is given at the very end of this message.
The original bug essentially came down to the following:
If trigonometric functions are called inside a loop with complex data structures
(vectorizer complains "subscript too complex"), they appear to break the dependency
recognition, force vectorization and hence create an incorrect result:
(Inacceptable) fixes include:
Compiler flags:
-O0
-O1
-no-vec
Code changes:
- Explicitly introduce dependence in the loop through write-statements
- Simplify data structures
- Use other intrinsic functions (like sqrt) instead of trigonometric ones (by now
  i have a similar bug, however, which does not involve a single intrinsic)
Architecture changes:
- go to 32-bit

For reference, example code is given below. When compiled with -O3 as the only
option it yields a value of zero for the variable "val" which is clearly incorrect.
It can be fixed by any (or more) of the fixes listed above. This is a major bug for
scientific code such as the code we work on and hence very important to us.

The previous compiler we used (version 10.1) does deal with this correctly.

Please note that since this first bug I encountered another similar issue with
complicated data structures and simple loops in which data dependency is
not recognized properly. Results are strictly false without any proper warning 
or documentation even when using -vec-report3. 

I wonder whether this has been fixed in 11.0.081 or whether it is at least being
worked on? Right now, version 11 is a strict no-go for us,
Andreas

---------------------------------------------------------

module one

  type t_dummy
    real(8), ALLOCATABLE:: it(:,:)
    real(8), ALLOCATABLE:: f(:)
  end type t_dummy
  type(t_dummy), ALLOCATABLE:: dummy(:)
  integer, ALLOCATABLE:: imap(:)
  integer, ALLOCATABLE:: bmap(:)
end module one



program abug

use one

implicit none

integer ndum,da,db,i
real(8), ALLOCATABLE:: prns(:)
real(8) val

ndum = 10
da = 2
db = 100

allocate(dummy(ndum))
do i=1,ndum
  allocate(dummy(i)%it(da,db))
end do
allocate(bmap(ndum))
allocate(prns(ndum))
call random_number(prns)
bmap(:) = int(10.0*prns - 0.5) + 1
deallocate(prns)
allocate(imap(db))
allocate(prns(db))
call random_number(prns)
imap(:) = int(30.0*prns - 0.5) + 1
deallocate(prns)

call s2(val)
write(*,*) val

deallocate(imap)
deallocate(bmap)
do i=1,ndum
  deallocate(dummy(i)%it)
end do
deallocate(dummy)

end


subroutine s1(i,ttc,arg3,val)

use one

implicit none

integer i,j,ttc
real(8), INTENT(in):: arg3
real(8), INTENT(inout):: val
real(8) rvec(3)

call random_number(rvec)

do j=1,3
  dummy(bmap(i))%it(ttc,3*imap(i)+j) = arg3*rvec(j)*sin(rvec(1))
  val = val + dummy(bmap(i))%it(ttc,3*imap(i)+j)
end do

end



subroutine s2(val)

use one

implicit none

integer i,ttc,j,imol
real(8) arg3
real(8), INTENT(inout):: val

ttc = 1
imol = 1
dummy(imol)%it(ttc,:) = 0.0
val = 0.0

do i=1,9
  call random_number(arg3)
  call s1(i,ttc,arg3,val)
end do

end

[Ron_Green]

What is the issue number in Premier? I can go check on it (there are too many matches from users at Wash. Univ in St. Louis.)

thanks

ron

[andrpapp]

issue# is 533973.

thanks

andreas

Quoting - Ronald Green (Intel)

What is the issue number in Premier? I can go check on it (there are too many matches from users at Wash. Univ in St. Louis.)

thanks

ron

[Ron_Green]

This seems to be a regression isolated to 11.0.074 and 11.0.081. Curiously, 11.0.069 produces pi as output.
I also see this fixed in forthcoming version 11.1.xxx.

Please revert back to 11.0.069 - instructions http://software.intel.com/en-us/articles/older-version-product

If I have the issue number on Premier I can get more information on this bug and it's fix in 11.1. I can also see if a fix will come in future 11.0 updates.

ron

[andrpapp]

do you mean "regression isolated to 11.0.074 and 11.0.081"? or is there a 11.0.084 somewhere?
i upgraded our compilers from 10 to 11 when 11.0.074 was the latest build, so we never actually used 11.0.069. i can look into downgrading, though, assuming there is some guarantee, i.e., written report, as to what the deal is.
--> is there a place where can i read up more on the bug itself?

and when (roughly of course) would you be seeing 11.1. forthcoming?

thanks

andreas

Quoting - Ronald Green (Intel)

This seems to be a regression isolated to 11.0.074 and 11.0.084. Curiously, 11.0.069 produces pi as output.
I also see this fixed in forthcoming version 11.1.xxx.

Please revert back to 11.0.069 - instructions http://software.intel.com/en-us/articles/older-version-product

If I have the issue number on Premier I can get more information on this bug and it's fix in 11.1. I can also see if a fix will come in future 11.0 updates.

ron

[TimP]

Quoting - Ronald Green (Intel)

Please revert back to 11.0.069 - instructions http://software.intel.com/en-us/articles/older-version-product

11.0.069 was packaged with the wrong libomp_dbg.so. You might want to save the one which came with 074 or 081, or you won't be able to run idb or thread checker.

[Ron_Green]

You reported this bug Jan 30, the internal bug report was issued the same day and work began.

Our bug tracking database is on our internal intranet, you will not have access to this. The TCE for your case will keep you posted as soon as the root cause is identified and fixed. The developers appear to have narrowed down the issue, but have yet to implement a fix.

This bug may exist in the next 11.0 update. It depends on how the fix intersects with the build/release schedule for the next 11.0 update. We will know more after the developers finish their analysis.

[andrpapp]

ah, i see. at least now i know that i won't be able to know more.
i also got a premier update on the issue to participate in the 11.1 beta (testing) program. bonnie said the issue appears to be fixed in that release. i'll try to reproduce that fix some time soon and will report the results here.

thanks for getting this moving (customer information-wise)
andreas

Quoting - Ronald Green (Intel)

You reported this bug Jan 30, the internal bug report was issued the same day and work began.

Our bug tracking database is on our internal intranet, you will not have access to this. The TCE for your case will keep you posted as soon as the root cause is identified and fixed. The developers appear to have narrowed down the issue, but have yet to implement a fix.

This bug may exist in the next 11.0 update. It depends on how the fix intersects with the build/release schedule for the next 11.0 update. We will know more after the developers finish their analysis.

[andrpapp]

Bug resolved in the 11.1.016 -beta version.

My limited testing so far shows that at least the example code behaves as expected in the beta-version for the 11.1 compiler.
Using vec-report3, the complaints about too complex a data structure are gone and dependencies seem to be identified correctly.

Thanks,
Andreas