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

Problems after latest 2018 Update 2

Stephen_Sutcliffe1
849 Views

I've just installed the latest update of the Visual Fortran Compiler for Windows. The installation completed with apparent no issues but when I open a project solution in Visual Studio 2015 (Update 3) the source file editor is not displaying any text. Only the file name is displayed on the tab at the top of the editor window and the remainder is blank dark blue. Resource file seem to be OK though.

Any help would be appreciated.

 

Thanks

0 Kudos
11 Replies
mecej4
Honored Contributor III
849 Views

This is probably the same issue as in https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/760883 . Please consider the solution that is suggested at https://software.intel.com/en-us/articles/how-to-fix-ms-vs2015-text-editor-is-blank-after-upgrading-intel-parallel-studio-xe .

0 Kudos
Stephen_Sutcliffe1
849 Views

Thanks for the link. It does sound like the same issue. I fixed it by uninstalling all Visual FORTRAN versions and Visual Studio and reinstalling. It took a long time and the received the work-round while in the middle of this. At least next time this happens I'll know what to try first.

Unfortunately before uninstalling to programs I rebuilt my application using the latest version of Visual Studio (2018 Update 2), as unlike the text editor the compiler worked fine, and an apparent bug introduced at Version 18 has still not been fixed in the update. I will try to get an example to reproduce this when I have time but for now I'll just stick with the latest 2017 version of the compiler. This brings to mind a couple of general observations as a user.

1) Intel used to publish all fixes, each with an ID reference, that had been addressed at each update which was great but this is no longer the case. Could these be reintroduced as the information must be available?

2) Current Intel personnel don't seem to contribute to the Forum as much as in the past (i.e. before Steve Lionel retired). BTW Steve still provides lots of valuable advice to the Intel Fortran users and long may it this continue.

It appears to me that Intel have taken their eye off the ball with regard to supporting their users.   

Sorry about the rant but is has been a very frustrating day!

0 Kudos
Devorah_H_Intel
Moderator
849 Views

Stephen Sutcliffe wrote:

  ...an apparent bug introduced at Version 18 has still not been fixed in the update. I will try to get an example to reproduce this when I have time but for now I'll just stick with the latest 2017 version of the compiler. This brings to mind a couple of general observations as a user.

Was this bug reported via Online Service Center? What is the case number? I will check the status for you and respond via Online Service Center if there is an open case with this bug report.

1) Intel used to publish all fixes, each with an ID reference, that had been addressed at each update which was great but this is no longer the case. Could these be reintroduced as the information must be available?

The list of fixes has been retired indefinitely. If you have a question regarding a specific fix or bug please submit via Online Service Center and we gladly provide you with the information, as well as answer any other questions on compiler fixes.

2)  ...It appears to me that Intel have taken their eye off the ball with regard to supporting their users.   

We continue to provide personal one-on-one support to customers who have purchased an Intel® Software Development Tools product via Online Service Center. Intel Fortran Forum is a peer forum for developers using Intel® technology.  This is the place to ask questions of and share information with other users of Intel Visual Fortran. This community forum is a good place for you to connect with other developers and technical experts as well. 

Please refer to this link for complete technical support information: Tech Support

Sorry about the rant but is has been a very frustrating day!

 Glad to hear that you were able to resolve PSXE 2018 U2 installation issue. Thank you for your feedback!

0 Kudos
Stephen_Sutcliffe1
849 Views

Hi Devorah,

I can confirm that the installation problem was fixed by clearing the files from the following folder: 

C:\Users\<your_username>\AppData\Local\Microsoft\VisualStudio\<version>\ComponentModelCache

Many thanks to mecej4 and David White for the information.

Now that I've installed Version 18.2 I am getting a problem when using the reallocate left hand side feature. This seems to no longer work as the program crashes when attempting to do this. It worked fine in the earlier Version 17 compiled applications but not in any of the Version 18 attempts. Has there been any changes to the default settings for standard-realloc-lhs.

The example where this has manifested itself consists of user defined data structures each containing a mixture of standard and allocatable data components as shown in the psuedo-code below.

! Data Structures

! Points
type NLIB_PNT
  sequence
  union 
    map
      real*8 :: p(3)
    end map
    map
     real*8 :: x = 0.0d0
     real*8 :: y = 0.0d0
     real*8 :: z = 0.0d0
    end map
  end union
end type

! Control Points
type NLIB_CTRL
  sequence
  type(NLIB_PNT) :: c         ! Coordinates
  real*8         :: w = 0.0d0 ! Weights
end type

! Knot Vector
type NLIB_KNOT
  sequence
  integer            :: m  = 0  ! Upper bound of knot vector
  real*8,allocatable :: knt(:)  ! Array for knots
