ifx does not honor INTENT(IN) check

[OP1]

I believe that in the following code (built with ifx 2026.0.0 on Windows), the compiler should issue an error to indicate that the argument STAT_ARG does not have the proper INTENT.

The documentation for CO_BROADCAST indicates that the stat argument of that intrinsic subroutine has the INTENT(INOUT) attribute (which makes sense, of course). Here, the subroutine S declares STAT_ARG has having INTENT(IN) only. The compiler should catch this.

PROGRAM P
IMPLICIT NONE

INTEGER :: I[*], STAT
CALL S(I, STAT)

CONTAINS

SUBROUTINE S(I_ARG, STAT_ARG)
IMPLICIT NONE
INTEGER, INTENT(IN) :: I_ARG[*], STAT_ARG
CALL CO_BROADCAST (I_ARG, 1, STAT_ARG)    
END SUBROUTINE S

END PROGRAM P

[JohnNichols]

If you look at the logic as a path, the path leads one way into S, then S calls cobroadcast and says I want a back answer

You get an answer and then throw it away.  That is ok you are allowed to write such code.

You have done nothing with the back answer, the compiler cannot tell your intent but it has done exactly what you want.  

So if the compiler signaled a warning that said what are you going to do after line 12, then I would be amazed.  

[JohnNichols]

Why not these is nothing wrong with passing only a value into S, you could use it in S.  But not pass it back, but you would need the compiler to make correct copies.

[Steve_Lionel]

The issue here is NOT the call to S, but rather the call to CO_BROADCAST. The STAT argument to CO_BROADCAST is INTENT(OUT), which specifies that the effective actual argument (STAT_ARG) will become undefined on entry to the called procedure, but because STAT_ARG is INTENT(IN), that's not allowed. A compiler is not required to check this, but every Fortran compiler I know of, including Intel's, does (usually). This case shows unintended behavior of the compiler.

[JohnNichols]

I followed the Intel Method to set up co-arrays, it gave me a could not find impi.lib

I added the path for the library in the dependencies it did not work , I added it to path and got this.  

They are not easy to set up. 

Any ideas on what I did wrong?

[JohnNichols]

I am using a standard VS Setup with Project Folder etc.. That is a generic error you see from time to time.  

[Steve_Lionel]

I agree with @OP1 that the compiler should diagnose this. An INTENT(IN) dummy is not allowed to be an actual argument corresponding to an INTENT(OUT) argument.

[Steve_Lionel]

Well, one thing you're doing wrong is using the boot drive's root folder to do your builds - the compiler can't write an object to that. Do this from a writable folder elsewhere on the disk. I have a Projects folder I use for this purpose.

[Steve_Lionel]

I'm just going by what minimal information you provided - the issue of the linker not finding the object because someone did the compile in a protected folder is one I have seen many times from users. I've never once seen a VS project do this when outside of the system folder tree. Given the error message explicitly says it is looking for the object in C:\, I continue to suspect a misconfiguration on your part.

How about attaching a zip of the buildlog.htm?

[JohnNichols]

[Steve_Lionel]

The filespec of impi.lib is not quoted, so the CLI stops at the space in "C:\Program FIles". I don't know what put that in there.