Re: egcs-ss-970814 on m68k-next-nextstep3

Re: egcs-ss-970814 on m68k-next-nextstep3

[Jeffrey A Law]

  > The hang at enquire:
  > 
  > Apparently, it happens in routine F_check, because the last routine  
  > in enquire.s is:
Can you send me the cpp output for enquire on your box so I can
look at things under the debugger?

jeff

Re: fixing the c++/f77 circular dependency

[Jim Wilson]

	But LANGUAGES is still desirable for bootstrapping, because if you compile
	with an inferior system compiler you only want to build the C compiler
	with it, and them build the rest with the just built gcc.

We do need a way to build only the C compiler in the first stage of a
bootstrap.  However, we do not have any particular need for LANGUAGES itself.
If we can find some other way to build only the C compiler, then we can get
rid of LANGUAGES.  For instance, it might be possible to have a `make all'
target that builds all languages, and a `make only_c' target that builds
only the C language stuff.

Jim

Re: Questions about Haifa scheduler

[Jeffrey A Law]

  In message <19970822131918.44330@puma.macbsd.com>you write:
  > > Are you just looking for performance information?  Or are you looking
  > > for technical information?  Regardless, this is the place to ask.
  > 
  > More for technical information--it's probably too early to get any
  > meaningful performance comparison (except possibly on the PPC model(s)
  > that the development team was working with).
OK.  I (and others) posted some general information about it to the
list -- you can probably find them in the list archives on
http://www.cygnus.com/egcs .

  > Heh...  That's a little surprising since it's been around for a while
  > and I thought a lot of folks were using gcc for 68k-based embedded
  > systems...
Well, first the machine has to be able to have multiple instructions
running at the same time.  For older 68ks this was probably only
possible with FP insns.  Newer ports may be different.

Second, someone actually was to describe the machine to the scheduler;
and with the way the 68k port has been written describing it to the
scheduler would be a non-trivial project.

Jeff

patches for libg++

[Alexandre Oliva]

--Multipart_Fri_Aug_22_16:38:40_1997-1
Content-Type: text/plain; charset=US-ASCII

Here are some patches for libg++ that I currently have applied to my
libg++-2.8.0b6 tree.  They do not conflict with Lu's.

The first one may seem unnecessary, but when I applied it I used to
test gcc/g++/libg++ on an AIX host and it would only build a shared
libg++ after this patch.  I don't know whether it was a bug in
gcc/collect2, GNU ld or AIX's ld or whatever, and I no longer have
access to any AIX host.

The second set of patches is necessary for creating correct soft links
for shared libg++ and libstdc++ at install time.

The third set of patches embeds the full pathname into shared
libraries, so that the fact that they are shared is transparent for
users (they do not have to issue -R/usr/local/lib nor set
LD_LIBRARY_PATH in order to run programs linked against them)

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
Universidade Estadual de Campinas, SP, Brasil

--Multipart_Fri_Aug_22_16:38:40_1997-1
Content-Type: application/octet-stream; type=patch
Content-Disposition: attachment; filename="patch1.diff"
Content-Transfer-Encoding: 7bit

	* libg++/config/aix.ml: change shared library dependencies

diff -ru libg++-2.8.0/libg++/config/aix.ml libg++-2.8.0/libg++/config/aix.ml
--- libg++-2.8.0/libg++/config/aix.ml	Fri Feb 14 07:37:06 1997
+++ libg++-2.8.0/libg++/config/aix.ml	Mon Mar 24 15:36:06 1997
@@ -3,5 +3,5 @@
 ARLIB	   = libg++-ar.a
 SHLINK     = libg++.a
 BUILD_LIBS = $(ARLIB) $(SHLIB) $(SHLINK)
-SHDEPS     = ../libstdc++/libstdc++.a -lm
+SHDEPS     = -L../libstdc++ -lstdc++ -lm
 SHFLAGS  = -Wl,-unix

--Multipart_Fri_Aug_22_16:38:40_1997-1
Content-Type: application/octet-stream; type=patch
Content-Disposition: attachment; filename="patch2.diff"
Content-Transfer-Encoding: 7bit

	* libg++/Makefile.in: correctly handle multiple links to
	shared libraries
	* libstdc++/Makefile.in: ditto

