generic assignment with type bound procedure and derived type giving odd warning

generic assignment with type bound procedure and derived type giving odd warning

Portrait de Izaak Beekman

I am using a Beta version to test this, specifically:

ifort (IFORT) 14.0.0 20130416

I have a string module which defines a string_t type with private components, in a stringhelper_m private module (save a few public entities like the string_t type, and some procedures/overloaded intrinsics for working with C strings. When I instantiate a string_t object and use my overloaded assignment operator in a unit test (which USEs stringhelper_m) and try to assign a character litteral (via my defined/overloaded assignment) I get the following compile time warning:

stringhelpertests.F90(41): warning #6931: Fortran 2008 does not allow this assignment statement. ['How are you']
 testvar1 = 'How are you'

The assignment operator should be resolving to:

elemental subroutine AssignChars(lhs,rhs) 
class(string_t) ,intent(inout) :: lhs 
character(*) ,intent(in) :: rhs 
lhs%string = rhs
 end subroutine

The code was compiled with the -warn -stand f08 and -assume reallocate_lhs flags. Am I indeed violating the 2008 standard here? If so, why? If not, then I think this is a bug. I am on OS X using CMake, and CMake's testdriver/harness which is provided in C by CMake.

Sources and CMakeLists.txt to build is attached.

Thanks,

Zaak

-Zaak
10 posts / 0 nouveau(x)
Dernière contribution
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.
Portrait de Steve Lionel (Intel)

Please use Intel Premier Support for all issues related to the beta.  Thanks.

Steve
Portrait de Izaak Beekman

EEEEK, Sorry!

Edit: Also could someone tell me if my code is standard compliant or not? I *think* it is, but I'm not 100% sure.

-Zaak
Portrait de Steve Lionel (Intel)

The 13.1 compiler gives the same complaint, and I think the compiler is wrong to do so. I will let the developers know.

Steve
Portrait de Steve Lionel (Intel)

I have escalated this as issue DPD200244417. I see the problem when assigning a string but not an integer (in a smaller example I wrote.)

Steve
Portrait de Izaak Beekman

Hi,

I found an error in my code (it does not comply with the standard and is not correct), which I think an additional feature-request or bug-report should be submitted for, assuming I am correct in saying that the following subroutine violates the standard:

elemental subroutine Assign(lhs,rhs)
 class(string_t) ,intent(inout) :: lhs
 class(string_t) ,intent(in) :: rhs
 if ( rhs%istempfnresult ) then
 call move_alloc(from=rhs%string,to=lhs%string) !This might be illegal for intent(in)
 else !use F2003 allocate on assignment
 lhs%string = rhs%string
 end if
 end subroutine

I think it should be illegal for rhs or a component of rhs to appear in the move_alloc call, since it is intent(in). Ifort Version 13.0.2.171 Build 20130314 compiles this code without warning or error (even though -warn is supplied on the command line). If this is indeed code that violates the standard and you think it makes sense to submit a bug-report or feature-request please do so.

-Zaak
Portrait de Steve Lionel (Intel)

I agree - the compiler should give an error here.  Issue number is DPD200244422.

Steve
Portrait de Steve Lionel (Intel)

Fixed for the 15.0 release later this year.

Steve
Portrait de Izaak Beekman

Both DPD200244417 and DPD200244422? Are the fixes likely to make it into the beta?

Thanks

-Zaak
Portrait de Steve Lionel (Intel)

Both are fixed. DPD200244422 is likely to make the next beta update, I'm not sure about DPD200244417 but it seems likely.

Steve

Connectez-vous pour laisser un commentaire.