libf2c/configure.in change

libf2c/configure.in change

[Dave Love]

I didn't know the following libf2c change had gone in (good), but I
presume it should have a corresponding configure change.

Mon Jan 19 17:19:27 EST 1998
[...]
  libi77: backspace.c: for b->ufmt==0, change sizeof(int) to
sizeof(uiolen).  On machines where this would make a difference, it is
best for portability to compile libI77 with -DUIOLEN_int, which will
render the change invisible.

1998-02-15  Dave Love  <d.love@dl.ac.uk>

	* configure.in: Define UIOLEN_int per dmg advice for Jan 18
	backspace.c change.

Index: configure.in
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/libf2c/configure.in,v
retrieving revision 1.2
diff -u -p -c -r1.2 configure.in
*** configure.in	1998/02/02 11:09:23	1.2
--- configure.in	1998/02/15 18:29:21
*************** F2C_INTEGER=$g77_cv_sys_f2cinteger
*** 286,291 ****
--- 286,297 ----
  ac_cpp=$late_ac_cpp
  AC_SUBST(F2C_INTEGER)
  
+ dnl Follow dmg advice to render 1998-01-19 change in backspace.c invisible.
+ if test "$F2C_INTEGER" = int; then
+   AC_DEFINE(UIOLEN_int) dnl 64-bit targets
+ else :
+ fi
+ 
  AC_MSG_CHECKING(f2c long int type)
  late_ac_cpp=$ac_cpp
  ac_cpp="$late_ac_cpp -I$srcdir/../gcc/f -I../../gcc -I$srcdir/../gcc -I$srcdir/../gcc/config"

Re: libf2c/configure.in change

[Jeffrey A Law]

  In message < rzq3ehk3e7d.fsf@djlvig.dl.ac.uk >you write:
  > I didn't know the following libf2c change had gone in (good), but I
  > presume it should have a corresponding configure change.
  > 
  > Mon Jan 19 17:19:27 EST 1998
  > [...]
  >   libi77: backspace.c: for b->ufmt==0, change sizeof(int) to
  > sizeof(uiolen).  On machines where this would make a difference, it is
  > best for portability to compile libI77 with -DUIOLEN_int, which will
  > render the change invisible.
  > 
  > 1998-02-15  Dave Love  <d.love@dl.ac.uk>
  > 
  > 	* configure.in: Define UIOLEN_int per dmg advice for Jan 18
  > 	backspace.c change.
I don't really follow what's going on here.  But if you & Toon think
it's the right change, then please install it.  (Toon submitted
the backspage.c fix if I remember correctly).

jeff

Re: libf2c/configure.in change

[Toon Moene]

Dave wrote:

  > I didn't know the following libf2c change had gone in (good), but I
  > presume it should have a corresponding configure change.
  >
  > Mon Jan 19 17:19:27 EST 1998
  > [...]
  >   libi77: backspace.c: for b->ufmt==0, change sizeof(int) to
  > sizeof(uiolen).  On machines where this would make a  
difference, it is
  > best for portability to compile libI77 with -DUIOLEN_int, which will
  > render the change invisible.
  >
  > 1998-02-15  Dave Love  <d.love@dl.ac.uk>
  >
  > 	* configure.in: Define UIOLEN_int per dmg advice for Jan 18
  > 	backspace.c change.

>  I don't really follow what's going on here.  But if you
>  & Toon think it's the right change, then please install
>  it.  (Toon submitted the backspage.c fix if I remember
>  correctly).

The problem with this change is that it is makes a compatibility  
break on systems where sizeof(long) != sizeof(int), e.g. Alpha's.   
With this change, people won't be able to read the sequential  
unformatted files they created with previous versions of the  
compiler.  OTOH, with this change, they could freely exchange such  
files with Digital Fortran on Digital UNIX.

I have no strong feeling either way, but if we're going to break  
backwards compatibility, we should write that down in the release  
notes.

Cheers,
Toon.

Re: libf2c/configure.in change

[Dave Love]

>>>>> "Toon" == Toon Moene <toon@moene.indiv.nluug.nl> writes:

 Toon> The problem with this change is that it is makes a compatibility  
 Toon> break on systems where sizeof(long) != sizeof(int), e.g. Alpha's.   
 Toon> With this change, people won't be able to read the sequential  
 Toon> unformatted files they created with previous versions of the  
 Toon> compiler.  

Bother.  I didn't look closely enough originally, and dmg's remark
suggested the opposite...

 Toon> OTOH, with this change, they could freely exchange such  
 Toon> files with Digital Fortran on Digital UNIX.

 Toon> I have no strong feeling either way, but if we're going to break  
 Toon> backwards compatibility, we should write that down in the release  
 Toon> notes.

I think it shouldn't go in.  Pity I didn't spot that definition and
its import in the beginning.  Breaking intra-platform compatibility
can wait until we do inter-platform portability of unformatted
files...

Re: libf2c/configure.in change

[Jeffrey A Law]

  In message < rzqn2frw6m5.fsf@djlvig.dl.ac.uk >you write:
  > Bother.  I didn't look closely enough originally, and dmg's remark
  > suggested the opposite...
  > 
  >  Toon> OTOH, with this change, they could freely exchange such  
  >  Toon> files with Digital Fortran on Digital UNIX.
  > 
  >  Toon> I have no strong feeling either way, but if we're going to break  
  >  Toon> backwards compatibility, we should write that down in the release  
  >  Toon> notes.
  > 
  > I think it shouldn't go in.  Pity I didn't spot that definition and
  > its import in the beginning.  Breaking intra-platform compatibility
  > can wait until we do inter-platform portability of unformatted
  > files...
