Re: Problems on PowerPC...

Re: Problems on PowerPC...

[David Edelsohn]

>>>>> David McWherter writes:

David> I dunno if they're C++ constructors, but a function pointer from
David> __CTOR_LIST__ is being picked off and run by __do_global_ctors_aux() when
David> I compile with egcs.  When I compile genattr with my standard gcc, it
David> doesn't do so.  The egcs-compiled genattr dies because the pointer it
David> picks out from __CTOR_LIST__ is a pointer to a block of illegal
David> instructions, and a SIGILL is generated.
 
David> I dunno.  My standard-gcc-built code seems to have empty __CTOR_LIST__'s,
David> but the egcs stuff has something there.

	All of the various Linux for PowerPC use SVR4 which has init and
fini object file sections.  Something is ending up in the __CTOR_LIST__
when using egcs that should not be present (genattr and obstack.o are pure
C, not C++: no constructors exist).  I would assume that something in the
rs6000/sysv4.h configuration distributed in the pax files on linuxppc.org
has not made it back to the FSF sources on which egcs is based.

David

Re: Reload patch to improve 386 code

[Bernd Schmidt]

> You are right, I mixed up something here.  What I actually saw was when
> an inherit was missed, the new reload - or its secondary reloads -
> would clobber other reload registers, which could otherwise have been used
> for subsequent inherits.
> reload_cse coudn't clean up the mess - it just changed the reload for the
> missed inherit from a memory-register to a register-register move.
> It isn't clever enough to reassign reload registers and then reclaim the
> freed register for further cse.

There are a zillion variations of this kind of problem. The following
code, or something that looks similar, is generated rather frequently:

movl 16(%esp),%eax
movl (%eax),%eax
movl 16(%esp),%edx

Another problem was mentioned today: the compiler really should move
constants that are used multiple times into registers if possible.  These
problems are similar, maybe they can be addressed together.  Again, I
think reload_cse_regs might be the right place to add cleverness about this.
I'll send some initial patches tomorrow or so.

Bernd

g77 building [was Re: bootstrapping problems with native compiler]

[Dave Love]

>>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes:

 Jim> 	The released G77 is known basically to survive criss-cross builds.
 Jim> 	(The sprintf test makes a pessimistic assumption if necessary.)

 Jim> But it does so by making guesses if CC is a cross compiler that
 Jim> can't link.  This would not be necessary if the f77-runtime was
 Jim> a separate directory from the compiler directory.

I'm sure I understand this properly and haven't had time to revisit
it.  I won't be able to until at least the back end of next week.  I
probably need to scrutinize cross-gcc etc. again, which I haven't
looked at for some time.  The G77 configuration does assume that it
has a working C compiler/library built for the host and target before
it starts and I'm not sure how else it can work.  (I'd have thought it
would be the same for ObjC too.)  However, g77 may well not be doing
the Right Thing because it's been out on a limb with no useful model.
I trust we can sort out any problems that there are later on.

I'm afraid I don't understand the current build system and I don't
know whether it's broken the g77 configuration/build (which has
changed somewhat recently anyhow).  I guess if it's problematic at
present, people have to take f77 out of LANGUAGES.

If the configuration is going to be changed, it would probably be a
good idea to discuss plans with fortran@gnu.ai.mit.edu, especially as
there are other things that we may want to do in the future, such as
using Fortran source directly in the runtime.

Re: fixing the c++/f77 circular dependency

[Dave Love]

>>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes:

 Jim> The fourth option is easy to implement.  The only downside I can see is
 Jim> that the f77-runtime is now configured always, 

It shoudn't be, and I didn't think it was in the vanilla version.
Will try to look at it before absconding for the holiday weekend.

Re: Some Haifa scheduler bugs

[Jeffrey A Law]

  In message <Pine.SOL.3.90.970821173718.733B-100000@maigret.informatik.rwth-aa
chen.de>you write:
  > I've thought about something like this, but this code won't work, I think.
  > It will call reemit_notes twice for the last insn in the SCHED_GROUP and
  > not at all for the first one. I've tried thinking of ways to use just one
  > loop, but they all had problems with putting all notes in the right places.
Good point.  However, the more I look at that SCHED_GROUP_P loop,
the more I think it must be broken.

Consider if we have Z <-A <-B <-C, all with SCHED_GROUP_P set on A B & C,
but not Z.



  insn = C
  We start the while loop (SCHED_GROUP_P (A) == 1)
    prev = B
    move_insn1 (C, last)
    insn = B
   2nd iteration (SCHED_GROUP_P (B) == 1)
    prev = A
    move_insn1 (B, last)
    insn = A
   3rd iteration (SCHED_GROUP_P (A) == 1)
    prev = Z
    move_insn_1 (A, last)
    insn = Z
   loop terminates (SCHED_GROUP_P (Z) == 0)

  move_insn1 (Z, last)
  
  
So we end up moving one insn more than we should right?

Seems to me move_insn should look like this:

static rtx
move_insn (insn, last)
     rtx insn, last;
{

  while (SCHED_GROUP_P (PREV_INSN (insn)))
    {
      rtx prev = PREV_INSN (insn);
      move_insn1 (insn, last);
      reemit_notes (insn, insn);
      insn = prev;
    }

  move_insn1 (insn, last);
  return reemit_notes (insn, insn);
}


Can you try it?  Or give me the testcase that's currently failing
for you so that I can try it myself?

Jeff

Re: fixing the c++/f77 circular dependency

[Dave Love]

>>>>> "Doug" == Doug Evans <dje@cygnus.com> writes:

 Doug> You could add a --enable-lang=foo [or some such] option,
 Doug> so while LANGUAGES=x is gone, the ability to only build a few
 Doug> is not.

I'd vote for that sort of thing.

