Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Another problem with XE 2016

DavidWhite
Valued Contributor II
815 Views

I am having problems with this line of code:

NEXTBL=SUM(MAXLOC(UNITY,MASK=(NSTRM(PORT,:)==SDMXOUT)))

Unity is an array, all containing the vlaue '1'; I am searching for the location within NSTRM for the value SDMXOUT.

For the current value of PORT, the Mask is False for all entries.  In versions up to XE 2015, under these circumstances, MAXLOC would return 0; under the compiler settings for XE 2016, it is returning 1 (I assume this means that the default for old_maxminloc has changed under this version.  (Incidentally, the documentation does not specify which option [no]old_maxminloc or old_maxminloc returns 0 or 1)

David

0 Kudos
6 Replies
TimP
Honored Contributor III
815 Views

As I understood it, old_maxminloc left the result undefined for the case (including the one you cite) of a zero length array. Among the welcome changes recently has been allowing optimization without old_maxminloc. Changed results other than the case of zero length array seem wrong.  I wouldn't be totally surprised to see optimization introducing problems with the case of ties, where the required result is the first instance among ties.

0 Kudos
Kevin_D_Intel
Employee
815 Views

Can you create a small reproducer that demonstrates this behavior?

The test case I have from our previous related discussion does not exhibit any change in behavior in PSXE 2016. I also did not find any internal id about any change in PSXE 2016 to the default for old_maxminloc.

No changes were made to the documentation for MAXLOC (https://software.intel.com/en-us/node/580850) and MINLOC (https://software.intel.com/en-us/node/580875) to specify this based on the previous discussion and both continue saying only:

If array has size zero, or every element of mask has the value .FALSE., the value of the result is controlled by compiler option assume [no]old_maxminloc, which can set the value of the result to either 1 or 0.

But the documentation for the assume (https://software.intel.com/en-us/node/579519) option does say:

Under the Default section:

old_maxminloc - MAXLOC and MINLOC return 1 when given an empty array as an argument.


And under Description:

assume noold_maxminloc - Tells the compiler that MAXLOC and MINLOC should return 0 when given an empty array as an argument. Compared to the default setting (old_maxminloc), this behavior may slow performance because of the extra code needed to check for an empty array argument.

It was thought this clearly conveyed which option returned 0 and 1.

0 Kudos
Lorri_M_Intel
Employee
815 Views

David -

    Is there a chance you have a different value of -standard-semantics for the two projects?

    The assume:noold_maxminloc switch is implicitly set by -standard-semantics.

                      --Lorri

 

0 Kudos
DavidWhite
Valued Contributor II
815 Views

Here is a reproducer:

Since no value of NSTRM is equal to sdmxoutm the the MASK returns false for all entries, and I am expecting NEXTBL to be zero.  Instead it returns 1.

In reply to Lorri, I have not changed any standard-semantics settings when I installed XE2016.  My projects worked perfectly in XE2015, but not in XE2016, so there is a change in default behaviour with the new version, which is not detailed in the release notes, and is not expected.

program testmaxloc

    integerdimension(2,2) :: nstrm
    integerdimension(2) :: unity
    integer sdmxout, nextbl, port
    
    sdmxout = 3
    nstrm = 2
    unity = 1
    port = 1
    NEXTBL=SUM(MAXLOC(UNITY,MASK=(NSTRM(PORT,:)==SDMXOUT)))
    write(*,*) nextbl
end program testmaxloc

Adding /assume:noold_maxminloc to the appropriate projects resolved the problem.

 

0 Kudos
Kevin_D_Intel
Employee
815 Views

Thank you for the reproducer. Our apologies. We will investigate and to the bottom of this.

0 Kudos
Kevin_D_Intel
Employee
815 Views

I confirmed your findings David and escalated this regression to our Developers under the tracking id below. I will keep you updated on what I hear back.

(Internal tracking id: DPD200375784)

0 Kudos
Reply