Re: lots of trouble with rs6000-ibm-aix3.2.5

Re: lots of trouble with rs6000-ibm-aix3.2.5

[Kate Hedstrom]

>   > I started by trying "configure; make" on the IBM and got as far as:
>   > 
>   >         ./move-if-change tmp-attrtab.c insn-attrtab.c
>   >         touch stamp-attrtab
>   >         gcc  -DIN_GCC    -g -O2   -DHAVE_CONFIG_H     -I. -I. -I./config -c
>   >  insn-attrtab.c
>   > gcc: Internal compiler error: program cc1 got fatal signal 9
>   > The error code from the last failed command is 1.
> Note, compiling insn-attrtab can require huge amounts of memory,
> especially when optimizing.
> 
> Make sure you don't have any soft memory limits and that you've
> got plenty of swap space.

Sorry, it looks like I have egcs on my face for that.  I tried again on
a twin machine with more memory and got as far as:

        rm -f milli.exp
        cp ./config/rs6000/milli.exp ./milli.exp
        /d0/kate/gnu/egcs-970825/gcc/xgcc -B/d0/kate/gnu/egcs-970825/gcc/  -DIN_
GCC    -g -O2 -I./include  -I. -I. -I./config \
                -c ./objc/hash.c -o objc/hash.o
xgcc: Internal compiler error: program cc1 got fatal signal 6
The error code from the last failed command is 1.

Make Quitting.

So it made it through building gcc, g++, and g77.

Kate

Re: g77 configuring, docs (was Re: 970825 Snapshot Available)

[Jeffrey A Law]

  In message <199708270645.CAA06014@churchy.gnu.ai.mit.edu>you write:
  > >I'm tempted to do both a gcc2 -> egcs and f77dev -> egcs merge
  > >as soon as we get the first release out the door.  I don't think
  > >we want to introduce too much new code this close to a release.
  > 
  > The patches to fix up the g77 docs are *very* safe, in case
  > you're wondering -- aside from deleting a gratuitous (and
  > non-conforming-in-ANSI-C ;-) comma after the last item in
  > an enum, they affect only the documentation, not the compiler
  > or the library.  (I'm referring to patches to intdoc.c, intrin.h,
  > the intdoc.in->intdoc.h renaming, and so on.)
  >
  > Generally, the fixes I'm making to other parts of g77 are quite
  > safe too, because I have a release coming up in less than a week,
  > but only alpha testing and the release itself will "prove" just
  > how safe these fixes are.
[ ... ]
In that case, it might make sense to bring them forward into egcs
now instead of after the first egcs release.  Having the egcs and
g77 releases based on the same front end just seems like a good
thing to me :-)

Depending on how much time I can find tonight, I'll try to integrate
the latest changes, then get an egcs snapshot made (or at least
started and let the test build run overnight).
jeff

Re: g77 configuring, docs (was Re: 970825 Snapshot Available)

[Craig Burley]

>I'm tempted to do both a gcc2 -> egcs and f77dev -> egcs merge
>as soon as we get the first release out the door.  I don't think
>we want to introduce too much new code this close to a release.

The patches to fix up the g77 docs are *very* safe, in case
you're wondering -- aside from deleting a gratuitous (and
non-conforming-in-ANSI-C ;-) comma after the last item in
an enum, they affect only the documentation, not the compiler
or the library.  (I'm referring to patches to intdoc.c, intrin.h,
the intdoc.in->intdoc.h renaming, and so on.)

Generally, the fixes I'm making to other parts of g77 are quite
safe too, because I have a release coming up in less than a week,
but only alpha testing and the release itself will "prove" just
how safe these fixes are.

One of the reasons I did the intdoc.in->intdoc.h change *now*,
instead of putting it off, is that I wanted to reduce the size
of future .diff files that would be needed to make the effective
rename.  g77 0.5.20 already had intdoc.h, it is true, but it
was quite small compared to the one pending for 0.5.21, which is
"full" (every single intrinsic documented!), so it seemed like
now was a worthwhile time to switch.

In the larger scale of egcs, I doubt this concern would amount
to much, as I expect the part of a future release->release patch
to rename intdoc.in to intdoc.h will amount to less than 1% of
the total patch.  ;-)

        tq vm, (burley)

Re: g77 configuring, docs (was Re: 970825 Snapshot Available)

[Jeffrey A Law]

  > P.S. I've put a new patch into ~fortran/dev/ (g77-970824.diff.gz)
  > that is my first attempt to fix the problem whereby people can't
  > build g77 docs from scratch without gcc.