diff -ru libg++-2.8.0/libg++/Makefile.in libg++-2.8.0/libg++/Makefile.in
--- libg++-2.8.0/libg++/Makefile.in	Fri Feb 14 07:44:06 1997
+++ libg++-2.8.0/libg++/Makefile.in	Fri Aug 22 15:55:56 1997
@@ -192,8 +192,13 @@
 	rootme=`pwd`/ ; export rootme ; \
 	for FILE in $(BUILD_LIBS) ; do \
 	  rm -f $(INSTALLDIR)$(MULTISUBDIR)/$$FILE ; \
-	  if [ $$FILE = $(SHLINK) ] || [ $$FILE = $(MSHLINK) ]; then \
+	  if [ $$FILE = $(SHLINK) ] ; then \
 	    ln -s -f $(SHLIB) $(INSTALLDIR)$(MULTISUBDIR)/$$FILE ; \
+	  elif [ $$FILE = mshlink ]; then \
+	    for FILE in $(MSHLINK) ; do \
+	      rm -f $(INSTALLDIR)$(MULTISUBDIR)/$$FILE ; \
+	      ln -s -f $(SHLIB) $(INSTALLDIR)$(MULTISUBDIR)/$$FILE ; \
+	    done; \
 	  elif [ $$FILE = $(SHLIB) ]; then \
 	    $(INSTALL_PROGRAM) $$FILE $(INSTALLDIR)$(MULTISUBDIR)/$$FILE ; \
 	    : On the HP, shared libraries must be mode 555. ;\
diff -ru libg++-2.8.0/libstdc++/Makefile.in libg++-2.8.0/libstdc++/Makefile.in
--- libg++-2.8.0/libstdc++/Makefile.in	Fri Feb 14 07:39:39 1997
+++ libg++-2.8.0/libstdc++/Makefile.in	Fri Aug 22 15:56:05 1997
@@ -263,8 +263,13 @@
 	rootme=`pwd`/ ; export rootme ; \
 	for FILE in $(LIBS) ; do \
 	  rm -f $(INSTALLDIR)$(MULTISUBDIR)/$$FILE ; \
-	  if [ $$FILE = $(SHLINK) ] || [ $$FILE = $(MSHLINK) ]; then \
+	  if [ $$FILE = $(SHLINK) ] ; then \
 	    ln -s -f $(SHLIB) $(INSTALLDIR)$(MULTISUBDIR)/$$FILE ; \
+	  elif [ $$FILE = mshlink ]; then \
+	    for FILE in $(MSHLINK) ; do \
+	      rm -f $(INSTALLDIR)$(MULTISUBDIR)/$$FILE ; \
+	      ln -s -f $(SHLIB) $(INSTALLDIR)$(MULTISUBDIR)/$$FILE ; \
+	    done; \
 	  elif [ $$FILE = $(SHLIB) ]; then \
 	    $(INSTALL_PROGRAM) $$FILE $(INSTALLDIR)$(MULTISUBDIR)/$$FILE ; \
 	    : On the HP, shared libraries must be mode 555. ;\

--Multipart_Fri_Aug_22_16:38:40_1997-1
Content-Type: application/octet-stream; type=patch
Content-Disposition: attachment; filename="patch3.diff"
Content-Transfer-Encoding: 7bit

	* libg++/Makefile.in: put full installation pathname in shared
	library, so that their existence is transparent to users.
	* libg++/config/elf.ml: ditto
	* libg++/config/elfshlibm.ml: ditto
	* libg++/config/linux.ml: ditto
	* libg++/config/sol2shm.ml: ditto
	* libstdc++/Makefile.in: ditto
	* libstdc++/config/elf.ml: ditto
	* libstdc++/config/elfshlibm.ml: ditto
	* libstdc++/config/linux.ml: ditto
	* libstdc++/config/sol2shm.ml: ditto

diff -ru libg++-2.8.0/libg++/Makefile.in libg++-2.8.0/libg++/Makefile.in
--- libg++-2.8.0/libg++/Makefile.in	Fri Feb 14 07:44:06 1997
+++ libg++-2.8.0/libg++/Makefile.in	Fri Aug 22 15:55:56 1997
@@ -71,7 +71,7 @@
 SHARLIB = libg++-sh.a
 SHLINK  = libg++.so
 MSHLINK = libg++.so.`echo $(VERSION) | sed 's/\([0-9][.][0-9]\).*/\1/'`
