- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 .
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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"?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page