Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
55 Views

Intrinsic Assignment of UDTs with Allocatable Components (repeat)

Jump to solution

Attached example executes without error if compiled with IVF 17.0.2.187, but fails when compiled with 18.0.0.124 or 19.0.0.203.

Failure with this exact code is an "access violation". I have been experimenting with this problem on my main code for the last 2 days, and various error modes can occur, depending on presence or absense of SEQUENCE, Padding, and allocatable attribute of AFL. I have tried it with and without /standard-realloc-lhs. Sometimes the assignment completes with no error, but the APRES array is full of garbage. 

From my reading of the 2008 Fortran standard, it appears that the assignment is legal. But I may be wrong.


This is a repeat of a posting I attempted yesterday, with my corporate login ID. I have reverted to my original login to try again, coz I can't see the original posting in the forum. (I know it exists "somewhere", see topic 812391)

0 Kudos

Accepted Solutions
Highlighted
Moderator
55 Views

This is fixed in PSXE 2020.  Compiler version 19.1

View solution in original post

0 Kudos
8 Replies
Highlighted
Beginner
55 Views

Oops, the correct version for the 2019 compiler is 19.0.3.203.

0 Kudos
Highlighted
Honored Contributor I
55 Views

@Colin W.,

The access violation error occurs with 19.0 Update 4 as well.  You may want to submit a request at Intel Support Center: https://supporttickets.intel.com/servicecenter?lang=en-US.

Toward a workaround, have you considered doing away with SEQUENCE attribute on your derived types?  Do you really need this?  If your interest is interoperability, have you looked at BIND(C)?  By the way, the error above appears to be avoided without SEQUENCE.

0 Kudos
Highlighted
Beginner
55 Views

Hi FortranFan

Thanks. Alas removing SEQUENCE doesn't fix it for me, failure looks the same.

In fact I only added SEQUENCE in my real application when trying to fix it there, before I resorted to creating this cut-down demo program for posting here. I don't need it, and neither do I need most of the padding. But as I originally said, the exact failure mode in my real app is different, depending on presence or absence of SEQUENCE and padding. Sometimes it runs without error, but the copied values in APRES are garbage. Or it doesn't allocate APRES. Or other bits of the structure are not copied at all.  Or...  

Yes I may wind up submitting a support request. But I wanted to ask here first because I find this forum is very quick to come up with potential fixes, and/or to spot silly errors.

0 Kudos
Highlighted
55 Views

>> If your interest is interoperability, have you looked at BIND(C)? 

The structure layout in the Fortran domain and C domain must be the same. BIND(C) does not necessarily assure this, neither does SEQUENCE for that matter.

When a C struct is compiled under the guise of __attribute__((__packed__)), then BIND(C) won't necessarily work whereas in this case SEQUENCE would work. (same issue with #pragma pack(1))

On the other hand, when naturally aligned packing is in effect on the C side, the BIND(C) on Fortran side should work.

Jim Dempsey

0 Kudos
Highlighted
Honored Contributor I
55 Views

Colin W. wrote:

Hi FortranFan

Thanks. Alas removing SEQUENCE doesn't fix it for me, failure looks the same.

In fact I only added SEQUENCE in my real application when trying to fix it there, before I resorted to creating this cut-down demo program for posting here. I don't need it, and neither do I need most of the padding. But as I originally said, the exact failure mode in my real app is different, depending on presence or absence of SEQUENCE and padding. Sometimes it runs without error, but the copied values in APRES are garbage. Or it doesn't allocate APRES. Or other bits of the structure are not copied at all.  Or...  

Yes I may wind up submitting a support request. But I wanted to ask here first because I find this forum is very quick to come up with potential fixes, and/or to spot silly errors.

Based on a quick glance, I don't notice any errors.  Besides gfortran processes your code as expected.  It appears an issue with Intel Fortran compiler - see below, with SEQUENCE removed, you can see the access violation error is avoided when /traceback compiler option is in effect but the results are wrong.  This does look like an immediate case for Intel support team to address:

C:\Temp>ifort /standard-semantics /warn:all /stand:f18 /traceback p.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 19.0.4.245 Build 20190417
Copyright (C) 1985-2019 Intel Corporation.  All rights reserved.

p.f90(32): warning #5268: Extension to standard: The text exceeds right hand column allowed on the line.
        real(8)                       :: ref_temp      = runset       ! temperature reference for the measurement, used to correct the
------------------------------------------------------------------------------------------------------------------------------------^
p.f90(61): warning #5268: Extension to standard: The text exceeds right hand column allowed on the line.
        type(t_meas)                  :: mass_rate                    ! calculated value and weight, see bo_fluids_mod for calculation
------------------------------------------------------------------------------------------------------------------------------------^
p.f90(142): warning #5268: Extension to standard: The text exceeds right hand column allowed on the line.
        type (t_dovcalib)  :: dov_calib                       ! Dead oil Viscosity correlation and calib data, for temperature dependence
------------------------------------------------------------------------------------------------------------------------------------^
p.f90(171): warning #5268: Extension to standard: The text exceeds right hand column allowed on the line.
        real(8)            :: gas_jt   = 0.07                 ! K/Pa, == 0.07 F/psia, AGA approximation (www.aga.org/Kc/glossary/Pages/J.aspx, needs user login). also 4.655e-6.
------------------------------------------------------------------------------------------------------------------------------------^
p.f90(222): warning #5268: Extension to standard: The text exceeds right hand column allowed on the line.
        type(t_measurement), allocatable :: measurement       ! measured values of P, T, VFG/O/W, plus some more things not directly applicable to fluids
------------------------------------------------------------------------------------------------------------------------------------^
p.f90(234): warning #5268: Extension to standard: The text exceeds right hand column allowed on the line.
        real(8) :: pRsO           = runset       ! "potential" Rs: gas that would disolve in the oil phase              std.vol/std.vol
------------------------------------------------------------------------------------------------------------------------------------^
Microsoft (R) Incremental Linker Version 14.21.27702.2
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:p.exe
-subsystem:console
-incremental:no
p.obj

C:\Temp>p.exe
 1.00000000000000 2.314613762410916E-152 1.755752353798156E+199
 -4.587255188532077E-246 5.812407954208153E+180

C:\Temp>gfortran -Wall -std=f2018 p.f90 -o p.exe

C:\Temp>p.exe
   1.0000000000000000        2.0000000000000000        3.0000000000000000        4.0000000000000000        5.0000000000000000

C:\Temp>

 

0 Kudos
Highlighted
Black Belt Retired Employee
55 Views

Your original post is now visible at https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/812391

0 Kudos
Highlighted
Moderator
55 Views

I have the bug report in Premier Support.  I'll send in a problem report.

0 Kudos
Highlighted
Moderator
56 Views

This is fixed in PSXE 2020.  Compiler version 19.1

View solution in original post

0 Kudos