[daip] [!7214]: AIPS - gfortran arguments

[Eric Greisen]

Eric Greisen updated #7214
--------------------------

       Staff (Owner): Eric Greisen (was: -- Unassigned --)
              Status: Closed (was: Open)
                 Due: - Cleared - (was: 09 September 2015 09:29 AM)

gfortran arguments
------------------

           Ticket ID: 7214
                 URL: https://help.nrao.edu/staff/index.php?/Tickets/Ticket/View/7214
           Full Name: Rhys Morris
               Email: r.morris at bristol.ac.uk
             Creator: User
          Department: AIPS Data Reduction
       Staff (Owner): Eric Greisen
                Type: Issue
              Status: Closed
            Priority: Default
      Template Group: Default
             Created: 07 September 2015 09:29 AM
             Updated: 07 September 2015 03:12 PM



The first question is why are you compiling it yourself?  The only
reason I know to do this would be when you are needing to write
your own versions of AIPS tasks.  Otherwise, the binary installation
is easier and the load modules run a bit faster.

#                                       for 4.4
COMPSWIT="-c -Wunused -Wuninitialized -finit-local-zero -m64 -fimplicit-none"

are the parameters I used to build a 4.4.7 version which i tested  fairly
extensively.  (My private version is now gfortran 5.1.0 for testing purposes.)

I have written an article for the next AIPSLetter on the subject.  I include a preview
(In TeXese):
The binary distributions of \AIPS\ are compiled with various older
versions of compilers from Intel.  People wishing to develop new
\AIPS\ tasks, or variants of existing \AIPS\ tasks, have limited
choices.  They can ask us to compile and link a task for them, making
the binary available on an anonymous ftp site.  That works for
well-tested programs, but is not appropriate for deveoping code.
Since the versions of Intel compilers we use are no longer available,
the only other alternative is to obtain a compiler and compile all of
\AIPS\ locally.  The usual choice of compiler is {\tt gfortran} plus
{\tt gcc} from gnu.  Unfortunately, until recently, that has not
worked well.

One of the reasons for the failures was the use of ``automatic''
variables, namely local variables that do not retain their value
between invocations of the subroutine.  The traditional compiler
option {\tt -fno-automatic} to prevent this is honored by some
versions of {\tt gfortran}, but not all.  The {\tt man} pages for {\tt
  gfortran} claim that this option is present even when it is not, but
no {\tt gfortran --help} will admit to it.  Therefore, considerable
effort has been expended to identify variables that need to be {\tt
  SAVE}d in order to retain their values between calls to the routine.
Undoubtedly, more will be discovered later, so your editor's personal
version of \AIPS| has been compiled with automatic variables allowed.
It was also discovered that automatic allocation of largish buffers
(\eg\ 1.5 Mbytes) can be horribly slow when that buffer is used a
great deal (\eg\ in the data reading routine of the calibration
package).

Another reason for the failures was an interaction between {\tt
  gfortran} optimization and the dynamic allocation of memory for the
pseudo-array processor.  Modern {\tt gfortran}s do something bad when
optimizing the ``{\tt Q}'' routines, but work well if that memory is a
fixed amount.  Therefore {\tt \$INC/PAPC.INC} was changed to allow the
choice of dynamic or fixed memory to be made before compiling \AIPS\@.
Another oddity that appeared connected with this was an apparent
limitation of labeled {\tt COMMON}s to a combined total of 2 Gbytes.
That still allows a mammoth pseudo-AP of say 200 million
double-precision words.  {\tt gfortran} also handles the reading of an
end-of-file in a Fortran text file differently from {\tt g77} and has
different options for the {\tt OPEN} command.  {\tt ZTXOP2} was
changed to handle this for both compilers.

Yet another issue has been the alignment of labeled {\tt COMMON}s.
Earlier Fortrans started each labeled {\tt COMMON} block on a double
precision address and we made sure that all double precision variables
appeared first in the list of variables in the {\tt COMMON} block.
Now, {\tt gfortran} starts each labeled {\tt COMMON} block on a
single-precision address unless every declaration of that block
contains explicitly a double-precision variable at its start.  A bad
habit of declaring an image header in its integer form in the local
include and then equivalencing it later to its floating and
double-precision versions causes a misalignment of the {\tt COMMON}\@.
It is best repaired by declaring the double-precision equivalence in
the local include block.

The various versions of {\tt gfortran} produce a plethora of warning
messages.  These were reviewed in detail and many routines were
altered to eliminate unused statement labels, variables, {\tt
  FORMAT}s, and the like.  This review also identified real errors
including {\tt NINER} operation {\tt KRSH}, {\tt IMAGR} when making a
second copy of the data for filtering, and {\tt BLANK} operation {\tt
  FLUW}\@.

--- Version 4.4.7 does not honor -fno-automatic  so I am trying my versions
without this option.

Eric Greisen





------------------------------------------------------
Staff CP:  https://help.nrao.edu/staff