- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
![](/skins/images/B7BA37F9CE4B52FF7CAE1FB0388839C8/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page