change in default return value for zero size minloc?

[abhimodak]

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

[andrew_4619]

look at https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/536614

[abhimodak]

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

[Steve_Lionel]

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.

[abhimodak]

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

[abhimodak]

Hi Steve

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

Abhijit

[Steve_Lionel]

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.

[abhimodak]

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

[andrew_4619]

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.

[Steve_Lionel]

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>

[abhimodak]

Attached is a screenshot showing the behavior.

[Steve_Lionel]

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

[Lorri_M_Intel]

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

[abhimodak]

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