Re: egcs release

Re: egcs release

[Jim Wilson]

	Wed Jul 30 14:43:34 1997  H.J. Lu  (hjl@gnu.ai.mit.edu)

		* sched.c (sched_analyze_2): Handle access stack memory
		beyond the stack pointer via the frame pointer.
		(STACK_POINTER_REG_NREGS): New. Default as 1.

We already have a patch installed that fixes this, and which works for
both the old (sched.c) and new (haifa-sched.c) schedulers.  Patches that
only fix sched.c aren't very userful anymore.

	Sun Jul 13 13:39:15 1997  H.J. Lu  (hjl@gnu.ai.mit.edu)

		* sched.c (sched_analyze_2): Handle USE_PIC_OFFSET_TABLE_REG if
		defined.
		(PIC_OFFSET_TABLE_REG_NREGS): New. Default as 1.

		* config/i386/i386.h (USE_PIC_OFFSET_TABLE_REG): New. True if
		the PIC base register is used.

I suggest we use this patch.  This fixes the testcase that you wrote your
patch for, and works for both schedulers.

Wed Aug 27 14:52:54 1997  Jim Wilson  <wilson@cygnus.com>

	* i386.c (ix86_expand_epilogue): Emit blockage instruction when pic.

Index: i386.c
===================================================================
RCS file: /cvs/cvsfiles/egcs/gcc/config/i386/i386.c,v
retrieving revision 1.1.1.1
diff -p -r1.1.1.1 i386.c
*** i386.c	1997/08/11 15:57:16	1.1.1.1
--- i386.c	1997/08/27 21:52:31
*************** ix86_expand_epilogue ()
*** 2128,2133 ****
--- 2128,2143 ----
  
    xops[2] = stack_pointer_rtx;
  
+   /* When -fpic, we must emit a scheduling barrier, so that the instruction
+      that restores %ebx (which is PIC_OFFSET_TABLE_REGNUM), does not get
+      moved before any instruction which implicitly uses the got.  This
+      includes any instruction which uses a SYMBOL_REF or a LABEL_REF.
+ 
+      Alternatively, this could be fixed by making the dependence on the
+      PIC_OFFSET_TABLE_REGNUM explicit in the RTL.  */
+   if (flag_pic)
+     emit_insn (gen_blockage ());
+ 
    if (nregs > 1 || ! frame_pointer_needed)
      {
        if (frame_pointer_needed)

Re: egcs-2.90.02 970825, hppa1.1-hp-hpux9.01 bootstraps okay

[Jeffrey A Law]

  In message <199708272133.RAA18344@caip.rutgers.edu>you write:
  > 	I bootstrapped egcs-2.90.02 970825 on hppa1.1-hp-hpux9.01 using
  > BOOTCFLAGS='-O3 -funroll-all-loops' and cc for stage1 with native as/ld. 
  > I got a clean "make compare" and identical c-torture results with those
  > of gcc2-970721.  (Later gcc2 snapshots don't bootstrap for me.)
Good/bad.

Good that we generate idential c-torture results, bad because
later gcc2 snapshots don't bootstrap.

Odds are this is a reload issue that I tried to explain to
Kenner without much success.  I'm going to have to take another
stab at it within the next couple days.

[ egcs has code to avoid the reload problem... ]

jeff

Re: Here are the g++ test results

[Jeffrey A Law]

  In message <Pine.PMDF.3.91.970827170134.538982528A-100000@MPS.OHIO-STATE.EDU>
you write:
  > > I believe it is a bug in the testsuite, but I need to see the contents
  > > of the $objdir/libio to make sure.
  > > 
  > Here are the contents of $objdir/libio, sorry about the delay.
THanks.  Looks like the message got garbled somewhere.

Regardless, I think I know what the problem is.  Try this patch
to dejagnu:

Index: lib/libgloss.exp
===================================================================
RCS file: /cvs/cvsfiles/devo/dejagnu/lib/libgloss.exp,v
retrieving revision 1.48
retrieving revision 1.49
diff -c -r1.48 -r1.49
*** libgloss.exp	1997/08/06 04:42:09	1.48
--- libgloss.exp	1997/08/07 01:42:15	1.49
***************
*** 166,172 ****
  	set gccpath [file dirname [file dirname ${base_dir}]]
      }
  
!     set libio_bin_dir [lookfor_file ${gccpath} libio/libio.a];
      set libio_src_dir [lookfor_file ${srcdir} libio/Makefile.in]
      if { $libio_bin_dir != "" && $libio_src_dir != "" } {
  	set libio_src_dir [file dirname ${libio_src_dir}]
--- 166,172 ----
  	set gccpath [file dirname [file dirname ${base_dir}]]
      }
  
!     set libio_bin_dir [lookfor_file ${gccpath} libio/_G_config.h];
      set libio_src_dir [lookfor_file ${srcdir} libio/Makefile.in]
      if { $libio_bin_dir != "" && $libio_src_dir != "" } {
  	set libio_src_dir [file dirname ${libio_src_dir}]

Re: Performance; was: 68k problem.

[Jeffrey A Law]

  In message <9708272100.AA01051@moene.indiv.nluug.nl>you write:
  > i.e. not as bad as I thought [38000+ seconds], but certainly worse  
  > than the g77-0.5.21-970811 + gcc-2.7.2.2 result (~ 10 %).
Just a note; I've got -freduce-all-givs and -fmove-all-movables
in my source tree, and barring any natual disasters they should
get checked in and appear in the next snapshot (tonight/tomorrow).

I'm not including -frerun-loop yet; I want to think about it a
little -- my experiences with trying to rerun passes hasn't been
good.  At various times over the years I've done this with cse
and flow, and in both cases doing so has destabilized things
pretty badly.

Jeff

egcs-2.90.02 970825, hppa1.1-hp-hpux9.01 bootstraps okay

[Kaveh R. Ghazi]

	I bootstrapped egcs-2.90.02 970825 on hppa1.1-hp-hpux9.01 using
BOOTCFLAGS='-O3 -funroll-all-loops' and cc for stage1 with native as/ld. 
I got a clean "make compare" and identical c-torture results with those
of gcc2-970721.  (Later gcc2 snapshots don't bootstrap for me.)

		--Kaveh
--
Kaveh R. Ghazi				Project Manager
ghazi@caip.rutgers.edu			ICon CMT Corp.