Who is supporting the "6.6C" update to CVF?

[lklawrie1]

I shouldn't have installed it....

While the new standards checking "may" be okay, the error message I get on the following:

Format(....I2.2)

"The field width is too small for the number of fractional digits"

is unacceptable.

Looking around -- I see the only link to this update is on this forum. Hence my question -- who authored and is supporting this update?

Linda Lawrie

[Steven_L_Intel1]

Up to this point, it's the same folks who have been doin CVF all along. There does seem to be a problem in that incorrect diagnostic checks are getting added - this one I know is fixed and yes, another 6.6C update will be out soon (in fact, it may be up on the site Monday.) This is the last one, really, I mean it...

I'll take it as a personal "action item" to get independent review of new diagnostics to prevent further problems such as this one. We apologize for the inconvenience.

[lklawrie1]

Hey, I'll even try to "test" it on my many lined and moduled source that runs on several compilers -- our release version is CVF.

Linda

[Jugoslav_Dujic]

If I may suggest naming it 6.0 D? Earlier 6.6C stillborns would certainly create a confusion, especially for you... I can imagine the following scenario in tech support:

- Type "df /what" in the command line. Which version does it give?

- 6.6C.

- Um.... err... which 6.6C?

:-)

Jugoslav

[Steven_L_Intel1]

It's actually a pain to do that, but I'll see what I can do.

[lklawrie1]

As I understand this (now), you were asking the forum to more or less preview this modification. As such, I would stick with the 6.6C designation. As I said in the message that started this thread, I could find no evidence of 6.6C except here in your messages (and links).

Linda

[Steven_L_Intel1]

Hmm - the I2.2 bug isn't fixed after all. Well, darm...

[Steven_L_Intel1]

Sigh. The introduction of the warning bug was a side effect of adding a diagnostic for something like F3.2. The engineer who made the change didn't notice (and we didn't have any tests for this) that it also affected the integer formats.

I have reported this to engineering, but it won't be fixed for CVF.

[lklawrie1]

Hard to believe that it won't be fixed.

Hopefully, nothing significant is contained in 6.6C but I'll have to warn all my other developers not to switch to it.

Linda

[Steven_L_Intel1]

It won't be fixed in CVF because there won't be any more updates to CVF. The bug also appears in Intel Fortran 8.0 and will be fixed in that compiler.

I did add a note about this to the release notes. It is an incorrect standards warning and does not prevent the code from running.

[lklawrie1]

Yes, but that means a large portion of this particular application cannot use the checkbox "treat standards warnings as errors".

In fact, I had the impression that it was a flat out warning -- not coming from the standards processing. I will check that with the next release of 6.6C.

Linda

[Steven_L_Intel1]

No, it's just a standards diagnostic.

I've uploaded a new one here, but at the time of this post, it hadn't been mirrored to the server yet. Should be there soon.

[Steven_L_Intel1]

Ok - the "6.6C3" update is available here. It doesn't identify itself as that, but the release notes are dated February and the compiler ident is 6.6-4088-47D3B.

[david_jones]

Just to note...

(i) I have found2 other incorrect standard-checking messages (having been prompted by the above to try this out for the first time), one a "severe" level message. This is with the above latest version of CVF. Reported tovf-fortran (CVF21515).

(ii) The acknowedgement message (yesterday) does not point to the above version as the latest update, but rather to the one before ....at least the name ends 66C.

[Steven_L_Intel1]

I put the "C3" version up for people here to try. I haven't mentioned it to the HP folks yet.

[Steven_L_Intel1]

Intel Fortran has the same two standards checking bugs (not surprising)- I've reported them to the appropriate developer. The frst one (line too long) requires that you ask for both standards checking and /extend_source:132, which seems a contradiction to me... The second one has some interaction with the INCLUDE of the affected source - if you compile the source on its own, it's fine.