/names:as-is

[John4]

Hi,

Shouldn't the following program compile just fine with the /names:as-is option?:

program test

integer, parameter :: rdp = KIND(1.d0)
integer :: nArray
real(rdp), allocatable :: Array(:)

read(*,*) nArray; if (nArray allocate(Array(nArray))
Array = 0._rdp
write(*, '((5G13.6))') Array

end program test


The only way it works right now is by defining the parameter as RDP (not rdp).


John.

[John4]

Hi,

Probably the subject is not interesting enough to be replied, but I have an additional problem regarding /names:as-is and the bind attribute.

With /names:uppercase or /names:lowercase everything is fine, but with /names:as-is I get four errors. I've attached a solution with the reduced version of the problem I have

Did I misunderstood the purpose of such compiler flag?... I don't know.

[Steven_L_Intel1]

Well, in the new program, you've found a compiler bug, where it does not properly parse the BIND spec in the presence of /names:as_is. Please report that to Intel Premier Support.

Let me strongly suggest, though, that you not use /names in any of its guises. Especially as_is can wreak havoc with Fortran programs (for example, sqrt is not an intrinsic anymore). Use BIND or ALIAS as needed.

[durisinm]

I think you're incorrectly using integer variable nArray as a logical in the IF test of your original program. I doubt that this has anything to do with your use of the /names:as-is compile option, though.

Mike D.

[Steven_L_Intel1]

True enough (I'll assume the missing parenthesis in the IF is a typo.) You seem to be assuming C semantics for the IF test. The test as you have it is not valid standard Fortran. It will work due to an extension but won't do what you want in Intel Fortran - odd values of nArray will be considered true and even values false.

[John4]

Weird things happen when you abuse of Ctrl+Ins/Shift+Ins (or maybe it was the check spelling feature). In the *.f90 file I wrote, I have

if (nArray > 0) allocate(Array(nArray))

But I think it is invalid anyway (since the next lines make use of Array, even if it's not allocated).

And I accept the suggestion about not using /names:as-is; it seems to be full of surprises ---e.g, today I found that executable projects with the default external function calling cannot access some module components in a library build with /names:as-is (like derived-type definitions and parameters). Thanks for the help!


John.