Intel® Fortran Compiler 17.0 Update 2

[FortranFan]

I see forum threads of pain, bloody noses too
I see them trouble for me and you
And I think to myself what a bugful update
..
I see links of Release Notes and clouds of nothingness
The blight cursed site, the stark missing compiler fix list
And I think to myself what a nonsensical world
..
I hear Intel Fortran customers pleading, I watch them wallow
They'll suffer much more than I will ever know
And I think to myself what a wretched world
And I think to myself what a wretched world

[andrew_4619]

Haha ! I tried to sing it (an experience to be missed I can assure you) it doesn't quite scan  but still an A+ from me.

[Kevin_D_Intel]

FortranFan, as I posted in Andrew's earlier post, we understand and hear the requests for the fixes lists. Hopefully this is something we can resume in the future.

[FortranFan]

andrew_4619 wrote:

.. I tried to sing it .. it doesn't quite scan ...

:-) :-)  But my apologies, it was produced during a state of deep melancholy!  Wait until Update 3, I might have something a tad better !!?!

[FortranFan]

Kevin D (Intel) wrote:

FortranFan, as I posted in Andrew's earlier post, we understand and hear the requests for the fixes lists. Hopefully this is something we can resume in the future.

Kevin,

I appreciate your effort greatly, but I have of late become very concerned with the wrong direction of Intel software tools in some aspects such as the missing compiler fixes list but also with the status quo in many other areas (such as the state of this forum or the integration with VS, etc.) for so long now.

You know, I know, and the Fortran coders know if there is a will, things can be so much easier and convenient for customers.  Intel can easily employ an  "incident tracking database system" that is first secure, but more importantly open to customers in a selective manner depending on what they wish to disclose, and also tractable where you can add fields e.g., public/confidential/internal for defect classification, resolution target release for the version the fix goes into, etc. using which both Intel staff as well as the customers can create various reports of differing levels of detail, depending on their levels of access to the "metadata" surrounding the defects, all in a matter of nanoseconds.  Software companies that are much smaller make use of such things now.  Surely some cost and effort is required for an organization to change to something better but customers really then notice the benefits and it can make things so much more productive for everyone that management has to know such investment pays for itself soon.

I'll be frank: the system and the work process followed currently leaves a lot to be desired: a customer posts a query on the forum, the query reveals a defect (often thanks to countless hours by unpaid volunteers), then the defect becomes an incident with an invisible state in terms of progress for an unknown period following which (this can even be years) an Intel analyst might post on the forum that the incident will be fixed in an unnamed future release, followed by y amount of time where the incident is finally fixed or a notice becomes available of the fix in a particular release.  In the meantime, patch versions come out such as 17.0 Update 1 and now 2 where there are NO release notes for Fortran (and C++ compiler); the customer has no idea what, if anything useful at all, is included in that update; and then finds out things are broken in their development environment.  This is highly unproductive to say the least for both the customers and the support staff, Intel can surely do better.  Solutions are available and they are in use by other software organization.  All I can surmise is a lack of willingness and/or a sheer failure of imagnation on the part of Intel software product management teams to want to do continuously better and to constantly improve the customer experience.

I am worried the missing compiler fixes list issue could be emblematic of something directional or tatical.  But if one were to accept the rationale about the large amount of time it takes to put it together, then, as I state above, Intel can adopt a system and a work process whereby such a list can be generated by the tracking database with manageable effort.  In this age of "big data" where even highschoolers are putting together and analyzing large datasets using anything from Excel VBA to Hadoop (I was at a school science fair event this weekend to notice this firsthand), the stated reason does not place a software team in a good light.

[jimdempseyatthecove]

Here, Here!

Excellent prose on the sentiments of we loyal users of Intel Software products. I hope that the management team of Intel Software Development pays attention to well thought statements like this, and more importantly, take effective action to improve on the process of incident tracking.

Jim Dempsey

[Kevin_D_Intel]

I gathered the feedback up and rolled it up to management. Thank you all the candid feedback.

FortranFan, the lack of a fixes list is mostly emblematic of the loss of staff resources and a mostly manual (time consuming, probably antiquated too) process of scrubbing content. I’m sure it could be improved and am hoping we can do so on short order.

[FortranFan]

Kevin D (Intel) wrote:

.. the lack of a fixes list .. could be improved and am hoping we can do so on short order.

Kevin,

Any progress on the communication of changes in Update 2 of 17.0 compiler?  As threads such as the one linked below keep popping up,

https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/702487

Intel software product management teams have to realize the situation is untenable.  From a product stewardship point-of-view, customers need to be informed at least of some summary of revisions, fixes, etc. in an update, if not a comprehensive listing of everything that has changed which will be most welcome of course.  Intel Fortran team at the very least should provide some indication to the customer on:

1. What is new and/or different with Fortran compiler in an Update.
2. The sort of bug fixes and an idea of the magnitude of these fixes

It takes considerable time and effort to migrate from one update to another and how can one do so blindly without knowing the benefits such as whether it is only a couple of bug fixes related to some specific area (say OpenMP) that have been addressed (of little interest to us in that case) or it is a broad slew of resolutions related to Fortran 2003 and newer standard revisions and with code optimization and VS integration, etc. (in which case, it may be worth to us to consider the migration)?  From what I can find, no such information is available to customers on Update 2 (and also Update 1), am I mistaken?  A few bullets or sentences or a paragraph or two on the update will be beneficial for the customers.

Thanks,

[Kevin_D_Intel]

Nothing at this moment. I’m sorry. I appreciate everyone’s continued patience.  I wanted to have something before this reply but that wasn't possible. I’m trying for a summary of Fortran specific fixes.

[Kevin_D_Intel]

I publish a partial fixes list (here) for Parallel Studio XE 2017 Update 2 Composer Edition. This is only a partial list of fixes and feature requests specific to the Fortran Front-end for PSXE 2017 Update 2.

The Fortran compiler RNs have a minor revision about the new DIR$ VECTOR [NO] MASK_READWRITE clause support in Update 2. (The revised RNs are unable to be published at this time due to an IDZ glitch). The content in that minor revision is replicated below.

Support for DIR$ VECTOR [NO] MASK_READWRITE clause enables/disables memory speculation by the vectorizer.

MASK_READWRITE | NOMASK READWRITE

       Enables or disables the generation of masked load and store operations within conditional statements.

       The MASK_READWRITE clause directs the compiler to disable memory speculation, causing the generation of masked load and store operations within conditional statements

       The NOMASK_READWRITE clause directs the compiler to enable memory speculation, causing the generation of unmasked loads and stores within conditional statements.

[jimdempseyatthecove]

Kevin,

When neither is supplied, does the compiler generate runtime checks to see if masked instructions are supported?

Their may be a need to have a directive to check for availability of masked instructions, if available to use them, else fall back to the non-masked instructions.

Jim Dempsey

[Kevin_D_Intel]

The User’s Guide says in the absence of the VECTOR directive the compiler uses default heuristics and it it may determine/assume masked instructions are supported based on the –x<arch>/-ax<arch> option (or default in the absence).  I'll get some clarification.

[Johannes_Rieke]

Dear Kevin,

would it be possible to extend this list (https://software.intel.com/en-us/articles/intel-parallel-studio-xe-2017-composer-edition-compiler-fixes-list) for the fixes of PSXE 2017 update 4. The ICE in conjunction with constants and /debug-parameters /debug options is solved and mentioned in the release notes (at least in the htlm version). That's fine.

That would be great.

[Kevin_D_Intel]

We will certainly try to.