Very cool.

  > Instead, any ANSI C compiler should be okay.  Jeff is pretty
  > busy, and I am too busy still to get into patching egcs myself,
  > but maybe Jeff will get some time to apply this soon
I'm tempted to do both a gcc2 -> egcs and f77dev -> egcs merge
as soon as we get the first release out the door.  I don't think
we want to introduce too much new code this close to a release.

But, yes,  it's very cool stuff.

  > he's done a great job so far IMO.
Thanks.

  > P.P.S. BTW am I correct in assuming that being able to build
  > everything (g77 docs, someday g77, and everything else, but I
  > think g77's the only problem child right now?) using an ANSI C,
  > not K&R C, compiler is the main concern? 
Well, K&R would be even better (some vendors ship bundled compilers
which are K&R only), but being able to build with ANSI C is a big
enough win by itself to make it worth the effort to remove the
GNU-isms.

And we may find that the K&R first stage issues become less and
less of an issue as our build procedures improve and fewer and
fewer companies ship old lame-o K&R compilers with systems and
force users to pay for ANSI compilers.

Jeff

g77 configuring, docs (was Re: 970825 Snapshot Available)

[Craig Burley]

>I am already working on your SMP patch.  I expect to check it in today
>unchanged.  My only comment is to notice that the f/runtime Makefile is
>missing dependencies.  If one of the lib*77 libraries is updated, libf2c.a
>won't be updated.  There were some partial dependencies for this before your
>change, but they were flawed, so I does appear that they should be removed.
>Still, it seems that this should be fixed someday.

g77's procedures for building libf2c have "evolved", to put it mildly,
over the past couple of years.  Dave Love has done most of the real
work, but as his work has given me some examples to learn and gain
confidence from, I've done more of it myself lately as well.

The problems with building libf2c.a include:

  -  Can't just go into each libF77, libI77, and now libU77 directory,
     build the objects there, and then have make decide whether to
     update the library from each directory's objects independently,
     certainly not from a lib?77.a library in each directory.  Why?
     Because otherwise make might decide, after it updates libf2c.a
     from libF77, it doesn't need to bother with libI77 (even if it
     has compiled new object files there) because libf2c.a is now
     "newer" than libI77.a or any of its objects.

  -  Can't just blindly add all the necessary objects every time one
     does "make install", else people installing in NFS contexts
     without permission to change files in the build directory but
     with permission to install them will run into trouble.

So, g77 0.5.20 and 0.5.21 build the individual objects in each subdirectory,
and the updating of each object into libf2c.a is made as a "wholesale"
decision -- that is, for all objects newer than libf2c.a, add *all*
those objects to libf2c.a at the same time.  If there are problems
with this, let me know, in case I can fix them before they bite us
in the 0.5.21 (non-egcs) release!

Then there are those little wrappers, which are added one at a time,
a la libgcc1.a and friends, but this is kinda slow (not fixincludes
slow, but each wrapper takes longer to compile and add on my i486 than
compiling each actual lib?77 routine).  This is done anytime *any*
updating of libf2c.a is done by make.

The idea is that, for people who don't change any sources midstream,
no library stuff gets built or added to libf2c.a after the first
build -- which is an improvement over old g77 releases.  And if a few
routines are changed, only those routines are compiled and added to
libf2c.a, but all those little wrappers will also be compiled and added,
which is kind of a pain.  (Maybe someday this'll be changed to
compile all the objects first, then add them wholesale; the reason
normal building of this isn't done now is just to avoid having
all those little wrappers' object files sitting around in each
stageN/ directory, but they could be built in a temporary `libE77'
directory, added wholesale, then "rm -fr libE77" would solve the
disk-space problem.)

        tq vm, (burley)

P.S. I've put a new patch into ~fortran/dev/ (g77-970824.diff.gz)
that is my first attempt to fix the problem whereby people can't
build g77 docs from scratch without gcc.  Instead, any ANSI C
compiler should be okay.  Jeff is pretty busy, and I am too busy
still to get into patching egcs myself, but maybe Jeff will get
some time to apply this soon -- he's done a great job so far IMO.

P.P.S. BTW am I correct in assuming that being able to build
everything (g77 docs, someday g77, and everything else, but I
think g77's the only problem child right now?) using an ANSI C,
not K&R C, compiler is the main concern?  I'd hate to waste any
time occasionally fixing up g77's GNUisms only to find out all
the ANSI-not-K&R stuff had to be fixed as well for the work
to be worthwhile, so if that's the case, let me know.  (I'm
assuming the old SunOS `cc' isn't the main reason for wanting
to not require `gcc', that most non-gcc compilers we want to
support are ANSI C, so let me know if I'm wrong about that.)