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.



10 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

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

Retired 12/31/2016

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.

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

Retired 12/31/2016

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.)

Retired 12/31/2016


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 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.

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

Retired 12/31/2016

Fixed for the 15.0 release later this year.

Retired 12/31/2016

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


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

Retired 12/31/2016

Leave a Comment

Please sign in to add a comment. Not a member? Join today