OK.  We'll table this patch.

jeff

Re: libf2c/configure.in change

[Craig Burley]

>  > I think it shouldn't go in.  Pity I didn't spot that definition and
>  > its import in the beginning.  Breaking intra-platform compatibility
>  > can wait until we do inter-platform portability of unformatted
>  > files...
>OK.  We'll table this patch.

Probably that is best.

I've been so busy that it didn't occur to me, until this morning,
just how important this issue is.

(First, though, I do have to say that, because g77 is still
officially in *beta testing*, it is not so crucial as it
would be in a product that isn't.  That is, we need to work
this, and any similar, issues out once and for all during
this beta-test period.)

Basically, the problem is that libf2c, like pretty much any
Fortran run-time library, makes what amounts to its "own"
decision as to what the format of an unformatted file should be.

(In Fortran, an unformatted file is kind of like a "binary"
file in C, in that data is read or written to it at a "raw"
level.  However, this level is somewhat higher-level than in
C.  In C, one simply write()'s, or whatever, an array or struct
or whatever.  In Fortran, statements like "WRITE (10) A, B"
accomplish that -- the difference between that statement and
"WRITE (9, '(F10.5)') A, B" is that the latter specifies that
the arrays are to be written using formatted I/O, which is
like C's `printf("%f10.5",...);'.  The program that runs in
an unformatted file must match the data types, array sizes,
and lengths, basically, but not explicit layout that Fortran
doesn't really have anyway, a la C's alignment stuff.)

Because Fortran provides unformatted I/O as a *language* feature,
it's more important for a Fortran vendor (like g77) to really
understand and explain just what an unformatted file *is* in
that system.  Choices include (but probably are not limited to,
even in practice):

  1.  A file that is assumed to be read and written using
      unformatted I/O *only* in programs compiled with the exact
      same version of the compiler on the exact same kind of
      system (OS and CPU).  That is, the file is binary-compatible
      with other files written by code compiled by the exact same
      compiler, but basically no other guarantees are made.

      Programmers wanting a more "universal" format must use
      formatted I/O or write code to do the binary encoding
      directly using low-level facilities (e.g. libU77).

  2.  Same as #1, but the vendor promises to make the file "work"
      across a range of versions of the compiler on that system
      (e.g. "this compiler writes unformatted files that this and
      all future versions of this compiler will read").

  3.  Same as #1, but the vendor promises to make the file "work"
      across a range of systems the compiler and version supports.
      (Nice when sharing files across NFS, for example.)

  4.  Best of #1 plus #2.

  5.  A file that is binary-compatible with a range of *other*
      compilers that support that system.  (E.g. "this compiler
      employs an unformatted-file format that is binary-compatible
      with Smegma f77 v99.88".)

  6.  A file that is binary-compatible with some industry-wide
      standard.

As you might guess, some of the promises conflict with others
as a *default*, but they're basically all useful in different
situations.  And, the more that is promised, generally speaking,
the less performance can be delivered -- which is why some
promises are not made the *default*, because, also generally
speaking, Fortran programmers use unformatted I/O when they
*need* performance.

For example, defaulting to some industry-wide standard, or to a
single format that, say, *all* systems g77 runs on (now or in
the future), has the obvious advantages, but at least one big
disadvantage, in that, for certain systems, I/O would go *much*
slower in some cases because of endian and other differences
between the CPU architecture and the file format.

Since it would *really* be nice for g77 to at least offer all
of the above as *options*, meaning options on the OPEN statement
(this is apparently how other vendors do it), I think this
whole issue basically requires "punting" to the long-hoped-for
new run-time-library (which we cleverly code-name "libg77" ;-).

And, picking the *default* choice should be simply a matter of
just that, once all the options are available.

Whether we'll *ever* want to change the default from "whatever
g77+libf2c delivered in the past", so as to give users no hard
work to cope with reading in data written, in the past, by g77
releases, I can't say.  The fact that libf2c has already,
apparently, made an incompatible change doesn't necessarily
mean we have to.  But if that change means 64-bit systems like
Alphas get 64-bit capacity in record length, and we don't accept
it, then, while we're thus ensuring existing files get read in
"naturally", we aren't defaulting to a model whereby users of g77
on Alphas get more than an artificial 32-bit limit on their
record lengths.

I hope I've accurately laid out most of the issues above.  Mostly,
in summary, I've saying "there's a lot to think about here, and
we aren't really close yet to having enough choices in the matter".

I *think* that implies that, indeed, it's best to not "rock the boat"
in any way until we know more about what we're doing, and can
elucidate those plans better.  So indeed it seems best to not
modify g77, even in the form of netlib-sanctioned libf2c patches,
to introduce changes in the format of unformatted files on any
systems that have been supported by g77 in the past, until we
are in a better position to offer real choices to our users.

        tq vm, (burley)

Re: libf2c/configure.in change

[Jeffrey A Law]

  In message < 199802181722.MAA19009@melange.gnu.org >you write:
  > >  > I think it shouldn't go in.  Pity I didn't spot that definition and
  > >  > its import in the beginning.  Breaking intra-platform compatibility
  > >  > can wait until we do inter-platform portability of unformatted
  > >  > files...
  > >OK.  We'll table this patch.
  > 
  > Probably that is best.
[ ... ]
Phew.  Lots of information there.  Glad we didn't open up that mess
at this time :-)

jeff