Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29342 Discussions

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

Izaak_Beekman
New Contributor II
1,125 Views

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

[plain]ifort (IFORT) 14.0.0 20130416[/plain]

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:

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

The assignment operator should be resolving to:

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

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

0 Kudos
9 Replies
Steven_L_Intel1
Employee
1,125 Views

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

0 Kudos
Izaak_Beekman
New Contributor II
1,125 Views

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.

0 Kudos
Steven_L_Intel1
Employee
1,125 Views

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

0 Kudos
Steven_L_Intel1
Employee
1,125 Views

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

0 Kudos
Izaak_Beekman
New Contributor II
1,125 Views

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:

[fortran]

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

[/fortran]

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.

0 Kudos
Steven_L_Intel1
Employee
1,125 Views

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

0 Kudos
Steven_L_Intel1
Employee
1,125 Views

Fixed for the 15.0 release later this year.

0 Kudos
Izaak_Beekman
New Contributor II
1,125 Views

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

Thanks

0 Kudos
Steven_L_Intel1
Employee
1,125 Views

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

0 Kudos
Reply