Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted

Fixed Format to Free Format replacing D lines

I transfered my fixed format to free format and search for an efficent way to replace the D lines used in the fixed format.

I have many sources and each calls some subroutines both with and without the D line consideration. The problem is that these calls often occur alternating so there would be lots of blocks with conditional compilation directives which would blow up the code. Is there a way to just replace the "D" with another sign in just one line without making blocks every time?

0 Kudos
4 Replies
Highlighted
Black Belt

No, sorry. And this is

No, sorry. And this is another case of unnecessary format changes causing problems. Admittedly, D-lines are HIGHLY non-standard but if you've been using them there's no corresponding feature in free-form source.

Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
New Contributor II

As far as efficiency goes,

As far as efficiency goes, how about single-line logical if-statements and hoping for compiler-optimization to do the rest?

Original fixed-format:

D     print *, 'DEBUG FLOW'

Converted to free-format:

if (__D) print *, 'DEBUG FLOW'

where __D is set up as a global parameter -- possibly hosted from a module similar to the following,

      module D_mod
      logical, parameter :: __D = 
D    &                          .not.
     &                          .false.
      end module

which can be compiled as -fixed with either the -d-lines / -DD or the -nod-lines flag. Only a few extra lines would be required to use/include the global parameter/module.

EDIT: However with respect to optimization (unless maybe inter-procedural optimization is used?), a preprocessor symbol in place of the use'd parameter might be more efficient; e.g. simply compiling with -fpp -D__D=.false.

EDIT II: Rereading the initial post, I am no longer sure the d-lines were meant to hold simple (one-line) exectuable statements (e.g. debug-subroutine calls), so the above construction may not be suitable. The following more general but less readable hack however should always work, by retaining the D-lines in free-format (just replace the "D" with some other symbol, e.g. "__D"),

__D   print *, 'DEBUG FLOW'

and compiling with either -fpp -D__D='!', or -fpp -D__D='' for including the debug lines.

Kind Regards, Ferdinand

0 Kudos
Highlighted
Black Belt

The basic obstacle to

The basic obstacle to converting fixed form source with D-lines is this: in fixed form, a 'd' or 'D' in column-1 makes the line a comment line when seen by a compiler that accepts D-lines and the compiler's "recognize D-lines" option has not been selected.

In free form source, the first column has no special significance, and a 'd' or 'D' in column-1 can be part of a variable name, construct name or 'DO'. The "recognize D-lines" option cannot apply to free form source because of this ambiguity.

Rather than bloat-up the code by converting D-lines using either preprocessor directives or with if (__D) ... as you indicated, you could write a short utility program to process each of your fixed form input source file and produce one of two output fixed form source files: one with D-lines converted to comments or stripped out and the other with 'd' or 'D' in column-1 replaced by a space, followed by a conversion of the resulting files to free form Fortran 9X source.

You will still be left with the issue of which version of the sources you wish to use when making future revisions. My suggestion would be to regard the conversion as a one-time project, and to abandon D-lines and fixed form as soon as it is convenient.

0 Kudos
Highlighted

Two files...

Two files...

I disagree.

IIF there is no value in keeping the D lines then remove them, and convert to free form

IFF there is value in keeping the D lines then I favor Ferdinand's approach if  if(__D) print ..... However, with the following caveats:

1) method must not rely on having a compiler that supports fixed form D lines
2) method must not rely on having a preprocessor
3) method must not rely on vendor specific (!DIR$...) directives

This will likely require that the build process includes one of two different modules to declare the value of __D

I do have an additional suggestion if you can use a preprocessor: make an "__ASSERT__(expression) statement" macro
and/or
make use of #if(...) #endif

Jim Dempsey

0 Kudos