- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please use Intel Premier Support for all issues related to the beta. Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The 13.1 compiler gives the same complaint, and I think the compiler is wrong to do so. I will let the developers know.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I agree - the compiler should give an error here. Issue number is DPD200244422.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Fixed for the 15.0 release later this year.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Both DPD200244417 and DPD200244422? Are the fixes likely to make it into the beta?
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Both are fixed. DPD200244422 is likely to make the next beta update, I'm not sure about DPD200244417 but it seems likely.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page