-SHFLAGS =
+SHFLAGS = -Wl,-soname,$(libdir)/$(SHLIB)
 SHDEPS  = -L../libstdc++ -lstdc++ -lm
 
 BUILD_LIBS = $(ARLIB)
diff -ru libg++-2.8.0/libg++/config/elf.ml libg++-2.8.0/libg++/config/elf.ml
--- libg++-2.8.0/libg++/config/elf.ml	Fri Feb 14 07:37:06 1997
+++ libg++-2.8.0/libg++/config/elf.ml	Mon Mar 24 15:36:06 1997
@@ -1,3 +1,3 @@
 BUILD_LIBS = $(ARLIB) $(SHLIB) $(SHLINK)
-SHFLAGS    = -h $(SHLIB)
+SHFLAGS    = -h $(libdir)/$(SHLIB)
 LIBS       = -L./$(TOLIBGXX) -L./$(TOLIBGXX)../libstdc++ -lg++ -lstdc++ -lm
diff -ru libg++-2.8.0/libg++/config/elfshlibm.ml libg++-2.8.0/libg++/config/elfshlibm.ml
--- libg++-2.8.0/libg++/config/elfshlibm.ml	Fri Feb 14 07:37:06 1997
+++ libg++-2.8.0/libg++/config/elfshlibm.ml	Mon Mar 24 15:36:06 1997
@@ -1,3 +1,3 @@
 BUILD_LIBS = $(ARLIB) $(SHLIB) $(SHLINK)
-SHFLAGS    = -h $(SHLIB)
+SHFLAGS    = -h $(libdir)/$(SHLIB)
 SHDEPS     = -lm
diff -ru libg++-2.8.0/libg++/config/linux.ml libg++-2.8.0/libg++/config/linux.ml
--- libg++-2.8.0/libg++/config/linux.ml	Fri Feb 14 07:37:07 1997
+++ libg++-2.8.0/libg++/config/linux.ml	Mon Mar 24 15:36:07 1997
@@ -1,2 +1,2 @@
 BUILD_LIBS = $(ARLIB) $(SHLIB) $(SHLINK) mshlink
-SHFLAGS    = -Wl,-soname,$(MSHLINK)
+SHFLAGS    = -Wl,-soname,$(libdir)/$(MSHLINK)
diff -ru libg++-2.8.0/libg++/config/sol2shm.ml libg++-2.8.0/libg++/config/sol2shm.ml
--- libg++-2.8.0/libg++/config/sol2shm.ml	Fri Feb 14 07:37:07 1997
+++ libg++-2.8.0/libg++/config/sol2shm.ml	Mon Mar 24 15:36:07 1997
@@ -1,3 +1,3 @@
 BUILD_LIBS = $(ARLIB) $(SHLIB) $(SHLINK)
-SHFLAGS    = -h $(SHLIB)
+SHFLAGS    = -h $(libdir)/$(SHLIB)
 SHDEPS     = -lm
diff -ru libg++-2.8.0/libstdc++/Makefile.in libg++-2.8.0/libstdc++/Makefile.in
--- libg++-2.8.0/libstdc++/Makefile.in	Fri Feb 14 07:39:39 1997
+++ libg++-2.8.0/libstdc++/Makefile.in	Fri Aug 22 15:56:05 1997
@@ -31,7 +31,7 @@
 SHARLIB = libstdc++-sh.a
 SHLINK  = libstdc++.so
 MSHLINK = libstdc++.so.`echo $(VERSION) | sed 's/\([0-9][.][0-9]\).*/\1/'`
-SHFLAGS = 
+SHFLAGS = -Wl,-soname,$(libdir)/$(SHLIB)
 SHDEPS  =
 
 STAMP   = bigstmp
diff -ru libg++-2.8.0/libstdc++/config/elf.ml libg++-2.8.0/libstdc++/config/elf.ml
--- libg++-2.8.0/libstdc++/config/elf.ml	Fri Feb 14 07:39:43 1997
+++ libg++-2.8.0/libstdc++/config/elf.ml	Mon Mar 24 15:36:08 1997
@@ -2,7 +2,7 @@
 # for programs that don't use complex.
 
 LIBS    = $(ARLIB) $(SHLIB) $(SHLINK)
