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


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

Submitted by:  Mike Miller <mtmiller>
Submitted on:  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

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

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

I pushed the following changeset on default:


Closing report as fixed.

John W. Eaton <jwe>
Project 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>
Project Administrator
Fri 27 Jul 2018 12:52:53 PM UTC, comment #10:


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>
Project 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:

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>
Project 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>
Project Administrator
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>
Project Administrator
Fri 27 Jul 2018 01:12:33 AM UTC, comment #6:

I see from the gfortran manpage


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

Carlo de Falco <cdf>
Project 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>
Project Administrator
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>
Project 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>
Project Administrator
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

Does the following equivalent code look better

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

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>
Project Administrator
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>
Project 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:
  • Shared DO loop labeled termination with nested loops, for example, from daspk/ddstp.f:
Mike Miller <mtmiller>
Project Administrator


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

Attach Files:

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)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project 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.4