Re: bootstrapping problems with native compiler

Re: bootstrapping problems with native compiler

[Dave Love]

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

 Jim> The problem here is that LANGUAGES is not passed on recursive
 Jim> invocations of make.  This causes a problem for any target (like
 Jim> irix6) with a multilib libgcc, because this is implemented via a
 Jim> recursive make.  

I passed LANGUAGES="$(LANGUAGES)" to all the $(MAKE)s in the top-level
Makefile.in and on an irix6.4 system with the native make (and having
forgotten to stop it picking up gcc as CC) it did a set of recursive
makes until running out of processes.

 Jim> Manfred Hollstein mailed a patch to the gcc2 developers that
 Jim> would fix this.

I checked the FSF version before complaining and couldn't see any
relevant changes there.  (Sorry I haven't been reading gcc2.)  If
someone can mail it to me I can see if it solves the problem on a
mighty, fairly-idle SGI.

Re: front end interface

[Nigel Stephens]

John Carr (jfc@MIT.EDU) writes:
 > > If I understand this correctly, you're depending on memcpy() being
 > > named 'memcpy' ?!
 > > 
 > > This leads into trouble with the current openVMS ports (vax and
 > > alpha), where most library functions are '#define'd with a DECC$ in
 > > front (and others have a __asm() appended to their declaration). So
 > > the compiler doesn't see memcpy but DECC$MEMCPY.
 > 
 > memcpy is recognized by the C front end, as are some of the other
 > string and math functions.

Perhaps a better way to do this in general would be to extend the
__attribute__ mechanism to allow a header file to tell the compiler
more about the behaviour of functions.  For example, since the
"malloc" test is used to tell the "alias" pass that pointers returned
by these functions won't alias to other pointers, we could perhaps
have:

	void * malloc (size_t) __attribute__ ((noalias));

This might then be useful for other functions with similar properties
to malloc(), realloc(), etc.

A similar trick would work for setjmp:

	int setjmp (jmp_buf) __attribute__ ((returns-twice));

As for the builtin use of memcpy() for structure copies etc,
presumably the name of the byte-copy function should be configurable
in the target's header file rather than hardwired into optabs.c.


-- 
________________________________________________________________________
Nigel Stephens, Algorithmics Ltd, 3 Drayton Park, London N5 1NU. England
mailto:nigel@algor.co.uk                          http://www.algor.co.uk
phone:+44 171 700 3301	   mobile:+44 976 686470    fax:+44 171 700 3400

Re: bootstrapping problems with native compiler

[Jeffrey A Law]

  In message <rzq4t8nlazh.fsf@djlvig.dl.ac.uk>you write:
  > >>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes:
  > 
  >  Jim> The problem here is that LANGUAGES is not passed on recursive
  >  Jim> invocations of make.  This causes a problem for any target (like
  >  Jim> irix6) with a multilib libgcc, because this is implemented via a
  >  Jim> recursive make.  
  > 
  > I passed LANGUAGES="$(LANGUAGES)" to all the $(MAKE)s in the top-level
  > Makefile.in and on an irix6.4 system with the native make (and having
  > forgotten to stop it picking up gcc as CC) it did a set of recursive
  > makes until running out of processes.
Did this happen during the stage2 build?  There's still some kind
of circular dependency with cplib2.txt that nobody's tracked down
yet.

Jeff

Re: front end interface

[Dave Love]

>>>>> "John" == John Carr <jfc@mit.edu> writes:

 John> I've mentioned this in private email but I should let the list
 John> know as well: my alias code in the back end recognizes certain
 John> C function names.  I believe this is correct because all
 John> languages will be linking with the C library and must mangle or
 John> prohibit any names which conflict.  For example, Fortran
 John> symbols traditionally have a "_" added to the end.

I suspect it's not relevant for the likely routines which are probably
used by the runtime anyhow, but just in case: G77 has an option to
suppress mangling.  It typically ends in tears when ths is used, of
course.

Re: bootstrapping problems with native compiler

[Dave Love]

>>>>> "Jeffrey" == Jeffrey A Law <law@hurl.cygnus.com> writes:

 Jeffrey> Did this happen during the stage2 build?  

I think so, but I lost the log.

 Jeffrey> There's still some kind of circular dependency with
 Jeffrey> cplib2.txt that nobody's tracked down yet.

Yes.  With gmake (and LANGUAGES passed down) I see:

[...]
if [ -f libgcc2.ready ] ; then \
	true; \
else \
	touch libgcc2.ready; \
fi
gmake[1]: Circular cplib2.ready <- f77 dependency dropped.
stage1/xgcc -Bstage1/  -DIN_GCC    -O -g  -DHAVE_CONFIG_H     -I. -I. -I./config -I./objc \

[...]

if [ -f libgcc2.ready ] ; then \
	true; \
else \
	touch libgcc2.ready; \
fi
gmake[3]: Circular stmp-multilib <- cplib2.txt dependency dropped.
top=`pwd`; \
src=`cd .; pwd`; \
  cd f/runtime; \
  CC="`case './xgcc -B./' in \
[...]

Then it dies after configuring the g77 runtime:

checking for getrusage... yes
updating cache ./config.cache
creating ./config.status
creating Makefile
creating config.h
config.h is unchanged
./xgcc -B./  -DIN_GCC    -O -g -I./include     -DNO_MEM -DNO_LONG_DOUBLE_IO -O0 -I. -c ./enquire.c
./enquire.c: In function `cprop':
./enquire.c:1387: warning: comparison is always 0 due to limited range of data type
./xgcc -B./  -DIN_GCC    -O -g -I./include   enquire.o -o enquire
ld: FATAL 9: I/O error (crtbegin.o): No such file or directory
collect2: ld returned 32 exit status
gmake[3]: *** [enquire] Error 1
gmake[3]: Leaving directory `/data1/scr1/fx/egcs-ss-970814'
gmake[2]: *** [stmp-multilib-sub] Error 2
gmake[2]: Leaving directory `/data1/scr1/fx/egcs-ss-970814'
gmake[1]: *** [stmp-multilib] Error 1
gmake[1]: Leaving directory `/data1/scr1/fx/egcs-ss-970814'
gmake: *** [bootstrap] Error 2
mscsv1 139%

Re: bootstrapping problems with native compiler

[Jim Wilson]

 Jeffrey> There's still some kind of circular dependency with
 Jeffrey> cplib2.txt that nobody's tracked down yet.

f77 depends on f77-runtime
f77-runtime depends on f/runtime/Makefile
f/runtime/Makefile depends on stmp-multilib (via $LIBGCC via $GCC_PARTS)
stmp-multilib depends on cplib2.txt
cplib2.txt depends on cplib2.ready
cplib2.ready depends on f77 (via $LANGUAGES)
circular dependence dropped

There are two curiousities here.

The f77 runtime library depends on GCC_PARTS because it wants to
compile-and-link code.  If this is just a runtime, then we should not need
to actually link code.  If we do need to be able to link, then this will cause
various problems (for instance it won't work for crosses), which will probably
require moving the f77 runtime out of the gcc directory into its own
directory.  I suspect it can be fixed by tweaking the f77 runtime autoconf
so that it doesn't try to link files.

The cplib2.ready file depends on LANGUAGES.  This is apparently an attempt
to get a dependence on cc1plus without actually mentioning anything C++
related unless C++ was in LANGUAGES.  Unfortunately, now that we have
more than one optional language, it means that some C++ stuff now ends up
with dependencies on some f77 stuff.

Jim

Re: double alignment patch for x86

[meissner]

| I see how the changes will preserve alignment, but what if
| the initial alignment is not double aligned?
| 
| My preference would be verb-object options, e.g. -malign-stack-double,
| -malign-args-double.  The Intel compiler defaults to aligning the
| stack double if the function uses doubles since this doesn't break the ABI.

IMHO, the stack should always be aligned to an 8 byte boundary unless you
specifically ask for it otherwise (-fspace for instance).  Otherwise, your
caller may not have aligned the stack properly.

| What about using #define constants instead of 0 and 1 in the
| ix86_sp_offset call?
| 
| Is there need for the % calculation in ix86_sp_offset, can't you just
| check for offset = 4, 8, or 12 and simplify this routine since the x86
| preserves at most 3 registers (edi, esi, ebx)?
| 
| 

Re: bootstrapping problems with native compiler

[Dave Love]

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

 Jim> The f77 runtime library depends on GCC_PARTS because it wants to
 Jim> compile-and-link code.  If this is just a runtime, then we
 Jim> should not need to actually link code.

Actually it wants to link and run too.  Its configuration needs to
check for non-ANSI sprintf (at least) and I don't know a way to do
that reliably other than with AC_TRY_RUN.  It certainly needs to be
able to do linking in configure to test for various library routines.

 Jim> If we do need to be able to link, then this will cause various
 Jim> problems (for instance it won't work for crosses), 

The released G77 is known basically to survive criss-cross builds.
(The sprintf test makes a pessimistic assumption if necessary.)  I've
probably omitted to document that that might be worth editing in most
cases of crosses.

 Jim> which will probably require moving the f77 runtime out of the
 Jim> gcc directory into its own directory.

The runtime is entirely isolated and configured separately in a
sub-directory of f/; it just depends on a working built (cross)
compiler for configuring.  However, it would be nice to be able to do
autoconf tests involving linking for the compiler as well as the
runtime from an f/configure.  In fact we used to hack that in from
config-lang.in.

(Some of this would be irrelevant if gcc provided an ANSI environment
by providing libiberty (?) type stuff where appropriate.  I don't know
how feasible that would be.)

I don't understand why C++ should stick stuff in libgcc anyhow -- why
isn't its runtime kept separate like objc and fortran?

Re: bootstrapping problems with native compiler

[meissner]

| >>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes:
| 
|  Jim> The f77 runtime library depends on GCC_PARTS because it wants to
|  Jim> compile-and-link code.  If this is just a runtime, then we
|  Jim> should not need to actually link code.
| 
| Actually it wants to link and run too.  Its configuration needs to
| check for non-ANSI sprintf (at least) and I don't know a way to do
| that reliably other than with AC_TRY_RUN.  It certainly needs to be
| able to do linking in configure to test for various library routines.

Sounds like it won't work too well on Canadian Crosses where build, host, and
target machines are all different.  For example at Cygnus, we build NT cross
compilers under random Unixes (for example, --host=i586-cygwin32,
--build=sparc-solaris2.5, --target=powerpc-eabi).

|  Jim> If we do need to be able to link, then this will cause various
|  Jim> problems (for instance it won't work for crosses), 
| 
| The released G77 is known basically to survive criss-cross builds.
| (The sprintf test makes a pessimistic assumption if necessary.)  I've
| probably omitted to document that that might be worth editing in most
| cases of crosses.
| 
|  Jim> which will probably require moving the f77 runtime out of the
|  Jim> gcc directory into its own directory.
| 
| The runtime is entirely isolated and configured separately in a
| sub-directory of f/; it just depends on a working built (cross)
| compiler for configuring.  However, it would be nice to be able to do
| autoconf tests involving linking for the compiler as well as the
| runtime from an f/configure.  In fact we used to hack that in from
| config-lang.in.
| 
| (Some of this would be irrelevant if gcc provided an ANSI environment
| by providing libiberty (?) type stuff where appropriate.  I don't know
| how feasible that would be.)

It can be done, its just a small matter of programming :-)  Of course, you do
have to build libiberty up to 3 times (once for build, once for host, and
possibly once for target).

| I don't understand why C++ should stick stuff in libgcc anyhow -- why
| isn't its runtime kept separate like objc and fortran?

Because GNU C supports static constructors and destructors as well with
__attribute__((__constructor__)).

Re: bootstrapping problems with native compiler

[Doug Evans]

   Date: Mon, 18 Aug 1997 18:48:07 -0400 (EDT)
   From: meissner@cygnus.com

   | Actually it wants to link and run too.  Its configuration needs to
   | check for non-ANSI sprintf (at least) and I don't know a way to do
   | that reliably other than with AC_TRY_RUN.  It certainly needs to be
   | able to do linking in configure to test for various library routines.

   Sounds like it won't work too well on Canadian Crosses where build, host, and
   target machines are all different.  For example at Cygnus, we build NT cross
   compilers under random Unixes (for example, --host=i586-cygwin32,
   --build=sparc-solaris2.5, --target=powerpc-eabi).

   | The released G77 is known basically to survive criss-cross builds.
   | (The sprintf test makes a pessimistic assumption if necessary.)  I've
   | probably omitted to document that that might be worth editing in most
   | cases of crosses.

Clearly using AC_TRY_RUN doesn't work too well for Canadian Cross builds,
but methinks Dave is saying an attempt has been made to handle them
[by choosing a default that works at least for the cases tried].

Re: bootstrapping problems with native compiler

[Jim Wilson]

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

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

There is a very natural build order here: compiler, C library, F77 library.
Each one depends on everything that comes before it.  Unfortunately, because
the compiler and the F77 library are in the same directory, it is impossible
to build the C library in between them.  For an embedded cross, this matters
a lot, because the C library can not be built until after gcc, and hence
it will not exist when configuring the F77 library.  For a native, this
generally does not matter, but consider what happens if someone wants to
install a new version of gcc and GNU libc at the same time.  What order
do you compile them in?  The natural order is to build gcc first, and then
GNU libc.  However, when you are done, you have an installed f77-runtime that
was autoconfed against a library that no longer exists, and hence you may
need to build and install gcc again to get a working f77 runtime.  This
would not be a problem if the f77 runtime was moved out of the gcc directory,
as then we would be able to build them in the proper order.  (I'm assuming
here that we aren't using shared libraries, as that adds additional problems.)

I don't expect this to be fixed immediately, but it is something we should
seriously consider for the long term.

Some parts of libgcc2.c incidentally have the same problem, which is
worked around via the -Dinhibit_libc hackery.  This stuff should also
be in a directory parallel to a gcc directory instead of inside the gcc
directory, so that we can build it after the C library.

	I don't understand why C++ should stick stuff in libgcc anyhow -- why
	isn't its runtime kept separate like objc and fortran?

It was convenient.  C++ has always had some runtime stuff in libgcc.a, but
it was all written in C.  Recently, some C++ code was added in, and it is only
this C++ code that is causing problems.  Whether this C++ code should remain
in libgcc.a is an open issue.

Jim

Re: Reload patch to improve 386 code

[Jakub Jelinek]

> 
>    Date: Mon, 18 Aug 1997 11:17:38 -0400 (EDT)
>    From: meissner@cygnus.com
> 
>    I think it is an horrible kludge that reload is run as a pass after
>    global-alloc, and that it forces reload registers not to be used
>    for any other purpose (which is murder on the x86 with each
>    register being special purpose in some way).
> 
> Before this leaves my head, I wanted to point something out which
> you've reminded me of.  When the scheduler (this applies to both the
> original and Haifa versions equally) becomes aggressive, it produces a
> large number of reloads in certain situations.  Reloads which would
> not have happened if scheduling did not take place.  This happens
> especially if register pressure is high already.  I noticed this
> particularly on RISC platforms, seems in this case the more registers
> available the worse things became when the register usage was
> saturated.

I thought about a quick solution, which would be during global-alloc, if it
finds out that the number of hard registers is exceeded, it could try to
undo some short pseudo setup RTL sequence merges and move them to the place
of the actual use, if the pseudo being set up is a constant and computable
in small number of instructions not involving memory loads.
Like that, we could rid of the following horror on sparc64:

	sethi %hi(var1), %r1
	stx %r1, [%sp + NN]
	...
	ldx [%sp + NN], %r1
	or %r1, %lo(var1), %r1
	stx %r1, [%sp + NN]
	...
some loop:
	...
	ldx [%sp + NN], %r1
	ldx [%r1], %r1
	...

and could have:

some loop:
	...
	sethi %hi(var1), %r1
	ldx [%r1 + %lo(var1)], %r1
	...

instead...

Cheers,
    Jakub
___________________________________________________________________
Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz
Administrator of SunSITE Czech Republic, MFF, Charles University
___________________________________________________________________
Ultralinux - first 64bit OS to take fool power from the UltraSparc
Linux version 2.0.30 on a sparc machine (291.64 BogoMips).
___________________________________________________________________

Re: bootstrapping problems with native compiler

[Dave Love]

>>>>> "meissner" == meissner  <meissner@cygnus.com> writes:

 meissner> Sounds like it won't work too well on Canadian Crosses
 meissner> where build, host, and target machines are all different.

I can only say that bug reports for cross-g77 have always been
welcome.  There has been a fix made in the development version for
cygwin defining `unix' AFAIR and there were some problems which
appeared to be due to bugs in cygwin which I think should be addressed
there.  (The term `criss-cross' was coined in g77 circles
independently on each side of the Atlantic as a less obscure
alternative to Canadian.)

 meissner> | I don't understand why C++ should stick stuff in libgcc anyhow -- why
 meissner> | isn't its runtime kept separate like objc and fortran?

 meissner> Because GNU C supports static constructors and destructors
 meissner> as well with __attribute__((__constructor__)).

It seems wrong to me if you need to build c++ to get that in C.
__constructor__ is useful for runtime configuration with g77 (and
other languages?) but I hadn't realized the dependency, damn.

Re: bootstrapping problems with native compiler

[Jason Merrill]

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

> It seems wrong to me if you need to build c++ to get that in C.
> __constructor__ is useful for runtime configuration with g77 (and
> other languages?) but I hadn't realized the dependency, damn.

You don't need C++ for that.  Only the major runtime stuff is built with
g++ (RTTI and EH support code).

Jason