New Releases of CVF

[durisinm]

A colleague of mine game me a recent article from the June 2002 Programmer's Paradise catalog that includes a discussion of merging the Compaq and Intel Fortran compilers. The article stated that there won't be any new releases of CVF until the release of the merged Intel VF (IVF?) in the second half of 2003. The current version of CVF is 6.6A. Does this mean that there won't be any 6.6B, 6.6C, etc. downloadable updates--we'll have to wait for IVF to appear?

Mike

[tomballard]

I would like also to hear from Intel on this subject. Will CVF be merged with IVF and CVF disappear from the scene? Also, a more important issue - what will happen to support on non-Intel platforms?

[Steven_L_Intel1]

I had already posted a statement regarding this in this forum. We are planning a 6.6B update, there may be future updates depending on need.

As for support on "non-Intel platforms" - I'm reminded of the people who ask us if Compaq Visual Fortran runs on Dell PCs. :-)

We believe that Intel Visual Fortran will be the best performing Fortran compiler for the IA-32 and Itanium architectures.

Steve

Message Edited by intel.software.network.support on 12-09-2005 01:26 PM

[Intel_C_Intel]

Good news, the one about 6.6B. But Steve, please remember that the comatibility library which was promised here for "early January" is not delivered yet. I do not dare to upgrade from 6.6 to 6.6A because I am afraid that my customer who has got .obj files from me, will come back and demand some modifications in the program and want new .obj files. What am I going to do with 6.6B?!

[Steven_L_Intel1]

Mea culpa on the compatibility library. It's still on my list. Let me see if I can carve out some time for it soon.

Steve

[durisinm]

Steve,

I read your previous post with the update on the compiler merger plans, but I didn't see anything in it about the A, B, etc. downloadable updates. I'm glad that those will continue.

Is there a new edition of the VF Newsletter in the works?

Mike

[Steven_L_Intel1]

We're collecting articles for a newsletter issue, it may come out sometime in June.

Steve

[durisinm]

Is there any word on whether the IMSL and SciGraph libraries will be available with the merged compiler?

Mike

[Steven_L_Intel1]

SciGraph, definitely. As for IMSL, we'd certainly like to include it, but Visual Numerics and Intel have to agree on terms - the contract with Compaq does not carry over. There is some overlap with Intel's own Math Kernel Libraries, but we understand that IMSL is a draw for some users. Discussions are in progress.

Steve

[hweisberg]

How much of your market or potential market relates to porting legacy code to Windows?

[Steven_L_Intel1]

Quite a bit, actually. We see a lot of this with CVF. Until recently, Intel's compiler focus had been on a small number of large ISVs, and not on general applications. That is changing rapidly.

Why do you ask?

Steve

[hweisberg]

I'm interested because that is our reason for using CVF. As we continue with the project we may find some Fortran features that should be added to a new revision of the compiler (or at least that should not be removed -- for example EQUIVALENCE).

[Steven_L_Intel1]

Our position on removing features is that we will not remove features that were once part of the Fortran standard, even if they are deleted from the standard. EQUIVALENCE, by the way, is not even "obsolescent" in Fortran 95.

We're glad to consider additions to the product to help with compatibility, though CVF already supports a pretty broad range of extensions. If you're an Intel Fortran user, you can submit requests through the QuAD support mechanism, for CVF, send to vf-support@compaq.com

Steve

[hweisberg]

Well, Lahey Fortran for .NET apparently doesn't support EQUIVALENCE and claims it is "Fortran 90 obsolescent."

[Steven_L_Intel1]

How amusing. I suggest they get new glasses when they next read the standard....

Here is the list of obsolescent features from F90, deleted in F95:

1. Arithmetic IF
2. Real and double precision DO control variables and DO loop control expressions
3. Shared DO termination and termination on a statement other than END DO or CONTINUE statement.
4. Branching to an END IF statement from outside its IF block
5. Alternate return
6. PAUSE statement
7. ASSIGN statement and assigned GO TO statements
8. Assigned FORMAT specifiers
9. cH edit descriptor

F95 deleted items 2,4,6,7,8,9 above. Here's the list of obsolescent features as of F95:

