bugGNU Octave - Bugs: bug #54390, liboctave/external...

 
 

bug #54390: liboctave/external incompatibilities with upcoming Fortran 2018

Submitter:  Mike Miller <mtmiller>
Submitted:  Thu 26 Jul 2018 07:39:20 PM UTC
   
 
Category:  Libraries Severity:  2 - Minor
Priority:  5 - Normal Item Group:  Other
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 13 Aug 2018 03:19:41 PM UTC, comment #12: 

I pushed the following changeset on default:

http://hg.savannah.gnu.org/hgweb/octave/rev/4e658452f6c7

Closing report as fixed.

John W. Eaton <jwe>
Group administrator
Fri 27 Jul 2018 03:43:51 PM UTC, comment #11: 

Seems like the best option is still to change the compiler flag to stop producing the warning rather than to take over dead code and modify it.  We don't need yet more maintenance burden.

Rik <rik5>
Group administrator
Fri 27 Jul 2018 12:52:53 PM UTC, comment #10: 

Rik:

Most (all?) of this code is orphaned.  It's still on Netlib, but not maintained in any way that I know of.  I could be wrong, but I don't think that there will be any updates to it.

John W. Eaton <jwe>
Group administrator
Fri 27 Jul 2018 12:49:43 PM UTC, comment #9: 

If -std=legacy eliminates the warnings, then I think that's fine for now.

My guess is that most of the code like this:


      DO 95 I = I1,I2
 95     RWORK(I) = 0.0D0


was written that way just to save the " 95   CONTINUE" card, or was written before the CONTINUE statement was added to Fortran and that there are no other references to those labels in the file.  It would be simple enough to check that.  Also, if there is a jump to the label, you should get a warning from gfortran about jumping into the range of a do loop because that's also an obsolete feature.

John W. Eaton <jwe>
Group administrator
Fri 27 Jul 2018 02:23:19 AM UTC, comment #8: 

Thank you Carlo, I got a build with no warnings printed with FFLAGS="-g -O2 -std=legacy" and no code changes required. So just need to ensure that that option is added to AM_FFLAGS if the compiler is GNU. I'll look into adding that to configure.ac.

Mike Miller <mtmiller>
Group Member
Fri 27 Jul 2018 01:17:24 AM UTC, comment #7: 

I can try -std=legacy to see if that eliminates the warnings.

If it does, that might be useful to automatically resolve this for any version of gfortran that we support. I didn't read closely enough, it looks like 'legacy' is equivalent to 'gnu', minus deprecation warnings, which might suit this situation.

If that works and everyone is ok with that, then we can add that to the configure script when gfortran is detected and not have to update any code.

Mike Miller <mtmiller>
Group Member
Fri 27 Jul 2018 01:12:33 AM UTC, comment #6: 

I see from the gfortran manpage


 -std=std
           Specify the standard to which the program is expected to conform, which may be
           one of f95, f2003, f2008, gnu, or legacy.  The default value for std is gnu,
           which specifies a superset of the Fortran 95 standard that includes all of the
           extensions supported by GNU Fortran, although warnings will be given for obsolete
           extensions not recommended for use in new code.  The legacy value is equivalent
           but without the warnings for obsolete extensions, and may be useful for old non-
           standard programs.  The f95, f2003 and f2008 values specify strict conformance to
           the Fortran 95, Fortran 2003 and Fortran 2008 standards, respectively; errors are
           given for all extensions beyond the relevant language standard, and warnings are
           given for the Fortran 77 features that are permitted but obsolescent in later
           standards. -std=f2008ts allows the Fortran 2008 standard including the additions
           of the Technical Specification (TS) 29113 on Further Interoperability of Fortran
           with C and TS 18508 on Additional Parallel Features in Fortran.


Isn't


-std=legacy


the compile option we need to use? Is there something similar in other compilers?

Carlo de Falco <cdf>
Group Member
Fri 27 Jul 2018 01:02:25 AM UTC, comment #5: 

I just did a little reading about DO loops, and apparently END DO is not strictly a part of Fortran 77, it was standardized in Fortran 90.

The liboctave/external/blas-xtra directory contains some code that uses 'end do', so we already de facto depend on a compiler that supports it. I'm going with that for now.

Mike Miller <mtmiller>
Group Member
Thu 26 Jul 2018 11:29:37 PM UTC, comment #4: 

Okay, my questions are answered.  I had hoped we could just silence them by compiling with a known version like Fortran90, but that is not to be.

In terms of style, as long as we are making changes I think we should just own the code.  In that case, I find pairing DO/END DO to be clearer than pairing DO 50/50 CONTINUE.  It is more like shell programming with if/endif or Octave itself with while/endwhile.

Rik <rik5>
Group administrator
Thu 26 Jul 2018 11:25:26 PM UTC, comment #3: 

Rik - I think we basically require at least Fortran 77 support. Octave used to build with g77 and I doubt any changes were needed to move from g77 to gfortran.

This is the first time I've seen gfortran spit out any deprecation messages about features that are being pruned from the Fortran language. And it's possible that these will remain warnings forever, maybe gfortran will keep supporting these structures forever if it's desired to keep building old code.

The -std option to gfortran doesn't seem as flexible as the g++ option. I think we want to use -std=gnu, which is the default, but with gfortran 9, that is now including these new warning messages.

