error #7374 still in ifort 11.1 20100203

[vandelstp]

Hello,

Is there any further information about a fix for the error that causes the

"error #7374: F95 standard requires all arguments be of the same type and same kind type parameter."

errors? Kevin Davis replied to an earlier question about this in Feb09 stating that it would fixed in the summer09 v11.1 release (internal ref. CQ-109905)

I got an eval copy of ofort installed today and I'm still getting this error:

[bash]Type_Kinds.f90(78): error #7374: F95 standard requires all arguments be of the same type and same kind type parameter. [1]
INTEGER, PARAMETER :: LLong = ((( 1 + SIGN(1,LLong_t)) / 2) * LLong_t) + &
-------------------------------------------^
Type_Kinds.f90(79): error #7374: F95 standard requires all arguments be of the same type and same kind type parameter. [1]
                              ((( 1 - SIGN(1,LLong_t)) / 2) * Long )    
-------------------------------------------^[/bash]

The declaration of LLong_t is

[bash]INTEGER, PARAMETER :: LLong_t = SELECTED_INT_KIND(16)[/bash]

so all the arguments of the SIGN() function above are of the same type (INTEGER) and kind type parameter (default).

Thanks for any information/updates.

cheers,

paulv

[Steven_L_Intel1]

I remember this one and am fairly certain that it is fixed for Update 6, scheduled for April. I just saw it last month. Can you point to the post where it was discussed in 2009?

[Kevin_D_Intel]

The 2009 reported instance(here: http://software.intel.com/en-us/forums/showthread.php?t=61732) was fixed in the initial 11.1 release and remains fixed today.

Steve can correct or extend, but looks to me the error is correct in your case because in line 3 of the snippet, the constant 1 specified the SIGN intrinsic reference

SIGN(1,LLong_t)

lacksthe required "_<kind>"specifier; therefore,its type (defaults to KIND(4)) is not the same as the type specified in the second argument (KIND(16)).

If you type the constant as 1_LLong_t then you will not receive this error.

[Steven_L_Intel1]

Kevin - the value of Llong_t is 16 but its type and kind is default integer. I too was initially confused when I first saw this test case.

The issue in this thread is DPD200151083. It has not yet been fixed in our 11.1 stream - I will add this as another report.

Is this from some open-source software package? The three reports I have seen of the error (a standards warning, really) are all using identical sources.

[vandelstp]

Hi Steve,

This code is from a radiative transfer model we develop here at NCEP/EMC (part of NOAA) for use in computing satellite radiances. But, it is based upon a common technique to dynamically select kind types when a requested one isn;t available (suggested by JvB on comp.lang.fortran)

One of our other users (who has an intel 11.1 compiler) discovered the problem. I posted about this to c.l.f but later retracted when the user in question (mistakenly) said they were using the wrong/different compiler.

Note that earlier versions of the intel compiler did not have this problem with this particular piece of code (which hasn't changed for many years.)

Is there a workaround that the Intel compiler folks are aware of so that we can continue our work before the evaluation license expires?

cheers,

paulv

[Steven_L_Intel1]

Paul,

This is a standards warning only, so it would not come out unless you asked for standards checking (-std). Also, it seems you have enabled the "warnings are errors" option. Disabling either of those should allow you to proceed.