possible bug when transmitting arrays to subroutines

[ojacquet]

Hello,

Could you please test the attached sample program that may highlight a bug when transmitting an array to a subroutine...

Thanks a lot,

Olivier

[Arjen_Markus]

No, this is not a bug, but a very deliberate choice: the lower and upper bounds are not passed to subroutines or functions. Consider what would happen if you had a routine like this:

subroutine printit( array )
    real, dimension(:) :: array
    integer :: i

    do i = 1,size(array)
        write(*,*) i, array(i)
    enddo
end subroutine printit

This is a rather typical pattern: the index is assumed to start at 1 - as it will be in the vast majority of cases. If the (non-default) lower bound was passed to the subroutine, then ANY subroutine or function would have to be written in a fashion that takes care of such non-trivial bounds. That would be a big impact on existing code.

Regards,

Arjen

[ojacquet]

I apologize if I do not understand your answer correctly.
I would have thought that the attached program should always give 1 and 2. However this is not the case and that intrigues me.

Here are the results obtained:

test 2D array of double precisions - lbound 0, ubound 0
direct write 1.00000000000000 2.00000000000000
write after transmission 1.00000000000000 2.00000000000000
lbound - ubound 1 2

test 2D array of type TYPE1 - lbound 0, ubound 0
direct write 1.00000000000000 2.00000000000000
write after transmission 1.00000000000000 2.00000000000000
lbound - ubound 1 2

test 2D array of type TYPE2 - lbound 1, ubound 1
direct write 1.00000000000000 2.00000000000000
write after transmission 1.00000000000000 2.00000000000000
lbound - ubound 1 2

test 2D array of type TYPE2 - lbound 0, ubound 0
direct write 1.00000000000000 2.00000000000000
write after transmission 0.000000000000000E+000 6.506773410276216E-317
lbound - ubound 1 2

test 1D array of type TYPE2 - lbound 0, ubound 1
direct write 1.00000000000000 2.00000000000000
write after transmission 6.506805030477550E-317 1.00000000000000
lbound - ubound 1 2

Do you observe the same thing as me?

It seems to me your answer does not justify what I observe... 

Best regards.

Olivier

[FortranFan · Accepted solution]

@ojacquet ,

The last 2 situations appear to indicate a bug in Intel Fortran compiler.

If your purchase terms allow, please submit a support request at Intel OSC: https://supporttickets.intel.com/?lang=en-US

[ojacquet]

Hello,

This bug of Intel Fortran compiler is still present in the very last version...

Is it sill necessary to submit a support request to have the bug corrected?

I think it is not only for my personal profit, but for Intel and for all users...

Best regards,

Olivier

[Barbara_P_Intel]

Did you file a support request?  What is the case number so I can follow up?

I can file one, if you didn't.  Please let me know.

[ojacquet]

Hello,

No I did not. I would appreciate if you could do that for me.

Best regards,

Olivier

[Barbara_P_Intel]

I filed bug report, CMPLRIL0-34513, on your behalf.  I'll keep you posted on its progress to a fix.

[Arjen_Markus]

Ah, my mistake :(. My reaction was triggered by your printing the lower and upper bounds only, but you found a completely different problem.

[Barbara_P_Intel]

This bug you reported is fixed in the current release of ifort, 2021.7.0. It's part of oneAPI 2022.3 that was released last week.

Give it a try!