Stabilization Status

Stabilization Status

[Jeffrey A Law]

I'm running a series of -funroll-loops tests now.  I'm currently trying to
debug a mis-compilation of stage2 genattrtab.c on the mips targets.  More
details as they're available.




Fun fun fun.
jeff

Re: Stabilization status

[Mike Stump]

> Date: Fri, 19 Feb 1999 17:40:06 +0100 (MET)
> From: Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>

> Here we also have some duplication, in that the GCC texinfo manual
> and wwwdocs/htdocs/install overlap.

> How should we handle that in the long term?

Yeah, I saw that one coming...  One way to think about it is, the web
site can beta information, and when it proves its value longer term
(how does it do that?), it can move to the texi file.  Also, volatile
information or timely information is better suited to the web.

The texi file is for the really good stuff that you might want to
print into a book and buy a copy of every three years.  If the
information you put into the texi file will quickly be out of date or
wrong, better to not put it in the texi file in the first place.  This
last point might be contentious.

A classic example of something that expires quickly, are random bugs
in the compiler.  The printed form will survive 100+ years, we hope
that the electronic form (the gcc binary people use) doesn't survive a
year.

Also, one can htmlize the texi and remove dups from the web site and
just put in pointers into the htmlized texi.  That way, if you want to
say more in the web version, you can, and then link to the texi for
the base discussion.

Re: Stabilization status

[craig]

>The texi file is for the really good stuff that you might want to
>print into a book and buy a copy of every three years.  If the
>information you put into the texi file will quickly be out of date or
>wrong, better to not put it in the texi file in the first place.  This
>last point might be contentious.

Perhaps a bit...

>A classic example of something that expires quickly, are random bugs
>in the compiler.  The printed form will survive 100+ years, we hope
>that the electronic form (the gcc binary people use) doesn't survive a
>year.

...one of the things I like about putting complete known-bugs lists
in the documentation that accompanies the release of a product is,
there's less likelihood someone will be "surprised" by a bug (or
deficiency).

Still, the proliferation of Web access around the globe does seem
to be making for a very different world in this respect.  Used to be
that the percentage of people who'd end up with a distribution of a
free-software product (like g77) *and* could take the time to check
out the latest on-line information (g77.plan) without taking a big
hit in productivity was too low to simply say "for lists of known
bugs, deficiencies, and installation instructions, see ...g77.plan".

Such users are somewhat "hibernative" (I'm this way too, in some
cases): they get active for awhile, grab everything they can (off
the net, off of tape/disk, get printed manuals), and then want (or
have) to be able to go into a "cave" (no real net access) somewhere
and make use of it all.

These users don't appreciate having information deliberately withheld,
though they need to recognize some info simply wasn't available during
their "gathering time".

However, the percentage of such users is much higher now, probably well
into the majority (if it wasn't before).

So, for a rapidly evolving (bazaar-development-style) project like
egcs, it might make sense to kick documentation of the more fluid
aspects of the product to the Web pages.

        tq vm, (burley)

Re: Stabilization status

[Joern Rennecke]

> Such users are somewhat "hibernative" (I'm this way too, in some
> cases): they get active for awhile, grab everything they can (off
> the net, off of tape/disk, get printed manuals), and then want (or
> have) to be able to go into a "cave" (no real net access) somewhere
> and make use of it all.

Such a user would probably better served with a proper release than with
a snapshot.  So I think it would make sense at release time, if any
bugs remain that we know about and decide not to fix in the release,
document them.

Re: Stabilization status

[craig]

>> Such users are somewhat "hibernative" (I'm this way too, in some
>> cases): they get active for awhile, grab everything they can (off
>> the net, off of tape/disk, get printed manuals), and then want (or
>> have) to be able to go into a "cave" (no real net access) somewhere
>> and make use of it all.
>
>Such a user would probably better served with a proper release than with
>a snapshot.  So I think it would make sense at release time, if any
>bugs remain that we know about and decide not to fix in the release,
>document them.

Oh, of course; I thought we were referring to releases all along.
Definitely, people shouldn't grab the latest snapshot and then
go into hibernation, thinking they've got a coherent product!!

It's that last sentence I'm particular hesitant to disagree with,
even though there's inevitably going to be some kind of duplication
(at least in presentation) between "known bugs" in the distributed
(released) documentation and the "known bugs" we put up on the web.

        tq vm, (burley)

Re: Stabilization status

[craig]

>> Such users are somewhat "hibernative" (I'm this way too, in some
>> cases): they get active for awhile, grab everything they can (off
>> the net, off of tape/disk, get printed manuals), and then want (or
>> have) to be able to go into a "cave" (no real net access) somewhere
>> and make use of it all.
>
>Such a user would probably better served with a proper release than with
>a snapshot.  So I think it would make sense at release time, if any
>bugs remain that we know about and decide not to fix in the release,
>document them.

Oh, of course; I thought we were referring to releases all along.
Definitely, people shouldn't grab the latest snapshot and then
go into hibernation, thinking they've got a coherent product!!

It's that last sentence I'm particular hesitant to disagree with,
even though there's inevitably going to be some kind of duplication
(at least in presentation) between "known bugs" in the distributed
(released) documentation and the "known bugs" we put up on the web.

        tq vm, (burley)

Re: Stabilization status

[Joern Rennecke]

> Such users are somewhat "hibernative" (I'm this way too, in some
> cases): they get active for awhile, grab everything they can (off
> the net, off of tape/disk, get printed manuals), and then want (or
> have) to be able to go into a "cave" (no real net access) somewhere
> and make use of it all.

Such a user would probably better served with a proper release than with
a snapshot.  So I think it would make sense at release time, if any
bugs remain that we know about and decide not to fix in the release,
document them.

Re: Stabilization status

[Gerald Pfeifer]

On 19 Feb 1999 craig@jcb-sc.com wrote:
> These users don't appreciate having information deliberately withheld,
> though they need to recognize some info simply wasn't available during
> their "gathering time".
> [...]
> So, for a rapidly evolving (bazaar-development-style) project like
> egcs, it might make sense to kick documentation of the more fluid
> aspects of the product to the Web pages.

I believe the way to go here is to add that kind of documentation to
the distribution for releases and snapshots and also put an up-to-date
version of that documentation on the web, where the URL is specified 
also in the distributed version.

We already to that for our FAQ

  EGCS Frequently Asked Question

  The latest version of this document is always available at
  http://egcs.cygnus.com/faq.html . 

and c++bugs.html (soon to become bugs.html), and I will add this for
the installation notes as well. (The latter is important so that we
can spread information about vendor patches and similiar issues, which
may become known only after the release has been rolled out.) 

Gerald
-- 
Gerald Pfeifer (Jerry)      Vienna University of Technology
pfeifer@dbai.tuwien.ac.at   http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Stabilization status

[Jeffrey A Law]

  In message < Pine.GSO.4.10.9902210219450.2483-100000@alphard.dbai.tuwien.ac.at
>you write:
  > We already to that for our FAQ
  > 
  >   EGCS Frequently Asked Question
  > 
  >   The latest version of this document is always available at
  >   http://egcs.cygnus.com/faq.html . 
  > 
  > and c++bugs.html (soon to become bugs.html), and I will add this for
  > the installation notes as well. (The latter is important so that we
  > can spread information about vendor patches and similiar issues, which
  > may become known only after the release has been rolled out.) 
And we want the same for the installation info, since there may be tidbits
we find out about specific systems after releases.

jeff

Re: Stabilization status

[Jeffrey A Law]

  In message < Pine.GSO.4.10.9902210219450.2483-100000@alphard.dbai.tuwien.ac.at
>you write:
  > We already to that for our FAQ
  > 
  >   EGCS Frequently Asked Question
  > 
  >   The latest version of this document is always available at
  >   http://egcs.cygnus.com/faq.html . 
  > 
  > and c++bugs.html (soon to become bugs.html), and I will add this for
  > the installation notes as well. (The latter is important so that we
  > can spread information about vendor patches and similiar issues, which
  > may become known only after the release has been rolled out.) 
And we want the same for the installation info, since there may be tidbits
we find out about specific systems after releases.

jeff

Re: Stabilization status

[Gerald Pfeifer]

On 19 Feb 1999 craig@jcb-sc.com wrote:
> These users don't appreciate having information deliberately withheld,
> though they need to recognize some info simply wasn't available during
> their "gathering time".
> [...]
> So, for a rapidly evolving (bazaar-development-style) project like
> egcs, it might make sense to kick documentation of the more fluid
> aspects of the product to the Web pages.

I believe the way to go here is to add that kind of documentation to
the distribution for releases and snapshots and also put an up-to-date
version of that documentation on the web, where the URL is specified 
also in the distributed version.

We already to that for our FAQ

  EGCS Frequently Asked Question

  The latest version of this document is always available at
  http://egcs.cygnus.com/faq.html . 

and c++bugs.html (soon to become bugs.html), and I will add this for
the installation notes as well. (The latter is important so that we
can spread information about vendor patches and similiar issues, which
may become known only after the release has been rolled out.) 

Gerald
-- 
Gerald Pfeifer (Jerry)      Vienna University of Technology
pfeifer@dbai.tuwien.ac.at   http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Stabilization status

[craig]

>The texi file is for the really good stuff that you might want to
>print into a book and buy a copy of every three years.  If the
>information you put into the texi file will quickly be out of date or
>wrong, better to not put it in the texi file in the first place.  This
>last point might be contentious.

Perhaps a bit...

>A classic example of something that expires quickly, are random bugs
>in the compiler.  The printed form will survive 100+ years, we hope
>that the electronic form (the gcc binary people use) doesn't survive a
>year.

...one of the things I like about putting complete known-bugs lists
in the documentation that accompanies the release of a product is,
there's less likelihood someone will be "surprised" by a bug (or
deficiency).

Still, the proliferation of Web access around the globe does seem
to be making for a very different world in this respect.  Used to be
that the percentage of people who'd end up with a distribution of a
free-software product (like g77) *and* could take the time to check
out the latest on-line information (g77.plan) without taking a big
hit in productivity was too low to simply say "for lists of known
bugs, deficiencies, and installation instructions, see ...g77.plan".

Such users are somewhat "hibernative" (I'm this way too, in some
cases): they get active for awhile, grab everything they can (off
the net, off of tape/disk, get printed manuals), and then want (or
have) to be able to go into a "cave" (no real net access) somewhere
and make use of it all.

These users don't appreciate having information deliberately withheld,
though they need to recognize some info simply wasn't available during
their "gathering time".