-SHFLAGS = -h $(SHLIB)
+SHFLAGS = -h $(libdir)/$(SHLIB)
 DEPLIBS = ../$(SHLIB)
 LDLIBS  = -L.. -lstdc++ -lm
 MLDLIBS = -L.. -lstdc++ -lm
diff -ru libg++-2.8.0/libstdc++/config/elfshlibm.ml libg++-2.8.0/libstdc++/config/elfshlibm.ml
--- libg++-2.8.0/libstdc++/config/elfshlibm.ml	Fri Feb 14 07:39:43 1997
+++ libg++-2.8.0/libstdc++/config/elfshlibm.ml	Mon Mar 24 15:36:09 1997
@@ -1,6 +1,6 @@
 # Elf with shared libm, so we can link it into the shared libstdc++.
 
 LIBS    = $(ARLIB) $(SHLIB) $(SHLINK)
-SHFLAGS = -h $(SHLIB)
+SHFLAGS = -h $(libdir)/$(SHLIB)
 SHDEPS  = -lm
 DEPLIBS = ../$(SHLIB)
diff -ru libg++-2.8.0/libstdc++/config/linux.ml libg++-2.8.0/libstdc++/config/linux.ml
--- libg++-2.8.0/libstdc++/config/linux.ml	Fri Feb 14 07:39:43 1997
+++ libg++-2.8.0/libstdc++/config/linux.ml	Mon Mar 24 15:36:10 1997
@@ -1,6 +1,6 @@
 # Elf with shared libm, so we can link it into the shared libstdc++.
 
 LIBS    = $(ARLIB) $(SHLIB) $(SHLINK) mshlink
-SHFLAGS = -Wl,-soname,$(MSHLINK)
+SHFLAGS = -Wl,-soname,$(libdir)/$(MSHLINK)
 SHDEPS  = -lm
 DEPLIBS = ../$(SHLIB)
diff -ru libg++-2.8.0/libstdc++/config/sol2shm.ml libg++-2.8.0/libstdc++/config/sol2shm.ml
--- libg++-2.8.0/libstdc++/config/sol2shm.ml	Fri Feb 14 07:39:43 1997
+++ libg++-2.8.0/libstdc++/config/sol2shm.ml	Mon Mar 24 15:36:10 1997
@@ -1,6 +1,6 @@
 # Solaris2 with shared libm, so we can link it into the shared libstdc++.
 
 LIBS    = $(ARLIB) $(SHLIB) $(SHLINK)
-SHFLAGS = -h $(SHLIB)
+SHFLAGS = -h $(libdir)/$(SHLIB)
 SHDEPS  = -lm
 DEPLIBS = ../$(SHLIB)

--Multipart_Fri_Aug_22_16:38:40_1997-1--

Re: libstdc++ and gcc2 merge

[Jason Merrill]

>>>>> H J Lu <hjl@lucon.org> writes:

>> Just a note that snapshots after tonight's will include libstdc++, so you
>> won't have to worry about finding the right version (and I won't have to
>> worry about making my own libg++ releases).

> I didn't see libstdc++ in egcs-ss-970814-970821.diff.gz. Did I miss
> something?

*after* tonight's.

Jason

Re: Questions about Haifa scheduler

[meissner]

| Heh...  That's a little surprising since it's been around for a while
| and I thought a lot of folks were using gcc for 68k-based embedded
| systems...

Ah, but scheduling does not do anything for you unless you have function units
that can do things in parallel (either through pipeling and/or multiple
functional units).  Have the newer 68ks started doing things like this?  For
example, until the Pentium came out, the x86 line could only do integer and fp
ops in parallel at a gross level, and so no scheduling information was put in
the md field.

Re: Questions about Haifa scheduler

[Allen Briggs]

> Are you just looking for performance information?  Or are you looking
> for technical information?  Regardless, this is the place to ask.

More for technical information--it's probably too early to get any
meaningful performance comparison (except possibly on the PPC model(s)
that the development team was working with).

> The m68k has no scheduling parameters defined, so the instruction
> scheduler will not do anything for 68k targets.

