Using XE2017 with the shell version of VS, I am getting a subscript 0 error on accessing an array section.
I am referring to TFLOW(NOSD(1:6)). When I attempt to display this in the debugger, it is also returning invalid subscript, while the individual references are all good:
tflow(nosd(1:6)) Subscript out of range
- nosd(1:6) (1:6) INTEGER(4)
nosd(1) 45 INTEGER(4)
nosd(2) 46 INTEGER(4)
nosd(3) 47 INTEGER(4)
nosd(4) 48 INTEGER(4)
nosd(5) 49 INTEGER(4)
nosd(6) 50 INTEGER(4)
- tflow(45:50) (45:50) REAL(8)
tflow(45) 37.1799413678762 REAL(8)
tflow(46) 182.845277103799 REAL(8)
tflow(47) 1.90446078777313 REAL(8)
tflow(48) 1.36296749114990 REAL(8)
tflow(49) 4.99094438552856 REAL(8)
tflow(50) 0.000000000000000D+000 REAL(8)
Why is tflow(45:50) OK while TFLOW(NOSD(1:6)) is not, even though the values of NOSD(1:6) are 45, 46, ... 50?
This code has not been touched, and was previously working.
Ok, I have a work around.
instead of TFLOW(NOSD(1:NSEED)), I can use (TFLOW(NOSD(I)),I=1,NSEED)
INTEGER, PARAMETER :: NSEED = 6
INTEGER :: NOSD(NSEED)
REAL(KIND=KIND(0D0)) :: TFLOW(99)
1. Is my first version valid Fortran?
2. If not, why did it work before and not now?
3. Are there any compiler switches that previously made this work, which have changed to break it?
I think it is the same issue you reported in https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/698697
Intel Customer Support
As far as the VS integration is concerned, it is the same issue.
While my comments earlier regarding runtime errors appears to be the same, somehow, I had previously got around this with XE2017, as far as I am aware. I am now seeing runtime fatal errors since the array index is being computed as 0 instead of 45-50 as expected.
This has arisen now, in part, as I am trying to migrate to a new machine.
Using a small sample code based on your code lines I can get the runtime error only with "/check:bounds" options applied. I will open a bug report for it. As a workaround you can disable this option.
Intel Customer Support
Thank you for that resolution for this issue. I have confirmed that this array bound issue no longer arises when bound checking is turned off. Over the last few weeks, it is probable that I have only built the Release version of my code, which did not include bounds checking. This is how I have been able to run with XE2017 and not have the problem arise.