Re: mdbench for g77 & f2c+gcc

[Dave Love]

If mdbnch discussions are continuing, I might point out some things
about it and some possibly-mis-remembered facts I don't have time to
check on.  Toon might correct me.

The first thing is that in my experience a couple of years ago it
depends critically on the cache and should probably be run single-user
for compiler benchmarking, as opposed to real-life performance.  (I
think this is an intentional feature of mdbnch, but not necessarily
representative.)  On MIPS R4000s it made a significant difference when
gcc 2.7 introduced an r4000 configuration and g77 basically caught up
with MIPS f77 on mdbnch IIRC; they've probably both got better since.

It looks as though data in (static) COMMON are a bottleneck (if
-malign-double makes a consistent significant improvement) and that
may hurt optimization -- Craig or Toon can probably say better.
Automatic data in it will be subject to the non-double-alignment
problem on [56]86.

On x86 -fforce-addr often has a significant effect on fortran in
either direction, doubtless differently in different parts of the
code.

f2c-compiled code is normally significantly better with gcc if you use
`-a' (basically equivalent to g77's default -fautomatic), as is always
appropriate for standard-conforming code.  Failure to use -a has given
f2c and C-as-UNCOL a worse press than warranted.

Beware that old Fortran benchmarks often have coding problems which
g77 will show up, either through straight standard-non-conformance or
portability problems such as not declaring EXTERNALs; mdbnch did the
latter IIRC, though it just elicits a warning from g77.

[One important x86-performance-related thing that backend experts
might like to look at sometime is why the backend allegedly doesn't
(or didn't early this year) generate optimal 586 code for the level-1
BLAS (O(n) floating point linear algebra), which people have been
feeling the need to code in assembler.  I can provide references for
that at some stage if anyone is interested.]

Gratifying interest in Fortran :-).

Incorrect i960 linker config

[Stephen Williams]

The LINK_SPEC doesn't deal with the -mjx and -mrp switches. Also,
ld handles not being given an architecture switch well enough by
looking at what its got. This very simply patch fixes the link spec
by adding the new Jx target types.

NOTE: I think I was the one who submitted the -mjx spec entries for the
assembler, so this is my error I'm correcting:-) (Joel, I'm suprised that
you missed this. I would have thought it would effect RTEMS/i960 links:-)

*** dist/egcs-970828/gcc/config/i960/i960.h     Mon Aug 11 08:57:28 1997
--- egcs-970828/gcc/config/i960/i960.h  Fri Aug 29 23:45:01 1997
***************
*** 81,87 ****
  #define LINK_SPEC \
        "%{mka:-AKA}%{mkb:-AKB}%{msa:-ASA}%{msb:-ASB}\
        %{mmc:-AMC}%{mca:-ACA}%{mcc:-ACC}%{mcf:-ACF}\
!       %{!mka:%{!mkb:%{!msa:%{!msb:%{!mmc:%{!mca:%{!mcc:%{!mcf:-AKB}}}}}}}}\
        %{mbout:-Fbout}%{mcoff:-Fcoff}\
        %{mlink-relax:-relax}"
  
--- 81,87 ----
  #define LINK_SPEC \
        "%{mka:-AKA}%{mkb:-AKB}%{msa:-ASA}%{msb:-ASB}\
        %{mmc:-AMC}%{mca:-ACA}%{mcc:-ACC}%{mcf:-ACF}\
!         %{mja:-AJX}%{mjd:-AJX}%{mjf:-AJX}%{mrp:-AJX}\
        %{mbout:-Fbout}%{mcoff:-Fcoff}\
        %{mlink-relax:-relax}"
  

-- 
Steve Williams
steve@icarus.com
steve@picturel.com

"The woods are lovely, dark and deep.  But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."

Re: fixing the c++/f77 circular dependency

[Joel Sherrill]

On Sat, 30 Aug 1997, Stephen Williams wrote:

> My work largely involves freestanding C++. Please, libgcc needing things
> from the C library (and posix) is bad enough. Start bringing in libraries
> from all over the universe and ``main() { return 0; }'' will no longer
> fit on certain boards!-)

I have not tried lately to see what the smallest useful exeutable is but I
know it is sometimes surprising what gets pulled in.

> Also, this again gets back to the build cycle problems Joel keeps griping
> about (and I also experience) and extending it ot yet another library.

 I don't know if gripe is the right word.  I just did not want the
problem to get worse in the reorganization.  

The reorganization seems to be a big step in the right direction for
embedded targets. 

--joel

Re: fixing the c++/f77 circular dependency

[Stephen Williams]

jason@cygnus.com said:
> That may be.  The code currently in libgcc is the freestanding 
> library, which includes some code called by various language 
> constructs, and therefore needs to be linked in automatically.  I 
> don't want people to have to pull in libstdc++ to get RTTI support.

My work largely involves freestanding C++. Please, libgcc needing things
from the C library (and posix) is bad enough. Start bringing in libraries
from all over the universe and ``main() { return 0; }'' will no longer
fit on certain boards!-)

Also, this again gets back to the build cycle problems Joel keeps griping
about (and I also experience) and extending it ot yet another library.

-- 
Steve Williams
steve@icarus.com
steve@picturel.com

"The woods are lovely, dark and deep.  But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."

Re: fixing the c++/f77 circular dependency

[Jim Wilson]

	So you do a 'make bootstrap'.  What's the problem?

See my initial message in this thread.  The problem incidentally has been
fixed.

	The Makefile has been fixed so LANGUAGES is passed to sub-makes, right?

Yes, but that is an unrelated problem.

Jim

Re: fixing the c++/f77 circular dependency

[Jim Wilson]

Incidentally, this particular problem is not one that needs to be fixed before
the initial release.  There is no point in trying to change the libgcc.a
build rules before the initial release, because there is too much risk that
this will break something.  There are many more important things that
we should be spending our time on at this time.

The circular dependency that was preventing egcs from building was important,
but that was fixed last week.

This scheme does seem more elegant than what we have now, and just taking
a quick look, I don't see anything obviously wrong with it.

The subdir_libgcc rule needs to use LANGUAGES, so that we build a subdirectory
libgcc only if that language is being built.

In order to actually work, this probably needs to be a lot more complicated
than what you have so far, because you haven't considered multilib yet.

Jim

Re: fixing the c++/f77 circular dependency

[Robert Lipe]

> > There exist hosts where the native compiler will build a subtly 
> > disfunctional cc1plus that therefore won't reliably compile the
> 
> So you do a 'make bootstrap'.  What's the problem?

In current snapshots, nothing.   Sorry if I was unclear.   

> The Makefile has been fixed so LANGUAGES is passed to sub-makes, right?

Yes.   But this characteristic has come and gone in that "other" branch 
with depressing frequency.   This is to reiterate the point that Jim made
that it's rather non-obvious and ill-understood.

RJL

Re: fixing the c++/f77 circular dependency

[Joe Buck]

I wrote:

> | During the build process, don't build a library named libgcc.a.  Instead,
> | build libgcc-c.a, libgcc-c++.a, libgcc-f.a (Fortran), etc.  At
> | installation time or just before, combine all of these libraries into one,
> | named libgcc.a.  The LANGUAGES variable determines which language-specific
> | libraries are combined to make libgcc.a.  Normally, gcc passes -lgcc to
> | the linker, but a flag can disable this, so that the compiler can be
> | bootstrapped with -lgcc-c instead.  We do want to wind up with a combined
> | libgcc.a so that multi-language programs work.

meissner@cygnus.com writes:

> No, installation time is too late.  I routinely test compilers in place
> without installing them (using ./xgcc -B./).

OK, it doesn't have to be installation time; each build can use LANGUAGES
to make libgcc.a, but the bootstrap process would not use this libgcc.a
to build the compiler with itself, it would only use libgcc-c.a.

I don't know enough about MULTILIB issues to comment there.  Maybe all
that is really needed is a temporary C-only library that is used in the
bootstrapping process and my solution is overkill.  But recent 2.8.0
snapshots have resulted in bogus libgcc.a files (that mysteriously fix
themselves if libgcc.a and constituent .o files are zapped and rebuilt)
so we need something simple and reliable.

Re: fixing the c++/f77 circular dependency

[meissner]

| The following notion just occurred to me.  I'm not sure it's the cleanest
| thing in the world, but it does break the circle. The basic idea:
| 
| During the build process, don't build a library named libgcc.a.  Instead,
| build libgcc-c.a, libgcc-c++.a, libgcc-f.a (Fortran), etc.  At
| installation time or just before, combine all of these libraries into one,
| named libgcc.a.  The LANGUAGES variable determines which language-specific
| libraries are combined to make libgcc.a.  Normally, gcc passes -lgcc to
| the linker, but a flag can disable this, so that the compiler can be
| bootstrapped with -lgcc-c instead.  We do want to wind up with a combined
| libgcc.a so that multi-language programs work.

No, installation time is too late.  I routinely test compilers in place without
installing them (using ./xgcc -B./).

Re: fixing the c++/f77 circular dependency

[David Edelsohn]

>>>>> Joe Buck writes:

Joe> During the build process, don't build a library named libgcc.a.  Instead,
Joe> build libgcc-c.a, libgcc-c++.a, libgcc-f.a (Fortran), etc.  At
Joe> installation time or just before, combine all of these libraries into one,
Joe> named libgcc.a.  The LANGUAGES variable determines which language-specific
Joe> libraries are combined to make libgcc.a.  Normally, gcc passes -lgcc to
Joe> the linker, but a flag can disable this, so that the compiler can be
Joe> bootstrapped with -lgcc-c instead.  We do want to wind up with a combined
Joe> libgcc.a so that multi-language programs work.

	Don't forget all of the MULTILIB variants.  This could get quite
involved and complicated to build libgcc-c, libgcc-c++, and libgcc-f for
various command-line flag cominations and then demux them during the
install.

David

Re: fixing the c++/f77 circular dependency

[Robert Lipe]

Jim Wilson wrote:

> There is a serious dependency problem which has already been mentioned a few
> times.  If libgcc.a contains C++ code, then libgcc.a depends on cc1plus,
> which means we always build cc1plus even if it is not in languages.  Simply

Though I think this is well understood by the few people really in the
know, it's worth reiterating Jim's point for the rest.

There exist hosts where the native compiler will build a subtly 
disfunctional cc1plus that therefore won't reliably compile the
C++ code to go into libgcc.a.     Quoting INSTALL:

     C is the only language that is sure to work when you build with
     other non-GNU C compilers.  In addition, building anything but C
     at this stage is a waste of time.

So if you have libgcc that depends on cc1plus and you're compiling
with a "non-GNU C compiler" you're in a catch-22.

Yes, I realize one Right Thing To Do is to track down the problem 
in using the native compiler to build cc1plus.

> The existing rule for the C++ libgcc.a stuff uses contortions to try to
> avoid an explicit cc1plus dependency, but it is ugly, does not work reliably,
> and has been causing problems.

I feel that pain.  I'll confess that "internal compiler error" when
building tinfo.cc did not exactly lead me to the Makefile as a 
prime suspect.

RJL

Re: fixing the c++/f77 circular dependency

[Jason Merrill]

>>>>> Robert Lipe <robertl@dgii.com> writes:

> There exist hosts where the native compiler will build a subtly 
> disfunctional cc1plus that therefore won't reliably compile the
> C++ code to go into libgcc.a.

So you do a 'make bootstrap'.  What's the problem?

The Makefile has been fixed so LANGUAGES is passed to sub-makes, right?

Jason

Re: fixing the c++/f77 circular dependency

[Joe Buck]

> There is a serious dependency problem which has already been mentioned a few
> times.  If libgcc.a contains C++ code, then libgcc.a depends on cc1plus,
> which means we always build cc1plus even if it is not in languages.

The following notion just occurred to me.  I'm not sure it's the cleanest
thing in the world, but it does break the circle. The basic idea:

During the build process, don't build a library named libgcc.a.  Instead,
build libgcc-c.a, libgcc-c++.a, libgcc-f.a (Fortran), etc.  At
installation time or just before, combine all of these libraries into one,
named libgcc.a.  The LANGUAGES variable determines which language-specific
libraries are combined to make libgcc.a.  Normally, gcc passes -lgcc to
the linker, but a flag can disable this, so that the compiler can be
bootstrapped with -lgcc-c instead.  We do want to wind up with a combined
libgcc.a so that multi-language programs work.

Re: fixing the c++/f77 circular dependency

[H.J. Lu]

> 
> 	Could someone please tell me why we cannot put a target libgcc.a in
> 	cp/Makefile.in? It will resolve that problem. I am willing to
> 	write a patch if people think it is a good idea.
> 
> There is a serious dependency problem which has already been mentioned a few
> times.  If libgcc.a contains C++ code, then libgcc.a depends on cc1plus,
> which means we always build cc1plus even if it is not in languages.  Simply
> moving the rule to cp/Makefile.in does not solve this problem, because
> we still have libgcc.a dependencing on cc1plus.
> 

What I have in mind is

1. In top level Makefile:

libgcc.a: .... cc1 subdir_libgcc
	autolock.sh libgcc.a.lck $(AR) ..

subdir_libgcc: cc1
	for d in  ...
	do
		$(MAKE) libgcc.a
	done

2. In cp/Makefile, we have

libgcc.a: ../cc1 ../cc1plus
	.....
	autolock.sh ../libgcc.a.lck $(AR) ..


H.J.

Re: fixing the c++/f77 circular dependency

[Jim Wilson]

	Could someone please tell me why we cannot put a target libgcc.a in
	cp/Makefile.in? It will resolve that problem. I am willing to
	write a patch if people think it is a good idea.

There is a serious dependency problem which has already been mentioned a few
times.  If libgcc.a contains C++ code, then libgcc.a depends on cc1plus,
which means we always build cc1plus even if it is not in languages.  Simply
moving the rule to cp/Makefile.in does not solve this problem, because
we still have libgcc.a dependencing on cc1plus.

The existing rule for the C++ libgcc.a stuff uses contortions to try to
avoid an explicit cc1plus dependency, but it is ugly, does not work reliably,
and has been causing problems.

Jim

Re: fixing the c++/f77 circular dependency

[H.J. Lu]

> 
> >>>>> Jim Wilson <wilson@cygnus.com> writes:
> 
> > 	I'd like to see them in libgcc.a. It should not be hard to put
> > 	something in libgcc.a from cp/Makefile.
> 
> > I am not opposed to having C++ code in libgcc.a if it can be made to
> > work.  However, having already dealt with a number of problems resulting
> > from this, I am skeptical that it can be made to work cleanly.
> 
> That may be.  The code currently in libgcc is the freestanding library,
> which includes some code called by various language constructs, and
> therefore needs to be linked in automatically.  I don't want people to have
> to pull in libstdc++ to get RTTI support.
> 
> The only other option would seem to be a third library, linked in along
> with libgcc.  Then the trick is insinuating it into the specs file.
> 

Could someone please tell me why we cannot put a target libgcc.a in
cp/Makefile.in? It will resolve that problem. I am willing to
write a patch if people think it is a good idea.


-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

Re: fixing the c++/f77 circular dependency

[Olivier Galibert]

On Mon, Aug 25, 1997 at 11:32:36AM -0700, Jason Merrill wrote:
> The only other option would seem to be a third library, linked in along
> with libgcc.  Then the trick is insinuating it into the specs file.

This would be quite a pain if you want to link together C++ and fortran
object files...

  OG.

Re: egcs release

[H.J. Lu]

Hi,

The bugs fixed by the patches enclosed here should be fixed in
the first egcs release. Otherwise, even glibc may be miscompiled
on linux/x86.

BTW, my 970731-1/runit test triggers the second bug. The first
one is hard to write a generic test case for. You need to look
at the asm code to see the bug.

Thanks.


H.J.
---
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.

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.

Re: fixing the c++/f77 circular dependency

[Jason Merrill]

>>>>> Jim Wilson <wilson@cygnus.com> writes:

> 	I'd like to see them in libgcc.a. It should not be hard to put
> 	something in libgcc.a from cp/Makefile.

> I am not opposed to having C++ code in libgcc.a if it can be made to
> work.  However, having already dealt with a number of problems resulting
> from this, I am skeptical that it can be made to work cleanly.

That may be.  The code currently in libgcc is the freestanding library,
which includes some code called by various language constructs, and
therefore needs to be linked in automatically.  I don't want people to have
to pull in libstdc++ to get RTTI support.

The only other option would seem to be a third library, linked in along
with libgcc.  Then the trick is insinuating it into the specs file.

Jason

Re: Building of generated parser files

[Jim Meyering]

Ian Lance Taylor <ian@cygnus.com> writes:

|    Date: Sat, 23 Aug 1997 19:02:57 -0400
|    From: Richard Stallman <rms@gnu.ai.mit.edu>
|
|    What do people propose for --enable-maintainer-mode to mean?
|
| --enable-maintainer-mode is currently being used by automake.
|
| If --enable-maintainer-mode is used when you configure, it means that
| you will get a Makefile which will automatically rebuild Makefile.in
| from Makefile.am using automake, and automatically rebuild configure
| from configure.in using autoconf, among other automatic dependencies.
|
| If you do not use --enable-maintainer-mode, then you will have to
| explicitly rebuild Makefile.in, configure.in, and other files by hand.

FYI, the fileutils, sh-utils, and textutils have been providing
--enable-maintainer-mode for over a year.  It seems to have had
the desired effect.

Re: fixing the c++/f77 circular dependency

[Jim Wilson]

	I'd like to see them in libgcc.a. It should not be hard to put
	something in libgcc.a from cp/Makefile.

I am not opposed to having C++ code in libgcc.a if it can be made to
work.  However, having already dealt with a number of problems resulting
from this, I am skeptical that it can be made to work cleanly.

Simply moving the rules into cp/Makefile does not itself fix the problem.
If we have a rule in Makefile that adds the C++ library created by cp/Makefile
to libgcc.a, then we still have the problem that libgcc.a depends on LANGUAGES
and/or cc1plus.  If we have a rule in cp/Makefile that adds stuff to libgcc.a,
then we have two different rules in two different Makefile writing to the
same file, which seems even worse.

Jim

Re: fixing the c++/f77 circular dependency

[H.J. Lu]

> 
> 	Why not fix it by moving the c++ part of libgcc.a into cp/Makefile?
> 
> That is one of the options I mentioned at the beginning of this discussion,
> and is still an open issue.
> 
> However, this does not fix the problem unless we move the c++ stuff out of
> libgcc.a and into a new library.  This means changing the c++ compiler to
> link in yet another library, and this isn't very desirable.  But now that
> we have added libstdc++ to the egcs distribution, this stuff could perhaps
> be moved into libstdc++.
> 

I'd like to see them in libgcc.a. It should not be hard to put
something in libgcc.a from cp/Makefile.

-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

Re: fixing the c++/f77 circular dependency

[Mike Stump]

> Date: Fri, 22 Aug 1997 11:32:18 -0700
> From: Jim Wilson <wilson@cygnus.com>

> But now that we have added libstdc++ to the egcs distribution, this
> stuff could perhaps be moved into libstdc++.

That's where it started!  :-)

(One should not infer that I am against moving it from this message.)

Re: fixing the c++/f77 circular dependency

[Jim Wilson]

	Why not fix it by moving the c++ part of libgcc.a into cp/Makefile?

That is one of the options I mentioned at the beginning of this discussion,
and is still an open issue.

However, this does not fix the problem unless we move the c++ stuff out of
libgcc.a and into a new library.  This means changing the c++ compiler to
link in yet another library, and this isn't very desirable.  But now that
we have added libstdc++ to the egcs distribution, this stuff could perhaps
be moved into libstdc++.

Jim

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: fixing the c++/f77 circular dependency

[H.J. Lu]

> 
> Dave Love <d.love@dl.ac.uk> writes:
> 
> |>>>>>> "Doug" == Doug Evans <dje@cygnus.com> writes:
> |>  Doug> You could add a --enable-lang=foo [or some such] option,
> |>  Doug> so while LANGUAGES=x is gone, the ability to only build a few
> |>  Doug> is not.
> 
> |> I'd vote for that sort of thing.
> 
> 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.
> 

Why not fix it by moving the c++ part of libgcc.a into cp/Makefile?

-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

Re: fixing the c++/f77 circular dependency

[Andreas Schwab]

Dave Love <d.love@dl.ac.uk> writes:

|>>>>>> "Doug" == Doug Evans <dje@cygnus.com> writes:
|>  Doug> You could add a --enable-lang=foo [or some such] option,
|>  Doug> so while LANGUAGES=x is gone, the ability to only build a few
|>  Doug> is not.

|> I'd vote for that sort of thing.

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.

Re: fixing the c++/f77 circular dependency

[Jim Wilson]

	 Jim> The fourth option is easy to implement.  The only downside I can see is
	 Jim> that the f77-runtime is now configured always, 

	It shoudn't be, and I didn't think it was in the vanilla version.
	Will try to look at it before absconding for the holiday weekend.

You are confusing the issues here a little.  The f77-runtime is being
configured all of the time because I changed the Makefile rule.  This was an
intentional change necessary to break the circular dependency.  It is not
a problem that you need to look at.

Jim

Problems on PowerPC...

[David McWherter]

	I was trying to compile egcs on my Linux-Pmac PowerPC 601 system,
and I noted that there seem to be problems with the generation of
crtbegin.o and crtend.o, or perhaps in the construction of __CTOR_END__
and __CTOR_LIST__ - I'm not sure yet.  I'm using the 970814 snapshot.

	Anyways, my problem comes in building stage2 of the compiler.
When building genattr, the compiler links obstack.o with a couple of 
other object files, resulting in an executable.  The problem is that when
the executable is run, from __do_global_ctors_aux(), program control is
jumping into a constructor for the obstack.o module, it seems.  The
problem is that the only thing there is a sequence of illegal instructions
(all 0's, as obstack.c seems to contain no real code after preprocessor
fun on my system).

    I've analyzed the generation of the __CTOR_LIST__ and __CTOR_END__
symbols in the genattr program, and it seems that somewhere, the version
being compiled by egcs is putting an extra item in the constructor list
that my 'real' gcc isn't creating.  This item points to the above
described block of illegal instructions.  

    I was wondering if anybody on this list might be able to give me some
pointers on where to look to solve this problem.  I figure that the
problem lies in the creation of the __CTOR_LIST__, but I'm not 100%
positive.  Perhaps I should be looking in collect2's source?

Thanks,
-David McWherter
dtm@waterw.com

Re: fixing the c++/f77 circular dependency

[Andreas Schwab]

Doug Evans <dje@cygnus.com> writes:

|>    From: Alexandre Oliva <oliva@dcc.unicamp.br>
|>    Date: 21 Aug 1997 01:27:55 -0300

|>    > You could add a --enable-lang=foo [or some such] option,
|>    > so while LANGUAGES=x is gone, the ability to only build a few
|>    > is not.

|>    I'd rather have all languages enabled by default (as it is now), and
|>    configuring --without-g77, --without-g++ (is this a valid identifier,
|>    by the way?), etc would selectively disable them.  I could provide a
|>    patch for that, if you agree with it.

|> When I proposed and wrote a patch for --{with,without}-lang [over two
|> years ago] it was suggested that --{enable,disable} was more appropriate.

According to the autoconf manual --with[out]-PACKAGE should be used for
something optional that is external to the source package (eg,
--with-gnu-ld, --with-debugging-malloc).  --{enable,disable}-FEATURE is
for controling the inclusion of something which is part of the source
package, but optional (eg, --enable-haifa, --enable-maintainer-mode).

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

Re: fixing the c++/f77 circular dependency

[Doug Evans]

   From: Alexandre Oliva <oliva@dcc.unicamp.br>
   Date: 21 Aug 1997 01:27:55 -0300

   > You could add a --enable-lang=foo [or some such] option,
   > so while LANGUAGES=x is gone, the ability to only build a few
   > is not.

   I'd rather have all languages enabled by default (as it is now), and
   configuring --without-g77, --without-g++ (is this a valid identifier,
   by the way?), etc would selectively disable them.  I could provide a
   patch for that, if you agree with it.

When I proposed and wrote a patch for --{with,without}-lang [over two
years ago] it was suggested that --{enable,disable} was more appropriate.

As for the behaviour, what's the default, etc. etc.
I don't have a strong opinion.  I realize it's reasonable
to want the default to be to install all languages.

Ultrasparc addition for sparc.md (fwd)

[Oleg Krivosheev]

Hi, All,

i don't know is it good idea or not to
forward message from gcc2 list but here it is...

OK

ps maybe someone knowledgeable will systematically
forward essential messages from/to gcc2?


---------- Forwarded message ----------
Date: Wed, 20 Aug 1997 14:00:27 +0200
From: Christian Kuehnke <Christian.Kuehnke@arbi.Informatik.UNI-OLDENBURG.DE>
To: gcc2@cygnus.COM
Subject: Ultrasparc addition for sparc.md

Hello,
here are first results of my experimnts (see comment at the end):

--- sparc.md.orig	Tue Aug 19 00:45:02 1997
+++ sparc.md	Tue Aug 19 00:45:02 1997
@@ -272,6 +272,43 @@
 ;; The multiply unit has a latency of 5.
 (define_function_unit "tsc701_mul" 1 0
   (and (eq_attr "type" "imul")		(eq_attr "cpu" "tsc701")) 5 5)
+
+;; ----- The UltraSPARC-1 scheduling
+;; The Ultrasparc can issue 1 - 4 insns per cycle; here we assume
+;; four insns/cycle, and hence multiply all costs by four.
+
+;; Memory delivers its result in three cycles to IU, three cycles to FP
+(define_function_unit "memory" 1 0
+  (and (eq_attr "type" "load,fpload")   (eq_attr "cpu" "ultrasparc")) 12 4)
+(define_function_unit "memory" 1 0
+  (and (eq_attr "type" "store,fpstore") (eq_attr "cpu" "ultrasparc"))  4 4)
+(define_function_unit "ieu" 1 0
+  (and (eq_attr "type" "ialu")          (eq_attr "cpu" "ultrasparc"))  1 2)
+(define_function_unit "ieu" 1 0
+  (and (eq_attr "type" "shift")         (eq_attr "cpu" "ultrasparc"))  1 4)
+(define_function_unit "ieu" 1 0
+  (and (eq_attr "type" "cmove")         (eq_attr "cpu" "ultrasparc"))  8 4)
+
+;; Timings; throughput/latency
+;; ?? FADD     1/3    add/sub, format conv, compar, abs, neg
+;; ?? FMUL     1/3
+;; ?? FDIVs    1/12
+;; ?? FDIVd    1/22
+;; ?? FSQRTs   1/12
+;; ?? FSQRTd   1/22
+
+(define_function_unit "fp" 1 0
+  (and (eq_attr "type" "fp")       (eq_attr "cpu" "ultrasparc")) 12 2)
+(define_function_unit "fp" 1 0
+  (and (eq_attr "type" "fpcmp")    (eq_attr "cpu" "ultrasparc"))  8 2)
+(define_function_unit "fp" 1 0
+  (and (eq_attr "type" "fpmul")    (eq_attr "cpu" "ultrasparc")) 12 2)
+(define_function_unit "fp" 1 0
+  (and (eq_attr "type" "fpdivs")   (eq_attr "cpu" "ultrasparc")) 48 2)
+(define_function_unit "fp" 1 0
+  (and (eq_attr "type" "fpdivd")   (eq_attr "cpu" "ultrasparc")) 88 2)
+(define_function_unit "fp" 1 0
+  (and (eq_attr "type" "fpsqrt")   (eq_attr "cpu" "ultrasparc")) 48 2)
 \f
 ;; Compare instructions.
 ;; This controls RTL generation and register allocation.
--- sparc.h.orig	Tue Aug 19 00:45:06 1997
+++ sparc.h	Tue Aug 19 00:45:06 1997
@@ -2707,7 +2707,7 @@
 
 #define RTX_COSTS(X,CODE,OUTER_CODE)			\
   case MULT:						\
-    return (TARGET_V8 || TARGET_SPARCLITE || TARGET_V9) \
+    return (TARGET_V8 || TARGET_SPARCLITE)              \
 	? COSTS_N_INSNS (5) : COSTS_N_INSNS (25);	\
   case DIV:						\
   case UDIV:						\


As David S. Miller recently commented, it is rather difficult to
accurately describe the UltraSPARC pipeline for gcc.

- UltraSPARC can issue up to 4 insns/cycle.
- Out of these 4
  * two can be ALU and/or branch (branch can only be in the first three)
    -     of which only one can be a shift
    - and of which only one can be a condition-code-setting op
  * one can be a load/store
  * two can be fp ops.
- Integer multiplication entirely stalls the pipeline for 4 up to
  18 (SMUL), 19 (UMUL), 34 (64-bit MULX) cycles, depending on the
  operands, hence my modification in sparc.h, could even be more
  aggressive about it (increase COSTS_N_INSNS).

With the floating point benchmark David Miller posted some days ago,
the results are as follows (on an Ultra 1/140):

gcc -O2 -mcpu=supersparc			12.35s
gcc -O2 -mcpu=cypress				12.68s
gcc -O2 -mcpu=ultrasparc			9.80s
cc -xO3 -xtarget=ultra1/140 -xarch=v8plus	8.75s
[Another commercial compiler]			9.80s

*HOWEVER*, when tested with other programs not using floating point,
the -mcpu=supersparc wins slightly over -mcpu=ultrasparc or is on par.

Any measurements or corrections or improvements are welcome.

Christian

-- 
Christian.Kuehnke@Informatik.Uni-Oldenburg.DE   | Tel.: +49 441 592 652  (home)
                                                | Tel.: +49 441 798 2978 (work)
                                                | Fax : +49 441 798 2980 (work)

Re: fixing the c++/f77 circular dependency

[Alexandre Oliva]

Doug Evans writes:

> You could add a --enable-lang=foo [or some such] option,
> so while LANGUAGES=x is gone, the ability to only build a few
> is not.

I'd rather have all languages enabled by default (as it is now), and
configuring --without-g77, --without-g++ (is this a valid identifier,
by the way?), etc would selectively disable them.  I could provide a
patch for that, if you agree with it.

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

[REQ] If the x86 people could do something about this...

[John Beppu]

        The problem I have with gcc's code generation for i386+
        regards the assigning of constants to variables in
        memory.  This constructor just sets a lot of things to 0.
        The assembly output of this constructor is a bit
        disappointing, though.  

.. C++ .................................................................

TextFile::TextFile()
{
    origBUF = NULL;
    lineDefLUT = NULL;
    eolnTYPE = EOLN_UNIX;
    accessMODE = xx_ACCESS;
    currentLINE = 0;
    lineQTY = 0;
    name[0] = 0;
    eolnStr[0] = 0x0d;
    eolnStr[1] = 0x0a;
    eolnStr[2] = 0x00;
    eolnStr[3] = 0x00;
}

        The following asm output was derived by using 
        
        "-O3 -fomit-frame-pointer -m486".  
        
        I would love it if gcc would be so kind as to put $0
        into a register.  The only way I found to coax gcc into
        putting $0 into a register was to compile without
        optimizations, and declare a variable of the form:

        register int blah = 0;

        Apparently the keyword "register" is ignored when
        compiling with -On (where n > 0).

.. x86 Assembly ........................................................

	.size	 _._8TextFile,.Lfe4-_._8TextFile
	.align 16
.globl __8TextFile
	.type	 __8TextFile,@function
__8TextFile:
	movl 4(%esp),%eax       ; movl $0,%ecx would be nice
	movl $0,16(%eax)        ; movl %ecx,16(%eax)
	movl $0,20(%eax)        ; movl %ecx,20(%eax)
	movl $0,156(%eax)       ; etc...
	movl $0,(%eax)
	movl $0,8(%eax)
	movl $0,4(%eax)
	movb $0,24(%eax)
	movb $13,152(%eax)
	movb $10,153(%eax)
	movb $0,154(%eax)
	movb $0,155(%eax)
	ret

        If this has already been dealt with in pgcc, great.  If
        not, I would really appreciate it if this were
        considered for modification.  It's such an easy
        optimization.  The example constructor would easily be
        twice as fast if not more if a register were to contain
        the constant $0, and used for the memory stores.

        Although this would require the use of one more register
        in a sparse register set, I believe this would be
        beneficial in more cases than detrimental.



  Thanks :)

  beppu@uci.edu .............................................................

Re: fixing the c++/f77 circular dependency

[Doug Evans]

   Date: Wed, 20 Aug 1997 15:18:31 -0700
   From: Jim Wilson <wilson@cygnus.com>

   I have thought of four possible solutions so far.
   1) Make all languages mandatory (eliminate LANGUAGES=X option).
   2) Move the C++ code out of libgcc.a.
   3) Move the f77-runtime out of the gcc directory.
   4) Put the f77-runtime in rest.encap instead of f77 LANGUAGES rule.

   The first option is probably too unpopular to consider further, though
   it would certainly simplify the Makefile.

You could add a --enable-lang=foo [or some such] option,
so while LANGUAGES=x is gone, the ability to only build a few
is not.

fixing the c++/f77 circular dependency

[Jim Wilson]

I have thought of four possible solutions so far.
1) Make all languages mandatory (eliminate LANGUAGES=X option).
2) Move the C++ code out of libgcc.a.
3) Move the f77-runtime out of the gcc directory.
4) Put the f77-runtime in rest.encap instead of f77 LANGUAGES rule.

The first option is probably too unpopular to consider further, though
it would certainly simplify the Makefile.

The second and third options are non-trivial to implement, though we may
have to move in this direction in the long term.

The fourth option is easy to implement.  The only downside I can see is
that the f77-runtime is now configured always, though it is only built
if f77 is in LANGUAGES (the f77-runtime rule already checks for this).
This seems to be the best solution for the short term.

Anyone see any serious problem with this, or want to suggest alternative
solutions?

Without some kind of patch for this, I can't build egcs on the system on
my desk, so this is a rather important problem to me. :-)

I have a tentative patch, though it needs to be cleaned up a bit.

Index: Makefile.in
===================================================================
RCS file: /cvs/cvsfiles/egcs/Makefile.in,v
retrieving revision 1.7
diff -p -r1.7 Makefile.in
*** Makefile.in	1997/08/19 15:36:20	1.7
--- Makefile.in	1997/08/20 21:56:56
*************** LANG_MAKEFILES = @all_lang_makefiles@
*** 510,515 ****
--- 510,516 ----
  LANG_STAGESTUFF = @all_stagestuff@
  LANG_DIFF_EXCLUDES = @all_diff_excludes@
  LANG_LIB2FUNCS = @all_lib2funcs@
+ LANG_REST_ENCAP = @all_rest_encap@
  LANG_EXTRA_HEADERS = @all_headers@
  
  # Flags to pass to recursive makes.
*************** all.build: native xgcc $(EXTRA_PARTS) la
*** 718,724 ****
  # This is what must be made before installing GCC and converting libraries.
  start.encap: native xgcc specs $(LIBGCC1) xlimits.h lang.start.encap
  # These can't be made until after GCC can run.
! rest.encap: stmp-headers $(LIBGCC) $(STMP_FIXPROTO) $(EXTRA_PARTS) lang.rest.encap
  # This is what is made with the host's compiler
  # whether making a cross compiler or not.
  native: config.status config.h cpp $(LANGUAGES) \
--- 719,725 ----
  # This is what must be made before installing GCC and converting libraries.
  start.encap: native xgcc specs $(LIBGCC1) xlimits.h lang.start.encap
  # These can't be made until after GCC can run.
! rest.encap: stmp-headers $(LIBGCC) $(STMP_FIXPROTO) $(EXTRA_PARTS) $(LANG_REST_ENCAP)
  # This is what is made with the host's compiler
  # whether making a cross compiler or not.
  native: config.status config.h cpp $(LANGUAGES) \
Index: configure.in
===================================================================
RCS file: /cvs/cvsfiles/egcs/configure.in,v
retrieving revision 1.7
diff -p -r1.7 configure.in
*** configure.in	1997/08/19 21:09:17	1.7
--- configure.in	1997/08/20 21:17:53
*************** all_outputs=Makefile
*** 2924,2929 ****
--- 2925,2931 ----
  all_lang_makefiles=
  all_headers=
  all_lib2funcs=
+ all_rest_encap=
  
  # Add the language fragments.
  # Languages are added via two mechanisms.  Some information must be
*************** do
*** 2970,2975 ****
--- 2972,2978 ----
  			oldstyle_subdirs="$oldstyle_subdirs $s"
  		fi
  		all_lib2funcs="$all_lib2funcs $lib2funcs"
+ 		all_rest_encap="$all_rest_encap $rest_encap"
  	fi
  done
  
*************** AC_SUBST(all_lang_makefiles)
*** 3046,3051 ****
--- 3049,3055 ----
  AC_SUBST(all_stagestuff)
  AC_SUBST(all_diff_excludes)
  AC_SUBST(all_lib2funcs)
+ AC_SUBST(all_rest_encap)
  AC_SUBST(all_headers)
  AC_SUBST(extra_passes)
  AC_SUBST(extra_programs)
Index: f/Make-lang.in
===================================================================
RCS file: /cvs/cvsfiles/egcs/f/Make-lang.in,v
retrieving revision 1.4
diff -p -r1.4 Make-lang.in
*** Make-lang.in	1997/08/18 15:01:55	1.4
--- Make-lang.in	1997/08/20 21:18:15
*************** G77_CROSS_NAME = `t='$(program_transform
*** 96,102 ****
  # Note that it would be nice to move the dependency on g77
  # into the F77 rule, but that needs a little bit of work
  # to do the right thing within all.cross.
