- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
integer, dimension(2,2) :: nstrm integer, dimension(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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for the reproducer. Our apologies. We will investigate and to the bottom of this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page