Mike Miller <mtmiller>
Group Member
Thu 26 Jul 2018 11:20:02 PM UTC, comment #2: 

I've started going through these and converting them to a more consistent loop syntax, just to see what the diff looks like and make sure that the changes can be done to silence these warnings.

Let's assume that we are ok with taking ownership of these Fortran soruces and amending them to keep up with evolving Fortran language standards. Does anyone (jwe, anyone else?) have any preference for a consistent style to use when converting these DO loops?

Specifically, the code in question has loops in this form that need to be updated to modern Fortran syntax


      DO 50 I=1,N
 50     Z(I) = X(I)


Does the following equivalent code look better


      DO I=1,N
 50     Z(I) = X(I)
      END DO


The advantage of this change is that it retains the label 50, just in case there is a jump anywhere else in the code that depends on the label. It also uses the END DO syntax, which I think is the preferred modern Fortran syntax for ending a DO loop.

Howveer, a lot of this older Fortran code also contains DO loops that are written like this, which is still allowed in Fortran 2018


      DO 60 I=1,N
        Z(I) = X(I)
 60   CONTINUE


If we use the former change, then we'll end up with two different styles of DO loops in the same source file. The second syntax should be safe as long as there are no GO TO or other jump commands that use the label that was previously inside the loop.

I'm testing a mix of these changes for now and so far gfortran likes the changes.

Mike Miller <mtmiller>
Group Member
Thu 26 Jul 2018 11:12:29 PM UTC, comment #1: 

Do we require a certain minimum Fortran level such as Fortran77 or Fortran90?  Secondly, can we supply a maximum version that the code should be compiled with in the same way we say tha g++ should use C++11 features, but not necessarily C++17 features?

Since we got this code from somewhere else, is it possible that the external libraries will be updated once Fortran2018 is widely available?

As a last resort, we can modify the code ourselves to eliminate the warnings.  But there are 219 of them which doesn't sound like a lot of fun and then we might be left with code that is out of sync with upstream sources.

Rik <rik5>
Group administrator
Thu 26 Jul 2018 07:39:20 PM UTC, original submission:  

Several Fortran routines built into Octave in the liboctave/external directory use Fortran constructs which are now deleted features in the Fortran 2018 language revision.

These source files do still compile with gfortran 9 (development snapshot), but a warning message is printed for each occurrence of a Fortran 2018 deleted feature.

The full list of warnings is attached. In summary, the source files affected are

  • liboctave/external/daspk/datv.f
  • liboctave/external/daspk/ddaspk.f
  • liboctave/external/daspk/ddstp.f
  • liboctave/external/daspk/ddwnrm.f
  • liboctave/external/daspk/dinvwt.f
  • liboctave/external/daspk/dlinsd.f
  • liboctave/external/daspk/dlinsk.f
  • liboctave/external/daspk/dmatd.f
  • liboctave/external/daspk/dnedd.f
  • liboctave/external/daspk/dnedk.f
  • liboctave/external/daspk/dnsd.f
  • liboctave/external/daspk/dnsk.f
  • liboctave/external/daspk/dslvk.f
  • liboctave/external/daspk/dspigm.f
  • liboctave/external/dasrt/ddasrt.f
  • liboctave/external/dasrt/drchek.f
  • liboctave/external/dassl/ddaini.f
  • liboctave/external/dassl/ddajac.f
  • liboctave/external/dassl/ddanrm.f
  • liboctave/external/dassl/ddassl.f
  • liboctave/external/dassl/ddastp.f
  • liboctave/external/dassl/ddatrp.f
  • liboctave/external/odepack/cfode.f
  • liboctave/external/odepack/dlsode.f
  • liboctave/external/odepack/ewset.f
  • liboctave/external/odepack/intdy.f
  • liboctave/external/odepack/prepj.f
  • liboctave/external/odepack/scfode.f
  • liboctave/external/odepack/sewset.f
  • liboctave/external/odepack/sintdy.f
  • liboctave/external/odepack/slsode.f
  • liboctave/external/odepack/solsy.f
  • liboctave/external/odepack/sprepj.f
  • liboctave/external/odepack/ssolsy.f
  • liboctave/external/odepack/sstode.f
  • liboctave/external/odepack/stode.f
  • liboctave/external/odepack/svnorm.f
  • liboctave/external/odepack/vnorm.f
  • liboctave/external/quadpack/dqagpe.f
  • liboctave/external/quadpack/qagpe.f
  • liboctave/external/slatec-fn/pchim.f


The used features that are now deleted fall into these three categories

  • DO loop that uses a labeled termination statement that is not END DO, for example, from odepack/dlsode.f:



      DO 95 I = I1,I2
 95     RWORK(I) = 0.0D0


  • Shared DO loop labeled termination with nested loops, for example, from daspk/ddstp.f:



      DO 595 J1=2,KP1
         J=KP1-J1+1
         DO 595 I=1,NEQ
595      PHI(I,J)=PHI(I,J)+PHI(I,J+1)




         IF ( PCHST(DEL1,DEL2) )  42, 41, 45


Mike Miller <mtmiller>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #44631:  gfortran9warnings.log added by mtmiller (58KiB - text/x-log)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by cdf (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by mtmiller (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-08-13 jwe StatusNone Fixed
        Open/ClosedOpen Closed
    2018-07-26 mtmiller Attached File- Added gfortran9warnings.log, #44631

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code