egcs and g77

egcs and g77

[Juan Casero]

Greetings everyone -

I have been using egcs for some time now on my RedHat 5.0 Linux box with
no problems.  The compiler seems to generate very efficient and stable
code.  I do not wish to start a debate about the merits of g77 or f2c
but my past experience with g77 has been that it often either fails to
compile standard fortran 77 code or it generates the wrong code when
compiled with optimizations turned on.  I plan to write some Fortran 77
code and I expect I will need to debug it with DDD.  Therefore I need to
use g77 to compile my code but I hesitate  to use it because of my
previous experience with the front end.  Has g77 received the same
attention and improvements as gcc in the egcs development project?  Can
I trust g77 to reliably generate the proper code with optimizations
turned on?  As I said I really don't want to start a debate so please a
simple yae or nae ( feel free to elaborate as long as it doesn't become
argumentative) will suffice.


Thank You.

--
Juan Casero
email:  casero@beowulf.cox.miami.edu
   __   _
  / /  (_)__  __ ____  __
 / /__/ / _ \/ // /\ \/ /  . . .  t h e   c h o i c e   o f   a
/____/_/_//_/\_,_/ /_/\_\              G N U   g e n e r a t i o n . . .

Re: egcs and g77

[Toon Moene]

>  I do not wish to start a debate about the merits of g77
>  or f2c but my past experience with g77 has been that it
>  often either fails to compile standard fortran 77 code
>  or it generates the wrong code when compiled with
>  optimizations turned on.

