Assignment of array sections

[Mark_Besley]

I am using Visual Fortran Compiler XE 15.0.0.108 [IA-32]

I am doing a simple assignment like this:

satfln(:,:,:,app) = fulsln(:,:,:,app)

Both satfln and fulsln are explicit size and shape arrays, both defined in the same module as real, dimension(0:2,2,20,8).

This assignment works fine in a debug build but when I compile with all the optimisation turned on, some elements are not assigned, e.g.

satfln(:,:,1,app) are assigned but satfln(:,:,2,app) aren't.  

Also, satfln(:,:,1:3,app) = fulsln(:,:,1:3,app) works but satfln(:,:,1:20,app) = fulsln(:,:,1:20,app) does not.  I feel like this has to be a bug in the latest Version 15.  

Can anyone shed any light on this?

Mark Besley

[Steven_L_Intel1]

We'll need to see a test case.

[Mark_Besley]

Hi Steve

Thanks for responding to this.  I fully understand you saying this but I don't think it would be feasible to provide a test case.  I could spend a long time trying to create a standalone program that tried to do the same thing and it might not exhibit the problem.

I guess that I was hoping someone might spot some silly error on my part that I could fix.

I have uninstalled Visual Fortran Compiler XE 15.0.0.108 [IA-32] and gone back to Version 14.0.3.202 that I was using previously.  The problem has disappeared.

Regards

Mark Besley

[IanH]

Note if you are working within Visual Studio you can just change the version of the compiler to use via Tools > Options, Intel Parallel Studio XE > Visual Fortran > Compilers.  If you are working at the command line you just use the relevant ifort command prompt.  Uninstallation wasn't necessary in this case.

[jimdempseyatthecove]

Can you insert a

!DIR$ NOVECTOR ALWAYS

in front of the section assignment?

If it complains about missing DO loop, then insert a dummy DO duh=1,1 loop around the statement (duh is a convenient integer variable).

Note, the section assign effectively has an implied do loop.

Jim Dempsey

[Steven_L_Intel1]

Mark,

My experience is that there is usually some additional context needed to understand a problem. The statements you show, by themselves, look fine. I am unaware of a general problem with array assignments, but it is certainly possible that the optimizer has introduced an error in the new version. It would be useful to know if the error is still there in a debug configuration (and hence without optimization.) It would be a great service to other users to get the bug fixed, if it is a bug, sooner than later, and any help you can provide would be appreciated. We'll take a large test case if you can't easily make a smaller one. Feel free to use Intel Premier Support to submit it if you don't want to do it here.

As Ian says, you didn't need to uninstall - you can switch among installed versions, See here for more information.

[Mark_Besley]

Hi Steve

I am honoured that you are looking at this issue and I know that it is difficult to resolve things like this out of context.  At this stage I can only provide the following additional information:

The two arrays are declared like this in a module:

real, dimension(0:2,2,maxlanenum,ARRAY_SIZE_LEG) :: &
fulsln, & !
satfln
maxlanenum is a constant (20) and ARRAY_SIZE_LEG is a constant (8)
 

In the subroutine where the problem occurs, the module is included with a use statement:
use approach_data

The problem occurs only when optimisation is used.  A Debug build of the program worked perfectly.

After executing the statement
satfln(:,:,:,app) = fulsln(:,:,:,app)

it seemed that every second element of the third dimension was set (as if a stride of 2 has been used).  For example in a case where app was 1
satfln(0,1,1,1) was set correctly
satfln(0,1,2,1) was NOT set correctly
satfln(0,1,3,1) was set correctly
satfln(0,1,4,1) was NOT set correctly

Other dimensions were affected similarly, e.g. second dimension in a case where app was 3
satfln(0,1,1,3) was set correctly
satfln(0,2,1,3) was NOT set correctly

Some alternative coding of the assignment statement produced interesting results

satfln(:,:,1:20,app) = fulsln(:,:,1:20,app) didn't work correctly either

But satfln(:,:,1:3,app) = fulsln(:,:,1:3,app) did work, i.e. satfln(0,1,1,1) satfln(0,1,2,1) and satfln(0,1,3,1) were all set correctly in a case where app=1

I declared a local array with the same dimension in the subroutine, e.g.
real, dimension(0:2,2,20,8) :: &
test

The assignment test(:,:,:,app) = fulsln(:,:,:,app) worked fine.

I would like to help further but I have the problem that I am just about to go on holidays for a month so I am rapidly running out of time.

Despite my belief that our support services are paid up to date, I also wasn't able to access Premier Support because it didn't think I had a copy of Fortran (it only listed VTune Analyser).

Regards
Mark Besley

[Mark_Besley]

For further information, I asked one of our programmers to try Jim Dempsey's suggestion.  This works.

With: !DIR$ NOVECTOR ALWAYS inserted, the problem does not occur.

After she removed the !DIR$ NOVECTOR ALWAYS, the problem returned. 

Regards
Mark Besley

[Steven_L_Intel1]

Mark,

I updated your support record and it now shows you as having Fortran access. When you return from holiday, please try to put together a test case for us. There's nothing we can do with an excerpt. Your experiments suggest that there is a vectorization bug that we'd like to fix for everyone's benefit.