- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Consider this thread - https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/698147 - where a simple example based on Note 9.48 in the Fortran 2008 working document is shown. Except for some potential confllict with some compiler option(s), the code as shown works ok with compiler 17. Note the default attribute for type-bound procedures in the example is PUBLIC which is what would apply to the generic binding for the defined derived type formatted write as well.
Now consider a slight variation where the default attribute is modified to PRIVATE and the PUBLIC attribute is explicitly applied to the generic binding. As far as I can tell looking at the standard, the code is ok but Intel Fortran compiler 17 throws an error which I think is incorrect. gfortran (GCC 7.0 development trunk that just recently has added the UDDTIO facility) compiles and works with the code.
module m implicit none type :: person character (len=20) :: name integer :: age contains private procedure :: pwf generic, public :: write(formatted) => pwf end type person contains subroutine pwf (dtv,unit,iotype,vlist,iostat,iomsg) ! argument definitions class(person), intent(in) :: dtv integer, intent(in) :: unit character (len=*), intent(in) :: iotype integer, intent(in) :: vlist(:) integer, intent(out) :: iostat character (len=*), intent(inout) :: iomsg ! local variable character (len=9) :: pfmt ! vlist(1) and (2) are to be used as the field widths of the two ! components of the derived type variable. First set up the format to ! be used for output. write(pfmt,'(A,I2,A,I2,A)', iostat=iostat, iomsg=iomsg ) '(A', vlist(1), ',I', vlist(2), ')' if (iostat /= 0) return ! now the basic output statement write(unit, fmt=pfmt, iostat=iostat, iomsg=iomsg) dtv%name, dtv%age if (iostat /= 0) return return end subroutine pwf end module m
Compiling with Intel(R) Visual Fortran Compiler 17.0.0.109 [Intel(R) 64]... m.f90 m.f90(11): error #5082: Syntax error, found IDENTIFIER 'FORMATTED' when expecting one of: = .EQV. .NEQV. .XOR. .OR. .AND. .LT. < .LE. <= .EQ. == .NE. /= .GT. > ... m.f90(11): error #6268: The keyword ASSIGNMENT or OPERATOR was expected in this context. [WRITE] m.f90(16): remark #7712: This variable has not been used. [IOTYPE] ifort: error #10298: problem during post processing of parallel object compilation compilation aborted for m.f90 (code 1)
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We'll check it out.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yep, this is a simple bug in the parsing that doesn't expect this combination. Escalated as issue DPD200414836. Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve Lionel (Intel) wrote:
Yep, this is a simple bug in the parsing that doesn't expect this combination. Escalated as issue DPD200414836. Thanks.
Steve,
Thanks.
By the way, if "this is a simple bug in the parsing", can a "quick" fix be possible?
As I mentioned in the original post, with the introduction of UDDTIO in gfortran, we were hoping to further explore and test out this standard Fortran feature in Intel Fortran with gfortran as a guide. Since almost all the derived type cases in test consideration have PRIVATE as the default attribute for type bound procedures, we can't proceed without a whole bunch of changes. Hence it will help us greatly if we are able to quickly apply the PUBLIC attribute on the generic bindings for derived type IO, as shown with the code in the original post.
Separately, is it for Intel Fortran team to consider rolling patches (in some continuous delivery mode) for "simple" bug fixes (if there is such a thing!) or completed standards related revisions following interps, so one does not have to wait several months or possibly even longer for updates?
Typically the window of attention is rather limited and once it passes, it's rather difficult to come back - previously, I'd looked in PDTs and several DP issues were escalated as a result, but the wait for resolution was longer than the development time window and the opportunity to make use of PDTs in some of the code was lost.
Thanks,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry, we don't have a mechanism in place for "rolling updates". We can provide engineering builds on a case-by-case basis, but it requires several levels of management approval.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page