Strange format error in g77

Strange format error in g77

[David Ronis]

Hi I'm using 

g77 version gcc-2.96 19990707 (experimental) 
(from FSF-g77 version 0.5.25 19990628 (experimental))

to compile some fortran code.  [For what follows I've used -O0 -g
-ffortran-bounds-check for options].  In my main program, I have lots
of loops inside of of which I put the following:

                  write(*,fmt=10,err=101)(s(ii),ii=1,2),
     $                 ((sum(ii,jj),jj=1,2),ii=1,2)
 10              format(1x,2d13.5,5x,2d13.5/31x,2d13.5)
                  stop
 101              stop 'write error'

s(2) and sum(2,2) are declared real*8.  The debugger shows me calling
the write, but nothing is output.  If I change the format to *, it
works.  If I remove the stops, the program completes and outputs
reasonable(?) numbers (via other write(*,*) statements).  I also get
the same behavior using egcs-1.1.2.  Finally, if I simply lift out the
write and it's format and put it into a simple test program (with s
and sum initialized via a data statement), the resulting program
works.

Unfortunately, I don't have a small test case that shows the problem as
the progam depends quite heavily on a large precompiled library.

Any thoughts/suggestions?

David

Re: Strange format error in g77

[craig]

>Unfortunately, I don't have a small test case that shows the problem as
>the progam depends quite heavily on a large precompiled library.
>
>Any thoughts/suggestions?

Make sure you don't depend on the output being printed by stepping through
a WRITE statement in the debugger -- you might want to insert a
"CALL FLUSH" or similar statement.  (Heck, calling the G77_flush_0 routine
from within the debugger might work!)

Other than that -- which might not be helpful -- I can't think of anything
obvious to suggest.

        tq vm, (burley)
>From law@cygnus.com Tue Jul 13 13:08:00 1999
From: Jeffrey A Law <law@cygnus.com>
To: Alexandre Oliva <oliva@dcc.unicamp.br>
Cc: Richard Henderson <rth@cygnus.com>, egcs-bugs@egcs.cygnus.com, egcs-patches@egcs.cygnus.com
Subject: Re: shared libstdc++ is broken on alphaev56-dec-osf4.0d 
Date: Tue, 13 Jul 1999 13:08:00 -0000
Message-id: <11932.931896370@upchuck.cygnus.com>
References: <ork8s4bhhp.fsf@cupuacu.lsd.dcc.unicamp.br>
X-SW-Source: 1999-07/msg00498.html
Content-length: 1672

  In message < ork8s4bhhp.fsf@cupuacu.lsd.dcc.unicamp.br >you write:
  > Anyway, if your position is to recommend static libstdc++, I see no
  > reason to reject my patch, given that it fixes a very serious problem
  > in a configuration that's broken and not recommended anyway, it's
  > platform specific and has minimal impact.  The other option is to
  > change libstdc++/configure.in to completely disable shared library
  > support on OSF, or at least emit large blinking warnings that it's
  > broken, which doesn't seem reasonable to me if there's such a trivial
  > patch that fixes the problem.
Sorry.  This is not going into this release.  First and foremost, the change is
wrong.  Shared libraries need to be self-contained.  Anything else is not
acceptable.  Thus it is not acceptable to simply remove libgcc from a shared
library link line.

In addition to simply being wrong you'll introduce a new and terrible
incompatibility with previous tools because if someone rebuilds a shared
library, it will now be incomplete and there's a good chance it will not
longer work (and thus break any applications which used that library).

This is nearly identical to all the problems that surfaced when some symbols
were made weak in the EH code in egcs-1.1.2.  It was a complete and total
disaster and we do *NOT* want to repeat it.

What we have to do (not for gcc-2.95) is find a way to prevent shared libraries
from re-exporting symbols they get from libgcc.

This change is not going into gcc-2.95.  No way.  Sorry.

I would recommend writing a suitable entry for the FAQ or installation
instructions which discusses the issues and possible workarounds.

jeff

Re: Strange format error in g77

[David M. Ronis]

In trying to pare down my code in order to get a small test case, I
finally discovered that the problem was being triggered when I linked
a shared library (of mainly of fortran code, but with some C) that had
been build with one of the egcs releases.  (Probably with a slew of
malign options, which I no longer use with gcc-2.96).  I played around
with nm but never found something obvious and finally rebuilt my
library with the current CVS.

The problem went away.  

I'd appreciate it if someone could explain why and whether/when I'll
have to rebuild other libraries.  Indeed, if this is not some kind of
dumb error on my part, it should also be mentioned in the docs for the
upcoming release.

David