- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I noticed by mistake that Intel's compiler seemingly supports using a period instead of % as a type member accessor. From reading around, I gather this is a non-standard extension. I noticed however, that it doesn't work in all cases.
Those work fine. This, however:
gives the rather unhelpful error #2 "Compilation Aborted (code 1)", at the first line in the file. In other words, whenever assigning the result of a function, the period notation is incompatible.
I can understand that perhaps ambiguities prevent it working in all cases, but surely a better error message can be produced? - at least giving the line number.
foo.bar = 3
call foo.barSub()
if(foo.barFunc(3))
Those work fine. This, however:
baz = foo.barFunc(3)
gives the rather unhelpful error #2 "Compilation Aborted (code 1)", at the first line in the file. In other words, whenever assigning the result of a function, the period notation is incompatible.
I can understand that perhaps ambiguities prevent it working in all cases, but surely a better error message can be produced? - at least giving the line number.
Link Copied
4 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Screeb,
The dot is the original VAX FORTRAN STRUCTURE/RECORD extension delimiter from 1988. When Fortran 90 adopted % as the derived type component separator, we (DEC at the time) chose to treat . and % as interchangeable in most (but not all) circumstances. Sometimes this led to bugs.
What you have encountered is an internal compiler error. The full build log should show this. You are correct that if the syntax is not to be accepted a real error message should be generated. An internal compiler error is always a compiler bug.
Would you please post a small but complete program that demonstrates the problem? I tried to construct one but it compiled ok for me. Please also show the exact compiler version you are using and the compile options.
The dot is the original VAX FORTRAN STRUCTURE/RECORD extension delimiter from 1988. When Fortran 90 adopted % as the derived type component separator, we (DEC at the time) chose to treat . and % as interchangeable in most (but not all) circumstances. Sometimes this led to bugs.
What you have encountered is an internal compiler error. The full build log should show this. You are correct that if the syntax is not to be accepted a real error message should be generated. An internal compiler error is always a compiler bug.
Would you please post a small but complete program that demonstrates the problem? I tried to construct one but it compiled ok for me. Please also show the exact compiler version you are using and the compile options.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Steve, Here's a complete example program. The compile options are the default for a console application (also has the same issue in a QuickWin project, so I don't think that makes any difference). Compiler version is 12.1.3518.2010.
Cheers
module class_toast
implicit none
public
TYPE, public :: toast
contains
procedure :: bar => toast_bar
END TYPE toast
contains
function toast_bar(this) result(baz)
class(toast), intent(in) :: this
integer baz
baz = 5
end function toast_bar
end module
module class_test
use class_toast
implicit none
public
TYPE, public :: test
type(toast) a
END TYPE test
end module
program foobar
use class_test
type(test) foo
type(toast) moo
integer baz
baz = foo.a.bar() ! ICE
baz = moo.bar() ! Works(!)
baz = foo%a%bar() ! Works as expected
end program
Cheers
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks - I can reproduce this. Note that your actual example differs significantly from the paraphrase in your original post. In particular, you need to have two levels of components. Also, the component has to be a type-bound procedure and not a procedure pointer for the failure to occur. My guess is that the compiler is getting confused by .a. which, in standard Fortran, could be a user-defined operator. The compiler has rules for trying to work out the ambiguity caused by the extension, but it is evidently failing here. I will let the developers know. The issue ID is DPD200176584.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This has been fixed for a future release. Use the standard syntax instead.

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page