Unfortunately, you never sent fortran@gnu.org any examples of such  
failures, so it is hard to say whether they've been solved in the  
mean time (if they were the compiler's fault).

>  Can I trust g77 to reliably generate the proper code with
>  optimizations turned on?  As I said I really don't want
>  to start a debate so please a simple yae or nae ... will
>  suffice.

We cannot answer such a broad question with a simple yes or no.  Of  
course we try to get the compiler bug-free, but in such a large  
project, there will always be corners containing bugs.

My experience is that for our code (a 1300-routine numerical  
weather forecasting system) egcs is without failure, but you should  
note that we don't do any complex arithmetic, and I only tested it  
on my m68k-next-nextstep3 system.

Perhaps you can send us some of the failures you get ?  Please send  
them to fortran@gnu.org - if they are of general interest to the  
egcs crowd, we will forward them here.

Thanks,

--
Toon Moene ( mailto:toon@moene.indiv.nluug.nl )
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: mailto:fortran@gnu.org ; NWP: http://www.knmi.nl/hirlam

Re: egcs and g77

[Dave Love]

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

[the right stuff]

 Toon> Perhaps you can send us some of the failures you get ?

... but certainly not before at least reading the `Working Programs'
node of the g77 manual!  If claiming g77 fails to compile
standard-conforming code, you probably need to reference the relevant
clauses of the Fortran77 and/or Fortran9[05] standard.

Re: egcs and g77

[Juan Casero]

Are you suggesting that g77 can compile Fortran 90 and/or Fortran 95 code? 
Where is the g77 manual?  I was not even aware there was such a thing.  As they
say ignorance is not an excuse so I offer none.

Cheers....

On 05-Jul-98 Dave Love wrote:
>>>>>> "Toon" == Toon Moene <toon@moene.indiv.nluug.nl> writes:
> 
> [the right stuff]
> 
>  Toon> Perhaps you can send us some of the failures you get ?
> 
> ... but certainly not before at least reading the `Working Programs'
> node of the g77 manual!  If claiming g77 fails to compile
> standard-conforming code, you probably need to reference the relevant
> clauses of the Fortran77 and/or Fortran9[05] standard.

Juan Casero
email:  casero@beowulf.cox.miami.edu
   __   _
  / /  (_)__  __ ____  __
 / /__/ / _ \/ // /\ \/ /  . . .  t h e   c h o i c e   o f   a
/____/_/_//_/\_,_/ /_/\_\              G N U   g e n e r a t i o n . . .

Re: egcs and g77

[Toon Moene]

[ To Juan's defense, he explained to me that software licences might
  prohibit him from sending the code g77 can't compile - he will
  e-mail me the error message(s), and - who knows - after some waving
  of dead chickens, I might have a bright moment and spot the error ]

>  Where is the g77 manual?  I was not even aware there was
>  such a thing.  As they say ignorance is not an excuse so
>  I offer none.

[ Sorry, can't resist: ]

Wow, I've been used to people writing fortran@gnu.org who couldn't  
find the answer to their question in the g77 manual in spite of the  
fact that it was there, properly indexed, but you win hands down on  
this front:  The g77 manual is the g77.texi file in the  
.../egcs/gcc/f directory.  The "info" files that are made from this  
file by makeinfo can be viewed with the `info' program or `emacs'.   
An alternative route is to convert them to HTML using `texi2html',  
or to Postscript via `tex' and `dvips' (if you have a DVI viewer on  
your system the last step might not even be necessary, unless you  
want to actually print the manual; however, do realise that this  
material is in a kind of flux).

Hope This Helps,
Toon.

Should web host docs? Was: egcs and g77

[Robert Lipe]

Some dude wrote:

> >  Where is the g77 manual?  I was not even aware there was such a
> >  thing.  As they say ignorance is not an excuse so

Toon Moene wrote:

[ a perfectly reasonable answer ]

> directory.  The "info" files that are made from this file by makeinfo
> can be viewed with the `info' program or `emacs'.  An alternative

In the days when every GNU software user had built (or written) the
software themselves, I think we could more reasonably expect users to
know (or be able to intuit) answers of this form.

> route is to convert them to HTML using `texi2html', or to Postscript
> via `tex' and `dvips' (if you have a DVI viewer on your system the

Would it be worthwhile - at least for releases - to spin these files
and include links in the doc or on the egcs web pages?

If it's decided worthwhile, I suppose I can add the Makefile targets
to populate wwwdocs or whatever.   

RJL

Re: Should web host docs? Was: egcs and g77

[Dave Love]

>>>>> "RL" == Robert Lipe <robertl@dgii.com> writes:

 RL> In the days when every GNU software user had built (or written)
 RL> the software themselves, I think we could more reasonably expect
 RL> users to know (or be able to intuit) answers of this form.

Is egcs-g77 different to any other official RedHat package, though?
It does install the info dir entry.

 RL> If it's decided worthwhile, I suppose I can add the Makefile
 RL> targets to populate wwwdocs or whatever.

If you do, use the current texi2html from ftp.cs.umb.edu/pub/tex.  It
was hacked to cope with recent Texinfo features used by the g77
manual.  Personally, I'd prefer somehow to get people reading what
they have locally (even though the Network was the Computer long
before it was a trademark).

BTW, I think the g77 doc needs a going over before egcs 1.1 to fix
stuff pertaining to the g77+gcc-2.8 incarnation.

Re: Should web host docs? Was: egcs and g77

[Craig Burley]

>BTW, I think the g77 doc needs a going over before egcs 1.1 to fix
>stuff pertaining to the g77+gcc-2.8 incarnation.

Absolutely.  I've got this on my (virtual) list of things to take
care of.

        tq vm, (burley)

Re: egcs and g77

[Craig Burley]

>On 05-Jul-98 Dave Love wrote:
>> ... but certainly not before at least reading the `Working Programs'
>> node of the g77 manual!  If claiming g77 fails to compile
>> standard-conforming code, you probably need to reference the relevant
>> clauses of the Fortran77 and/or Fortran9[05] standard.

>Are you suggesting that g77 can compile Fortran 90 and/or Fortran 95 code? 
>Where is the g77 manual?  I was not even aware there was such a thing.  As they
>say ignorance is not an excuse so I offer none.

Yet, it does seem like many more of the questions re g77 that suggest
the docs have not been read come via the egcs route.  egcs might have
become very popular, moreso than the gcc/g77 combination, especially among
new g77 users, which could explain the difference.  But it might also be
that the "pretty wrapping" packaging aspects of egcs, vis-a-vis its
supported languages, need ironing out.  And it might well be that they
already are in egcs 1.1-in-development; we've made some fixes to
how the g77 docs are installed, FWIW.  `info g77' should work, for
example, after a normal installation of egcs 1.1.

Also, it seems more likely people will think to look for and find
the g77 docs when they've had to take the extra step to obtain g77
instead of just getting it for "free" with most any egcs distribution.

Re F90/F95 -- g77 does support a few of the "easier" features of F90,
and soon maybe F95 (probably an intrinsic or two), which is why
we're interested in bugs g77 has regarding those features, and of
course we can't insist people tell us how those bugs indicate
violations of the F77 standard.  :)

But, generally, no, g77 can't yet compile F90 code.  We figure a g90
project will be nedeed to ever make that happen, though maybe g77
will "extend" itself to support many examples of F90 code down
the road.

        tq vm, (burley)

Re: egcs and g77

[Dave Love]

I wrote my comment about standards carelessly.  The f90/5 standards
are only relevant for post-f77 features or interpretations which g77
claims to support, since it's basically an f77 compiler.  An example
is some `f90' intrinsics; I've just been referring to the current
standard for these.  Some of the f90 features which are present may be
supported incompletely (e.g. SELECT CASE, IIRC).

Re: egcs and g77

[Martin von Loewis]

> As I said I really don't want to start a debate so please a simple
> yae or nae.

I can offer a clear 'dunno'. AFAIK, integration of the g77 front-end
with the backend was given quite some attention in egcs; and
optimization bugs would usually count as a back-end problem.  OTOH,
the gcc and g++ front-end are certainly used by more users than the
objc and g77 front-ends.

The reason I respond at all is simple: If you don't report the bugs,
they won't get fixed. So I'd suggest that you try the compiler and see
how it works out. If you think you find a bug, report it. Include
every information you can, even source code, if possible. 

Regards,
Martin

Re: egcs and g77

[N8TM]

In a message dated 7/4/98 4:54:34 AM Pacific Daylight Time,
toon@moene.indiv.nluug.nl writes:

> >  Can I trust g77 to reliably generate the proper code with
>  >  optimizations turned on?  As I said I really don't want
>  >  to start a debate so please a simple yae or nae ... will
>  >  suffice.

Well, no one can give a simple answer; for one thing, bugs in codes often show
up when optimization is on.  Many such problems are results of incorrect
initialization, or other non-standard stuff which worked on many compilers
over the years.  The problem is not just with g77; commercial f90 compilers
have dropped backwards compatibility with non-standard ibm360 fortran.  I wish
g77 had more complete diagnostics for some of these uglies, but wishing also
obligates us to document where warnings are needed but not yet available.  One
area where better diagnostics would help is in the flagging of improper or
unreliable use of undeclared character strings.

I maintain one of those fortran codes which dates back over the years, and I
have fixed enough bugs so that g77 is the most modern compiler which runs it
totally cleanly, no matter which compiler switches are on, and g77 is the only
compiler which runs the same across architectures.

g77 has options which make all variables static and initially zero, and all
local variables are visible in debug even with optimization.   Use these
options when needed.  There is no automatic switching of uninitialized
variables to static.  Such features of other compilers, while they often
eliminate bugs, do cause performance problems, and they don't cure the non-
portability.

Re: egcs and g77

[Craig Burley]

>There is no automatic switching of uninitialized
>variables to static.

Are there cases where this would be useful?  I.e. -fno-uninit-automatic?

Though, if by "uninitialized" you mean "not given initial values
via DATA [etc.]", I assume it'd have the exact same effect as
-fno-automatic.  Or, if by that you mean "compiler warnings report
these as possibly uninitialized", then it'd be really really hard
to do.

So maybe I shouldn't ask.  :)

        tq vm, (burley)