why has Cray dropped CPP support from cf77?

[Dik T. Winter]

 > >In article <1298 at red8.qtp.ufl.edu> bernhold at qtp.ufl.edu (David E. Bernholdt) writes:
About Cray dropping support for .F

 > In article <1991Feb19.162007.28774 at ncsa.uiuc.edu> hirchert at ncsa.uiuc.edu (Kurt Hirchert) writes:
About scc taking over from cc.  (I would say good riddance, cc is very bug-
ridden.)

In article <1991Feb19.203555.8262 at craycos.com> pmk at craycos.com (Peter Klausler) writes:
 > It would appear infeasible to use an ANSI Standard C preprocessor or
 > preprocessing phase as a general cpp-like macro processor for Fortran or CAL.
 > Why? ANS C preprocessing is token-based, not character-based, and applies ANS C
 > tokenization to its input. This works fine for C, of course, but has some
 > trouble with Hollerith data, CAL's odd O' and X' syntax, apostrophes in Fortran
 > comments, etc.
(Note that not all pre-ANSI cpp's where character-based.)
But there is more to come.  scc has the -E flag to only run the preprocessor.
It will include #line directives (those are not a problem; you can filter
them out), but it will not include them between source code lines, but in
the middle!  For example when the first line is:
      SUBROUTINE A
that becomes:
      
#line 1 ....
SUBROUTINE A
(note the line with 6 spaces on the line before #line :-)).
Now tell the Fortran compiler about that!  Of course you could correct that,
but that is one more tool to be used different on the Cray.

Another comment about the RS6000: yes, xlf does not use cpp, but you can
use the preprocessor on fortran sources without ill-effects.  Now commented
assembler is completely different (because # also starts comments in the
assembler).  Pre-ANSI cpp's would have no problem with that if you did not put
your comment # symbol in column one; with ANSI cpp's this is different.
--
dik t. winter, cwi, amsterdam, nederland
dik at cwi.nl