! F77 f77: f771 f77-runtime
  
  # Tell GNU make to ignore these if they exist.
  .PHONY: F77 f77 f77-runtime f77-runtime-unsafe f77.all.build f77.all.cross \
--- 96,102 ----
  # Note that it would be nice to move the dependency on g77
  # into the F77 rule, but that needs a little bit of work
  # to do the right thing within all.cross.
! F77 f77: f771
  
  # Tell GNU make to ignore these if they exist.
  .PHONY: F77 f77 f77-runtime f77-runtime-unsafe f77.all.build f77.all.cross \
Index: f/config-lang.in
===================================================================
RCS file: /cvs/cvsfiles/egcs/f/config-lang.in,v
retrieving revision 1.2
diff -p -r1.2 config-lang.in
*** config-lang.in	1997/08/12 17:12:05	1.2
--- config-lang.in	1997/08/20 21:18:15
***************
*** 25,30 ****
--- 25,31 ----
  # compilers	- value to add to $(COMPILERS)
  # stagestuff	- files to add to $(STAGESTUFF)
  # diff_excludes	- files to ignore when building diffs between two versions.
+ # rest_encap	- files to build after gcc can be used to link
  
  #if grep DECL_STATIC_CONSTRUCTOR $srcdir/tree.h >/dev/null; then
  #   if grep flag_move_all_movables $srcdir/toplev.c >/dev/null; then true
*************** case "$arguments" in
*** 58,63 ****
--- 59,66 ----
  esac
  
  diff_excludes="-x \"f/g77.info*\""
+ 
+ rest_encap="f77-runtime"
  
  # Create the runtime library directory tree if necessary.
  test -d f || mkdir f