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

Percent sign versus period (bug?)

Screeb
Beginner
2,205 Views
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.

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.
0 Kudos
4 Replies
Steven_L_Intel1
Employee
2,205 Views
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.
0 Kudos
Screeb
Beginner
2,205 Views
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.
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
0 Kudos
Steven_L_Intel1
Employee
2,205 Views
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.
0 Kudos
Steven_L_Intel1
Employee
2,205 Views
This has been fixed for a future release. Use the standard syntax instead.
0 Kudos
Reply