IFORT Compiler 2021.7.0 - coding syntax queries

[Stephen_Sutcliffe]

Just updated the to the latest version of oneAPI and attempted to recompile an existing fortran solution using VS2019 IFORT 2021.7.0.

This project has compiled OK in previous version but now I am getting 2 types of error displayed:

1) The arguments of the C_LOC function now have to be declared as target (or pointer) even if the /stand setting is not set.  This appears to be a correct diagnosis based upon other threads and documentation though maybe a warning might be more appropriate unless the /standard flag is set. The earlier compilers didn't complain and code worked as required.

2) the second error occurs when attempting to copy allocated data into an  allocated data structure. See following code for extracted reproducer example (also attached):

Module Test

implicit none

! Variable size
  integer,parameter :: H8 = 8

  type HDF_TABLE1
    sequence
    integer(H8)          :: id = 0 
    real(H8),allocatable :: vals(:)
    integer(H8)          :: domain = 0
  end type

  type(HDF_TABLE1),allocatable,target :: hdf_Gen(:)
  
  end module
  
  subroutine Reproducer
  
  ! Extracted variables from my project to demonstrate new "error #7828" issued by latest IFORT 2021.7.0
  
  use Test
  
  implicit none
  
  ! Variables
  real(H8),allocatable :: vals(:)
  integer :: nreal
  integer :: length
  Integer :: jcol
  integer :: ier
  integer :: i
  
  ! Set Size and Column
  length = 100
  nreal = 10
  jcol   = 4
  
  ! Allocate
  allocate(hdf_Gen(length),vals(length),stat=ier)
  if(ier.eq.0) then
    
    vals = 1.0d0
    do i = 1 , length
      allocate(hdf_Gen(i)%vals(nreal),stat=ier)
      if(ier.ne.0) goto 999
    enddo
   
    ! Copy Vals Column into Table Array
    
    ! This used to work in previous versions
    hdf_Gen(1:length)%vals(jcol) = vals(1:length)
    
    ! Now have to use this work round
!!    do i = 1 , length
!!      hdf_Gen(i)%vals(jcol) = vals(i)
!!    enddo

  else
    goto 999
  endif
  
  return
  
999 continue
    
  end subroutine 1)

The error message displayed is:

Build started...
1>------ Build started: Project: BugReport (IFORT), Configuration: Debug x64 ------
1>Compiling with Intel® Fortran Compiler Classic 2021.7.0 [Intel(R) 64]...
1>Bug_021022_test.f90
1>C:\Users\steve\Dropbox\General\BugReport\Bug_021022_test.f90(53): error #7828: The part-name to the right of a part-ref with nonzero rank has the ALLOCATABLE attribute (6.1.2).   [VALS]
1>compilation aborted for C:\Users\steve\Dropbox\General\BugReport\Bug_021022_test.f90 (code 1)
1>
1>Build log written to  "file://C:\Users\steve\Dropbox\General\BugReport\x64\Debug\BuildLog.htm"
1>BugReport - 2 error(s), 0 warning(s)

Is this error being correctly displayed and if so what is wrong with the code?

My current work around uses a simple do loop (commented out) though this may reduce performance.

Again this coding feature was not picked up in previous version of compiler and data was copied into the table array correctly.

3) I would be interested to find out if this error #7828 (or similar) is also displayed in the IFX compiler. I am not yet ready to move across IFX until it has been fully released as a production code. One reason for not moving across is that, as I understand it based upon another thread on this forum, the present function does not work on optional arguments.

Thanks

Steve

[Steve_Lionel]

Regarding the 7828 error, it is correct:

C919 (R911) There shall not be more than one part-ref with nonzero rank. A part-name to the right of a part-ref with nonzero rank shall not have the ALLOCATABLE or POINTER attribute.

It is not unusual for a new version of the compiler to detect an error that earlier versions did not. I'd guess that the restriction is there because of the rules for intrinsic assignment to allocatable arrays where you are assigning to an array of allocatable arrays.

As for C_LOC, the same applies. The standard says, "Argument. X shall have either the POINTER or TARGET attribute."

In general, you'll find the same language behavior in both ifort and ifx as they share a "front end".  Can you point to a thread suggesting an ifx problem with PRESENT? 

[Stephen_Sutcliffe]

Thanks Steve,

Requested screen shot of the post I mentioned shown below. 

It is on page 1 of the forum.

Sorry, not sure how to put in a proper link to another thread on this page. This thread may relate to older version of IFX.

I am still a bit nervous about switching over to IFX as I can see it taking weeks to getting everything compiled successfully and tested etc. I assume I'd have to recompile all associated modules (like HDF) and possibly get updated libraries from the likes of (Hexagon) MSC Software. I say this as users who interact with ABAQUS are having issues. The IFORT might see me through to retirement!  

Is my work round for copying the arrays I have adopted the best solution from a performance point of view?

Thanks

Steve

[Steve_Lionel · Accepted solution]

Yes, a loop is appropriate - that's what the compiler would have to do if it were allowed.

That thread indicates that the particular usage the user had was fixed in ifx 2022.2.0.

[Barbara_P_Intel]

Assuming the same OS (Linux or Windows) ifort and ifx object files can be used interchangeably. Same with the .mod files and libraries. You can implement ifx in steps.

See the Porting Guide for ifort Users to ifx for more information.