1. Arithmetic IF
2. Shared DO termination and termination on a statement other than END DO or CONTINUE
3. Alternate return
4. Computed GO TO statement (use CASE)
5. Statement functions (use CONTAINed procedures)
6. DATA statements amongst executable statements (betcha didn't know they could go there!)
7. Assumed length character functions (this means CHARACTER*(*) FUNCTIONs)
8. Fixed form source (!!!!)
9. CHARACTER* form of CHARACTER declaration (use CHARACTER([LEN=]))

Do you see EQUIVALENCE in here? I don't... See my article on this topic in Issue 3 of the Visual Fortran Newsletter.

Steve

[gfthomas8]

Here's the entry for the equivalence statement in L/F Fortran .NET:

Description
The EQUIVALENCE statement specifies two or more aliases that share the same storage.

Syntax
EQUIVALENCE equivalence-sets
Where:
equivalence-sets is a comma-separated list of (equivalence-objects)
equivalence-objects is a comma-separated list of
variables,
array elements,
or substrings

Remarks
An equivalence-object must not be:

made available by use association;

a dummy argument;

a pointer;

a target;

a derived type;

an allocatable array;

an automatic object;

a function name;

an entry name;

a result name;

a named constant;

a structure component;

or a subobject of any of these objects

If the equivalenced objects have different types or kinds, the EQUIVALENCE statement does not perform any type conversion or imply mathematical equivalence.

If a scalar and an array are equivalenced, the scalar does not have array properties and the array does not have scalar properties.

If an equivalence-object is of an intrinsic type other than default INTEGER, default REAL, double precision REAL, default COMPLEX, default LOGICAL, or default CHARACTER, all of the objects in equivalence-set must be of the same type with the same kind value.

A data object of type default CHARACTER can be equivalenced only with other objects of type default CHARACTER. The lengths of the equivalenced objects are not required to be the same.

An EQUIVALENCE statement can not specify that the same storage unit is to occur more than once in a storage sequence.

When one of the equivalence objects is initialized, all associated objects are considered to be initialized. Each equivalence set may have only one initialization value.


A DATA statement should not contain equivalence-objects which are from different equivalence-sets.

.

Example
real :: a=1.
real(kind(1.d0)) :: d
integer :: i
logical :: l
equivalence (a,d,i,l)
write(*,*) a ! writes 1.0000000
write(*,*) d ! writes 5.263544247120890E-315
write(*,*) i ! writes 1065353216
write(*,*) l ! writes T

I guess Lahey got new glasses.

Ciao,
Gerry T.

[hweisberg]

Lahey added support in Fortran.NET for EQUIVALENCE, but with lots of restrictions. For example in our legacy codebase, there are thousands of cases where INTEGER*2 and INTEGER*4 variables are EQUIVALENCE'd. Apparently these still wouldn?t compile.

It is unclear to me why one would want to recompile legacy code as managed code. If you retain all the horrors of the old code, such as EQUIVALENCE and COMMON, then many of the advantages of managed code are lost.

Better to keep the legacy code as unmanaged modules. Provide new features and a new user interface in managed code; access the legacy code via P/Invoke.

[gfthomas8]

> Lahey added support in Fortran.NET for EQUIVALENCE,
> but with lots of restrictions.

EQUIVALENCE is part of L/F F95 and Fortran .NET. Where did you get the idea that it wasn't?

> For example in our
> legacy codebase, there are thousands of cases where
> INTEGER*2 and INTEGER*4 variables are EQUIVALENCE'd.
> Apparently these still wouldn?t compile.
>

Equivalencing int*2 and int*4 was never a good idea. I'd waste no time in changing it. There's nothing sacrosanct about 'legacy' code, especially if all it does is perpetuate the errors of the past.

Ciao,
Gerry T.

[Steven_L_Intel1]

I remember that when I tested an earlier beta of Lahey Fortran.NET sometime last year, there was a LONG list of F95 (and even F90) features it didn't support, including EQUIVALENCE. Clearly they've made some progress since then. I can't imagine releasing a product claiming to be Fortran without EQUIVALENCE.

LF.NET has been in beta/preview for a very long time. I hope for their sake .NET is still around by the time it is finally released! :-) (A couple of articles in this week's eWeek suggest that MS is backing away from .NET.) I'm very interested to see what the end product looks like and how much of an audience it finds. I have a lot of respect for Lahey in striking out in this new direction.

Steve

[gfthomas8]

The only restrictions on use of EQUIVALENCE in Lahey Fortran .NET are:

FRT4012: An equivalence object that has a TARGET or derived type is restricted
FRT4010: A data statement object list containing two or more variables that belong to another common block and equivalence association is restricted

Lahey document other restrictions that are a consequence of the limitations of the CLR, eg, kind=16 data types are out because quad isn't part of the CLR. Anyways, there's always unmanaged code, .COM, and all.

The Fortran .NET v7.0 release candidate is a giant improvement on the beta release of last year. Even I'm impressed!

Is .NET The Twilight Zone as Paul Dubois of CiS&E puts it, beats me. Any reference to the impending demise of .NET?

Ciao,
Gerry T.

[Steven_L_Intel1]

I don't think anyone is suggesting .NET is going to die soon, but it may become a marginalized technology, useful to some, but not actively promoted by MS. Too soon to say. A coutple of interesting articles I found: http://www.eweek.com/article2/0,3959,1184728,00.asp and http://www.microsoft-watch.com/article2/0,4248,990793,00.asp

Steve