However, the percentage of such users is much higher now, probably well
into the majority (if it wasn't before).

So, for a rapidly evolving (bazaar-development-style) project like
egcs, it might make sense to kick documentation of the more fluid
aspects of the product to the Web pages.

        tq vm, (burley)

Re: Stabilization status

[Mike Stump]

> Date: Fri, 19 Feb 1999 17:40:06 +0100 (MET)
> From: Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>

> Here we also have some duplication, in that the GCC texinfo manual
> and wwwdocs/htdocs/install overlap.

> How should we handle that in the long term?

Yeah, I saw that one coming...  One way to think about it is, the web
site can beta information, and when it proves its value longer term
(how does it do that?), it can move to the texi file.  Also, volatile
information or timely information is better suited to the web.

The texi file is for the really good stuff that you might want to
print into a book and buy a copy of every three years.  If the
information you put into the texi file will quickly be out of date or
wrong, better to not put it in the texi file in the first place.  This
last point might be contentious.

A classic example of something that expires quickly, are random bugs
in the compiler.  The printed form will survive 100+ years, we hope
that the electronic form (the gcc binary people use) doesn't survive a
year.

Also, one can htmlize the texi and remove dups from the web site and
just put in pointers into the htmlized texi.  That way, if you want to
say more in the web version, you can, and then link to the texi for
the base discussion.

Stabilization status

[Jeffrey A Law]

                                    
                                    -O0     -O1     -O2     -O9     -Os
alpha-dec-osf4.0a                    failing -- the inline problem
alphaev56-unknown-linux-gnu          Y       Y       Y       Y       Y
hppa2.0-hp-hpux10.20                 Y       Y       Y       Y       Y
i386-unknown-freebsd2.2.6            Y       Y       Y       Y       Y
i586-pc-linux-gnu 		     Y       Y       Y       Y       Y  
i686-pc-linux-gnu                    Y       Y       Y       Y       Y
m68k-hp-bsd4.4                       Y       Y       Y       Y       Y
mips-sgi-irix6.5                     Y       Y       Y       Y       Y
powerpc-ibm-aix4.2.0.0               N  fails building libgcc1 
powerpc-unknown-linux-gnulibc1       Untested
sparc-sun-solaris2.5.1               Y       Y       Y       Y       Y
sparc-sun-sunos4.1.1                 failing -- the inline problem



fixheader/fixproto seem to be spewing out many more warnings/errors than
before.  This needs to be investigated.

I also need to retest alpha-osf & sparc-sunos now that the inline problem
has been fixed.


The ppc port seems to be badly broken.  Meissner?  Any word on getting it
fixed?

jeff

Re: Stabilization status

[Zack Weinberg]

On Tue, 02 Feb 1999 11:01:57 -0700, Jeffrey A Law wrote:
>
>fixheader/fixproto seem to be spewing out many more warnings/errors than
>before.  This needs to be investigated.

Might conceivably be due to recent changes in cpplib.  What
warnings/errors were you getting?  (I don't have a system that needs
fixheader and can compile snapshots in a reasonable length of time.)

zw

Re: Stabilization status

[Jeffrey A Law]

  In message < 199902021837.NAA06399@blastula.phys.columbia.edu >you write:
  > On Tue, 02 Feb 1999 11:01:57 -0700, Jeffrey A Law wrote:
  > >
  > >fixheader/fixproto seem to be spewing out many more warnings/errors than
  > >before.  This needs to be investigated.
  > 
  > Might conceivably be due to recent changes in cpplib.  What
  > warnings/errors were you getting?  (I don't have a system that needs
  > fixheader and can compile snapshots in a reasonable length of time.)
For example, on aix4.2 I now get this kind of stuff from fix-header:

/nfs/sethra/can/law/ppc/gcc/include/root/usr/lpp/X11/include/X11/Intrinsic.h:0: warning: `__STDC__' redefined
/nfs/sethra/can/law/ppc/gcc/include/root/usr/lpp/X11/include/X11/Xfuncs.h:0: warning: `__STDC__' redefined
/nfs/sethra/can/law/ppc/gcc/include/root/usr/lpp/X11/include/X11/Xi18nlib.h:0: warning: `__STDC__' redefined
/nfs/sethra/can/law/ppc/gcc/include/root/usr/lpp/X11/include/X11/Xlibint.h:0: warning: `__STDC__' redefined
/nfs/sethra/can/law/ppc/gcc/include/root/usr/lpp/X11/include/X11/Xlocale.h:0: warning: `__STDC__' redefined
/nfs/sethra/can/law/ppc/gcc/include/root/usr/lpp/X11/include/X11/Xosdefs.h:0: warning: `__STDC__' redefined
/nfs/sethra/can/law/ppc/gcc/include/root/usr/lpp/X11/include/X11/shrmem.h:0: warning: `__STDC__' redefined
/nfs/sethra/can/law/ppc/gcc/include/X11/Intrinsic.h:0: warning: `__STDC__' redefined

[ ... ]


The errors/warnings on alpha-dec-osf4.0a go on for pages and pages and pages.

I haven't tried to track this down yet.

jeff

Re: Stabilization status

[Jeffrey A Law]

  In message < 199902021837.NAA06399@blastula.phys.columbia.edu >you write:
  > On Tue, 02 Feb 1999 11:01:57 -0700, Jeffrey A Law wrote:
  > >
  > >fixheader/fixproto seem to be spewing out many more warnings/errors than
  > >before.  This needs to be investigated.
  > 
  > Might conceivably be due to recent changes in cpplib.  What
  > warnings/errors were you getting?  (I don't have a system that needs
  > fixheader and can compile snapshots in a reasonable length of time.)
For example, on aix4.2 I now get this kind of stuff from fix-header:

/nfs/sethra/can/law/ppc/gcc/include/root/usr/lpp/X11/include/X11/Intrinsic.h:0: warning: `__STDC__' redefined
/nfs/sethra/can/law/ppc/gcc/include/root/usr/lpp/X11/include/X11/Xfuncs.h:0: warning: `__STDC__' redefined
/nfs/sethra/can/law/ppc/gcc/include/root/usr/lpp/X11/include/X11/Xi18nlib.h:0: warning: `__STDC__' redefined
/nfs/sethra/can/law/ppc/gcc/include/root/usr/lpp/X11/include/X11/Xlibint.h:0: warning: `__STDC__' redefined
/nfs/sethra/can/law/ppc/gcc/include/root/usr/lpp/X11/include/X11/Xlocale.h:0: warning: `__STDC__' redefined
/nfs/sethra/can/law/ppc/gcc/include/root/usr/lpp/X11/include/X11/Xosdefs.h:0: warning: `__STDC__' redefined
/nfs/sethra/can/law/ppc/gcc/include/root/usr/lpp/X11/include/X11/shrmem.h:0: warning: `__STDC__' redefined
/nfs/sethra/can/law/ppc/gcc/include/X11/Intrinsic.h:0: warning: `__STDC__' redefined

[ ... ]


The errors/warnings on alpha-dec-osf4.0a go on for pages and pages and pages.

I haven't tried to track this down yet.

jeff

Re: Stabilization status

[Zack Weinberg]

On Tue, 02 Feb 1999 11:01:57 -0700, Jeffrey A Law wrote:
>
>fixheader/fixproto seem to be spewing out many more warnings/errors than
>before.  This needs to be investigated.

Might conceivably be due to recent changes in cpplib.  What
warnings/errors were you getting?  (I don't have a system that needs
fixheader and can compile snapshots in a reasonable length of time.)

zw

Re: Stabilization status

[Michael Meissner]

On Tue, Feb 02, 1999 at 11:01:57AM -0700, Jeffrey A Law wrote:
> 
>                                     
>                                     -O0     -O1     -O2     -O9     -Os
> alpha-dec-osf4.0a                    failing -- the inline problem
> alphaev56-unknown-linux-gnu          Y       Y       Y       Y       Y
> hppa2.0-hp-hpux10.20                 Y       Y       Y       Y       Y
> i386-unknown-freebsd2.2.6            Y       Y       Y       Y       Y
> i586-pc-linux-gnu 		     Y       Y       Y       Y       Y  
> i686-pc-linux-gnu                    Y       Y       Y       Y       Y
> m68k-hp-bsd4.4                       Y       Y       Y       Y       Y
> mips-sgi-irix6.5                     Y       Y       Y       Y       Y
> powerpc-ibm-aix4.2.0.0               N  fails building libgcc1 
> powerpc-unknown-linux-gnulibc1       Untested
> sparc-sun-solaris2.5.1               Y       Y       Y       Y       Y
> sparc-sun-sunos4.1.1                 failing -- the inline problem
> 
> 
> 
> fixheader/fixproto seem to be spewing out many more warnings/errors than
> before.  This needs to be investigated.
> 
> I also need to retest alpha-osf & sparc-sunos now that the inline problem
> has been fixed.
> 
> 
> The ppc port seems to be badly broken.  Meissner?  Any word on getting it
> fixed?

Powerpc linux gets through building libgcc1 and fails in building insn-recog.c
on the second pass, so once the xmalloc's on AIX are taken care of, it may fall
victim to this (though I'm suspecting that the base compiler on ppc linux may
not be up the task, because I was able to build it with a cross compiler on the
x86 -- I need to make sure about revs, etc.).

-- 
Michael Meissner, Cygnus Solutions (Massachusetts office)
4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA
meissner@cygnus.com,	617-354-5416 (office),	617-354-7161 (fax)

Re: Stabilization status

[Franz Sirl]

At 04:21 03.02.99 , Michael Meissner wrote:
>On Tue, Feb 02, 1999 at 11:01:57AM -0700, Jeffrey A Law wrote:
>> 
>>                                     
>>                                     -O0     -O1     -O2     -O9     -Os
>> alpha-dec-osf4.0a                    failing -- the inline problem
>> alphaev56-unknown-linux-gnu          Y       Y       Y       Y       Y
>> hppa2.0-hp-hpux10.20                 Y       Y       Y       Y       Y
>> i386-unknown-freebsd2.2.6            Y       Y       Y       Y       Y
>> i586-pc-linux-gnu 		     Y       Y       Y       Y       Y  
>> i686-pc-linux-gnu                    Y       Y       Y       Y       Y
>> m68k-hp-bsd4.4                       Y       Y       Y       Y       Y
>> mips-sgi-irix6.5                     Y       Y       Y       Y       Y
>> powerpc-ibm-aix4.2.0.0               N  fails building libgcc1 
>> powerpc-unknown-linux-gnulibc1       Untested
>> sparc-sun-solaris2.5.1               Y       Y       Y       Y       Y
>> sparc-sun-sunos4.1.1                 failing -- the inline problem
>> 
>> 
>> 
>> fixheader/fixproto seem to be spewing out many more warnings/errors than
>> before.  This needs to be investigated.
>> 
>> I also need to retest alpha-osf & sparc-sunos now that the inline problem
>> has been fixed.
>> 
>> 
>> The ppc port seems to be badly broken.  Meissner?  Any word on getting it
>> fixed?
>
>Powerpc linux gets through building libgcc1 and fails in building insn-recog.c
>on the second pass, so once the xmalloc's on AIX are taken care of, it may
fall
>victim to this (though I'm suspecting that the base compiler on ppc linux may
>not be up the task, because I was able to build it with a cross compiler
on the
>x86 -- I need to make sure about revs, etc.).

Hi Michael,

I was able to build the mainline from CVS 2 days in a row on
powerpc-linux-gnu (with your latest changes removed) and it passed "make
check" with reasonable results (see the reports in egcs-testresults).
After I did the last report today, I synced config/rs6000/* with CVS and
now the bootstrap suffers from the segfaulting genrecog again. Next I will
do a simple build and run make check on that one. Maybe it will show a
difference against the bootstrapped compiler.

Michael, can I do anything else to help you with that one?

Franz.

Re: Stabilization status

[Gary Thomas]

Franz,

I've just tried this [twice] from fresh CVS sources checked out on
Feb 6 & 7.  Here's what happens when I 'make bootstrap'

stage1/xgcc -Bstage1/ -B/usr/local/powerpc-unknown-linux-gnulibc1/bin/  -DIN_GCC -DHAIFA   -DUSE_GNULIBC_1 -W -Wall -O2
-g -O2  -DHAVE_CONFIG_H  -o genrecog \
 genrecog.o rtl.o bitmap.o print-rtl.o ` case "obstack.o" in ?*) echo obstack.o ;; esac ` ` case "" in ?*) echo  ;;
esac ` ` case "" in ?*) echo  ;; esac `  ` case "" in ?*) echo  ;; esac ` ` case "" in ?*) echo  ;; esac ` 
./genrecog ../../egcs/gcc/config/rs6000/rs6000.md > tmp-recog.c
make[2]: *** [s-recog] Error 139

Any ideas?

On 04-Feb-99 Franz Sirl wrote:
> At 04:21 03.02.99 , Michael Meissner wrote:
>>On Tue, Feb 02, 1999 at 11:01:57AM -0700, Jeffrey A Law wrote:
>>> 
>>>                                     
>>>                                     -O0     -O1     -O2     -O9     -Os
>>> alpha-dec-osf4.0a                    failing -- the inline problem
>>> alphaev56-unknown-linux-gnu          Y       Y       Y       Y       Y
>>> hppa2.0-hp-hpux10.20                 Y       Y       Y       Y       Y
>>> i386-unknown-freebsd2.2.6            Y       Y       Y       Y       Y
>>> i586-pc-linux-gnu                Y       Y       Y       Y       Y  
>>> i686-pc-linux-gnu                    Y       Y       Y       Y       Y
>>> m68k-hp-bsd4.4                       Y       Y       Y       Y       Y
>>> mips-sgi-irix6.5                     Y       Y       Y       Y       Y
>>> powerpc-ibm-aix4.2.0.0               N  fails building libgcc1 
>>> powerpc-unknown-linux-gnulibc1       Untested
>>> sparc-sun-solaris2.5.1               Y       Y       Y       Y       Y
>>> sparc-sun-sunos4.1.1                 failing -- the inline problem
>>> 
>>> 
>>> 
>>> fixheader/fixproto seem to be spewing out many more warnings/errors than
>>> before.  This needs to be investigated.
>>> 
>>> I also need to retest alpha-osf & sparc-sunos now that the inline problem
>>> has been fixed.
>>> 
>>> 
>>> The ppc port seems to be badly broken.  Meissner?  Any word on getting it
>>> fixed?
>>
>>Powerpc linux gets through building libgcc1 and fails in building insn-recog.c
>>on the second pass, so once the xmalloc's on AIX are taken care of, it may
> fall
>>victim to this (though I'm suspecting that the base compiler on ppc linux may
>>not be up the task, because I was able to build it with a cross compiler
> on the
>>x86 -- I need to make sure about revs, etc.).
> 
> Hi Michael,
> 
> I was able to build the mainline from CVS 2 days in a row on
> powerpc-linux-gnu (with your latest changes removed) and it passed "make
> check" with reasonable results (see the reports in egcs-testresults).
> After I did the last report today, I synced config/rs6000/* with CVS and
> now the bootstrap suffers from the segfaulting genrecog again. Next I will
> do a simple build and run make check on that one. Maybe it will show a
> difference against the bootstrapped compiler.
> 
> Michael, can I do anything else to help you with that one?
> 
> Franz.

Re: Stabilization status

[Franz Sirl]

Am Sun, 07 Feb 1999 schrieb Gary Thomas:
>Franz,
>
>I've just tried this [twice] from fresh CVS sources checked out on
>Feb 6 & 7.  Here's what happens when I 'make bootstrap'
>
>stage1/xgcc -Bstage1/ -B/usr/local/powerpc-unknown-linux-gnulibc1/bin/  -DIN_GCC -DHAIFA   -DUSE_GNULIBC_1 -W -Wall -O2
>-g -O2  -DHAVE_CONFIG_H  -o genrecog \
> genrecog.o rtl.o bitmap.o print-rtl.o ` case "obstack.o" in ?*) echo obstack.o ;; esac ` ` case "" in ?*) echo  ;;
>esac ` ` case "" in ?*) echo  ;; esac `  ` case "" in ?*) echo  ;; esac ` ` case "" in ?*) echo  ;; esac ` 
>./genrecog ../../egcs/gcc/config/rs6000/rs6000.md > tmp-recog.c
>make[2]: *** [s-recog] Error 139
>
>Any ideas?

That's the result of Michaels patches. I removed them to be able to bootstrap.
I also need a gas (I use 981227) snapshot for everything to work,
binutils-2.9.1.0.19a doesn't seem to work (I got an yet unverified report that
it's working with binutils-2.9.1.0.15 too).

But even with these changes I now can no longer bootstrap the cvs, something
changed during the last 3 days:

stage1/xgcc -Bstage1/ -B/home/fsirl/gnubin/ppc-redhat-linux/bin/ -c  -DIN_GCC -DHAIFA    -W -Wall -O2 -g -O2  -DHAVE_CONFIG_H    -I. -I../../../egcsm/gcc -I../..
/../egcsm/gcc/config -I../../../egcsm/gcc/../include ../../../egcsm/gcc/genattrtab.c
.../../../egcsm/gcc/genattrtab.c: In function `operate_exp':
.../../../egcsm/gcc/genattrtab.c:1606: warning: `i' might be used uninitialized in this function
.../../../egcsm/gcc/genattrtab.c: In function `evaluate_eq_attr':
.../../../egcsm/gcc/genattrtab.c:2789: warning: `newexp' might be used uninitialized in this function
stage1/xgcc -Bstage1/ -B/home/fsirl/gnubin/ppc-redhat-linux/bin/  -DIN_GCC -DHAIFA    -W -Wall -O2 -g -O2  -DHAVE_CONFIG_H  -o genattrtab \
 genattrtab.o rtl.o bitmap.o print-rtl.o rtlanal.o ` case "obstack.o" in ?*) echo obstack.o ;; esac ` ` case "" in ?*) echo  ;; esac ` ` case "" in ?*) echo  ;;
esac `  ` case "" in ?*) echo  ;; esac ` ` case "" in ?*) echo  ;; esac `
if cmp -s Makefile   ../../../egcsm/gcc/config/rs6000/rs6000.md;        \
then                                    \
  echo Using ;  \
  cp  tmp-attrtab.c;    \
else                                    \
  ./genattrtab ../../../egcsm/gcc/config/rs6000/rs6000.md > tmp-attrtab.c;      \
fi
.../../../egcsm/gcc/rtlanal.c:1163: Internal compiler error in function rtx_equal_p
Please submit a full bug report to `egcs-bugs@egcs.cygnus.com'.
See <URL: http://egcs.cygnus.com/faq.html#bugreport > for details.
make[2]: *** [s-attrtab] Error 33
make[2]: Leaving directory `/home/fsirl/obj/cvsm/gcc'
make[1]: *** [bootstrap-lean] Error 2
make[1]: Leaving directory `/home/fsirl/obj/cvsm/gcc'
make: *** [bootstrap-lean] Error 2

I got this type of failure a few times during the last weeks, I'm currently
toggling between this bug, temporary CVS bugs and successful bootstraps :-).

Franz.

PS: Gary, this is on the kernel machine, where you have access too.

Re: Stabilization status

[Franz Sirl]

Am Sun, 07 Feb 1999 schrieb Gary Thomas:
>Franz,
>
>I've just tried this [twice] from fresh CVS sources checked out on
>Feb 6 & 7.  Here's what happens when I 'make bootstrap'
>
>stage1/xgcc -Bstage1/ -B/usr/local/powerpc-unknown-linux-gnulibc1/bin/  -DIN_GCC -DHAIFA   -DUSE_GNULIBC_1 -W -Wall -O2
>-g -O2  -DHAVE_CONFIG_H  -o genrecog \
> genrecog.o rtl.o bitmap.o print-rtl.o ` case "obstack.o" in ?*) echo obstack.o ;; esac ` ` case "" in ?*) echo  ;;
>esac ` ` case "" in ?*) echo  ;; esac `  ` case "" in ?*) echo  ;; esac ` ` case "" in ?*) echo  ;; esac ` 
>./genrecog ../../egcs/gcc/config/rs6000/rs6000.md > tmp-recog.c
>make[2]: *** [s-recog] Error 139
>
>Any ideas?

That's the result of Michaels patches. I removed them to be able to bootstrap.
I also need a gas (I use 981227) snapshot for everything to work,
binutils-2.9.1.0.19a doesn't seem to work (I got an yet unverified report that
it's working with binutils-2.9.1.0.15 too).

But even with these changes I now can no longer bootstrap the cvs, something
changed during the last 3 days:

stage1/xgcc -Bstage1/ -B/home/fsirl/gnubin/ppc-redhat-linux/bin/ -c  -DIN_GCC -DHAIFA    -W -Wall -O2 -g -O2  -DHAVE_CONFIG_H    -I. -I../../../egcsm/gcc -I../..
/../egcsm/gcc/config -I../../../egcsm/gcc/../include ../../../egcsm/gcc/genattrtab.c
.../../../egcsm/gcc/genattrtab.c: In function `operate_exp':
.../../../egcsm/gcc/genattrtab.c:1606: warning: `i' might be used uninitialized in this function
.../../../egcsm/gcc/genattrtab.c: In function `evaluate_eq_attr':
.../../../egcsm/gcc/genattrtab.c:2789: warning: `newexp' might be used uninitialized in this function
stage1/xgcc -Bstage1/ -B/home/fsirl/gnubin/ppc-redhat-linux/bin/  -DIN_GCC -DHAIFA    -W -Wall -O2 -g -O2  -DHAVE_CONFIG_H  -o genattrtab \
 genattrtab.o rtl.o bitmap.o print-rtl.o rtlanal.o ` case "obstack.o" in ?*) echo obstack.o ;; esac ` ` case "" in ?*) echo  ;; esac ` ` case "" in ?*) echo  ;;
esac `  ` case "" in ?*) echo  ;; esac ` ` case "" in ?*) echo  ;; esac `
if cmp -s Makefile   ../../../egcsm/gcc/config/rs6000/rs6000.md;        \
then                                    \
  echo Using ;  \
  cp  tmp-attrtab.c;    \
else                                    \
  ./genattrtab ../../../egcsm/gcc/config/rs6000/rs6000.md > tmp-attrtab.c;      \
fi
.../../../egcsm/gcc/rtlanal.c:1163: Internal compiler error in function rtx_equal_p
Please submit a full bug report to `egcs-bugs@egcs.cygnus.com'.
See <URL: http://egcs.cygnus.com/faq.html#bugreport > for details.
make[2]: *** [s-attrtab] Error 33
make[2]: Leaving directory `/home/fsirl/obj/cvsm/gcc'
make[1]: *** [bootstrap-lean] Error 2
make[1]: Leaving directory `/home/fsirl/obj/cvsm/gcc'
make: *** [bootstrap-lean] Error 2

I got this type of failure a few times during the last weeks, I'm currently
toggling between this bug, temporary CVS bugs and successful bootstraps :-).

Franz.

PS: Gary, this is on the kernel machine, where you have access too.

Re: Stabilization status

[Gary Thomas]

Franz,

I've just tried this [twice] from fresh CVS sources checked out on
Feb 6 & 7.  Here's what happens when I 'make bootstrap'

stage1/xgcc -Bstage1/ -B/usr/local/powerpc-unknown-linux-gnulibc1/bin/  -DIN_GCC -DHAIFA   -DUSE_GNULIBC_1 -W -Wall -O2
-g -O2  -DHAVE_CONFIG_H  -o genrecog \
 genrecog.o rtl.o bitmap.o print-rtl.o ` case "obstack.o" in ?*) echo obstack.o ;; esac ` ` case "" in ?*) echo  ;;
esac ` ` case "" in ?*) echo  ;; esac `  ` case "" in ?*) echo  ;; esac ` ` case "" in ?*) echo  ;; esac ` 
./genrecog ../../egcs/gcc/config/rs6000/rs6000.md > tmp-recog.c
make[2]: *** [s-recog] Error 139

Any ideas?

On 04-Feb-99 Franz Sirl wrote:
> At 04:21 03.02.99 , Michael Meissner wrote:
>>On Tue, Feb 02, 1999 at 11:01:57AM -0700, Jeffrey A Law wrote:
>>> 
>>>                                     
>>>                                     -O0     -O1     -O2     -O9     -Os
>>> alpha-dec-osf4.0a                    failing -- the inline problem
>>> alphaev56-unknown-linux-gnu          Y       Y       Y       Y       Y
>>> hppa2.0-hp-hpux10.20                 Y       Y       Y       Y       Y
>>> i386-unknown-freebsd2.2.6            Y       Y       Y       Y       Y
>>> i586-pc-linux-gnu                Y       Y       Y       Y       Y  
>>> i686-pc-linux-gnu                    Y       Y       Y       Y       Y
>>> m68k-hp-bsd4.4                       Y       Y       Y       Y       Y
>>> mips-sgi-irix6.5                     Y       Y       Y       Y       Y
>>> powerpc-ibm-aix4.2.0.0               N  fails building libgcc1 
>>> powerpc-unknown-linux-gnulibc1       Untested
>>> sparc-sun-solaris2.5.1               Y       Y       Y       Y       Y
>>> sparc-sun-sunos4.1.1                 failing -- the inline problem
>>> 
>>> 
>>> 
>>> fixheader/fixproto seem to be spewing out many more warnings/errors than
>>> before.  This needs to be investigated.
>>> 
>>> I also need to retest alpha-osf & sparc-sunos now that the inline problem
>>> has been fixed.
>>> 
>>> 
>>> The ppc port seems to be badly broken.  Meissner?  Any word on getting it
>>> fixed?
>>
>>Powerpc linux gets through building libgcc1 and fails in building insn-recog.c
>>on the second pass, so once the xmalloc's on AIX are taken care of, it may
> fall
>>victim to this (though I'm suspecting that the base compiler on ppc linux may
>>not be up the task, because I was able to build it with a cross compiler
> on the
>>x86 -- I need to make sure about revs, etc.).
> 
> Hi Michael,
> 
> I was able to build the mainline from CVS 2 days in a row on
> powerpc-linux-gnu (with your latest changes removed) and it passed "make
> check" with reasonable results (see the reports in egcs-testresults).
> After I did the last report today, I synced config/rs6000/* with CVS and
> now the bootstrap suffers from the segfaulting genrecog again. Next I will
> do a simple build and run make check on that one. Maybe it will show a
> difference against the bootstrapped compiler.
> 
> Michael, can I do anything else to help you with that one?
> 
> Franz.

Re: Stabilization status

[Franz Sirl]

At 04:21 03.02.99 , Michael Meissner wrote:
>On Tue, Feb 02, 1999 at 11:01:57AM -0700, Jeffrey A Law wrote:
>> 
>>                                     
>>                                     -O0     -O1     -O2     -O9     -Os
>> alpha-dec-osf4.0a                    failing -- the inline problem
>> alphaev56-unknown-linux-gnu          Y       Y       Y       Y       Y
>> hppa2.0-hp-hpux10.20                 Y       Y       Y       Y       Y
>> i386-unknown-freebsd2.2.6            Y       Y       Y       Y       Y
>> i586-pc-linux-gnu 		     Y       Y       Y       Y       Y  
>> i686-pc-linux-gnu                    Y       Y       Y       Y       Y
>> m68k-hp-bsd4.4                       Y       Y       Y       Y       Y
>> mips-sgi-irix6.5                     Y       Y       Y       Y       Y
>> powerpc-ibm-aix4.2.0.0               N  fails building libgcc1 
>> powerpc-unknown-linux-gnulibc1       Untested
>> sparc-sun-solaris2.5.1               Y       Y       Y       Y       Y
>> sparc-sun-sunos4.1.1                 failing -- the inline problem
>> 
>> 
>> 
>> fixheader/fixproto seem to be spewing out many more warnings/errors than
>> before.  This needs to be investigated.
>> 
>> I also need to retest alpha-osf & sparc-sunos now that the inline problem
>> has been fixed.
>> 
>> 
>> The ppc port seems to be badly broken.  Meissner?  Any word on getting it
>> fixed?
>
>Powerpc linux gets through building libgcc1 and fails in building insn-recog.c
>on the second pass, so once the xmalloc's on AIX are taken care of, it may
fall
>victim to this (though I'm suspecting that the base compiler on ppc linux may
>not be up the task, because I was able to build it with a cross compiler
on the
>x86 -- I need to make sure about revs, etc.).

Hi Michael,

I was able to build the mainline from CVS 2 days in a row on
powerpc-linux-gnu (with your latest changes removed) and it passed "make
check" with reasonable results (see the reports in egcs-testresults).
After I did the last report today, I synced config/rs6000/* with CVS and
now the bootstrap suffers from the segfaulting genrecog again. Next I will
do a simple build and run make check on that one. Maybe it will show a
difference against the bootstrapped compiler.

Michael, can I do anything else to help you with that one?

Franz.

Re: Stabilization status

[Michael Meissner]

On Tue, Feb 02, 1999 at 11:01:57AM -0700, Jeffrey A Law wrote:
> 
>                                     
>                                     -O0     -O1     -O2     -O9     -Os
> alpha-dec-osf4.0a                    failing -- the inline problem
> alphaev56-unknown-linux-gnu          Y       Y       Y       Y       Y
> hppa2.0-hp-hpux10.20                 Y       Y       Y       Y       Y
> i386-unknown-freebsd2.2.6            Y       Y       Y       Y       Y
> i586-pc-linux-gnu 		     Y       Y       Y       Y       Y  
> i686-pc-linux-gnu                    Y       Y       Y       Y       Y
> m68k-hp-bsd4.4                       Y       Y       Y       Y       Y
> mips-sgi-irix6.5                     Y       Y       Y       Y       Y
> powerpc-ibm-aix4.2.0.0               N  fails building libgcc1 
> powerpc-unknown-linux-gnulibc1       Untested
> sparc-sun-solaris2.5.1               Y       Y       Y       Y       Y
> sparc-sun-sunos4.1.1                 failing -- the inline problem
> 
> 
> 
> fixheader/fixproto seem to be spewing out many more warnings/errors than
> before.  This needs to be investigated.
> 
> I also need to retest alpha-osf & sparc-sunos now that the inline problem
> has been fixed.
> 
> 
> The ppc port seems to be badly broken.  Meissner?  Any word on getting it
> fixed?

Powerpc linux gets through building libgcc1 and fails in building insn-recog.c
on the second pass, so once the xmalloc's on AIX are taken care of, it may fall
victim to this (though I'm suspecting that the base compiler on ppc linux may
not be up the task, because I was able to build it with a cross compiler on the
x86 -- I need to make sure about revs, etc.).

-- 
Michael Meissner, Cygnus Solutions (Massachusetts office)
4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA
meissner@cygnus.com,	617-354-5416 (office),	617-354-7161 (fax)

Re: Stabilization status

[H.J. Lu]

> powerpc-unknown-linux-gnulibc1       Untested

I was horried to find out we have powerpc-unknown-linux-gnulibc1
and powerpc-unknown-linux-gnu. They use different ABIs. But they
use the same specs. The result is binaries compiled on
powerpc-unknown-linux-gnulibc1 won't run on powerpc-unknown-linux-gnu,
and vice versa.

We have the same problem with Linux on x86, alpha, sparc and m68k
when we change ABIs. We solved this by using a different specs so
that the old binary will run on the new system and vice versa, as
long as the necessary dynamic linker and shared libraries are
available. Why didn't we do it on PPC? It is very bad for Linux
and egcs.

BTW, glibc 2.1 has the same problem. May I propose to fix it in
egcs and glibc before it is too late? I can provide patches for
both if necessary.

Thanks.

H.J.

Re: Stabilization status

[David Edelsohn]

	The LinuxPPC developers applied an incorrect patch to egcs for
LinuxPPC which makes it binary incompatible with normal EGCS.  This is
going to be corrected during the glibc2.1 conversion which already is
binary incompatible for other reasons.

	Binaries already cannot be transported across the two versions of
glibc so I am not sure that this fix provides any benefit.

David

Re: Stabilization status

[David Edelsohn]

	The LinuxPPC developers applied an incorrect patch to egcs for
LinuxPPC which makes it binary incompatible with normal EGCS.  This is
going to be corrected during the glibc2.1 conversion which already is
binary incompatible for other reasons.

	Binaries already cannot be transported across the two versions of
glibc so I am not sure that this fix provides any benefit.

David

Re: Stabilization status

[Franz Sirl]

At 15:49 04.02.99 , H.J. Lu wrote:
>> powerpc-unknown-linux-gnulibc1       Untested
>
>I was horried to find out we have powerpc-unknown-linux-gnulibc1
>and powerpc-unknown-linux-gnu. They use different ABIs. But they
>use the same specs. The result is binaries compiled on
>powerpc-unknown-linux-gnulibc1 won't run on powerpc-unknown-linux-gnu,
>and vice versa.
>
>We have the same problem with Linux on x86, alpha, sparc and m68k
>when we change ABIs. We solved this by using a different specs so
>that the old binary will run on the new system and vice versa, as
>long as the necessary dynamic linker and shared libraries are
>available. Why didn't we do it on PPC? It is very bad for Linux
>and egcs.
>
>BTW, glibc 2.1 has the same problem. May I propose to fix it in
>egcs and glibc before it is too late? I can provide patches for
>both if necessary.

AFAIK this was a decision on purpose, so there's no need to change
anything. Geoff has done the bincompat package, which can be used to binary
patch glibc-1.99 based executables, so they will work on glibc-2.1.

Our goal on PPC is to phase out glibc-1.99 ASAP, and there will be a
distribution ready as soon as Uli releases glibc-2.1.

Franz.

Re: Stabilization status

[Franz Sirl]

At 15:49 04.02.99 , H.J. Lu wrote:
>> powerpc-unknown-linux-gnulibc1       Untested
>
>I was horried to find out we have powerpc-unknown-linux-gnulibc1
>and powerpc-unknown-linux-gnu. They use different ABIs. But they
>use the same specs. The result is binaries compiled on
>powerpc-unknown-linux-gnulibc1 won't run on powerpc-unknown-linux-gnu,
>and vice versa.
>
>We have the same problem with Linux on x86, alpha, sparc and m68k
>when we change ABIs. We solved this by using a different specs so
>that the old binary will run on the new system and vice versa, as
>long as the necessary dynamic linker and shared libraries are
>available. Why didn't we do it on PPC? It is very bad for Linux
>and egcs.
>
>BTW, glibc 2.1 has the same problem. May I propose to fix it in
>egcs and glibc before it is too late? I can provide patches for
>both if necessary.

AFAIK this was a decision on purpose, so there's no need to change
anything. Geoff has done the bincompat package, which can be used to binary
patch glibc-1.99 based executables, so they will work on glibc-2.1.

Our goal on PPC is to phase out glibc-1.99 ASAP, and there will be a
distribution ready as soon as Uli releases glibc-2.1.

Franz.

Re: Stabilization status

[H.J. Lu]

> powerpc-unknown-linux-gnulibc1       Untested

I was horried to find out we have powerpc-unknown-linux-gnulibc1
and powerpc-unknown-linux-gnu. They use different ABIs. But they
use the same specs. The result is binaries compiled on
powerpc-unknown-linux-gnulibc1 won't run on powerpc-unknown-linux-gnu,
and vice versa.

We have the same problem with Linux on x86, alpha, sparc and m68k
when we change ABIs. We solved this by using a different specs so
that the old binary will run on the new system and vice versa, as
long as the necessary dynamic linker and shared libraries are
available. Why didn't we do it on PPC? It is very bad for Linux
and egcs.

BTW, glibc 2.1 has the same problem. May I propose to fix it in
egcs and glibc before it is too late? I can provide patches for
both if necessary.

Thanks.

H.J.

Re: Stabilization status

[Bruce Korb]

Jeffrey A Law wrote:
> fixheader/fixproto seem to be spewing out many more warnings/errors than
> before.  This needs to be investigated.

The old stuff or the new stuff?
If the new stuff, please send details.

See also:

	http://autogen.linuxbox.com/fixinc

Re: Stabilization status

[Jeffrey A Law]

  In message < 36B747E2.B26FD4F@datadesign.com >you write:
  > Jeffrey A Law wrote:
  > > fixheader/fixproto seem to be spewing out many more warnings/errors than
  > > before.  This needs to be investigated.
  > 
  > The old stuff or the new stuff?
  > If the new stuff, please send details.
Old stuff only.  Note fixheader/fixproto != fixincludes.  

jeff

Re: Stabilization status

[Jeffrey A Law]

  In message < 36B747E2.B26FD4F@datadesign.com >you write:
  > Jeffrey A Law wrote:
  > > fixheader/fixproto seem to be spewing out many more warnings/errors than
  > > before.  This needs to be investigated.
  > 
  > The old stuff or the new stuff?
  > If the new stuff, please send details.
Old stuff only.  Note fixheader/fixproto != fixincludes.  

jeff

Re: Stabilization status

[Bruce Korb]

Jeffrey A Law wrote:
> fixheader/fixproto seem to be spewing out many more warnings/errors than
> before.  This needs to be investigated.

The old stuff or the new stuff?
If the new stuff, please send details.

See also:

	http://autogen.linuxbox.com/fixinc

Stabilization status

[Jeffrey A Law]

                                    
                                    -O0     -O1     -O2     -O9     -Os
alpha-dec-osf4.0a                    failing -- the inline problem
alphaev56-unknown-linux-gnu          Y       Y       Y       Y       Y
hppa2.0-hp-hpux10.20                 Y       Y       Y       Y       Y
i386-unknown-freebsd2.2.6            Y       Y       Y       Y       Y
i586-pc-linux-gnu 		     Y       Y       Y       Y       Y  
i686-pc-linux-gnu                    Y       Y       Y       Y       Y
m68k-hp-bsd4.4                       Y       Y       Y       Y       Y
mips-sgi-irix6.5                     Y       Y       Y       Y       Y
powerpc-ibm-aix4.2.0.0               N  fails building libgcc1 
powerpc-unknown-linux-gnulibc1       Untested
sparc-sun-solaris2.5.1               Y       Y       Y       Y       Y
sparc-sun-sunos4.1.1                 failing -- the inline problem



fixheader/fixproto seem to be spewing out many more warnings/errors than
before.  This needs to be investigated.

I also need to retest alpha-osf & sparc-sunos now that the inline problem
has been fixed.


The ppc port seems to be badly broken.  Meissner?  Any word on getting it
fixed?

jeff

Stabilization status

[Jeffrey A Law]

-fomit-frame-pointer tests.  This is a much smaller matrix as most of the
risc targets turn on frame pointer elimination by default at -O1 and higher
optimization levels.


			   -O1		   -O2		   -O9
			 -fo-f-p	 -fo-f-p	 -fo-f-p
-------------------------------------------------------------------
i386-pc-freebsd		    Y		    Y		    Y
i586-pc-linux-gnu	    Y		    Y		    Y	    
i686-pc-linux-gnu	    Y		    Y		    Y
m68k-hp-bsd4.4		    Y		    Y		    Y

Stabilization status

[Jeffrey A Law]

With the various bugfixes from the last several days things have improved,
except that I've had zero success with rs6000/powerpc platforms.

On AIX 4.1.3 I get relocation overflow errors building chill, even though we're
linking with -Wl,-bbigtoc:

stage1/xgcc -Bstage1/ -B/usr/local/powerpc-ibm-aix4.1.3.0/bin/  -DIN_GCC   -W -Wall -O2 -g  -Wl,-bbigtoc -o ../cc1chill parse.o actions.o except.o grant.o lang.o tree.o lex.o decl.o typeck.o convert.o expr.o loop.o tasking.o timing.o inout.o satisfy.o ch-version.o \
      `cat ../stamp-objlist`  `if [ xobstack.o != x ]; then echo ../obstack.o; else true; fi` `if [ xalloca.o != x ]; then echo ../alloca.o; else true; fi` `if [ x != x ]; then echo ../; else true; fi` -lld
ld: 0711-783 WARNING: TOC overflow. TOC size: 68200     Maximum size: 65536
        Extra instructions are being generated for each reference to a TOC
        symbol if the symbol is in the TOC overflow area.
ld: 0711-780 SEVERE ERROR: Symbol .sched_analyze_2 (entry 1392) in object ../haifa-sched.o:
        Relocation overflow in reference to: rtx_format (entry 4264)
        Address: 0x00005176;    RLD type: R_TOC;   RLD length: 16
ld: 0711-780 SEVERE ERROR: Symbol .attach_deaths (entry 1862) in object ../haifa-sched.o:
        Relocation overflow in reference to: rtx_format (entry 4264)
        Address: 0x00007de2;    RLD type: R_TOC;   RLD length: 16
ld: 0711-780 SEVERE ERROR: Symbol .regno_use_in (entry 3251) in object ../haifa-sched.o:
        Relocation overflow in reference to: rtx_format (entry 4264)
        Address: 0x0000f472;    RLD type: R_TOC;   RLD length: 16
collect2: ld returned 12 exit status

Makes me wonder if we should be building with -mminimal-toc during stage2 and
stage3.  I'm not all that familiar with the PPC, so I'm not sure.


On ppc-linux it appears that the stage1 compiler has mis-compiled stage2 cpp
which causes stage2 cpp to croak.






Target				BOOT_CFLAGS
-------------------------------------------------------------
				std	-O0	-O1	-O9
alpha-dec-osf4.0a		 Y	 Y	 Y	 Y
alphaev56-unknown-linux-gnu	 Y	 Y	 Y	 Y
hppa2.0-hp-hpux10.20		 Y	 Y	 Y	 Y
i386-unknown-freebsd2.2.6	 Y	 Y	 Y	 Y
i586-pc-linux-gnu		 Y	 Y	 Y	 Y
i686-pc-linux-gnu		 Y	 Y	 Y	 Y
m68k-hp-bsd4.4			 Y	 Y	 Y	 Y
mips-sgi-irix6.3		 Y	 Y	 Y	 Y
powerpc-ibm-aix4.1.3.0		 N
powerpc-unknown-linux-gnulibc1	 N
sparc-sun-solaris2.5.1		 Y	 Y	 Y	 Y
sparc-sun-sunos4.1.1		 Y	 Y	 Y


Both alpha targets, the m68k & sparc targets all failed at some point due
to codegen issues.

Next I'm going to look at -fomit-frame-pointer and -funroll-loops issues.

I'm also going to take a stab at finding the ppc-linux codegen issue, but we'd
be better off if someone else could analyze it instead.

Let's keep things semi-frozen for another week.  I'm inclined to let some of
the less risky patches though now.  But let's try and keep the volume of
non-bugfix changes reasonably low.


jeff

Re: Stabilization status

[David Edelsohn]

>>>>> Jeffrey A Law writes:

Jeff> With the various bugfixes from the last several days things have improved,
Jeff> except that I've had zero success with rs6000/powerpc platforms.

Jeff> On AIX 4.1.3 I get relocation overflow errors building chill, even though we're
Jeff> linking with -Wl,-bbigtoc:

	Jeff, this error is a problem with AIX 4.1.3 and is described in
the EGCS FAQ about -bbigtoc.  You need to upgrade your system to AIX 4.1.5
and the latest version of the AIX linker for that AIX release.  The linker
fix description is:

APAR IX75823 (OVERFLOW DURING LINK WHEN USING GCC AND -BBIGTOC)

which I think pretty well covers it.

David

Re: Stabilization status

[Franz Sirl]

Am Fri, 01 Jan 1999 schrieb Jeffrey A Law:
>With the various bugfixes from the last several days things have improved,
>except that I've had zero success with rs6000/powerpc platforms.
>
>On ppc-linux it appears that the stage1 compiler has mis-compiled stage2 cpp
>which causes stage2 cpp to croak.
>

Hi Jeff,

I further investigated this and it seems to be a binutils problem. Michael
Meissners recent change to put things into .sbss instead of .sdata triggers a
bug in binutils-2.9.1.0.19a (and earlier probably). I built egcs with a current
gas snapshot without problems.

I would appreciate if someone could send the corresponding binutils fix to H.J
Lu, so he can include it in binutils-2.9.1.0.20.

Franz.

Re: Stabilization status

[H.J. Lu]

> 
> Hi Jeff,
> 
> I further investigated this and it seems to be a binutils problem. Michael
> Meissners recent change to put things into .sbss instead of .sdata triggers a
> bug in binutils-2.9.1.0.19a (and earlier probably). I built egcs with a current
> gas snapshot without problems.
> 
> I would appreciate if someone could send the corresponding binutils fix to H.J
> Lu, so he can include it in binutils-2.9.1.0.20.
> 

I am back from my vacation. Please send me the patch.

Thanks.


-- 
H.J. Lu (hjl@gnu.org)

Re: Stabilization status

[Jeffrey A Law]

  In message <99010521361700.01228@ns1102.munich.netsurf.de>you write:
  > I further investigated this and it seems to be a binutils problem. Michael
  > Meissners recent change to put things into .sbss instead of .sdata triggers
  > a bug in binutils-2.9.1.0.19a (and earlier probably). I built egcs with a
  > current gas snapshot without problems.
  >
  > 
  > I would appreciate if someone could send the corresponding binutils fix to 
  > H.J Lu, so he can include it in binutils-2.9.1.0.20.
It occurs to me that we should probably have an FAQ entry on the need for a
newer assembler on ppc-linux.

Want to write one up and submit it?

If you don't know html, then submitting plaintext is fine, it can be html-ized
easily.

jeff

Re: Stabilization status

[Franz Sirl]

Am Mon, 15 Feb 1999 schrieb Jeffrey A Law:
>In message <99010521361700.01228@ns1102.munich.netsurf.de>you write:
>  > I further investigated this and it seems to be a binutils problem. Michael
>  > Meissners recent change to put things into .sbss instead of .sdata triggers
>  > a bug in binutils-2.9.1.0.19a (and earlier probably). I built egcs with a
>  > current gas snapshot without problems.
>  >
>  > 
>  > I would appreciate if someone could send the corresponding binutils fix to 
>  > H.J Lu, so he can include it in binutils-2.9.1.0.20.
>It occurs to me that we should probably have an FAQ entry on the need for a
>newer assembler on ppc-linux.
>
>Want to write one up and submit it?
>
>If you don't know html, then submitting plaintext is fine, it can be html-ized
>easily.

Yeah, I can write something up. Would you mind placing a gas-981227-ppc.tar.gz
into the infrastructure dir? Then I can hyperlink to it. Later/current snapshots
don't check well on the PPC. One, hopefully harmless :-), test will always fail,
cause -fdata-sections is not yet implemented in egcs for PPC.

Franz.

Re: Stabilization status

[Gary Thomas]

On 15-Feb-99 Franz Sirl wrote:
> Am Mon, 15 Feb 1999 schrieb Jeffrey A Law:
>>In message <99010521361700.01228@ns1102.munich.netsurf.de>you write:
>>  > I further investigated this and it seems to be a binutils problem. Michael
>>  > Meissners recent change to put things into .sbss instead of .sdata triggers
>>  > a bug in binutils-2.9.1.0.19a (and earlier probably). I built egcs with a
>>  > current gas snapshot without problems.
>>  >
>>  > 
>>  > I would appreciate if someone could send the corresponding binutils fix to 
>>  > H.J Lu, so he can include it in binutils-2.9.1.0.20.
>>It occurs to me that we should probably have an FAQ entry on the need for a
>>newer assembler on ppc-linux.
>>
>>Want to write one up and submit it?
>>
>>If you don't know html, then submitting plaintext is fine, it can be html-ized
>>easily.
> 
> Yeah, I can write something up. Would you mind placing a gas-981227-ppc.tar.gz
> into the infrastructure dir? Then I can hyperlink to it. Later/current snapshots
> don't check well on the PPC. One, hopefully harmless :-), test will always fail,
> cause -fdata-sections is not yet implemented in egcs for PPC.
> 
> Franz.

Franz,

If you send me the files/patches, I'll make a binutils+gas RPM available until
there is a more "official" solution.


------------------------------------------------------------------------
Gary Thomas                              |
email: gdt@linuxppc.org                  | "Fine wine is a necessity of
   ... opinions expressed here are mine  |        life for me"
       and no one else would claim them! |
                                         |      Thomas Jefferson
------------------------------------------------------------------------

Re: Stabilization status

[Franz Sirl]

Am Mon, 15 Feb 1999 schrieb Gary Thomas:
>On 15-Feb-99 Franz Sirl wrote:
>> Am Mon, 15 Feb 1999 schrieb Jeffrey A Law:
>>>In message <99010521361700.01228@ns1102.munich.netsurf.de>you write:
>>>  > I further investigated this and it seems to be a binutils problem. Michael
>>>  > Meissners recent change to put things into .sbss instead of .sdata triggers
>>>  > a bug in binutils-2.9.1.0.19a (and earlier probably). I built egcs with a
>>>  > current gas snapshot without problems.
>>>  >
>>>  > 
>>>  > I would appreciate if someone could send the corresponding binutils fix to 
>>>  > H.J Lu, so he can include it in binutils-2.9.1.0.20.
>>>It occurs to me that we should probably have an FAQ entry on the need for a
>>>newer assembler on ppc-linux.
>>>
>>>Want to write one up and submit it?
>>>
>>>If you don't know html, then submitting plaintext is fine, it can be html-ized
>>>easily.
>> 
>> Yeah, I can write something up. Would you mind placing a gas-981227-ppc.tar.gz
>> into the infrastructure dir? Then I can hyperlink to it. Later/current snapshots
>> don't check well on the PPC. One, hopefully harmless :-), test will always fail,
>> cause -fdata-sections is not yet implemented in egcs for PPC.
>> 
>> Franz.
>
>Franz,
>
>If you send me the files/patches, I'll make a binutils+gas RPM available until
>there is a more "official" solution.

I would love to, but it's impossible for me to track them down as there is no
anonymous CVS for binutils/gas yet. But I don't see it as a big problem, cause
it only hurts the mainline now and I assume binutils-2.10 will be out before
egcs-1.2. And for people trying the mainline now on PPC the FAQ entry should be
enough for now.

Hmm, this problem might become obsolete quite soon, as H.J. Lu will switch his
linux-binutils to the snapshots during one of the next releases (.21 or .22 I
assume).

Franz.

Re: Stabilization status

[H.J. Lu]

> 
> Hmm, this problem might become obsolete quite soon, as H.J. Lu will switch his
> linux-binutils to the snapshots during one of the next releases (.21 or .22 I
> assume).
> 

BTW, I am working on 2.9.1.0.21 now. The problem is Linux/ARM. I was told the gas
snapshots didn't do Linux/ARM right. I cannot switch to the gas snapshots before
Linux/ARM is supported.

-- 
H.J. Lu (hjl@gnu.org)

Re: Stabilization status

[Philip Blundell]

>BTW, I am working on 2.9.1.0.21 now. The problem is Linux/ARM. I was told the 
>gas snapshots didn't do Linux/ARM right. I cannot switch to the gas 
>snapshots before Linux/ARM is supported.

I think patches exist to make Linux/ARM work on the snapshots.  Most of them 
are in the hands of the gas2 people and waiting to be merged.  If you want I 
can send them to you for binutils 2.9.1.0.21.

p.

Re: Stabilization status

[Franz Sirl]

At 10:59 16.02.99 , Philip Blundell wrote:
>>BTW, I am working on 2.9.1.0.21 now. The problem is Linux/ARM. I was told
the 
>>gas snapshots didn't do Linux/ARM right. I cannot switch to the gas 
>>snapshots before Linux/ARM is supported.
>
>I think patches exist to make Linux/ARM work on the snapshots.  Most of them 
>are in the hands of the gas2 people and waiting to be merged.  If you want I 
>can send them to you for binutils 2.9.1.0.21.

This would be great. The last snapshot that tests fine for me is 981227. I
just tested the 990217 snapshot and it is mostly fine except one failing ld
test that puzzles me:

BUG IN DYNAMIC LINKER ld.so: dl-load.c: 870: _dl_map_object_from_fd:
Assertion `loadcmds[0].mapoff == 0' failed!
FAIL: shared (non PIC, load offset)

This is the only thing I would like to have resolved before using a current
snapshot in 2.9.1.0.21.

Franz.

Re: Stabilization status

[Franz Sirl]

At 10:59 16.02.99 , Philip Blundell wrote:
>>BTW, I am working on 2.9.1.0.21 now. The problem is Linux/ARM. I was told
the 
>>gas snapshots didn't do Linux/ARM right. I cannot switch to the gas 
>>snapshots before Linux/ARM is supported.
>
>I think patches exist to make Linux/ARM work on the snapshots.  Most of them 
>are in the hands of the gas2 people and waiting to be merged.  If you want I 
>can send them to you for binutils 2.9.1.0.21.

This would be great. The last snapshot that tests fine for me is 981227. I
just tested the 990217 snapshot and it is mostly fine except one failing ld
test that puzzles me:

BUG IN DYNAMIC LINKER ld.so: dl-load.c: 870: _dl_map_object_from_fd:
Assertion `loadcmds[0].mapoff == 0' failed!
FAIL: shared (non PIC, load offset)

This is the only thing I would like to have resolved before using a current
snapshot in 2.9.1.0.21.

Franz.

Re: Stabilization status

[Philip Blundell]

>BTW, I am working on 2.9.1.0.21 now. The problem is Linux/ARM. I was told the 
>gas snapshots didn't do Linux/ARM right. I cannot switch to the gas 
>snapshots before Linux/ARM is supported.

I think patches exist to make Linux/ARM work on the snapshots.  Most of them 
are in the hands of the gas2 people and waiting to be merged.  If you want I 
can send them to you for binutils 2.9.1.0.21.

p.

Re: Stabilization status

[H.J. Lu]

> 
> Hmm, this problem might become obsolete quite soon, as H.J. Lu will switch his
> linux-binutils to the snapshots during one of the next releases (.21 or .22 I
> assume).
> 

BTW, I am working on 2.9.1.0.21 now. The problem is Linux/ARM. I was told the gas
snapshots didn't do Linux/ARM right. I cannot switch to the gas snapshots before
Linux/ARM is supported.

-- 
H.J. Lu (hjl@gnu.org)

Re: Stabilization status

[Franz Sirl]

Am Mon, 15 Feb 1999 schrieb Gary Thomas:
>On 15-Feb-99 Franz Sirl wrote:
>> Am Mon, 15 Feb 1999 schrieb Jeffrey A Law:
>>>In message <99010521361700.01228@ns1102.munich.netsurf.de>you write:
>>>  > I further investigated this and it seems to be a binutils problem. Michael
>>>  > Meissners recent change to put things into .sbss instead of .sdata triggers
>>>  > a bug in binutils-2.9.1.0.19a (and earlier probably). I built egcs with a
>>>  > current gas snapshot without problems.
>>>  >
>>>  > 
>>>  > I would appreciate if someone could send the corresponding binutils fix to 
>>>  > H.J Lu, so he can include it in binutils-2.9.1.0.20.
>>>It occurs to me that we should probably have an FAQ entry on the need for a
>>>newer assembler on ppc-linux.
>>>
>>>Want to write one up and submit it?
>>>
>>>If you don't know html, then submitting plaintext is fine, it can be html-ized
>>>easily.
>> 
>> Yeah, I can write something up. Would you mind placing a gas-981227-ppc.tar.gz
>> into the infrastructure dir? Then I can hyperlink to it. Later/current snapshots
>> don't check well on the PPC. One, hopefully harmless :-), test will always fail,
>> cause -fdata-sections is not yet implemented in egcs for PPC.
>> 
>> Franz.
>
>Franz,
>
>If you send me the files/patches, I'll make a binutils+gas RPM available until
>there is a more "official" solution.

I would love to, but it's impossible for me to track them down as there is no
anonymous CVS for binutils/gas yet. But I don't see it as a big problem, cause
it only hurts the mainline now and I assume binutils-2.10 will be out before
egcs-1.2. And for people trying the mainline now on PPC the FAQ entry should be
enough for now.

Hmm, this problem might become obsolete quite soon, as H.J. Lu will switch his
linux-binutils to the snapshots during one of the next releases (.21 or .22 I
assume).

Franz.

Re: Stabilization status

[H.J. Lu]

> >>  > I would appreciate if someone could send the corresponding binutils fix to 
> >>  > H.J Lu, so he can include it in binutils-2.9.1.0.20.
> 
> Franz,
> 
> If you send me the files/patches, I'll make a binutils+gas RPM available until
> there is a more "official" solution.
> 

I have access to a PPC. But it is a glibc-1.99 based system. I cannot install
glibc 2.1 on it. If someone can tell me where I can get a glibc-2.1 based
PPC CD or distribution, I will fix binutils-2.9.1.0.2x for PPC.


H.J.

Re: Stabilization status

[Gary Thomas]

On 16-Feb-99 H.J. Lu wrote:
>> >>  > I would appreciate if someone could send the corresponding binutils fix to 
>> >>  > H.J Lu, so he can include it in binutils-2.9.1.0.20.
>> 
>> Franz,
>> 
>> If you send me the files/patches, I'll make a binutils+gas RPM available until
>> there is a more "official" solution.
>> 
> 
> I have access to a PPC. But it is a glibc-1.99 based system. I cannot install
> glibc 2.1 on it. If someone can tell me where I can get a glibc-2.1 based
> PPC CD or distribution, I will fix binutils-2.9.1.0.2x for PPC.
> 

I'm not running GLIBC-2.1 yet either and I think that it would be nice/appropriate
to make these changes for all systems.

If you can get me the [gas] changes, etc, I'll make the 2.9.1.0.2x for Linux/PPC

Re: Stabilization status

[Gary Thomas]

On 16-Feb-99 H.J. Lu wrote:
>> >>  > I would appreciate if someone could send the corresponding binutils fix to 
>> >>  > H.J Lu, so he can include it in binutils-2.9.1.0.20.
>> 
>> Franz,
>> 
>> If you send me the files/patches, I'll make a binutils+gas RPM available until
>> there is a more "official" solution.
>> 
> 
> I have access to a PPC. But it is a glibc-1.99 based system. I cannot install
> glibc 2.1 on it. If someone can tell me where I can get a glibc-2.1 based
> PPC CD or distribution, I will fix binutils-2.9.1.0.2x for PPC.
> 

I'm not running GLIBC-2.1 yet either and I think that it would be nice/appropriate
to make these changes for all systems.

If you can get me the [gas] changes, etc, I'll make the 2.9.1.0.2x for Linux/PPC

Re: Stabilization status

[H.J. Lu]

> >>  > I would appreciate if someone could send the corresponding binutils fix to 
> >>  > H.J Lu, so he can include it in binutils-2.9.1.0.20.
> 
> Franz,
> 
> If you send me the files/patches, I'll make a binutils+gas RPM available until
> there is a more "official" solution.
> 

I have access to a PPC. But it is a glibc-1.99 based system. I cannot install
glibc 2.1 on it. If someone can tell me where I can get a glibc-2.1 based
PPC CD or distribution, I will fix binutils-2.9.1.0.2x for PPC.


H.J.

Re: Stabilization status

[Gary Thomas]

On 15-Feb-99 Franz Sirl wrote:
> Am Mon, 15 Feb 1999 schrieb Jeffrey A Law:
>>In message <99010521361700.01228@ns1102.munich.netsurf.de>you write:
>>  > I further investigated this and it seems to be a binutils problem. Michael
>>  > Meissners recent change to put things into .sbss instead of .sdata triggers
>>  > a bug in binutils-2.9.1.0.19a (and earlier probably). I built egcs with a
>>  > current gas snapshot without problems.
>>  >
>>  > 
>>  > I would appreciate if someone could send the corresponding binutils fix to 
>>  > H.J Lu, so he can include it in binutils-2.9.1.0.20.
>>It occurs to me that we should probably have an FAQ entry on the need for a
>>newer assembler on ppc-linux.
>>
>>Want to write one up and submit it?
>>
>>If you don't know html, then submitting plaintext is fine, it can be html-ized
>>easily.
> 
> Yeah, I can write something up. Would you mind placing a gas-981227-ppc.tar.gz
> into the infrastructure dir? Then I can hyperlink to it. Later/current snapshots
> don't check well on the PPC. One, hopefully harmless :-), test will always fail,
> cause -fdata-sections is not yet implemented in egcs for PPC.
> 
> Franz.

Franz,

If you send me the files/patches, I'll make a binutils+gas RPM available until
there is a more "official" solution.


------------------------------------------------------------------------
Gary Thomas                              |
email: gdt@linuxppc.org                  | "Fine wine is a necessity of
   ... opinions expressed here are mine  |        life for me"
       and no one else would claim them! |
                                         |      Thomas Jefferson
------------------------------------------------------------------------

Re: Stabilization status

[Jeffrey A Law]

  In message < 99021509205800.00478@ns1102.munich.netsurf.de >you write:
  > Yeah, I can write something up. Would you mind placing a
  > gas-981227-ppc.tar.gz into the infrastructure dir? Then I can hyperlink to
  > it. Later/current snapshots don't check well on the PPC. One, hopefully
  > harmless :-), test will always fail, cause -fdata-sections is not yet
  > implemented in egcs for PPC.
I'd prefer to put a standard gas/binutils snapshot out there rather if we
could make that work.

jeff

Re: Stabilization status

[Jeffrey A Law]

  In message < 99021509205800.00478@ns1102.munich.netsurf.de >you write:
  > Yeah, I can write something up. Would you mind placing a
  > gas-981227-ppc.tar.gz into the infrastructure dir? Then I can hyperlink to
  > it. Later/current snapshots don't check well on the PPC. One, hopefully
  > harmless :-), test will always fail, cause -fdata-sections is not yet
  > implemented in egcs for PPC.
I'd prefer to put a standard gas/binutils snapshot out there rather if we
could make that work.

jeff

Re: Stabilization status

[Franz Sirl]

Am Mon, 15 Feb 1999 schrieb Jeffrey A Law:
>In message <99010521361700.01228@ns1102.munich.netsurf.de>you write:
>  > I further investigated this and it seems to be a binutils problem. Michael
>  > Meissners recent change to put things into .sbss instead of .sdata triggers
>  > a bug in binutils-2.9.1.0.19a (and earlier probably). I built egcs with a
>  > current gas snapshot without problems.
>  >
>  > 
>  > I would appreciate if someone could send the corresponding binutils fix to 
>  > H.J Lu, so he can include it in binutils-2.9.1.0.20.
>It occurs to me that we should probably have an FAQ entry on the need for a
>newer assembler on ppc-linux.
>
>Want to write one up and submit it?
>
>If you don't know html, then submitting plaintext is fine, it can be html-ized
>easily.

Yeah, I can write something up. Would you mind placing a gas-981227-ppc.tar.gz
into the infrastructure dir? Then I can hyperlink to it. Later/current snapshots
don't check well on the PPC. One, hopefully harmless :-), test will always fail,
cause -fdata-sections is not yet implemented in egcs for PPC.

Franz.

Re: Stabilization status

[Gerald Pfeifer]

On Mon, 15 Feb 1999, Jeffrey A Law wrote:
> It occurs to me that we should probably have an FAQ entry on the need for a
> newer assembler on ppc-linux.
> 
> Want to write one up and submit it?

I believe that we should try to put all configure and build time
instructions into http://egcs.cygnus.com/install/ aka htdocs/install/
in our wwwdocs module.

If, and only if, people still Frequently Ask we should consider adding
something a pointer to the FAQ as well. Perhaps a general link to the
installation notes might be useful?


Franz, currently htdocs/install/specific.html says:

<p><b>powerpc-*-linux-gnu*</b><br>
You will need
<a href=" ftp://ftp.yggdrasil.com/private/hjl ">binutils-2.8.1.0.23</a> for
a working egcs. It is strongly recommended to recompile binutils with egcs
if you initially built it with gcc-2.7.2.*.

Is that sufficient? If not, could you please provide an update for that?
(As Jeff said, any format is fine, though clearly I wouldn't mind a patch
either... ;-) )

Gerald
-- 
Gerald Pfeifer (Jerry)      Vienna University of Technology
pfeifer@dbai.tuwien.ac.at   http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Stabilization status

[Jeffrey A Law]

  In message < Pine.GSO.4.10.9902151234440.17124-100000@markab.dbai.tuwien.ac.at
>you write:
  > I believe that we should try to put all configure and build time
  > instructions into http://egcs.cygnus.com/install/ aka htdocs/install/
  > in our wwwdocs module.
  > 
  > If, and only if, people still Frequently Ask we should consider adding
  > something a pointer to the FAQ as well. Perhaps a general link to the
  > installation notes might be useful?
Seems reasonable to me.

One of the long term things I think we ought to do is ravamp the gcc manual
a little bit and get it online too -- probably generating html from the
texinfo source.

I'd also like to see the manual more physically split up -- we've got 3
significant sections.  1. installation stuff  2. using gcc (flags, extensions
and the like) and 3. internals for developers.  Few people actually need to
look at all three sections.  As is, it's rather intimidating when someone
says "look in the gcc manual".

jeff

Re: Stabilization status

[Benjamin Scherrey]

    This is probably as important as implementing any new feature I could think of
right now. Wonderful idea!

        Ben Scherrey

Jeffrey A Law wrote:

> One of the long term things I think we ought to do is ravamp the gcc manual
> a little bit and get it online too -- probably generating html from the
> texinfo source.
>
> I'd also like to see the manual more physically split up -- we've got 3
> significant sections.  1. installation stuff  2. using gcc (flags, extensions
> and the like) and 3. internals for developers.  Few people actually need to
> look at all three sections.  As is, it's rather intimidating when someone
> says "look in the gcc manual".
>
> jeff

Re: Stabilization status

[Benjamin Scherrey]

    This is probably as important as implementing any new feature I could think of
right now. Wonderful idea!

        Ben Scherrey

Jeffrey A Law wrote:

> One of the long term things I think we ought to do is ravamp the gcc manual
> a little bit and get it online too -- probably generating html from the
> texinfo source.
>
> I'd also like to see the manual more physically split up -- we've got 3
> significant sections.  1. installation stuff  2. using gcc (flags, extensions
> and the like) and 3. internals for developers.  Few people actually need to
> look at all three sections.  As is, it's rather intimidating when someone
> says "look in the gcc manual".
>
> jeff

Re: Stabilization status

[Gerald Pfeifer]

On Wed, 17 Feb 1999, Jeffrey A Law wrote:
> I'd also like to see the manual more physically split up -- we've got
> 3 significant sections.  1. installation stuff 2. using gcc (flags,
> extensions and the like) and 3. internals for developers.

Here we also have some duplication, in that the GCC texinfo manual and
wwwdocs/htdocs/install overlap.

How should we handle that in the long term?

Gerald
-- 
Gerald Pfeifer (Jerry)      Vienna University of Technology
pfeifer@dbai.tuwien.ac.at   http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Stabilization status

[Jeffrey A Law]

  In message < Pine.GSO.4.10.9902191738520.20726-100000@markab.dbai.tuwien.ac.at
>you write:
  > On Wed, 17 Feb 1999, Jeffrey A Law wrote:
  > > I'd also like to see the manual more physically split up -- we've got
  > > 3 significant sections.  1. installation stuff 2. using gcc (flags,
  > > extensions and the like) and 3. internals for developers.
  > 
  > Here we also have some duplication, in that the GCC texinfo manual and
  > wwwdocs/htdocs/install overlap.
  > 
  > How should we handle that in the long term?
This duplication is one of the issues behind the desire to revamp that part
of the manual.

The stuff on the web (IMHO) is in better shape than the gcc manual, largely
because the gcc manual's installation instructions are geared towards old
systems that nobody has anymore.

Regardless, I want to unify the configure/install information in the manual
with the stuff on the web into a single document that we can put on the web
and include in the gcc distributions.

jeff

Re: Stabilization status

[Gerald Pfeifer]

On Fri, 19 Feb 1999, Jeffrey A Law wrote:
> The stuff on the web (IMHO) is in better shape than the gcc manual
> [...]
> Regardless, I want to unify the configure/install information in the
> manual with the stuff on the web into a single document that we can
> put on the web and include in the gcc distributions.

I agree that this is highly desirable. Just, which should be the base
format? texi or HTML?

Personally, I'd somewhat favor HTML stored in our wwwdocs repository.  
Among others, we seem to get more contributions these days for stuff
residing there than we do for the texi manual.

(Actually I think we already might have a volunteer for the texi ->
HTML merger...)

Gerald
-- 
Gerald Pfeifer (Jerry)      Vienna University of Technology
pfeifer@dbai.tuwien.ac.at   http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Stabilization status

[Per Bothner]

> I agree that this is highly desirable. Just, which should be the base
> format? texi or HTML?

HTML is not a suitable source format for GNU manuals or non-trivial
documents.  (It is of course an important *distribution* format.)

At some point, we should switch to the Docbook DTD for SGML (and the XML
variant).  Maybe after SGMLtools 1.0 is released and common on Linux/GNU
distributions, since then it should be quite easy for people to install
and use it.  (It would also be desirable to have a texinfo->docbook
conversion program, as well as a docbook->info backend.)

Projects that already use Docbook include Gnome, eCos (Cygnus's
RTOS), and the Linux Docuemntation project.

Until we are ready to switch to Docbook, we should stick to texinfo.
(It doesn't have to be a complate change.  For example, it may make
sense to use Docbook for new documents initially.)

	--Per

Re: Stabilization status

[Per Bothner]

> Maybe after SGMLtools 1.0 is released ...

I should have checked first.  SGMLtools 2.0.2 is out.
See http://www.sgmltools.org .

We still don't have:

(a) a replacement for standalone info - either a docbok->info
converter, or program (and emacs mode) that can read html
but has the search and convenient keybindings of info.

(b) tools to make it easier to convert existing texinfo documents
to docbook.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: Stabilization status

[Dave Love]

>>>>> "Per" == Per Bothner <bothner@cygnus.com> writes:

 Per> We still don't have:

(c) Even any decent documentation on DocBook AFAIK -- though I'd like
    to hear otherwise!

Re: Stabilization status

[Dave Love]

>>>>> "Per" == Per Bothner <bothner@cygnus.com> writes:

 Per> We still don't have:

(c) Even any decent documentation on DocBook AFAIK -- though I'd like
    to hear otherwise!

Re: Stabilization status

[Per Bothner]

> Maybe after SGMLtools 1.0 is released ...

I should have checked first.  SGMLtools 2.0.2 is out.
See http://www.sgmltools.org .

We still don't have:

(a) a replacement for standalone info - either a docbok->info
converter, or program (and emacs mode) that can read html
but has the search and convenient keybindings of info.

(b) tools to make it easier to convert existing texinfo documents
to docbook.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: Stabilization status

[Per Bothner]

> I agree that this is highly desirable. Just, which should be the base
> format? texi or HTML?

HTML is not a suitable source format for GNU manuals or non-trivial
documents.  (It is of course an important *distribution* format.)

At some point, we should switch to the Docbook DTD for SGML (and the XML
variant).  Maybe after SGMLtools 1.0 is released and common on Linux/GNU
distributions, since then it should be quite easy for people to install
and use it.  (It would also be desirable to have a texinfo->docbook
conversion program, as well as a docbook->info backend.)

Projects that already use Docbook include Gnome, eCos (Cygnus's
RTOS), and the Linux Docuemntation project.

Until we are ready to switch to Docbook, we should stick to texinfo.
(It doesn't have to be a complate change.  For example, it may make
sense to use Docbook for new documents initially.)

	--Per

Re: Stabilization status

[Jeffrey A Law]

  In message < Pine.GSO.4.10.9902211859250.3380-100000@alphard.dbai.tuwien.ac.at
>you write:

  > I agree that this is highly desirable. Just, which should be the base
  > format? texi or HTML?
Unfortunately, I think it needs to be texi -- it is the GNU standard formatter.

We'll need a pretty strong argument to go a different direction than the
GNU standard.  I haven't seen any such arguments yet.

  > Personally, I'd somewhat favor HTML stored in our wwwdocs repository.  
  > Among others, we seem to get more contributions these days for stuff
  > residing there than we do for the texi manual.
Yes.  This is unfortunate.  We'll have to deal with it.

jeff

Re: Stabilization status

[Jeffrey A Law]

  In message < Pine.GSO.4.10.9902211859250.3380-100000@alphard.dbai.tuwien.ac.at
>you write:

  > I agree that this is highly desirable. Just, which should be the base
  > format? texi or HTML?
Unfortunately, I think it needs to be texi -- it is the GNU standard formatter.

We'll need a pretty strong argument to go a different direction than the
GNU standard.  I haven't seen any such arguments yet.

  > Personally, I'd somewhat favor HTML stored in our wwwdocs repository.  
  > Among others, we seem to get more contributions these days for stuff
  > residing there than we do for the texi manual.
Yes.  This is unfortunate.  We'll have to deal with it.

jeff

Re: Stabilization status

[Scott McDermott]

Gerald Pfeifer on Sun 21/02 19:15 +0100:
> I agree that this is highly desirable. Just, which should be the base
> format? texi or HTML?

sgml-tools-2 has backends for conversion of SGML to both of these
formats and of course several others.

-- 
Scott

Re: Stabilization status

[Scott McDermott]

To egcs@cygnus.com on Mon 22/02 11:28 -0500:
> > I agree that this is highly desirable. Just, which should be the
> > base format? texi or HTML?
> 
> sgml-tools-2 has backends for conversion of SGML to both of these
> formats and of course several others.

Sorry, this was in error.

-- 
Scott

Re: Stabilization status

[Scott McDermott]

To egcs@cygnus.com on Mon 22/02 11:28 -0500:
> > I agree that this is highly desirable. Just, which should be the
> > base format? texi or HTML?
> 
> sgml-tools-2 has backends for conversion of SGML to both of these
> formats and of course several others.

Sorry, this was in error.

-- 
Scott

Re: Stabilization status

[Dave Love]

>>>>> "SMD" == Scott McDermott <vaxerdec@frontiernet.net> writes:

 SMD> sgml-tools-2 has backends for conversion of SGML to both of
 SMD> these formats and of course several others.

Are you sure?  I wouldn't have thought DocBook->Texinfo was really
even feasible.  DocBook->info is a different matter, but I don't think
there's any Jade technology for that either.

Re: Stabilization status

[Dave Love]

>>>>> "SMD" == Scott McDermott <vaxerdec@frontiernet.net> writes:

 SMD> sgml-tools-2 has backends for conversion of SGML to both of
 SMD> these formats and of course several others.

Are you sure?  I wouldn't have thought DocBook->Texinfo was really
even feasible.  DocBook->info is a different matter, but I don't think
there's any Jade technology for that either.

Re: Stabilization status

[Scott McDermott]

Gerald Pfeifer on Sun 21/02 19:15 +0100:
> I agree that this is highly desirable. Just, which should be the base
> format? texi or HTML?

sgml-tools-2 has backends for conversion of SGML to both of these
formats and of course several others.

-- 
Scott

Re: Stabilization status

[Andreas Schwab]

Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

|> I agree that this is highly desirable. Just, which should be the base
|> format? texi or HTML?

Texinfo format can be trivially converted to HTML (in current pretests
this is done by makeinfo --html).  On the other hand, HTML is pretty
useless as a source format.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.cs.uni-dortmund.de                      completely different"
schwab@gnu.org

Re: Stabilization status

[Andreas Schwab]

Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

|> I agree that this is highly desirable. Just, which should be the base
|> format? texi or HTML?

Texinfo format can be trivially converted to HTML (in current pretests
this is done by makeinfo --html).  On the other hand, HTML is pretty
useless as a source format.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.cs.uni-dortmund.de                      completely different"
schwab@gnu.org

Re: Stabilization status

[Gerald Pfeifer]

On Fri, 19 Feb 1999, Jeffrey A Law wrote:
> The stuff on the web (IMHO) is in better shape than the gcc manual
> [...]
> Regardless, I want to unify the configure/install information in the
> manual with the stuff on the web into a single document that we can
> put on the web and include in the gcc distributions.

I agree that this is highly desirable. Just, which should be the base
format? texi or HTML?

Personally, I'd somewhat favor HTML stored in our wwwdocs repository.  
Among others, we seem to get more contributions these days for stuff
residing there than we do for the texi manual.

(Actually I think we already might have a volunteer for the texi ->
HTML merger...)

Gerald
-- 
Gerald Pfeifer (Jerry)      Vienna University of Technology
pfeifer@dbai.tuwien.ac.at   http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Stabilization status

[Jeffrey A Law]

  In message < Pine.GSO.4.10.9902191738520.20726-100000@markab.dbai.tuwien.ac.at
>you write:
  > On Wed, 17 Feb 1999, Jeffrey A Law wrote:
  > > I'd also like to see the manual more physically split up -- we've got
  > > 3 significant sections.  1. installation stuff 2. using gcc (flags,
  > > extensions and the like) and 3. internals for developers.
  > 
  > Here we also have some duplication, in that the GCC texinfo manual and
  > wwwdocs/htdocs/install overlap.
  > 
  > How should we handle that in the long term?
This duplication is one of the issues behind the desire to revamp that part
of the manual.

The stuff on the web (IMHO) is in better shape than the gcc manual, largely
because the gcc manual's installation instructions are geared towards old
systems that nobody has anymore.

Regardless, I want to unify the configure/install information in the manual
with the stuff on the web into a single document that we can put on the web
and include in the gcc distributions.

jeff

Re: Stabilization status

[Gerald Pfeifer]

On Wed, 17 Feb 1999, Jeffrey A Law wrote:
> I'd also like to see the manual more physically split up -- we've got
> 3 significant sections.  1. installation stuff 2. using gcc (flags,
> extensions and the like) and 3. internals for developers.

Here we also have some duplication, in that the GCC texinfo manual and
wwwdocs/htdocs/install overlap.

How should we handle that in the long term?

Gerald
-- 
Gerald Pfeifer (Jerry)      Vienna University of Technology
pfeifer@dbai.tuwien.ac.at   http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Stabilization status

[siliconjackal]

Warning
Could not process message with given Content-Type: 
multipart/signed; boundary=0XhtP95kHFp3KGBe; micalg=pgp-md5;protocol="application/pgp-signature"

Re: Stabilization status

[Jeffrey A Law]

  In message < 19990218012725.H20100@diwanh.cais.net >you write:
  > 1. Make and keep the documentation current if at all possible. For
  > instance, I found no instance of the '-m' switch on the manpage and in the
  > help, it does not give any mention as to the processors it will support
  > [I found out about -mpentiumpro through fooling around, which, although
  > fun, should be unnecesary].
The man pages are not really supported.  The GNU project supports documentation
in the "info" format.

In the distribution you picked up you have a copy of the gcc manual in the
info format.  You can use emacs to browse that format, or convert it into
postscript for printing.

All the -m switches for each target should be documented in the manual.

  > 2. Provide a source trace for what stage of compilation goes where. For
  > instance, something like this [I have looked but, have been unable to
  > locate this file]> When compiling a program, comments are stripped in file
  > blah.c, then the preprocessor function includes(...) is called to
  > determine and extract the functions from the library, etc.
Huh?  Can you try to be clearer?  I have no idea what you're asking for.

  > 3. Since most, if not all, egcs developers are on the internet, these
  > should ideally be stored on high-bandwidth servers. This will reduce the
  > size of my CVS repository for the compiler by elimating all the texinfo/
  > directory and a few more things.
"these" refers to what?  

I don't forsee getting the egcs server co-located directly on bbn's network or
anything like that.  Such services can cost thousands of dollars per month.
Way outside the budget for a project like this.

Instead we have to depend on mirror sites to distribute the load of ftp service
for the project.



jeff

Re: Stabilization status

[Zack Weinberg]

On Sat, 20 Feb 1999 12:46:17 -0700, Jeffrey A Law wrote:
>  > 2. Provide a source trace for what stage of compilation goes where. For
>  > instance, something like this [I have looked but, have been unable to
>  > locate this file]> When compiling a program, comments are stripped in file
>  > blah.c, then the preprocessor function includes(...) is called to
>  > determine and extract the functions from the library, etc.
>Huh?  Can you try to be clearer?  I have no idea what you're asking for.

I think he's looking for the `Passes' node of the manual, except he
seems to be talking about the preprocessor.

zw

Re: Stabilization status

[Zack Weinberg]

On Sat, 20 Feb 1999 12:46:17 -0700, Jeffrey A Law wrote:
>  > 2. Provide a source trace for what stage of compilation goes where. For
>  > instance, something like this [I have looked but, have been unable to
>  > locate this file]> When compiling a program, comments are stripped in file
>  > blah.c, then the preprocessor function includes(...) is called to
>  > determine and extract the functions from the library, etc.
>Huh?  Can you try to be clearer?  I have no idea what you're asking for.

I think he's looking for the `Passes' node of the manual, except he
seems to be talking about the preprocessor.

zw

Re: Stabilization status

[Jeffrey A Law]

  In message < 19990218012725.H20100@diwanh.cais.net >you write:
  > 1. Make and keep the documentation current if at all possible. For
  > instance, I found no instance of the '-m' switch on the manpage and in the
  > help, it does not give any mention as to the processors it will support
  > [I found out about -mpentiumpro through fooling around, which, although
  > fun, should be unnecesary].
The man pages are not really supported.  The GNU project supports documentation
in the "info" format.

In the distribution you picked up you have a copy of the gcc manual in the
info format.  You can use emacs to browse that format, or convert it into
postscript for printing.

All the -m switches for each target should be documented in the manual.

  > 2. Provide a source trace for what stage of compilation goes where. For
  > instance, something like this [I have looked but, have been unable to
  > locate this file]> When compiling a program, comments are stripped in file
  > blah.c, then the preprocessor function includes(...) is called to
  > determine and extract the functions from the library, etc.
Huh?  Can you try to be clearer?  I have no idea what you're asking for.

  > 3. Since most, if not all, egcs developers are on the internet, these
  > should ideally be stored on high-bandwidth servers. This will reduce the
  > size of my CVS repository for the compiler by elimating all the texinfo/
  > directory and a few more things.
"these" refers to what?  

I don't forsee getting the egcs server co-located directly on bbn's network or
anything like that.  Such services can cost thousands of dollars per month.
Way outside the budget for a project like this.

Instead we have to depend on mirror sites to distribute the load of ftp service
for the project.



jeff

Re: Stabilization status

[siliconjackal]

1. Make and keep the documentation current if at all possible. For instance, I found no instance of the '-m' switch on the manpage and in the help, it does not give any mention as to the processors it will support [I found out about 
-mpentiumpro through fooling around, which, although fun, should be unnecessary]. 
2. Provide a source trace for what stage of compilation goes where. For instance, something like this [I have looked but, have been unable to locate this file]: 
When compiling a program, comments are stripped in file blah.c, then the preprocessor function includes(...) is called to determine and extract the functions from the library, etc.
3. Since most, if not all, egcs developers are on the internet, these should ideally be stored on high-bandwidth servers. This will reduce the size of my CVS repository for the compiler by elimating all the texinfo/ directory and a few more things.

-- 
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a

iQCVAwUBNsuyzQ6sg/oMyISxAQGI9gP+OP/1q2nTh7SliJDohz03o3cwGBU3zW6X
P9Hx8HD2IZgxWDgpWSkm+nVuNT8FszlfRGmzrXC6Nsefw2dtphXCc3/kXR9K+KLS
TzDsStFksdYAv+qCurL7d+lbuIMbgAr8HjjDHpcVZP57dbQibACLtWbUZPOfnAbc
gqOoC0f+O2Q=
=XT6e
-----END PGP SIGNATURE-----

Re: Stabilization status

[Jeffrey A Law]

  In message < Pine.GSO.4.10.9902151234440.17124-100000@markab.dbai.tuwien.ac.at
>you write:
  > I believe that we should try to put all configure and build time
  > instructions into http://egcs.cygnus.com/install/ aka htdocs/install/
  > in our wwwdocs module.
  > 
  > If, and only if, people still Frequently Ask we should consider adding
  > something a pointer to the FAQ as well. Perhaps a general link to the
  > installation notes might be useful?
Seems reasonable to me.

One of the long term things I think we ought to do is ravamp the gcc manual
a little bit and get it online too -- probably generating html from the
texinfo source.

I'd also like to see the manual more physically split up -- we've got 3
significant sections.  1. installation stuff  2. using gcc (flags, extensions
and the like) and 3. internals for developers.  Few people actually need to
look at all three sections.  As is, it's rather intimidating when someone
says "look in the gcc manual".

jeff

Re: Stabilization status

[Gerald Pfeifer]

On Mon, 15 Feb 1999, Jeffrey A Law wrote:
> It occurs to me that we should probably have an FAQ entry on the need for a
> newer assembler on ppc-linux.
> 
> Want to write one up and submit it?

I believe that we should try to put all configure and build time
instructions into http://egcs.cygnus.com/install/ aka htdocs/install/
in our wwwdocs module.

If, and only if, people still Frequently Ask we should consider adding
something a pointer to the FAQ as well. Perhaps a general link to the
installation notes might be useful?


Franz, currently htdocs/install/specific.html says:

<p><b>powerpc-*-linux-gnu*</b><br>
You will need
<a href=" ftp://ftp.yggdrasil.com/private/hjl ">binutils-2.8.1.0.23</a> for
a working egcs. It is strongly recommended to recompile binutils with egcs
if you initially built it with gcc-2.7.2.*.

Is that sufficient? If not, could you please provide an update for that?
(As Jeff said, any format is fine, though clearly I wouldn't mind a patch
either... ;-) )

Gerald
-- 
Gerald Pfeifer (Jerry)      Vienna University of Technology
pfeifer@dbai.tuwien.ac.at   http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Stabilization status

[Jeffrey A Law]

  In message <99010521361700.01228@ns1102.munich.netsurf.de>you write:
  > I further investigated this and it seems to be a binutils problem. Michael
  > Meissners recent change to put things into .sbss instead of .sdata triggers
  > a bug in binutils-2.9.1.0.19a (and earlier probably). I built egcs with a
  > current gas snapshot without problems.
  >
  > 
  > I would appreciate if someone could send the corresponding binutils fix to 
  > H.J Lu, so he can include it in binutils-2.9.1.0.20.
It occurs to me that we should probably have an FAQ entry on the need for a
newer assembler on ppc-linux.

Want to write one up and submit it?

If you don't know html, then submitting plaintext is fine, it can be html-ized
easily.

jeff

Re: Stabilization status

[David Edelsohn]

>>>>> Jeffrey A Law writes:

Jeff> Makes me wonder if we should be building with -mminimal-toc during stage2 and
Jeff> stage3.  I'm not all that familiar with the PPC, so I'm not sure.

	We definitely should not be using -mminimal-toc.

Jeff> On ppc-linux it appears that the stage1 compiler has mis-compiled stage2 cpp
Jeff> which causes stage2 cpp to croak.

	I assume that this is completely unrelated to the AIX bug.

David

Re: Stabilization status

[Jeffrey A Law]

  In message < 9901020122.AA26732@marc.watson.ibm.com >you write:
  > Jeff> On ppc-linux it appears that the stage1 compiler has mis-compiled sta
  > ge2 cpp
  > Jeff> which causes stage2 cpp to croak.
  > 
  > 	I assume that this is completely unrelated to the AIX bug.
Correct.

jeff

Re: Stabilization Status

[Kaveh R. Ghazi]

 >  From: Jeffrey A Law <law@hurl.cygnus.com>
 >  
 >  I'm running a series of -funroll-loops tests now.  I'm currently trying
 >  to debug a mis-compilation of stage2 genattrtab.c on the mips targets. 
 >  More details as they're available. 
 >  Fun fun fun.
 >  jeff

	I think it might be a more thorough stress on the unrolling code
if you used -funroll-all-loops instead of -funroll-loops in your matrix.

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Icon CMT Corp.

Re: Stabilization Status

[Jeffrey A Law]

  In message < 199901060452.XAA17297@caip.rutgers.edu >you write:
  >  >  From: Jeffrey A Law <law@hurl.cygnus.com>
  >  >  
  >  >  I'm running a series of -funroll-loops tests now.  I'm currently trying
  >  >  to debug a mis-compilation of stage2 genattrtab.c on the mips targets. 
  >  >  More details as they're available. 
  >  >  Fun fun fun.
  >  >  jeff
  > 
  > 	I think it might be a more thorough stress on the unrolling code
  > if you used -funroll-all-loops instead of -funroll-loops in your matrix.
-funroll-loops is turning of plenty of problems on its own right now.  :(

jeff

Stabilization status

[Jeffrey A Law]

				    -O1		    -O2		    -O9
			       -funroll-loops  -funroll-loops  -funroll-loops

alpha-dec-osf4.0a		     Y		     Y		     Y
alphaev56-unknown-linux-gnu	     Y		     Y		     Y
hppa2.0-hp-hpux10.20		     Y		     Y		     Y
i386-unknown-freebsd2.2.6	     Y		     Y		     Y
i586-pc-linux-gnu		     Y		     Y		     Y
i686-pc-linux-gnu		     Y		     Y		     Y
m68k-hp-bsd4.4			    FAIL -->
mips-sgi-irix6.3		    FAIL -->
powerpc-ibm-aix4.2.0.0		     Y		    FAIL -->
powerpc-unknown-linux-gnulibc1	    FAIL -->
sparc-sun-solaris2.5.1		     Y		     Y		     Y
sparc-sun-sunos4.1.1		     Y		     Y		     Y


I think this shows pretty clearly that there's still at least one major
problem still in the unroller.

Re: Stabilization status

[Franz Sirl]

At 23:19 17.01.99 , Jeffrey A Law wrote:
>
>
>				    -O1		    -O2		    -O9
>			       -funroll-loops  -funroll-loops  -funroll-loops
>
>alpha-dec-osf4.0a		     Y		     Y		     Y
>alphaev56-unknown-linux-gnu	     Y		     Y		     Y
>hppa2.0-hp-hpux10.20		     Y		     Y		     Y
>i386-unknown-freebsd2.2.6	     Y		     Y		     Y
>i586-pc-linux-gnu		     Y		     Y		     Y
>i686-pc-linux-gnu		     Y		     Y		     Y
>m68k-hp-bsd4.4			    FAIL -->
>mips-sgi-irix6.3		    FAIL -->
>powerpc-ibm-aix4.2.0.0		     Y		    FAIL -->
>powerpc-unknown-linux-gnulibc1	    FAIL -->
>sparc-sun-solaris2.5.1		     Y		     Y		     Y
>sparc-sun-sunos4.1.1		     Y		     Y		     Y
>
>
>I think this shows pretty clearly that there's still at least one major
>problem still in the unroller.

With cvs-egcs on powerpc-unknow-linux-gnu on glibc-2.0.108/110 with
gas-981227, latest egcs ChangeLog entry being:
Tue Jan 19 21:20:52 1999  Richard Henderson  <rth@cygnus.com>

        * recog.c (pop_operand): New function.
        * recog.h (pop_operand): Declare it.
        * genrecog.c (preds): Define it.

        * expr.c (do_jump_for_compare): Handle conditional branch expanders
        emitting multiple jump instructions.
        * jump.c (condjump_label): New function.
        * rtl.h (condjump_label): Declare it.

egcs now bootstraps fine with both -O2 and -O2 -funroll-loops. make check
shows identical results for both.
There is however a regression compared to earlier versions in the Fortran
tests:
FAIL: g77.f-torture/compile/980424-0.f,  -O1  
FAIL: g77.f-torture/compile/980424-0.f,  -O2  
FAIL: g77.f-torture/compile/980424-0.f,  -O2 -fomit-frame-pointer
-finline-functions  
FAIL: g77.f-torture/compile/980424-0.f,  -Os  

Do you want me to run the bootstrap with other options again?

BTW, maybe egcs_1_2_branch could be branched of now, as a fallout of the
stabilization cycle? :-)

Franz.

Re: Stabilization status

[Franz Sirl]

At 23:19 17.01.99 , Jeffrey A Law wrote:
>
>
>				    -O1		    -O2		    -O9
>			       -funroll-loops  -funroll-loops  -funroll-loops
>
>alpha-dec-osf4.0a		     Y		     Y		     Y
>alphaev56-unknown-linux-gnu	     Y		     Y		     Y
>hppa2.0-hp-hpux10.20		     Y		     Y		     Y
>i386-unknown-freebsd2.2.6	     Y		     Y		     Y
>i586-pc-linux-gnu		     Y		     Y		     Y
>i686-pc-linux-gnu		     Y		     Y		     Y
>m68k-hp-bsd4.4			    FAIL -->
>mips-sgi-irix6.3		    FAIL -->
>powerpc-ibm-aix4.2.0.0		     Y		    FAIL -->
>powerpc-unknown-linux-gnulibc1	    FAIL -->
>sparc-sun-solaris2.5.1		     Y		     Y		     Y
>sparc-sun-sunos4.1.1		     Y		     Y		     Y
>
>
>I think this shows pretty clearly that there's still at least one major
>problem still in the unroller.

With cvs-egcs on powerpc-unknow-linux-gnu on glibc-2.0.108/110 with
gas-981227, latest egcs ChangeLog entry being:
Tue Jan 19 21:20:52 1999  Richard Henderson  <rth@cygnus.com>

        * recog.c (pop_operand): New function.
        * recog.h (pop_operand): Declare it.
        * genrecog.c (preds): Define it.

        * expr.c (do_jump_for_compare): Handle conditional branch expanders
        emitting multiple jump instructions.
        * jump.c (condjump_label): New function.
        * rtl.h (condjump_label): Declare it.

egcs now bootstraps fine with both -O2 and -O2 -funroll-loops. make check
shows identical results for both.
There is however a regression compared to earlier versions in the Fortran
tests:
FAIL: g77.f-torture/compile/980424-0.f,  -O1  
FAIL: g77.f-torture/compile/980424-0.f,  -O2  
FAIL: g77.f-torture/compile/980424-0.f,  -O2 -fomit-frame-pointer
-finline-functions  
FAIL: g77.f-torture/compile/980424-0.f,  -Os  

Do you want me to run the bootstrap with other options again?

BTW, maybe egcs_1_2_branch could be branched of now, as a fallout of the
stabilization cycle? :-)

Franz.

Re: Stabilization status

[H.J. Lu]

> 				    -O1		    -O2		    -O9
> 			       -funroll-loops  -funroll-loops  -funroll-loops
> 
> i686-pc-linux-gnu		     Y		     Y		     Y

Correct me if I am wrong. I have an impression that even if egcs is
configured for i686-pc-linux-gnu, it won't generate i686 instructions
by default. You still need to add -march=i686 to exercise the i686
part of egcs. If it is true, should -march=i686 be added to CFLAGS for
i686-pc-linux-gnu?

-- 
H.J. Lu (hjl@gnu.org)

Re: Stabilization status

[Jeffrey A Law]

  In message < m1022Mc-000390C@ocean.lucon.org >you write:
  > > 				    -O1		    -O2		    -O9
  > > 			       -funroll-loops  -funroll-loops  -funroll-loops
  > > 
  > > i686-pc-linux-gnu		     Y		     Y		     Y
  > 
  > Correct me if I am wrong. I have an impression that even if egcs is
  > configured for i686-pc-linux-gnu, it won't generate i686 instructions
  > by default. You still need to add -march=i686 to exercise the i686
  > part of egcs. If it is true, should -march=i686 be added to CFLAGS for
  > i686-pc-linux-gnu?
Correct.  I haven't started on the machine dependent stuff yet.

If you read the first message about this topic, it explained the order in
which I was going to attack problems.

jeff

Re: Stabilization Status

[Kaveh R. Ghazi]

 > From: Jeffrey A Law <law@hurl.cygnus.com>
 >  
 >   In message < 199901060452.XAA17297@caip.rutgers.edu >you write:
 >   >  >  From: Jeffrey A Law <law@hurl.cygnus.com>
 >   >  >  
 >   >  >  I'm running a series of -funroll-loops tests now.  I'm currently trying
 >   >  >  to debug a mis-compilation of stage2 genattrtab.c on the mips targets. 
 >   >  >  More details as they're available. 
 >   >  >  Fun fun fun.
 >   >  >  jeff
 >   > 
 >   >     I think it might be a more thorough stress on the unrolling code
 >   > if you used -funroll-all-loops instead of -funroll-loops in your matrix.
 >  
 > -funroll-loops is turning of plenty of problems on its own right now.  :(
 > jeff

	Okay.  

PS: thanks for all the work stabilizing the tree.  Its much improved
from your recent efforts.

--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Icon CMT Corp.

Re: Stabilization status

[Kaveh R. Ghazi]

 > From: Jeffrey A Law <law@hurl.cygnus.com>
 > 
 >   In message < 9901131953.AA100818@marc.watson.ibm.com >you write:
 >   >     Some AIX "lslpp" command can obtain the level of the linker
 >   > fileset installed on the system.
 > 
 > This would be the best approach for detecting the older braindamaged linkers.
 > jeff


	Okay.  I'm not an AIX guru so I don't know much about lslpp.  I
read the man page, poked at it a bit and guessed that bos.rte.bind_cmds
is the correct Fileset name.

The response from "lslpp -Lc bos.rte.bind_cmds" on AIX4.1.4.0 is:

 > #Package Name:Fileset:Level:State:PTF Id:Fix State:Type:Description:
 > bos:bos.rte.bind_cmds:4.1.4.0: : :C: :Binder and Loader Commands

	I'm guessing that if we did "| awk -F: '{printf$3}'" it would get
us the "Level" which should be the right number to check.



David, would you verify/answer:

1.  Is bos.rte.bind_cmds the right fileset?
2.  Is field #3 the right field to check?
3.  What does the output look like when the patch is installed?
	I don't know if the bos.rte.bind_cmds is replaced with a new
	version row or a second row appears after the first.
	Should I just pipe it thought tail -1 to get the right row?
4.  Assuming we are looking at the correct data, what values signify
	we have the patch and which ones signify we don't have it?




 > From: Jeffrey A Law <law@hurl.cygnus.com>
 > 
 >   > If we can run an autoconf test and it fails, then and only then would we
 >   > need to compile with -mminimal-toc. 
 > 
 > Agreed.  It's cleaner too.  I've got a dusty 3.2.5 and 4.1.3 box I can test
 > and iterate on if you've got something rough.
 > jeff


	Once David answers the above questions, I can hack something up. 
What's your feeling on the best way to implement this and the place to
put it?

	I'm thinking we set X_CFLAGS in x-aix41 to something like this:

X_CFLAGS=`if [ x@minimal_toc@ != x -a x$(BOOT_CFLAGS) != x ] ; echo '-mminimal-toc' ; fi`

where @minimal_toc@ is replaced by an autoconf test using lslpp.  (The
check on BOOT_CFLAGS makes sure we are in stage2 or later.)

	In the x-aix31 case we don't need to check lslpp according to
David, so we'd just make sure we are in stage2 or later.

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Icon CMT Corp.

Re: Stabilization status

[Jeffrey A Law]

  In message <199901141842.NAA02579@caip.rutgers.edu>you write:
  > 	Okay.  I'm not an AIX guru so I don't know much about lslpp.  I
  > read the man page, poked at it a bit and guessed that bos.rte.bind_cmds
  > is the correct Fileset name.
  > 
  > The response from "lslpp -Lc bos.rte.bind_cmds" on AIX4.1.4.0 is:
  > 
  >  > #Package Name:Fileset:Level:State:PTF Id:Fix State:Type:Description:
  >  > bos:bos.rte.bind_cmds:4.1.4.0: : :C: :Binder and Loader Commands
  > 
  > 	I'm guessing that if we did "| awk -F: '{printf$3}'" it would get
  > us the "Level" which should be the right number to check.
I think so.  Though as you note it is not clear what the field will look
like with the linker patch installed.

For reference here's what I get on two of our older aix boxes:

#Package Name:Fileset:Level:State:PTF Id:Fix State:Type:Description:
bos:bos.rte.bind_cmds:4.1.3.0: : :C:F:Binder and Loader Commands

#Package Name:Fileset:Level:State:PTF Id:Fix State:Type:Description:
bos:bos.rte.bind_cmds:4.1.4.0: : :C: :Binder and Loader Commands

And on our 4.2 box:

#Package Name:Fileset:Level:State:PTF Id:Fix State:Type:Description:
bos:bos.rte.bind_cmds:4.2.0.0: : :C: :Binder and Loader Commands

  > 1.  Is bos.rte.bind_cmds the right fileset?
  > 2.  Is field #3 the right field to check?
  > 3.  What does the output look like when the patch is installed?
  > 	I don't know if the bos.rte.bind_cmds is replaced with a new
  > 	version row or a second row appears after the first.
  > 	Should I just pipe it thought tail -1 to get the right row?
  > 4.  Assuming we are looking at the correct data, what values signify
  > 	we have the patch and which ones signify we don't have it?
One thought would be to add -minimal-toc for any aix 4.1.x box where x <
whatever version has the fixed linker bundled with the system.

Yes, it will cause us to generate poorer code on those older aix boxes, but 
since those older versions of aix less and less popular I don't think that's
a bad compromise.

  > 	Once David answers the above questions, I can hack something up. 
  > What's your feeling on the best way to implement this and the place to
  > put it?
  > 
  > 	I'm thinking we set X_CFLAGS in x-aix41 to something like this:
  > 
  > X_CFLAGS=`if [ x@minimal_toc@ != x -a x$(BOOT_CFLAGS) != x ] ; echo '-mmini
  > mal-toc' ; fi`
  > 
  > where @minimal_toc@ is replaced by an autoconf test using lslpp.  (The
  > check on BOOT_CFLAGS makes sure we are in stage2 or later.)
  > 
  > 	In the x-aix31 case we don't need to check lslpp according to
  > David, so we'd just make sure we are in stage2 or later.
Seems reasonable.

jeff

Re: Stabilization status

[Jeffrey A Law]

  In message <199901141842.NAA02579@caip.rutgers.edu>you write:
  > 	Okay.  I'm not an AIX guru so I don't know much about lslpp.  I
  > read the man page, poked at it a bit and guessed that bos.rte.bind_cmds
  > is the correct Fileset name.
  > 
  > The response from "lslpp -Lc bos.rte.bind_cmds" on AIX4.1.4.0 is:
  > 
  >  > #Package Name:Fileset:Level:State:PTF Id:Fix State:Type:Description:
  >  > bos:bos.rte.bind_cmds:4.1.4.0: : :C: :Binder and Loader Commands
  > 
  > 	I'm guessing that if we did "| awk -F: '{printf$3}'" it would get
  > us the "Level" which should be the right number to check.
I think so.  Though as you note it is not clear what the field will look
like with the linker patch installed.

For reference here's what I get on two of our older aix boxes:

#Package Name:Fileset:Level:State:PTF Id:Fix State:Type:Description:
bos:bos.rte.bind_cmds:4.1.3.0: : :C:F:Binder and Loader Commands

#Package Name:Fileset:Level:State:PTF Id:Fix State:Type:Description:
bos:bos.rte.bind_cmds:4.1.4.0: : :C: :Binder and Loader Commands

And on our 4.2 box:

#Package Name:Fileset:Level:State:PTF Id:Fix State:Type:Description:
bos:bos.rte.bind_cmds:4.2.0.0: : :C: :Binder and Loader Commands

  > 1.  Is bos.rte.bind_cmds the right fileset?
  > 2.  Is field #3 the right field to check?
  > 3.  What does the output look like when the patch is installed?
  > 	I don't know if the bos.rte.bind_cmds is replaced with a new
  > 	version row or a second row appears after the first.
  > 	Should I just pipe it thought tail -1 to get the right row?
  > 4.  Assuming we are looking at the correct data, what values signify
  > 	we have the patch and which ones signify we don't have it?
One thought would be to add -minimal-toc for any aix 4.1.x box where x <
whatever version has the fixed linker bundled with the system.

Yes, it will cause us to generate poorer code on those older aix boxes, but 
since those older versions of aix less and less popular I don't think that's
a bad compromise.

  > 	Once David answers the above questions, I can hack something up. 
  > What's your feeling on the best way to implement this and the place to
  > put it?
  > 
  > 	I'm thinking we set X_CFLAGS in x-aix41 to something like this:
  > 
  > X_CFLAGS=`if [ x@minimal_toc@ != x -a x$(BOOT_CFLAGS) != x ] ; echo '-mmini
  > mal-toc' ; fi`
  > 
  > where @minimal_toc@ is replaced by an autoconf test using lslpp.  (The
  > check on BOOT_CFLAGS makes sure we are in stage2 or later.)
  > 
  > 	In the x-aix31 case we don't need to check lslpp according to
  > David, so we'd just make sure we are in stage2 or later.
Seems reasonable.

jeff

Re: Stabilization status

[Kaveh R. Ghazi]

 > From: Jeffrey A Law <law@hurl.cygnus.com>
 > 
 > I can understand the desire to not spend a lot of time on old systems
 > like this because I feel the same way about hpux9 and earlier systems. 
 > However, fixing things so that the compiler "just works" on these older
 > versions of aix4.1 should be trivial and not take a lot of time. 
 >  
 > We just recognize the old versions and use a different x-blah file for
 > them.  Right?
 >  
 > Given the potential number of these boxes that are out there and the
 > ease of detecting them and handling them cleanly, I think we should bite
 > the bullet and handle them. 


	By handling them I take it you mean we add -mminimal-toc to the
bootstrap.  However I think David said this makes cc1 slower. 

Thus detecting the version number of AIX might not be enough.  I think
we want to only add -mminimal-toc if their AIX version needs it _and_
they haven't installed the magic patch which fixes this. 

David, is it possible to generate a C test case?  Or run some shell magic
to detect if the patch is installed and -bbigtoc works?

If we can run an autoconf test and it fails, then and only then would we
need to compile with -mminimal-toc. 

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Icon CMT Corp.

Re: Stabilization status

[David Edelsohn]

>>>>> "Kaveh R Ghazi" writes:

Kaveh> By handling them I take it you mean we add -mminimal-toc to the
Kaveh> bootstrap.  However I think David said this makes cc1 slower. 

	So far, cc1 has not crossed the TOC limit although cc1plus and
f771 have.

	It would be good to build cc1 and the common GCC files without
-mminimal-toc and only build cc1plus- and f771-specific files with that
option enabled.  The EGCS build process currently does not have the
functionality to use special LDFLAGS only for some targets.

Kaveh> Thus detecting the version number of AIX might not be enough.  I think
Kaveh> we want to only add -mminimal-toc if their AIX version needs it _and_
Kaveh> they haven't installed the magic patch which fixes this. 

	-mminimal-toc is necessary on AIX to build cc1plus and f771 on all
releases of AIX 3.  With the correct linker patch, -bbigtoc will work on
all releases of AIX 4.  If you want to use -mminimal-toc on AIX 4.1
without the patch, go ahead.

Kaveh> David, is it possible to generate a C test case?  Or run some shell magic
Kaveh> to detect if the patch is installed and -bbigtoc works?

Kaveh> If we can run an autoconf test and it fails, then and only then would we
Kaveh> need to compile with -mminimal-toc. 

	Some AIX "lslpp" command can obtain the level of the linker
fileset installed on the system.

David

Re: Stabilization status

[Jeffrey A Law]

  In message < 9901131953.AA100818@marc.watson.ibm.com >you write:
  > Kaveh> If we can run an autoconf test and it fails, then and only then woul
  > d we
  > Kaveh> need to compile with -mminimal-toc. 
  > 
  > 	Some AIX "lslpp" command can obtain the level of the linker
  > fileset installed on the system.
This would be the best approach for detecting the older braindamaged linkers.

jeff

Re: Stabilization status

[Jeffrey A Law]

  In message < 199901131743.MAA11350@caip.rutgers.edu >you write:
  > 	By handling them I take it you mean we add -mminimal-toc to the
  > bootstrap.
Correct.

  > However I think David said this makes cc1 slower. 
Correct.


  > If we can run an autoconf test and it fails, then and only then would we
  > need to compile with -mminimal-toc. 
Agreed.  It's cleaner too.  I've got a dusty 3.2.5 and 4.1.3 box I can test
and iterate on if you've got something rough.


jeff

Stabilization Status

[Jeffrey A Law]

                                    -O1             -O2             -O9
                               -funroll-loops  -funroll-loops  -funroll-loops
                                  -fo-f-p         -fo-f-p         -fo-f-p

i386-unknown-freebsd2.2.6            Y               Y               Y
i586-pc-linux-gnu                    Y               Y               Y
i686-pc-linux-gnu                    Y               Y               Y
m68k-hp-bsd4.4                      FAIL --> 


Well, these are the same results  I got a week ago with this test.  I was
hoping that the fixes Michael & I made to the unroller would fix the m68k
problems.  But that's not the case.

I guess I'll have to try again when we fix the unroller bug exposed by the
mips port.

jeff

Re: Stabilization status

[Kaveh R. Ghazi]

 > From: David Edelsohn <dje@watson.ibm.com>
 > 
 > >>>>> Jeffrey A Law writes:
 > 
 > Jeff> Makes me wonder if we should be building with -mminimal-toc
 > Jeff> during stage2 and stage3.  I'm not all that familiar with the
 > Jeff> PPC, so I'm not sure.
 > 
 > 	We definitely should not be using -mminimal-toc.
 > David

David,

	I agree we should not have -mminimal-toc inserted
automatically during a bootstrap.  However sometimes we do not have
the luxury of upgrading the OS or even installing a patch.  In my case
its a guest account and the sysadmin can't be bothered. :-(

	In these situations, adding -mminimal-toc by hand to
BOOT_CFLAGS has been a useful (and the only) course of action for me
ir order to be able to test egcs at all on AIX.

Jeff, if you find yourself in similar straights, -mminimal-toc should
allow testing bootstraps at various opt levels until you can arrange
for the patch to be installed or the OS to be upgraded.

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Icon CMT Corp.

Re: Stabilization status

[Jeffrey A Law]

  In message < 199901021849.NAA09920@caip.rutgers.edu >you write:
  > 	I agree we should not have -mminimal-toc inserted
  > automatically during a bootstrap.  However sometimes we do not have
  > the luxury of upgrading the OS or even installing a patch.  In my case
  > its a guest account and the sysadmin can't be bothered. :-(
Yup.  I'm in a similar situation, except that it's not a guest account.


  > 	In these situations, adding -mminimal-toc by hand to
  > BOOT_CFLAGS has been a useful (and the only) course of action for me
  > ir order to be able to test egcs at all on AIX.
OK.  I hadn't gotten around to trying that yet, but I will give it a try today.

Another approach would be to look at gcc itself to see why it uses so much TOC
space and see if there are sensible things we can do to reduce TOC space usage.

For example, grouping several related globals into a single global structure
may (or may not) reduce TOC usage and does have a small positive influence on
code generation for other targets.  It also makes debugging easier.

Consider Meissner's work to put all the reg_n_blah things into a single global
structure from 1997.  With a single gdb command I can get all the information
about a particular pseudo (uses, sets, live length, etc).

Similarly for the global_rtl changes jfc did in 1997.

I do not think we need to do this stuff immediately, but they do represent
some infrastructure cleanup with can do piecemeal over time.



jeff

Re: Stabilization status

[Michael Hayes]

Jeffrey A Law writes:
 > For example, grouping several related globals into a single global structure
 > may (or may not) reduce TOC usage and does have a small positive
 > influence on code generation for other targets.  It also makes
 > debugging easier.  Consider Meissner's work to put all the
 > reg_n_blah things into a single global structure from 1997.
 >  With a single gdb command I can get all the information
 > about a particular pseudo (uses, sets, live length, etc).

 > I do not think we need to do this stuff immediately, but they do represent
 > some infrastructure cleanup with can do piecemeal over time.

Coincedentally, a few days ago I modified the reload files to reduce
the plethora of global arrays by using a structure to hold the
information find_reloads collects.  I've been trying to debug an
obscure reload problem and decided that while reload was complex it
was still unnecessarily complicated, even after Bernd's sterling efforts.
However, since the patches are not a bug-fix, per se, I was waiting
for the freeze to be lifted...

Michael.

Re: Stabilization status

[David Edelsohn]

>>>>> Jeffrey A Law writes:

Jeff> Another approach would be to look at gcc itself to see why it uses so much TOC
Jeff> space and see if there are sensible things we can do to reduce TOC space usage.

	Anyone can boot or use those flags if they want, but GCC should
not use those flag automatically.

	The primary problem is that GCC does not utilize the TOC very
efficiently.  Identical TOC definitions in different modules are merged,
but multiple definitions in a single module (assembly file) are
concatenated.  GCC can emit definitions for static variables multiple
times which bloats the TOC when static variables are used.  Another
problem is that static variables and constants each are allocated a
separate TOC entry instead of using pools with only a single entry for
each per module.

	Your old -fcombine-statics functionality is the type of thing that
is needed.  The simplest way to describe it is that IBM's compiler behaves
like -mminimal-toc is enabled for constants and statics but not for global
variables.  And it dynamically allocates the base registers, only
allocating them when necessary.  I have not had time to pursue this.

David

Re: Stabilization status

[Jeffrey A Law]

  In message < 9901021937.AA26758@marc.watson.ibm.com >you write:
  > 	Anyone can boot or use those flags if they want, but GCC should
  > not use those flag automatically.
I'm not sure I totally agree.  I believe there's still a fair number of
AIX systems out there which aren't up-to-date enough to build egcs without
special options.  That's not good.

It may make sense to enable -mminimal-toc during a bootstrap for those older
AIX platforms.  Either based on the canonical target name or an autoconf test
of some kind.

  > concatenated.  GCC can emit definitions for static variables multiple
  > times which bloats the TOC when static variables are used. 
?!?  Really?  Wouldn't that cause an assembler error for multiple definitions?
Or are they output as "local common" variables?

  > Another
  > problem is that static variables and constants each are allocated a
  > separate TOC entry instead of using pools with only a single entry for
  > each per module.
It would probably be to our advantage to have multiple const pools.  One for
TOC entries, then another for all the compile-time constants.  Then we could
use a single TOC entry to reference all the compile-time constants for a single
file.

  > 	Your old -fcombine-statics functionality is the type of thing that
  > is needed.
Yea.  The big problem is we need the GC work before we can safely bring back
-fcombine-statics.  The root of the problem is we have to defer output of
statics until EOF.  Initializers in particular are troublesome because they're
often created on one of the short-lived obstacks.  So we have to copy them to
a more permanent obstack.  Worse yet, we have to recursively copy things they
point to that are not already on the permanent obstack.  The copying itself is
rather fragile and the memory explosions are signifiant.

  > The simplest way to describe it is that IBM's compiler behaves
  > like -mminimal-toc is enabled for constants and statics but not for global
  > variables.  And it dynamically allocates the base registers, only
  > allocating them when necessary.  I have not had time to pursue this.
Interesting.
jeff

Re: Stabilization status

[David Edelsohn]

>>>>> Jeffrey A Law writes:

Jeff> I'm not sure I totally agree.  I believe there's still a fair number of
Jeff> AIX systems out there which aren't up-to-date enough to build egcs without
Jeff> special options.  That's not good.

Jeff> It may make sense to enable -mminimal-toc during a bootstrap for those older
Jeff> AIX platforms.  Either based on the canonical target name or an autoconf test
Jeff> of some kind.

	The only versions of AIX which have problems are versions that IBM
no longer supports (AIX 3.2.5, AIX 4.1 < 4.1.5 with linker patch, etc.).
There are many additional reasons to upgrade to AIX 4.1.5+ or AIX 4.3.2;
it is very important that customers upgrade for security and millenium
reasons.  IBM's current policy is that if this is a known problem solved
by a patch then upgrade, so that has to be my response as well. 

Jeff> Wouldn't that cause an assembler error for multiple definitions?
Jeff> Or are they output as "local common" variables?

	Emiting multiple static variable definitions in the assembly does
not cause multiple definition errors, but I do not have a testcase
anymore.  I assume the problem is a file that declares a function or
variable static in multiple places (possibly automatically-generated code)
and, under certain circumstances, GCC emits that definition into the
assembly multiple times instead of finding it already defined in some
obstack in the appropriate scope. 

	Also, any floating-point constants appear in the TOC and occupy
two TOC entries (on 32-bit AIX) instead of utilizing a separate constant
pool.

Jeff> It would probably be to our advantage to have multiple const pools.  One for
Jeff> TOC entries, then another for all the compile-time constants.  Then we could
Jeff> use a single TOC entry to reference all the compile-time constants for a single
Jeff> file.

	As I mentioned from the AIX implementation, we should have a
constants pool and a statics pool per module (file).  Placing ALL
variables within a local pool per file is exactly what -mminimal-toc does.

	GCC for AIX creates a special pool and throws all memory
references into it.  Normally that pool is the TOC and it lets the AIX
linker combine each file's pool into a single, large pool for the entire
program.  When -mminimal-toc is enabled, it creates a private pool within
each file and only defines a reference for the local pool in the TOC.

	This is wasteful for global variables because although the storage
only is allocated once, each module must redefine addressibility for that
global storage and accesses to that global storage might require an
additional indirection.  This also causes the AIX linker and loader to
work much harder performing additional, repeated, global fixups outside
the normal TOC program section slowing linking and program startup.

>> And it dynamically allocates the base registers, only
>> allocating them when necessary.  I have not had time to pursue this.

	Just to clarify, the AIX compiler always uses the standard TOC
register but, unlike GCC -mminimal-toc, it does not explicitly, manually
allocate a secondary base register.  The AIX compiler acts more like the
PowerPC SVR4 PIC implementation currently handles the GOT regsiter, it
allocates the secondary base register(s) as needed and uses CSE to
collapse the creation/initialization as much as possible.

David

Re: Stabilization status

[Jeffrey A Law]

  In message < 9901022332.AA37512@marc.watson.ibm.com >you write:
  > 	The only versions of AIX which have problems are versions that IBM
  > no longer supports (AIX 3.2.5, AIX 4.1 < 4.1.5 with linker patch, etc.).
Understood.

  > There are many additional reasons to upgrade to AIX 4.1.5+ or AIX 4.3.2;
  > it is very important that customers upgrade for security and millenium
  > reasons.
Understood.  But that still doesn't mean everyone will upgrade.

  > IBM's current policy is that if this is a known problem solved
  > by a patch then upgrade, so that has to be my response as well. 
?!?  That's silly.  egcs != IBM, just like  egcs != Cygnus.

I can understand the desire to not spend a lot of time on old systems like
this because I feel the same way about hpux9 and earlier systems.  However,
fixing things so that the compiler "just works" on these older versions of
aix4.1 should be trivial and not take a lot of time.

We just recognize the old versions and use a different x-blah file for them.
Right?

Given the potential number of these boxes that are out there and the ease
of detecting them and handling them cleanly, I think we should bite the bullet
and handle them.



  > Jeff> Wouldn't that cause an assembler error for multiple definitions?
  > Jeff> Or are they output as "local common" variables?
  > 
  > 	Emiting multiple static variable definitions in the assembly does
  > not cause multiple definition errors, but I do not have a testcase
  > anymore.
That can be the case for an ansi tenative definition ie "static int x;".  But
once you give it an initializer you can only define the variable one time.

Furthermore, given a tenative definition, gcc should only be emitting a single
definition at the end of file.

Either way, you're supposed to only get a single definition of the variable. 
If we're getting more than one, we should look into why and fix it since it's
simply the wrong thing to do.


  > 	Also, any floating-point constants appear in the TOC and occupy
  > two TOC entries (on 32-bit AIX) instead of utilizing a separate constant
  > pool.
I suspect this is because the aix port uses the constant pool for the toc
entries, right?  I've stated more than once that we really need support for
multiple constant pools.  If we had that, then we could handle the toc with
one pool, and the floating point constants with another.

A second lossage (I suspect) is gcc does not combine constant pool entires for
floating point constants which appear in different functions within a file.
I've always thought this was highly bogus.

double
foo()
{
return 1.0;
}

double
bar ()
{
return 1.0;
}

You'll get two memory constants for 1.0 in the resulting assembly code.  Ugh.
This certainly can't help.


  > 	As I mentioned from the AIX implementation, we should have a
  > constants pool and a statics pool per module (file).  Placing ALL
  > variables within a local pool per file is exactly what -mminimal-toc does.
  >
  > 	GCC for AIX creates a special pool and throws all memory
  > references into it.  Normally that pool is the TOC and it lets the AIX
  > linker combine each file's pool into a single, large pool for the entire
  > program.  When -mminimal-toc is enabled, it creates a private pool within
  > each file and only defines a reference for the local pool in the TOC.
  > 
  > 	This is wasteful for global variables because although the storage
  > only is allocated once, each module must redefine addressibility for that
  > global storage and accesses to that global storage might require an
  > additional indirection.  This also causes the AIX linker and loader to
  > work much harder performing additional, repeated, global fixups outside
  > the normal TOC program section slowing linking and program startup.
Thanks this helps me understand how all this TOC stuff works...

At the least, local constants should probably go into a per-file pool with a
reference to that pool placed in the TOC.

Depending on how statics are output and how you build TOC entries, it may be
possible to do something similar for them -- without all the combine-statics
tree copying hair.

jeff

Re: Stabilization status

[David Edelsohn]

>>>>> Jeffrey A Law writes:

Jeff> At the least, local constants should probably go into a per-file pool with a
Jeff> reference to that pool placed in the TOC.

Jeff> Depending on how statics are output and how you build TOC entries, it may be
Jeff> possible to do something similar for them -- without all the combine-statics
Jeff> tree copying hair.

	Utilizing both suggestions is exactly how IBM's XLC compiler
efficiently interacts with the TOC.  This would remove most of the TOC
overflow issues.  If GCC provided multiple constant pools (local
constants, addresses local to module [statics], global addresses) and the
PowerPC port could direct different types of constants into different
pools, we would solve this problem.  I peeked at the current constant pool
support looking at how to add more, but have never really had time to
pursue is myself.

David