From: SMTP%"RELAY-INFO-VAX@CRVAX.SRI.COM" 7-MAY-1993 18:19:10.50 To: EVERHART CC: Subj: Re: fortran V6.0 X-Newsgroups: comp.os.vms From: lionel@quark.enet.dec.com (Steve Lionel) Subject: Re: fortran V6.0 Message-ID: <1993May7.020641.6694@dbased.nuo.dec.com> Sender: news@dbased.nuo.dec.com (USENET News System) Organization: Digital Equipment Corporation Date: Fri, 7 May 1993 02:18:07 GMT Lines: 274 To: Info-VAX@KL.SRI.COM X-Gateway-Source-Info: USENET In article <1993May6.202632.18720@butch.lmsc.lockheed.com>, burkhardt@force.ssd.lmsc.lockheed.com (Spike Burkhardt) writes... >Hello fortran masters! I am thinking about upgrading fortran from V5.5 to >6.0. How stable is the new version? Are there any installation gotchas >or problems with it? > How about the straight dope from the source? (Or the straight source from the dope - your choice...) The most significant "gotcha" you may run into is if you have any Fortran programs around that were linked on VMS V3 or earlier. This is due to an incompatibility between the VMSRTL.EXE provided by VMS and the new FORRTL and MTHRTL provided on the Fortran kit. The other important thing to be aware of is that the MTHRTL provided on the Fortran kit has had its GSMATCH ident bumped as the transfer vector had to be extended to include the large number of new entry points. The side effect of this is that images linked against the new MTHRTL won't run on systems that don't have Fortran V6.0 installed. There are ways around this, detailed in the Release Notes, but it is important that all your system users be aware of it. The installation preserves the VMS-supplied RTL images so you won't be stuck. As for installation itself, some users have failed to read the warnings in the Installation Guide and displayed by the installation procedure itself regarding installing the kit on a VMScluster. If you do, be *SURE* to run the SYS$UPDATE:FORTRAN$POST_INSTALL.COM procedure on all other cluster nodes after installation. The IG has complete details on this. Now as for stability... we ran a six-month field test at 10 high-activity sites, and have our own 9000-program test system. But no amount of testing prepares one for what users really do... There is currently the first update kit, called FORTECO01060, available from the support centers. I highly recommend that you install this instead of the SSB version. The ECO01 kit is edit level V6.0-14 and it fixes the various RTL-related problems. This was made available at the end of March. I'm about to release a second update, ECO02, which will be edit level V6.0-31. This may sound like a lot of fixes in a short time, but almost all of these are minor annoyances (and a few are relaxations of restrictions and improved error reporting). I'll attach the list of the fixes to the end of this message. V6.0 has a lot of new features and contains some significant performance optimizations. One feature you may like is detection of uninitialized variables; I was astonished when I turned on this feature, ran our test system which contains many industry standard applications, and found dozens of uninitialized variables. How many hidden bugs will this feature find in your code? Another new feature is recursion, though you'll want to get ECO02 to make the most of it; this should be available by the end of next week. Also there's the ability to read and write unformatted data in non-VAX formats such as IEEE floating (big and little-endian), Cray and IBM System-370. Pull the release notes from the kit (they're available in text, PostScript and Bookreader form) and read them to get a good feel for what's new. The March ConOLD CD-ROM also has the new documentation - look under "DEC Fortran for OpenVMS VAX Systems", our new name, rather than VAX FORTRAN. I'm always interested in comments and questions on the VAX Fortran product; I'll answer them in the newsgroup or by mail, as you prefer. And lastly, I'll be at DECUS in Atlanta giving a presentation on "DEC Fortran Directions", including full details on the new V6.0 for OpenVMS VAX. Stop by and say hello. Table_A-1_DEC_Fortran_Maintenance_Changes________________________ Version_____Description__________________________________________ V6.0-1 DEC Fortran V6.0 Release; contains all corrections to VAX FORTRAN through version V5.9-175 and to VAX FORTRAN-HPO through version V1.3-252 V6.0-2 The compiler now detects as an extension to FORTRAN-77 the use of a non-integer expression as a logical unit number in an I/O statement. V6.0-3 A number of problems related to the "non-native data in I/O" feature were corrected, including: o The FOR$CONVERTnnn logical names were not properly recognized. o Big-endian IEEE and all big-endian integer conversion did not work correctly. o Conversion in I/O statements with implied DO-loops did not always work correctly. o Conversion of COMPLEX variables did not work. o Applications which executed an ENDFILE or FIND statement on a unit which was not open could get an INVARGFOR error at run-time. V6.0-4 The compiler no longer goes into a loop if a statement function has two or more formals which are declared as RECORDs using the same STRUCTURE. V6.0-5 The compiler now issues the new diagnostic EQVSAVCOM if EQUIVALENCE is used to attempt to put a SAVE variable into COMMON. V6.0-6 The DEC Fortran kit now provides an updated copy of the VMSRTL.EXE shareable image, which is required by images linked against VAX/VMS versions earlier than V4.0. Without the updated VMSRTL.EXE, images which use it may fail unpredictably due to registers not being properly saved across calls to Fortran or Math Run-Time Library routines. The new VMSRTL.EXE specifies that all registers are to be saved so that changes to register usage in routines now in the BASRTL, COBRTL, FORRTL, LIBRTL and MTHRTL shareable images will not break images linked against VMSRTL. Images linked on VAX/VMS V4.0 or later do not use VMSRTL and are not affected. The updated VMSRTL.EXE is not provided on OpenVMS VAX Version V6.0 or later as it is not needed there. V6.0-7 A problem in which the compiler would fail with a bugcheck in the PACK phase was corrected. V6.0-8 The Digital-provided INCLUDE files SYS$LIBRARY:FORDEF.FOR, SYS$LIBRARY:FORIOSDEF.FOR and the $FORMSG module of SYS$LIBRARY:FORSYSDEF.TLB have been updated to include the new FOR$_FLOCONFAI status value and associated IOSTAT number definitions. V6.0-9 The compiler no longer issues the CRX error message BADRGTJUST for a CDD non-text field that specifies right-justification. The justification attribute is ignored by DEC Fortran. V6.0-10 The correct line number is now displayed for the EXTCHASOU and TOOMANCON compiler diagnostics. V6.0-11 The compiler no longer gives spurious USEUNIVAR warnings for references to COMPLEX variables which were data-initialized using character constants, and now only gives one warning per COMPLEX variable instead of separate warnings for the real and imaginary parts. V6.0-12 The compiler now properly displays the attempted file specification when it gives an INCOPEFAI error on failing to open an INCLUDE library. V6.0-13 The compiler now allows record variables to appear in AUTOMATIC, SAVE and STATIC statements. V6.0-14 The compiler was changed to emit the quadword stack alignment routine entry code sequence (see Section 1.5.9) only when the /VECTOR compile command qualifier is specified. V6.0-15 The compiler no longer generates bad code when a LOGICAL*2 or LOGICAL*4 array element is used in an arithmetic-IF statement. V6.0-16 A nested STRUCTURE with a data-initialized field in in a program unit compiled with /RECURSIVE no longer causes the linker to issue an UDEFPSC error. In addition, the compiler now issues the warnings AUTDATINI and AUTSAVALL if a variable declared AUTOMATIC was data-initialized or appears in a program unit which specifies that all variables are to be SAVEd. V6.0-17 The compiler no longer generates incorrect code when the only store to a formal argument occurs by its reference in an IOSTAT specification. In some cases, the modified value was not written back through the argument list. V6.0-18 The compiler no longer causes the linker to issue a UDEFPSC error for program units which reference a local variable in a READ or ACCEPT statement but don't pass that variable as an actual argument. V6.0-19 The compiler now properly passes a copy of an actual argument when that argument is an expression consisting of a reference to an intrinsic function that returns its argument unchanged, such as INT of an INTEGER argument. V6.0-20 The Run-Time Library no longer reports an INVARGFOR error when the PDP-11 compatibility routines ERRSET, ERRSNS or ERRTST are used for error number 95, FLOCONFAI. V6.0-21 The compiler no longer fails with a bugcheck in the CSE phase when /VECTOR is specified and the program contains certain uses of COMPLEX intrinsics. V6.0-22 The compiler now allows recursive function references as well as recursive references to ENTRY points which are defined after the function reference or CALL statement. The new error message ROUREFREC, "Routine referenced recursively; /RECURSIVE required" is given if the compiler detects a recursive reference and /RECURSIVE was not specified. The compiler now produces correct cross-reference and SCA information for recursive function references. V6.0-23 The compiler no longer generates incorrect code in a situation whose symptom was that register R0 was believed to still hold a value that had been loaded prior to a subroutine call which modified R0. V6.0-24 The compiler no longer issues the EXCCHASOU, "Extra characters in source" warning, enabled by /WARNINGS=TRUNCATED_SOURCE, for source lines containing whole-line comments or only blank characters, even if those lines exceed the statement field width. The compiler issues the new warning message FUNVALUND, "Function value undefined at end of routine" if a function return value is not defined at one or more exit points of the function. The standards extension diagnostic EXT_UNDFUNC is no longer issued, being replaced by FUNVALUND. The compiler now more accurately displays statement line numbers associated with error messages and the /SHOW=LOOP_STRUCTURE display. V6.0-25 The compiler no longer generates incorrect code for certain unusual cases involving a routine with a character formal argument whose address was taken with %LOC and another argument was used as a KEY value in an indexed READ statement. The symptom was that one argument's address was loaded into register R0 or R1 for later use, but the copy of the character argument's descriptor overwrote those registers. V6.0-26 The compiler's limit for the amount of internal representation allowed per statement has been doubled, making it much less likely than the STATOOCOM, "Statement too complex" error will be generated. V6.0-27 The compiler no longer fails with a bugcheck during LEXSYN when a type declaration statement has an end- of line comment, is followed by a blank line, and /ANALYSIS_DATA is specified. V6.0-28 The compiler now generates correct code for the case where a subprogram has one or more ENTRY statements, a non-CHARACTER dummy argument appears in two or more of the dummy argument lists, and that argument is passed as an actual argument to another routine using %DESCR. V6.0-29 The compiler no longer fails with a bugcheck during PACK in certain cases where the double-precision MOD intrinsic is used in conjunction with array references. V6.0-30 The compiler now recognizes the /OPTIMIZE=[NO]COMPLEX_EXPANSION compile command qualifier which, if specified as NOCOMPLEX_EXPANSION, disables the complex expansion optimization. V6.0-31 The compiler no longer fails with a bugcheck during LOCAL when the %LOC operator is used on an external procedure which has been typed as COMPLEX or COMPLEX*16. Steve Lionel lionel@quark.enet.dec.com SDT Languages Group Digital Equipment Corporation 110 Spit Brook Road Nashua, NH 03062