Heh...  That's a little surprising since it's been around for a while
and I thought a lot of folks were using gcc for 68k-based embedded
systems...

Maybe I'll look at this if I get bored (unlikely).  It's chalked on the
list, anyway.  I've been wanting to learn more about the gcc backend for
a while...

> The best benchmarking tool is always code you care about instead of
> synthetic benchmarks.

:-)  Of course...

Thanks for the responses, folks.

-allen

-- 
              Allen Briggs - end killing - briggs@macbsd.com

Re: Questions about Haifa scheduler

[Jeffrey A Law]

  In message <19970822112848.56919@puma.macbsd.com>you write:
  > Hello...  I'm looking for more information on the Haifa scheduler.  I
  > noticed a large comment at the top of haifa-sched.c.  Is there anything
  > more?
Not really....

Are you just looking for performance information?  Or are you looking
for technical information?  Regardless, this is the place to ask.

  > How well does it work on the m68k
The m68k has no scheduling parameters defined, so the instruction
scheduler will not do anything for 68k targets.

Furthermore, the 68k machine description often has one INSN generating
multiple instructions.  This tends to make instruction scheduling
less accurate.  Instruction scheduling works best when each INSN
corresponds to a single machine instruction -- the closer you get
to that goal, the more accurate the schedules will be.


  > or PowerPC (my main processors of interest at the moment ;-)?
Unknown at this point -- that's one of the things we're going to
need as we continue to convert to the haifa scheduler.

  > Do the processor descriptions need to be tuned for it?
Maybe, it depends on how the existing processor description was
written.

Some were written to get the best possible performance out of the
old scheduler.  Sometimes this involved "little white lies" about
issue delays and latency; these "little white lies" can seriously
impact the performance of code when using the haifa scheduler.

Targets will need a correct definition of ISSUE_RATE for haifa to
work well too.

  > Is there any good benchmarking tool that can be used to try and
  > optimize it?
The best benchmarking tool is always code you care about instead of
synthetic benchmarks.

So, benchmark it on code you care about :-)

Or get many of the widely available benchmarks and choose some
that are similar to the workloads you care about.

Jeff

Re: Questions about Haifa scheduler

[meissner]

|   > or PowerPC (my main processors of interest at the moment ;-)?
| Unknown at this point -- that's one of the things we're going to
| need as we continue to convert to the haifa scheduler.

In theory, the PowerPC should be pretty accurate in terms of the scheduler,
since that was the machine IBM Haifa originally worked with (to no great
surprise :-).  One optimization is to use CTR for simple count down (and maybe
count up) loops.

Re: Questions about Haifa scheduler

[David Edelsohn]

>>>>> Allen Briggs writes:

Allen> Hello...  I'm looking for more information on the Haifa scheduler.  I
Allen> noticed a large comment at the top of haifa-sched.c.  Is there anything
Allen> more?  How well does it work on the m68k or PowerPC (my main processors
Allen> of interest at the moment ;-)?  Do the processor descriptions need to be
Allen> tuned for it?  Is there any good benchmarking tool that can be used to
Allen> try and optimize it?  Note, I'm just looking for basic info and pointers
Allen> right now...

	The Haifa scheduler seems to work best if the processor scheduling
description is accurate.  The original GCC scheduler did not truly
understand multi-issue, deeply-pipelined superscalar processors and
sometimes did better if the machine descriptions were transformed in
certain ways.  The POWER and PowerPC machine descriptions always have been
accurate.  Everyone is welcome to explore ways to obtain better
performance from the Haifa scheduler, but lying in the machine description
usually bites one in the end as the scheduler itself is fixed and improved.

	For the time being, the comments at the top of haifa-sched.c are
the extent of the public documentation.

David

Questions about Haifa scheduler

[Allen Briggs]

Hello...  I'm looking for more information on the Haifa scheduler.  I
noticed a large comment at the top of haifa-sched.c.  Is there anything
more?  How well does it work on the m68k or PowerPC (my main processors
of interest at the moment ;-)?  Do the processor descriptions need to be
tuned for it?  Is there any good benchmarking tool that can be used to
try and optimize it?  Note, I'm just looking for basic info and pointers
right now...

Thanks,
-allen

-- 
              Allen Briggs - end killing - briggs@macbsd.com