end type

! NURB Surface
type NLIB_SURFACE
  sequence
  integer                     :: type   = 0     ! Surface Type
  integer                     :: de     = 0     ! Surface Index
  integer                     :: n      = 0     ! Number of Control Points -1 U
  integer                     :: p      = 0     ! Degree U
  type(NLIB_KNOT)             :: U              ! Knot Vector U
  integer                     :: m      = 0     ! Number of Control Points -1 V
  integer                     :: q      = 0     ! Degree V
  type(NLIB_KNOT)             :: V              ! Knot Vector V
  type(NLIB_CTRL),allocatable :: Pw(:,:)        ! Control Points
  integer                     :: status = 0     ! Surface Status
  integer                     :: prop   = 0     ! Special Flags
  real*8                      :: tu(2)  = 0.0d0 ! Parameter U Limits
  real*8                      :: tv(2)  = 0.0d0 ! Parameter V Limits
end type

! Trimmed Surface
type TRM_SURF
  integer            :: de = 0
  type(TRM_DATA)     :: trm
  type(NLIB_SURFACE) :: NLSf
end type

! Declarations
integer                        :: nsf
integer                        :: i
type(TRM_DATA)                 :: trm
type(NLIB_SURFACE)             :: NLSf

type(TRM_SURF),allocatable     :: trmcs(:)

! Initialise
nsf = 2

! Allocate Surface Arrays
allocate(trmcs(nsf),stat=ier)
if(ier.eq.0) then

  do i = 1 , nsf

 ! Get Surface Info
 ....
.....
  NLSf

! get Trim Curves Info
....
  trm 

    trmcs(nsf)%trm  = trm    ! Crashes here with Access Violation error. Data values in none allocatable components contain gargage values
    trmcs(nsf)%NLSf = NLSf

  enddo

endif

....
....

In my application the right hand side data structures are correctly defined (allocated) with sensible values.

For now I've only put in pseudo-code as I hope there is an obvious fix (other than reverting back to Version 17). If not I will try to create a proper reproducer.

Thanks

Steve 

0 Kudos
mecej4
Honored Contributor III
849 Views

Here is something odd about the code that you show in #5. If the allocation of trmcs(nsf) fails, IER is set to a non-zero value. Then, you proceed to store values into this variable, which has not been allocated! Did you describe the actual code correctly when you posted the "pseudo-code"?

0 Kudos
Stephen_Sutcliffe1
849 Views

Er no,

I copied bits of code from the actual application source and cobbled together the text. The statement should be if(ier.eq.0) then.

I will try to change it.

 

 

0 Kudos
Stephen_Sutcliffe
New Contributor II
849 Views

I have since been in touch with Online Support regarding this matter and they have managed to reproduce the problem in the reallocation of user defined components.  This suggests that a bug was introduced in the reallocation routine when changed at 18.0. A related issue also introduced in 18.0 where the allocation status was being wrongly returned was fixed at 18.1. I will update with Intel's findings as soon I get anything useful to report as this may lead to all sorts of weird behaviour in applications.

Steve 

0 Kudos
Stephen_Sutcliffe
New Contributor II
849 Views

The problem appears to be related to the copying of union/map components in the derived types. I use the union/map feature to enable a variety of array types to occupy the same memory. I seem to remember reading somewhere that these are being phased out in preference to the transfer() function.

A test reproducer has been sent to developers for fixing, though not sure when fix will be done.

For anyone interested the test source is attached. 

I will be interesting to see what happens in the latest beta version.

Steve

0 Kudos
Steve_Lionel
Honored Contributor III
849 Views

UNION/MAP is an extension - it should continue to work and is not being "phased out", at least not by the Intel compiler. TRANSFER can be used if you don't want to use UNION/MAP, but it can be more awkward.

0 Kudos
Stephen_Sutcliffe
New Contributor II
849 Views

I have not had any further feedback from Intel Premier Support on this issue since April, even though I requested an update two weeks ago.

I was wondering if the problem had been fixed in the latest version 2019 as I don't want to spend hours installing it if I still can't rely on it working properly.

Steve

0 Kudos
Stephen_Sutcliffe
New Contributor II
849 Views

Thanks Intel,

I finally got a response but not what I was hoping for.

"Dear Customer,

It isn't resolved in version 19.0. union and map are non-standard language extension so it is not on our priority list of fixing and no information about the time of its fix is available now."

This is very disappointing as the incorrect behaviour was introduced at version 18.0 by the Intel development team. I could understand it being a low priority if this feature had never worked properly in previous versions. Surely all issues that have been caused by an update should be high on the priority list irrespective of whether it is standard or non-standard purely on the grounds of upward compatibility. 

 

0 Kudos
Reply