build problem...
I assume I'm not the only one seeing this build failure: make[5]: Entering directory `/build/gcc/2006-06-15/i686-pc-linux-gnu/libjava/classpath/tools' /bin/sh ../libtool --mode=link /build/gcc/2006-06-15/./gcc/xgcc -B/build/gcc/2006-06-15/./gcc/ -B/install/gcc/i686-pc-linux-gnu/bin/ -B/install/gcc/i686-pc-linux-gnu/lib/ -isystem /install/gcc/i686-pc-linux-gnu/include -isystem /install/gcc/i686-pc-linux-gnu/sys-include -O2 -g -O2-o gappletviewer -L/install/gcc/lib -lgcj gappletviewer-toolwrapper.o /build/gcc/2006-06-15/./gcc/xgcc -B/build/gcc/2006-06-15/./gcc/ -B/install/gcc/i686-pc-linux-gnu/bin/ -B/install/gcc/i686-pc-linux-gnu/lib/ -isystem /install/gcc/i686-pc-linux-gnu/include -isystem /install/gcc/i686-pc-linux-gnu/sys-include -O2 -g -O2 -o gappletviewer gappletviewer-toolwrapper.o -L/install/gcc/lib -lgcj /usr/bin/ld: cannot find -lgcj collect2: ld returned 1 exit status make[5]: *** [gappletviewer] Error 1 make[5]: Leaving directory `/build/gcc/2006-06-15/i686-pc-linux-gnu/libjava/classpath/tools' make[4]: *** [all] Error 2 make[4]: Leaving directory `/build/gcc/2006-06-15/i686-pc-linux-gnu/libjava/classpath/tools' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/build/gcc/2006-06-15/i686-pc-linux-gnu/libjava/classpath' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/build/gcc/2006-06-15/i686-pc-linux-gnu/libjava' make[1]: *** [all-target-libjava] Error 2 make[1]: Leaving directory `/build/gcc/2006-06-15' make: *** [all] Error 2 The same failure existed yesterday... Is a fix under way? this is stock mainline with no configuration options except --prefix=install/gcc Andrew
Re: build problem...
On Thu, 2006-06-15 at 14:14 -0400, Andrew MacLeod wrote: > I assume I'm not the only one seeing this build failure: > > > make[5]: Entering directory > `/build/gcc/2006-06-15/i686-pc-linux-gnu/libjava/classpath/tools' > /bin/sh ../libtool --mode=link /build/gcc/2006-06-15/./gcc/xgcc > -B/build/gcc/2006-06-15/./gcc/ -B/install/gcc/i686-pc-linux-gnu/bin/ > -B/install/gcc/i686-pc-linux-gnu/lib/ -isystem > /install/gcc/i686-pc-linux-gnu/include -isystem > /install/gcc/i686-pc-linux-gnu/sys-include -O2 -g -O2-o gappletviewer > -L/install/gcc/lib -lgcj gappletviewer-toolwrapper.o > /build/gcc/2006-06-15/./gcc/xgcc -B/build/gcc/2006-06-15/./gcc/ > -B/install/gcc/i686-pc-linux-gnu/bin/ -B/install/gcc/i686-pc-linux-gnu/lib/ > -isystem /install/gcc/i686-pc-linux-gnu/include -isystem > /install/gcc/i686-pc-linux-gnu/sys-include -O2 -g -O2 -o gappletviewer > gappletviewer-toolwrapper.o -L/install/gcc/lib -lgcj > /usr/bin/ld: cannot find -lgcj > collect2: ld returned 1 exit status > make[5]: *** [gappletviewer] Error 1 Thank you Tom.. :-) Andrew
Re: build problem...
On Thu, 2006-06-15 at 15:59 -0400, Thomas Fitzsimmons wrote: > Andrew MacLeod wrote: > > On Thu, 2006-06-15 at 14:14 -0400, Andrew MacLeod wrote: > >> I assume I'm not the only one seeing this build failure: > >> > >> > >> make[5]: Entering directory > >> `/build/gcc/2006-06-15/i686-pc-linux-gnu/libjava/classpath/tools' > >> /bin/sh ../libtool --mode=link /build/gcc/2006-06-15/./gcc/xgcc > >> -B/build/gcc/2006-06-15/./gcc/ -B/install/gcc/i686-pc-linux-gnu/bin/ > >> -B/install/gcc/i686-pc-linux-gnu/lib/ -isystem > >> /install/gcc/i686-pc-linux-gnu/include -isystem > >> /install/gcc/i686-pc-linux-gnu/sys-include -O2 -g -O2-o gappletviewer > >> -L/install/gcc/lib -lgcj gappletviewer-toolwrapper.o > >> /build/gcc/2006-06-15/./gcc/xgcc -B/build/gcc/2006-06-15/./gcc/ > >> -B/install/gcc/i686-pc-linux-gnu/bin/ > >> -B/install/gcc/i686-pc-linux-gnu/lib/ -isystem > >> /install/gcc/i686-pc-linux-gnu/include -isystem > >> /install/gcc/i686-pc-linux-gnu/sys-include -O2 -g -O2 -o gappletviewer > >> gappletviewer-toolwrapper.o -L/install/gcc/lib -lgcj > >> /usr/bin/ld: cannot find -lgcj > >> collect2: ld returned 1 exit status > >> make[5]: *** [gappletviewer] Error 1 > > > > Thank you Tom.. :-) > > :-( > > This patch of mine: <...> > caused a bootstrap failure on multilib architectures. A clean bootstrap did > work for me on my x86 workstation, but I hadn't cleared out $prefix. I have > a > suspicion that the libjava configury reaches into $prefix during the > bootstrap. > In the future I'll be sure to clear $prefix before bootstrapping, and I'll > also bootstrap on a multilib architecture (x86-64). > > Sorry for the inconvenience. For now I've reverted the part of the patch > that > was causing the failure. Actually, I just meant 'thank you' for fixing it so quickly after the note :-)
more build failures...
On mainline, when building with no checking enabled, the stage 2 compiler is segfaulting when building crtbegin.o : make[3]: Entering directory `/build/gcc/out-branchpoint-nc/gcc' /build/gcc/out-branchpoint-nc/./gcc/xgcc -B/build/gcc/out-branchpoint-nc/./gcc/ -B/install/gcc-nc/i686-pc-linux-gnu/bin/ -B/install/gcc-nc/i686-pc-linux-gnu/lib/ -isystem /install/gcc-nc/i686-pc-linux-gnu/include -isystem /install/gcc-nc/i686-pc-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I/src/gcc/out-branchpoint/gcc/gcc -I/src/gcc/out-branchpoint/gcc/gcc/. -I/src/gcc/out-branchpoint/gcc/gcc/../include -I/src/gcc/out-branchpoint/gcc/gcc/../libcpp/include -I/src/gcc/out-branchpoint/gcc/gcc/../libdecnumber -I../libdecnumber -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-omit-frame-pointer \ -c /src/gcc/out-branchpoint/gcc/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o xgcc: Internal error: Segmentation fault (program cc1) Please submit a full bug report. See http://gcc.gnu.org/bugs.html> for instructions. make[3]: *** [crtbegin.o] Error 1 the traceback, for what its worth (since something in stage 2 has been miscompiled): (gdb) where #0 bitmap_ior_into (a=0x85ac228, b=0x85ac2fc) at /src/gcc/out-branchpoint/gcc/gcc/bitmap.c:1201 #1 0x080bd34c in insert_updated_phi_nodes_for (var=0xb7be8738, dfs=0x8590300, blocks=0x85ac228, update_flags=128) at /src/gcc/out-branchpoint/gcc/gcc/tree-into-ssa.c:2599 #2 0x080be9ab in update_ssa (update_flags=128) at /src/gcc/out-branchpoint/gcc/gcc/tree-into-ssa.c:2884 #3 0x0832c51d in execute_todo (flags=Variable "flags" is not available. ) at /src/gcc/out-branchpoint/gcc/gcc/passes.c:748 #4 0x0832c84c in execute_one_pass (pass=0x84d02c0) This was from yesterday afternoon, no special configuration other than to disable checking, on i686-pc-linux-gnu on an FC4 box. Is this a known problem? Andrew
Re: more build failures...
On Fri, 2006-06-16 at 10:45 -0400, Andrew MacLeod wrote: > On mainline, when building with no checking enabled, the stage 2 > compiler is segfaulting when building crtbegin.o : > > > make[3]: Entering directory `/build/gcc/out-branchpoint-nc/gcc' > /build/gcc/out-branchpoint-nc/./gcc/xgcc > -B/build/gcc/out-branchpoint-nc/./gcc/ > -B/install/gcc-nc/i686-pc-linux-gnu/bin/ > -B/install/gcc-nc/i686-pc-linux-gnu/lib/ -isystem > /install/gcc-nc/i686-pc-linux-gnu/include -isystem > /install/gcc-nc/i686-pc-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC-W > -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes > -Wold-style-definition -isystem ./include -I. -I. > -I/src/gcc/out-branchpoint/gcc/gcc -I/src/gcc/out-branchpoint/gcc/gcc/. > -I/src/gcc/out-branchpoint/gcc/gcc/../include > -I/src/gcc/out-branchpoint/gcc/gcc/../libcpp/include > -I/src/gcc/out-branchpoint/gcc/gcc/../libdecnumber -I../libdecnumber -g0 > -finhibit-size-directive -fno-inline-functions -fno-exceptions > -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-omit-frame-pointer \ > -c /src/gcc/out-branchpoint/gcc/gcc/crtstuff.c -DCRT_BEGIN \ > -o crtbegin.o > xgcc: Internal error: Segmentation fault (program cc1) > Please submit a full bug report. > See http://gcc.gnu.org/bugs.html> for instructions. > make[3]: *** [crtbegin.o] Error 1 Never mind, Its seems to have disappeared since then, the latest checkout works fine... Andrew
Mainline build problem on FC4
OK, so I wasn't just wacko last week. Mainline fails to build on Fedora Core 4 (with all the latest updates, kernel 2111) when built with checking disabled. Diego verified this on a second FC4 box. The compile fails when building crtfastmath during stage2. It doesn't happen when checking is enabled, nor does it happen on FC5 under any circumstance I have found. /build/gcc/2006-06-19-nc/./gcc/xgcc -B/build/gcc/2006-06-19-nc/./gcc/ -B/install/gcc-nc/i686-pc-linux-gnu/bin/ -B/install/gcc-nc/i686-pc-linux-gnu/lib/ -isystem /install/gcc-nc/i686-pc-linux-gnu/include -isystem /install/gcc-nc/i686-pc-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -msse -c \ /src/gcc/2006-06-19/gcc/gcc/config/i386/crtfastmath.c \ -o crtfastmath.o /bin/sh /src/gcc/2006-06-19/gcc/gcc/../move-if-change tmp-macro_list macro_list *** glibc detected *** /build/gcc/2006-06-19-nc/./gcc/cc1: malloc(): memory corruption: 0x08591630 *** === Backtrace: = /lib/libc.so.6[0x5ee1a2] /lib/libc.so.6(malloc+0x74)[0x5ef587] /lib/libc.so.6[0x5af193] /lib/libc.so.6[0x5ad498] /lib/libc.so.6[0x5ace25] /lib/libc.so.6(__dcgettext+0x43)[0x5abed7] /lib/libc.so.6(strsignal+0x13c)[0x5f4a13] /build/gcc/2006-06-19-nc/./gcc/cc1[0x830e5b2] === Memory map: 0055d000-0055e000 r-xp 0055d000 00:00 0 [vdso] 0055e000-00578000 r-xp fd:00 5499650/lib/ld-2.3.6.so 00578000-00579000 r-xp 00019000 fd:00 5499650/lib/ld-2.3.6.so 00579000-0057a000 rwxp 0001a000 fd:00 5499650/lib/ld-2.3.6.so 0058a000-006ad000 r-xp fd:00 5499657/lib/libc-2.3.6.so 006ad000-006af000 r-xp 00122000 fd:00 5499657/lib/libc-2.3.6.so 006af000-006b1000 rwxp 00124000 fd:00 5499657/lib/libc-2.3.6.so 006b1000-006b3000 rwxp 006b1000 00:00 0 00a29000-00a33000 r-xp fd:00 16893261 /build/gcc/2006-06-19-nc/prev-gcc/libgcc_s.so.1 00a33000-00a34000 rwxp 9000 fd:00 16893261 /build/gcc/2006-06-19-nc/prev-gcc/libgcc_s.so.1 08048000-084cf000 r-xp fd:00 16926839 /build/gcc/2006-06-19-nc/gcc/cc1 084cf000-084d4000 rw-p 00486000 fd:00 16926839 /build/gcc/2006-06-19-nc/gcc/cc1 084d4000-085a rw-p 084d4000 00:00 0 [heap] b7b0-b7b21000 rw-p b7b0 00:00 0 b7b21000-b7c0 ---p b7b21000 00:00 0 b7c87000-b7dd8000 rw-p b7c87000 00:00 0 b7dd8000-b7fd8000 r--p fd:00 201117 /usr/lib/locale/locale-archive b7fd8000-b7fd9000 rw-p b7fd8000 00:00 0 b7ffe000-b800 rw-p b7ffe000 00:00 0 bffe8000-b000 rw-p bffe8000 00:00 0 [stack] xgcc: Internal error: Segmentation fault (program cc1) Please submit a full bug report. See http://gcc.gnu.org/bugs.html> for instructions. make[3]: *** [crtfastmath.o] Error 1 make[3]: *** Waiting for unfinished jobs echo timestamp > s-macro_list make[3]: *** Waiting for unfinished jobs rm fsf-funding.pod gcov.pod gfdl.pod cpp.pod gpl.pod gcc.pod make[3]: Leaving directory `/build/gcc/2006-06-19-nc/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/build/gcc/2006-06-19-nc' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/build/gcc/2006-06-19-nc' make: *** [all] Error 2 Has anyone else encountered this? I'm checking back to see when/if this suddenly appeared. It also happens with a much earlier version of the kernel. If I recall from my poking around earlier last week, bitmap.o get miscompiled in stage1, but take that with a grain of salt.. a lot of things were going on last week and I don't know if that is still true today. Andrew
Re: Mainline build problem on FC4
On Mon, 2006-06-19 at 12:31 -0400, Andrew MacLeod wrote: > OK, so I wasn't just wacko last week. Mainline fails to build on Fedora > Core 4 (with all the latest updates, kernel 2111) when built with > checking disabled. Diego verified this on a second FC4 box. > I've narrowed this down to the patch in revision 114674. (114673 works fine, 114674 exhibits the problem) r114674 | rakdver | 2006-06-15 05:42:03 -0400 (Thu, 15 Jun 2006) | 10 lines * tree-ssa-loop-niter.c (implies_nonnegative_p): New function. (derive_constant_upper_bound): Derive more precise upper bound in common cases. Return type changed to double_int. (record_estimate): Reflect the changed return type of derive_constant_upper_bound. * double-int.c (double_int_zext, double_int_sext): Fix. * gcc.dg/tree-ssa/loop-18.c: New test. bitmap.o in stage 2 is miscompiled by the stage 1 compiler. If I replace bitmap.o with the bitmap.o produced by the stage 2 compiler from rev. 114673, everything proceeds and we get a failure in stage3. Thats as far as I've gotten today. Andrew PS. The only configure options are --enable-languages=c,c++ --disable-checking > The compile fails when building crtfastmath during stage2. > > It doesn't happen when checking is enabled, nor does it happen on FC5 > under any circumstance I have found. > > > /build/gcc/2006-06-19-nc/./gcc/xgcc -B/build/gcc/2006-06-19-nc/./gcc/ > -B/install/gcc-nc/i686-pc-linux-gnu/bin/ > -B/install/gcc-nc/i686-pc-linux-gnu/lib/ -isystem > /install/gcc-nc/i686-pc-linux-gnu/include -isystem > /install/gcc-nc/i686-pc-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC-W > -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes > -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT > -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -msse -c \ > /src/gcc/2006-06-19/gcc/gcc/config/i386/crtfastmath.c \ > -o crtfastmath.o > /bin/sh /src/gcc/2006-06-19/gcc/gcc/../move-if-change tmp-macro_list > macro_list > *** glibc detected *** /build/gcc/2006-06-19-nc/./gcc/cc1: malloc(): memory > corruption: 0x08591630 *** > === Backtrace: = > /lib/libc.so.6[0x5ee1a2] > /lib/libc.so.6(malloc+0x74)[0x5ef587] > /lib/libc.so.6[0x5af193] > /lib/libc.so.6[0x5ad498] > /lib/libc.so.6[0x5ace25] > /lib/libc.so.6(__dcgettext+0x43)[0x5abed7] > /lib/libc.so.6(strsignal+0x13c)[0x5f4a13] > /build/gcc/2006-06-19-nc/./gcc/cc1[0x830e5b2] > === Memory map: > 0055d000-0055e000 r-xp 0055d000 00:00 0 [vdso] > 0055e000-00578000 r-xp fd:00 5499650/lib/ld-2.3.6.so > 00578000-00579000 r-xp 00019000 fd:00 5499650/lib/ld-2.3.6.so > 00579000-0057a000 rwxp 0001a000 fd:00 5499650/lib/ld-2.3.6.so > 0058a000-006ad000 r-xp fd:00 5499657/lib/libc-2.3.6.so > 006ad000-006af000 r-xp 00122000 fd:00 5499657/lib/libc-2.3.6.so > 006af000-006b1000 rwxp 00124000 fd:00 5499657/lib/libc-2.3.6.so > 006b1000-006b3000 rwxp 006b1000 00:00 0 > 00a29000-00a33000 r-xp fd:00 16893261 > /build/gcc/2006-06-19-nc/prev-gcc/libgcc_s.so.1 > 00a33000-00a34000 rwxp 9000 fd:00 16893261 > /build/gcc/2006-06-19-nc/prev-gcc/libgcc_s.so.1 > 08048000-084cf000 r-xp fd:00 16926839 > /build/gcc/2006-06-19-nc/gcc/cc1 > 084cf000-084d4000 rw-p 00486000 fd:00 16926839 > /build/gcc/2006-06-19-nc/gcc/cc1 > 084d4000-085a rw-p 084d4000 00:00 0 [heap] > b7b0-b7b21000 rw-p b7b0 00:00 0 > b7b21000-b7c0 ---p b7b21000 00:00 0 > b7c87000-b7dd8000 rw-p b7c87000 00:00 0 > b7dd8000-b7fd8000 r--p fd:00 201117 > /usr/lib/locale/locale-archive > b7fd8000-b7fd9000 rw-p b7fd8000 00:00 0 > b7ffe000-b800 rw-p b7ffe000 00:00 0 > bffe8000-b000 rw-p bffe8000 00:00 0 [stack] > xgcc: Internal error: Segmentation fault (program cc1) > Please submit a full bug report. > See http://gcc.gnu.org/bugs.html> for instructions. > make[3]: *** [crtfastmath.o] Error 1 > make[3]: *** Waiting for unfinished jobs > echo timestamp > s-macro_list > make[3]: *** Waiting for unfinished jobs > rm fsf-funding.pod gcov.pod gfdl.pod cpp.pod gpl.pod gcc.pod > make[3]: Leaving directory `/build/gcc/2006-06-19-nc/gcc' > make[2]: *** [all-stage2-gcc] Error 2 > make[2]: Leaving directory `/build/gcc/2006-06-19-nc' > make[1]: *** [stage2-bubble] Error 2 > make[1]: Leaving directory `/build/gcc/2006-06-19-nc' > make: *** [all] Error 2 > > > > Has anyone else encountered this? I'm checking back to see when/if this > suddenly appeared. It also happens with a much earlier version of the > kernel. If I recall from my poking around earlier last week, bitmap.o > get miscompiled in stage1, but take that with a grain of salt.. a lot of > things were going on last week and I don't know if that is still true > today. > > Andrew >
Re: Mainline build problem on FC4
On Tue, 2006-06-20 at 09:48 +0200, Zdenek Dvorak wrote: > Hello, > does this still fail? I have fixed one misscompilation due to this > patch yesterday: > > 2006-06-19 Zdenek Dvorak <[EMAIL PROTECTED]> > > * tree-ssa-loop-niter.c (implies_ge_p): New function. > (derive_constant_upper_bound): Handle OP0 - CST in unsigned types > correctly. I'm building now, and I'll let you know. Lets hope so :-) Andrew
Re: Mainline build problem on FC4
On Tue, 2006-06-20 at 08:44 -0400, Andrew MacLeod wrote: > On Tue, 2006-06-20 at 09:48 +0200, Zdenek Dvorak wrote: > > Hello, > > > does this still fail? I have fixed one misscompilation due to this > > patch yesterday: > > > > 2006-06-19 Zdenek Dvorak <[EMAIL PROTECTED]> > > > > * tree-ssa-loop-niter.c (implies_ge_p): New function. > > (derive_constant_upper_bound): Handle OP0 - CST in unsigned types > > correctly. > > I'm building now, and I'll let you know. Lets hope so :-) Indeed, that does resolve the problem. Thanks Andrew
Re: Another NaT bit propagation bug.
>> On Fri, Nov 09, 2001 at 08:54:27AM -0800, Andrew Macleod wrote: >> > I couldn't find a decent/logical place to put the 2 routines >> > that are currently in toplev.c... suggestions? >> >> life.c? OK, I can create it. >> >> I also think you'll get better results if you place the >> initialization in the same block as the sets. Make sure >> to update the LOG_LINKS if you run this after regular >> life analysis. Well, we can kinda do that, but we need to use more infrastructure. We'd have to make sure that the first use we've found isn't also fed by some other definition, ie its in a loop. So we can't always insert it in that block, but we could insert it at the end of a block which dominates it. I took the cheap method of inserting it right at the beginning. Its doesn't come into play often, and I was hoping since its a set of 0, that any inefficiencies might be taken care of by another optimization. I suppose we could go build and use dominators at -O3 and get the set closer... What we really need to know is exactly what sets feed the use. If the block with the first use dominates all other sets, then we could insert the set right in front of the insn. Otherwise we'd have to set it at the end of the block which dominates the first use and all the other sets. Anyway, thats the logic I used to insert it at the beginning. Should I change that? Or is this sufficient for now? >> > We can use the flag to selectivly turn on the optimization just >> > for the targets we care about. >> >> As I demonstrated, I think _all_ targets will likely want this. Ok, I'll simply remove the flag. Here's the patch as it stands now: * Makefile.in (OBJS, life.o): Add life.c object and dependancies. * rtl.h (initialize_uninitialized_subregs): New prototype. * toplev.c (rest_of_compilation): Call initialize_uninitialized_subregs when optimization is on. * life.c (find_regno_partial, initialize_uninitialized_subregs): New file and functions. Index: gcc/Makefile.in === RCS file: /cvs/gcc/egcs/gcc/Makefile.in,v retrieving revision 1.757 diff -c -p -r1.757 Makefile.in *** Makefile.in 2001/10/21 16:29:12 1.757 --- Makefile.in 2001/11/14 19:45:33 *** C_OBJS = c-parse.o c-lang.o $(C_AND_OBJC *** 733,755 # Language-independent object files. ! OBJS =\ ! alias.o bb-reorder.o bitmap.o builtins.o caller-save.o calls.o \ ! combine.o conflict.o convert.o cse.o cselib.o dbxout.o debug.o \ ! dependence.o df.o diagnostic.o doloop.o dominance.o dwarf2asm.o \ ! dwarf2out.o dwarfout.o emit-rtl.o except.o explow.o expmed.o expr.o \ ! final.o flow.o fold-const.o function.o gcse.o genrtl.o ggc-common.o \ ! global.o graph.o haifa-sched.o hash.o hashtable.o ifcvt.o\ ! insn-attrtab.o insn-emit.o insn-extract.o insn-opinit.o insn-output.o\ ! insn-peep.o insn-recog.o integrate.o intl.o jump.o lcm.o lists.o \ ! local-alloc.o loop.o mbchar.o optabs.o params.o predict.o print-rtl.o\ ! print-tree.o profile.o real.o recog.o reg-stack.o regclass.o regmove.o \ ! regrename.o reload.o reload1.o reorg.o resource.o rtl.o rtlanal.o\ ! rtl-error.o sbitmap.o sched-deps.o sched-ebb.o sched-rgn.o sched-vis.o \ ! sdbout.o sibcall.o simplify-rtx.o splay-tree.o ssa.o ssa-ccp.o \ ! ssa-dce.o stmt.o stor-layout.o stringpool.o timevar.o toplev.o tree.o \ ! unroll.o varasm.o varray.o version.o xcoffout.o cfg.o cfganal.o \ ! cfgbuild.o cfgcleanup.o cfgloop.o cfgrtl.o tree-inline.o langhooks.o \ $(GGC) $(out_object_file) $(EXTRA_OBJS) BACKEND = main.o libbackend.a --- 733,755 # Language-independent object files. ! OBJS = \ ! alias.o bb-reorder.o bitmap.o builtins.o caller-save.o calls.o\ ! combine.o conflict.o convert.o cse.o cselib.o dbxout.o debug.o\ ! dependence.o df.o diagnostic.o doloop.o dominance.o dwarf2asm.o \ ! dwarf2out.o dwarfout.o emit-rtl.o except.o explow.o expmed.o expr.o \ ! final.o flow.o fold-const.o function.o gcse.o genrtl.o ggc-common.o \ ! global.o graph.o haifa-sched.o hash.o hashtable.o ifcvt.o \ ! insn-attrtab.o insn-emit.o insn-extract.o insn-opinit.o insn-output.o \ ! insn-peep.o insn-recog.o integrate.o intl.o jump.o lcm.o life.o lists.o \ ! local-alloc.o loop.o mbchar.o optabs.o params.o predict.o print-rtl.o \ ! print-tree.o profile.o real.o recog.o reg-stack.o regclass.o regmove.o\ ! regrename.o reload.o reload1.o reorg.o resource.o rtl.o rtlanal.o \ ! rtl-error.o sbitmap.o sched-d
