* Ultrasparc addition for sparc.md (fwd)
@ 1997-08-21 3:05 Oleg Krivosheev
1997-08-21 3:05 ` f/runtime/Makefile.in: mclock_.o left out of libU77 Mumit Khan
1997-08-21 4:27 ` fixing the c++/f77 circular dependency Alexandre Oliva
0 siblings, 2 replies; 33+ messages in thread
From: Oleg Krivosheev @ 1997-08-21 3:05 UTC (permalink / raw)
To: egcs
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)
^ permalink raw reply [flat|nested] 33+ messages in thread
* f/runtime/Makefile.in: mclock_.o left out of libU77
1997-08-21 3:05 Ultrasparc addition for sparc.md (fwd) Oleg Krivosheev
@ 1997-08-21 3:05 ` Mumit Khan
1997-08-21 4:27 ` fixing the c++/f77 circular dependency Alexandre Oliva
1 sibling, 0 replies; 33+ messages in thread
From: Mumit Khan @ 1997-08-21 3:05 UTC (permalink / raw)
To: egcs
Was there a reason to leave mclock out of libU77? If not, here's a patch
to f/runtime/Makefile.in:
*** f/runtime/Makefile.in.orig Wed Aug 20 22:02:14 1997
--- f/runtime/Makefile.in Wed Aug 20 22:02:33 1997
*************** UOBJ = libU77/VersionU.o libU77/gerror_
*** 133,137 ****
libU77/lnblnk_.o libU77/hostnm_.o libU77/rename_.o libU77/fgetc_.o \
libU77/fputc_.o libU77/umask_.o libU77/system_clock_.o libU77/date_.o \
! libU77/second_.o libU77/flush1_.o libU77/alarm_.o
F2CEXT = abort derf derfc ef1asc ef1cmc erf erfc exit getarg getenv iargc \
--- 133,138 ----
libU77/lnblnk_.o libU77/hostnm_.o libU77/rename_.o libU77/fgetc_.o \
libU77/fputc_.o libU77/umask_.o libU77/system_clock_.o libU77/date_.o \
! libU77/second_.o libU77/flush1_.o libU77/alarm_.o \
! libU77/mclock_.o
F2CEXT = abort derf derfc ef1asc ef1cmc erf erfc exit getarg getenv iargc \
Regards,
Mumit -- khan@xraylith.wisc.edu
http://www.xraylith.wisc.edu/~khan/
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: fixing the c++/f77 circular dependency
1997-08-21 3:05 Ultrasparc addition for sparc.md (fwd) Oleg Krivosheev
1997-08-21 3:05 ` f/runtime/Makefile.in: mclock_.o left out of libU77 Mumit Khan
@ 1997-08-21 4:27 ` Alexandre Oliva
1 sibling, 0 replies; 33+ messages in thread
From: Alexandre Oliva @ 1997-08-21 4:27 UTC (permalink / raw)
To: egcs
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Incorrect i960 linker config
@ 1997-08-30 12:00 Stephen Williams
1997-08-30 19:18 ` fixing the c++/f77 circular dependency Joel Sherrill
0 siblings, 1 reply; 33+ messages in thread
From: Stephen Williams @ 1997-08-30 12:00 UTC (permalink / raw)
To: egcs
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."
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: fixing the c++/f77 circular dependency
1997-08-30 12:00 Incorrect i960 linker config Stephen Williams
@ 1997-08-30 19:18 ` Joel Sherrill
0 siblings, 0 replies; 33+ messages in thread
From: Joel Sherrill @ 1997-08-30 19:18 UTC (permalink / raw)
To: egcs
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: fixing the c++/f77 circular dependency
@ 1997-08-30 12:00 Stephen Williams
0 siblings, 0 replies; 33+ messages in thread
From: Stephen Williams @ 1997-08-30 12:00 UTC (permalink / raw)
To: egcs
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."
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: fixing the c++/f77 circular dependency
@ 1997-08-25 21:30 Jim Wilson
0 siblings, 0 replies; 33+ messages in thread
From: Jim Wilson @ 1997-08-25 21:30 UTC (permalink / raw)
To: egcs
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: fixing the c++/f77 circular dependency
@ 1997-08-25 21:22 Jim Wilson
1997-08-25 21:28 ` Robert Lipe
0 siblings, 1 reply; 33+ messages in thread
From: Jim Wilson @ 1997-08-25 21:22 UTC (permalink / raw)
To: egcs
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: fixing the c++/f77 circular dependency
1997-08-25 21:22 Jim Wilson
@ 1997-08-25 21:28 ` Robert Lipe
0 siblings, 0 replies; 33+ messages in thread
From: Robert Lipe @ 1997-08-25 21:28 UTC (permalink / raw)
To: egcs
> > 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: fixing the c++/f77 circular dependency
@ 1997-08-25 21:16 Joe Buck
0 siblings, 0 replies; 33+ messages in thread
From: Joe Buck @ 1997-08-25 21:16 UTC (permalink / raw)
To: egcs
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.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: fixing the c++/f77 circular dependency
@ 1997-08-25 20:59 meissner
0 siblings, 0 replies; 33+ messages in thread
From: meissner @ 1997-08-25 20:59 UTC (permalink / raw)
To: egcs
| 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./).
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: fixing the c++/f77 circular dependency
@ 1997-08-25 20:41 David Edelsohn
1997-08-25 20:47 ` Robert Lipe
1997-08-25 20:59 ` Jason Merrill
0 siblings, 2 replies; 33+ messages in thread
From: David Edelsohn @ 1997-08-25 20:41 UTC (permalink / raw)
To: egcs
>>>>> 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: fixing the c++/f77 circular dependency
1997-08-25 20:41 David Edelsohn
@ 1997-08-25 20:47 ` Robert Lipe
1997-08-25 20:59 ` Jason Merrill
1 sibling, 0 replies; 33+ messages in thread
From: Robert Lipe @ 1997-08-25 20:47 UTC (permalink / raw)
To: egcs
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: fixing the c++/f77 circular dependency
1997-08-25 20:41 David Edelsohn
1997-08-25 20:47 ` Robert Lipe
@ 1997-08-25 20:59 ` Jason Merrill
1 sibling, 0 replies; 33+ messages in thread
From: Jason Merrill @ 1997-08-25 20:59 UTC (permalink / raw)
To: egcs
>>>>> 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: fixing the c++/f77 circular dependency
@ 1997-08-25 20:25 Joe Buck
0 siblings, 0 replies; 33+ messages in thread
From: Joe Buck @ 1997-08-25 20:25 UTC (permalink / raw)
To: egcs
> 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.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: fixing the c++/f77 circular dependency
@ 1997-08-25 20:25 H.J. Lu
0 siblings, 0 replies; 33+ messages in thread
From: H.J. Lu @ 1997-08-25 20:25 UTC (permalink / raw)
To: egcs
>
> 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.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: fixing the c++/f77 circular dependency
@ 1997-08-25 20:08 Jim Wilson
0 siblings, 0 replies; 33+ messages in thread
From: Jim Wilson @ 1997-08-25 20:08 UTC (permalink / raw)
To: egcs
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: fixing the c++/f77 circular dependency
@ 1997-08-25 18:48 H.J. Lu
1997-08-25 19:30 ` Olivier Galibert
0 siblings, 1 reply; 33+ messages in thread
From: H.J. Lu @ 1997-08-25 18:48 UTC (permalink / raw)
To: egcs
>
> >>>>> 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)
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: fixing the c++/f77 circular dependency
1997-08-25 18:48 H.J. Lu
@ 1997-08-25 19:30 ` Olivier Galibert
0 siblings, 0 replies; 33+ messages in thread
From: Olivier Galibert @ 1997-08-25 19:30 UTC (permalink / raw)
To: egcs
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.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: egcs release
@ 1997-08-25 18:29 H.J. Lu
1997-08-25 18:32 ` fixing the c++/f77 circular dependency Jason Merrill
0 siblings, 1 reply; 33+ messages in thread
From: H.J. Lu @ 1997-08-25 18:29 UTC (permalink / raw)
To: egcs
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.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: fixing the c++/f77 circular dependency
1997-08-25 18:29 egcs release H.J. Lu
@ 1997-08-25 18:32 ` Jason Merrill
0 siblings, 0 replies; 33+ messages in thread
From: Jason Merrill @ 1997-08-25 18:32 UTC (permalink / raw)
To: egcs
>>>>> 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Building of generated parser files
@ 1997-08-24 3:43 Jim Meyering
1997-08-24 3:43 ` fixing the c++/f77 circular dependency Jim Wilson
0 siblings, 1 reply; 33+ messages in thread
From: Jim Meyering @ 1997-08-24 3:43 UTC (permalink / raw)
To: egcs
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.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: fixing the c++/f77 circular dependency
1997-08-24 3:43 Building of generated parser files Jim Meyering
@ 1997-08-24 3:43 ` Jim Wilson
0 siblings, 0 replies; 33+ messages in thread
From: Jim Wilson @ 1997-08-24 3:43 UTC (permalink / raw)
To: egcs
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: fixing the c++/f77 circular dependency
@ 1997-08-22 19:47 H.J. Lu
0 siblings, 0 replies; 33+ messages in thread
From: H.J. Lu @ 1997-08-22 19:47 UTC (permalink / raw)
To: egcs
>
> 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)
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: fixing the c++/f77 circular dependency
@ 1997-08-22 19:23 Mike Stump
0 siblings, 0 replies; 33+ messages in thread
From: Mike Stump @ 1997-08-22 19:23 UTC (permalink / raw)
To: egcs
> 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.)
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: fixing the c++/f77 circular dependency
@ 1997-08-22 19:23 Jim Wilson
0 siblings, 0 replies; 33+ messages in thread
From: Jim Wilson @ 1997-08-22 19:23 UTC (permalink / raw)
To: egcs
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: egcs-ss-970814 on m68k-next-nextstep3
@ 1997-08-22 19:23 Jeffrey A Law
1997-08-22 19:23 ` fixing the c++/f77 circular dependency Jim Wilson
0 siblings, 1 reply; 33+ messages in thread
From: Jeffrey A Law @ 1997-08-22 19:23 UTC (permalink / raw)
To: egcs
> 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: fixing the c++/f77 circular dependency
1997-08-22 19:23 egcs-ss-970814 on m68k-next-nextstep3 Jeffrey A Law
@ 1997-08-22 19:23 ` Jim Wilson
0 siblings, 0 replies; 33+ messages in thread
From: Jim Wilson @ 1997-08-22 19:23 UTC (permalink / raw)
To: egcs
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: fixing the c++/f77 circular dependency
@ 1997-08-22 17:41 H.J. Lu
0 siblings, 0 replies; 33+ messages in thread
From: H.J. Lu @ 1997-08-22 17:41 UTC (permalink / raw)
To: egcs
>
> 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)
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: fixing the c++/f77 circular dependency
@ 1997-08-22 8:36 Andreas Schwab
0 siblings, 0 replies; 33+ messages in thread
From: Andreas Schwab @ 1997-08-22 8:36 UTC (permalink / raw)
To: egcs
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.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: fixing the c++/f77 circular dependency
@ 1997-08-21 18:45 Jim Wilson
0 siblings, 0 replies; 33+ messages in thread
From: Jim Wilson @ 1997-08-21 18:45 UTC (permalink / raw)
To: egcs
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Problems on PowerPC...
@ 1997-08-21 16:51 David Edelsohn
1997-08-21 17:43 ` fixing the c++/f77 circular dependency Dave Love
1997-08-21 17:47 ` Dave Love
0 siblings, 2 replies; 33+ messages in thread
From: David Edelsohn @ 1997-08-21 16:51 UTC (permalink / raw)
To: egcs
>>>>> 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Problems on PowerPC...
@ 1997-08-21 9:21 David McWherter
1997-08-21 9:21 ` fixing the c++/f77 circular dependency Andreas Schwab
0 siblings, 1 reply; 33+ messages in thread
From: David McWherter @ 1997-08-21 9:21 UTC (permalink / raw)
To: egcs
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: fixing the c++/f77 circular dependency
1997-08-21 9:21 Problems on PowerPC David McWherter
@ 1997-08-21 9:21 ` Andreas Schwab
0 siblings, 0 replies; 33+ messages in thread
From: Andreas Schwab @ 1997-08-21 9:21 UTC (permalink / raw)
To: egcs
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"
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: fixing the c++/f77 circular dependency
@ 1997-08-21 4:52 Doug Evans
0 siblings, 0 replies; 33+ messages in thread
From: Doug Evans @ 1997-08-21 4:52 UTC (permalink / raw)
To: egcs
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.
^ permalink raw reply [flat|nested] 33+ messages in thread
* [REQ] If the x86 people could do something about this...
@ 1997-08-20 23:19 John Beppu
1997-08-20 23:19 ` fixing the c++/f77 circular dependency Doug Evans
0 siblings, 1 reply; 33+ messages in thread
From: John Beppu @ 1997-08-20 23:19 UTC (permalink / raw)
To: egcs
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 .............................................................
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: fixing the c++/f77 circular dependency
1997-08-20 23:19 [REQ] If the x86 people could do something about this John Beppu
@ 1997-08-20 23:19 ` Doug Evans
0 siblings, 0 replies; 33+ messages in thread
From: Doug Evans @ 1997-08-20 23:19 UTC (permalink / raw)
To: egcs
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.
^ permalink raw reply [flat|nested] 33+ messages in thread
* fixing the c++/f77 circular dependency
@ 1997-08-20 22:18 Jim Wilson
0 siblings, 0 replies; 33+ messages in thread
From: Jim Wilson @ 1997-08-20 22:18 UTC (permalink / raw)
To: egcs
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
^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~1997-08-30 19:18 UTC | newest]
Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-08-21 3:05 Ultrasparc addition for sparc.md (fwd) Oleg Krivosheev
1997-08-21 3:05 ` f/runtime/Makefile.in: mclock_.o left out of libU77 Mumit Khan
1997-08-21 4:27 ` fixing the c++/f77 circular dependency Alexandre Oliva
-- strict thread matches above, loose matches on Subject: below --
1997-08-30 12:00 Incorrect i960 linker config Stephen Williams
1997-08-30 19:18 ` fixing the c++/f77 circular dependency Joel Sherrill
1997-08-30 12:00 Stephen Williams
1997-08-25 21:30 Jim Wilson
1997-08-25 21:22 Jim Wilson
1997-08-25 21:28 ` Robert Lipe
1997-08-25 21:16 Joe Buck
1997-08-25 20:59 meissner
1997-08-25 20:41 David Edelsohn
1997-08-25 20:47 ` Robert Lipe
1997-08-25 20:59 ` Jason Merrill
1997-08-25 20:25 Joe Buck
1997-08-25 20:25 H.J. Lu
1997-08-25 20:08 Jim Wilson
1997-08-25 18:48 H.J. Lu
1997-08-25 19:30 ` Olivier Galibert
1997-08-25 18:29 egcs release H.J. Lu
1997-08-25 18:32 ` fixing the c++/f77 circular dependency Jason Merrill
1997-08-24 3:43 Building of generated parser files Jim Meyering
1997-08-24 3:43 ` fixing the c++/f77 circular dependency Jim Wilson
1997-08-22 19:47 H.J. Lu
1997-08-22 19:23 Mike Stump
1997-08-22 19:23 Jim Wilson
1997-08-22 19:23 egcs-ss-970814 on m68k-next-nextstep3 Jeffrey A Law
1997-08-22 19:23 ` fixing the c++/f77 circular dependency Jim Wilson
1997-08-22 17:41 H.J. Lu
1997-08-22 8:36 Andreas Schwab
1997-08-21 18:45 Jim Wilson
1997-08-21 16:51 Problems on PowerPC David Edelsohn
1997-08-21 17:43 ` fixing the c++/f77 circular dependency Dave Love
1997-08-21 17:47 ` Dave Love
1997-08-21 9:21 Problems on PowerPC David McWherter
1997-08-21 9:21 ` fixing the c++/f77 circular dependency Andreas Schwab
1997-08-21 4:52 Doug Evans
1997-08-20 23:19 [REQ] If the x86 people could do something about this John Beppu
1997-08-20 23:19 ` fixing the c++/f77 circular dependency Doug Evans
1997-08-20 22:18 Jim Wilson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).