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

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

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 Beiträge / 0 neu
Letzter Beitrag
Nähere Informationen zur Compiler-Optimierung finden Sie in unserem Optimierungshinweis.

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

Steve - Intel Developer Support

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

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 - Intel Developer Support

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 - Intel Developer Support

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

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

Steve - Intel Developer Support

Fixed for the 15.0 release later this year.

Steve - Intel Developer Support

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

Thanks

-Zaak

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

Steve - Intel Developer Support

Kommentar hinterlassen

Bitte anmelden, um einen Kommentar hinzuzufügen. Sie sind noch nicht Mitglied? Jetzt teilnehmen