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

change in default return value for zero size minloc?

abhimodak
New Contributor I
1,077 Views

Hi

The snippet below when used with IVF in composer-XE 2015 update 2 package 179 (and many versions before) and when used with 2017 update 4 through 2018 update 1 produces opposite results --- when using just "ifort".

In 2018 update 1, /assume:no_oldmaxminloc gives 0 and /assume:oldmaxminloc yields 1. Whereas in 2015 update 2, either switch gives 0. I believe, as per Fortran 2003, 0 is the correct result. However, it seems that the "default" value has changed...

Abhi

--

Program Test

Implicit None

Integer :: J(3), L(1)

J = [1, 2, 3]

L = minLoc(J, Mask=(J > 4))

print *, L(1)

End Program Test

0 Kudos
13 Replies
andrew_4619
Honored Contributor II
1,077 Views
0 Kudos
abhimodak
New Contributor I
1,077 Views

Hi Andrew

Thanks for the link. I had seen it; but the question raised by Tim P there seems to have gone unanswered. That is, up until XE2015 update 2, the returned result was correctly 0 "without" any additional compiler switch. (In fact, that flag seems to be no working at all.) With the new compiler the default behavior is now to return 1. And one can imagine it causing a lot of problems; and hence wondering if some Intel folks can respond.

Abhi

0 Kudos
Steve_Lionel
Honored Contributor III
1,077 Views

The default hasn't changed - it is still oldmax_minloc so that 1 is the expected return for an empty array. There may have been a bug in the 2015 version. Use /standard-semantics if you want to select F2003 semantics.

0 Kudos
abhimodak
New Contributor I
1,077 Views

Hi Steve

It wasn't just the 2015 compiler...It was so in 2013, 2011 as well; I don't have all the versions but the default behavior has been to return 0 since about the year 2009 compiler --- whatever version that was called. (I also don't think that the documentation had the line that talks about returning 1 and 0 in earlier versions; but I am not so sure of that.)

I am not sure if the usage of /standard-semantics would be a solution; I think there are things like automatic rhs allocation which are standard F2003 but that wouldn't be the default. Correct? Using /standard-semantics would turn that on; I think. (That is, the default is /assume:norealloc_rhs but default doesn't seem to be /assume:noold_maxminloc.)

Nevertheless, coming to today, where can I find a document that lists the bugs fixed and/or changes to the defaults? Certainly, it would be a probably too big one but since we are going to upgrade the compiler to the current one and since there are issues like this we probably would be better off to dig through such a list; if one exists.

Abhi

0 Kudos
abhimodak
New Contributor I
1,077 Views

Hi Steve

Did you get a chance to look through when/why the default got changed?

Abhijit

0 Kudos
Steve_Lionel
Honored Contributor III
1,077 Views

As I wrote above, the default has not changed. My ability to research such things is extremely limited now, but I see that the 18.0 default is the same as it always was. I raised the possibility of bugs in earlier versions that might have led to inconsistent results.

0 Kudos
abhimodak
New Contributor I
1,077 Views

Hi Steve

Thanks. As I wrote earlier, we see that the default has indeed changed ---after something like 10 years. We have XE2011, 2013,and 2015 editions all returning [0] "by default" -- meaning when using just "ifort" and no other compiler flag. I will see if I get anywhere through the premier support. Thanks again.

Abhijit

0 Kudos
andrew_4619
Honored Contributor II
1,077 Views

Anhimodak I read the thread and what you are saying is far from clear to me. The correct behaviour with no options is to return 0 which versions specifically do not do that in your experience? Further what are you trying to achieve? Surely you need to modify your code so that it is standard conforming irrespective.

0 Kudos
Steve_Lionel
Honored Contributor III
1,077 Views

Here is the behavior I see with 18.0.1, which is what I expect, and I believe is consistent with earlier versions:

integer a(10)
a = [1,2,3,4,5,-44,7,8,9,10]

print *, minloc(a)
print *, minloc(a,.false.)
print *, minloc(a(1:0))
end
D:\Projects>ifort t.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, 
Version 18.0.1.156 Build 20171018
Copyright (C) 1985-2017 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 14.12.25834.0
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:t.exe
-subsystem:console
t.obj

D:\Projects>t.exe
           6
           1
           1

D:\Projects>ifort /standard-semantics t.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, 
Version 18.0.1.156 Build 20171018
Copyright (C) 1985-2017 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 14.12.25834.0
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:t.exe
-subsystem:console
t.obj

D:\Projects>t.exe
 6
 0
 0

D:\Projects>

 

0 Kudos
abhimodak
New Contributor I
1,077 Views

Attached is a screenshot showing the behavior.

0 Kudos
Steve_Lionel
Honored Contributor III
1,077 Views

The default hasn't changed but the behavior has. I would say this is a compiler bug. Please report it.

0 Kudos
Lorri_M_Intel
Employee
1,077 Views

We did fix a bug in V16.0 where assume:noold_maxminloc was not being correctly interrogated when there was a  MASK argument, but no DIM argument.

Your program in the screen-capture exactly demonstrates that circumstance.

There is no publicly-available list of fixed bugs, sorry.

          Hopefully this helps --

                                       --Lorri

 

0 Kudos
abhimodak
New Contributor I
1,077 Views

I think the following captures it:-

(1)The  "default" is (or has always been) /assume:old_maxminloc. And that would mean that result of the test-program would be "1" --- as per the documentation.

(2)XE2015-update2-package-79 (and previous versions; as I mentioned in my earlier posts, it was like that all the way back to 2009) gives the result as "0" for the test-case since it is not using the "DIM". This is/has-been the case regardless of whether /assume:noold_ or  /assume:old is used.  And that is/was the bug!

I see that the "current" documentation is now making a clear mention of the result being dependent on the /assume switch; it wasn't there earlier either -- so nice to see that happen. If I may suggest, perhaps it would be a good idea to include what the "default" option in the line immediately after this is mentioned.

Abhi

 

 

0 Kudos
Reply