Re: bootstrap compare failure in ada/targparm.o on i686-pc-linux-gnu?

On Apr 12, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > It looks like it wouldn't be too hard to overcome this problem by > generating the artificial labels in case_index order, instead of in > goto_queue order, but it's not obvious to me that the potential > randomness from sorting of stmt

Re: GCC 4.0 RC1 Available

Geoffrey Keating wrote: [...] > which I see you've already committed a patch for, and a large number > of Java failures. > > You can see full test results at [...] > > > > for 4.0.0-20050410. It might be helpful to put your "libjava.

Re: Bootstrap failure on i686-pc-linux-gnu since 2005-04-09 20:41UTC

The patch has just been submitted to gcc-patches for approval (the tests are nearly done and appear to be passing so far). -- Caroline [EMAIL PROTECTED] On Apr 11, 2005, at 10:12 PM, Kazu Hirata wrote: Hi, I have been getting bootstrap failures on i686-pc-linux-gnu since Caroline's patch http://g

Re: GCC 4.0 RC1 Available

> which I see you've already committed a patch for, and a large number > of Java failures. > > > > for 4.0.0-20050410. Same failure as on Solaris. Andrew, do you have a Darwin machine at hand? -- Eric Botcazou

Bootstrap failure on i686-pc-linux-gnu since 2005-04-09 20:41UTC

Hi, I have been getting bootstrap failures on i686-pc-linux-gnu since Caroline's patch http://gcc.gnu.org/ml/gcc-cvs/2005-04/msg00541.html Errors go like so: org/xml/sax/helpers/ParserAdapter.java: In class 'org.xml.sax.helpers.ParserAdapter': org/xml/sax/helpers/ParserAdapter.java: In const

Re: bootstrap compare failure in ada/targparm.o on i686-pc-linux-gnu?

On Apr 11, 2005, Richard Henderson <[EMAIL PROTECTED]> wrote: > On Mon, Apr 11, 2005 at 05:41:56PM -0300, Alexandre Oliva wrote: >> I take that back. The hash tables seem to be fine. I suspect it's >> the sorting on pointers in the goto_queue that triggers the problem. >> In fact, I'm pretty sur

Re: Mainline build failure on i686-pc-linux-gnu

--prefix=/home/gdr --enable-languages=c++ --disable-nls Thread model: posix gcc version 4.1.0 20050411 (experimental) Blowing away that compiler and using the native compiler (3.3.1) of my system let me complete the build. Whatever problem there was yesterday, it seems to have been fixed. Thanks, -- Gaby

Re: Mainline build failure on i686-pc-linux-gnu

Diego Novillo <[EMAIL PROTECTED]> writes: | On Mon, Apr 11, 2005 at 10:59:46PM -0500, Gabriel Dos Reis wrote: | | >-c /home/gdr/redhat/egcs/gcc/crtstuff.c -DCRT_BEGIN \ | > -o crtbegin.o | > make[1]: *** [crtbegin.o] Aborted | > make[1]: Leaving directory `/home/gdr/build/4.1/gcc' | > make:

RTL code

Can someone tell me if there is a way to generate RTL code which does not include use and def of the same pseudo in the same insn? Of course, I can break every such instruction into two but I am wondering if it is already there or anyone has the code already available. i.e. generate t=p56+p76;

about the parse tree

i want very much to learn more about the parse tree in gcc. but it`s much more complicate than i have thought. can some one show me some way to learn it a little easier, i have tried to debug it, but the structure is difficult to understand, and i can`t find any document about it, except the commen

Re: GCC 4.0 RC1 Available

Marcus Meissner wrote: Btw, We still see some critical 4.0 problems, ordered by my view of importance: PR/20126 triggers a miscompilation of python (i386 and x86_64 at least). PR/20917 triggers a miscompilation of glibc (on s390). PR/20739 triggers a --enable-checking problem triggering in ncurse

Re: GCC 4.0 RC1 Available

Mark Mitchell <[EMAIL PROTECTED]> writes: > The first GCC 4.0 candidate is available ... > Then, if you are running on a primary or secondary platform, please > send me an email pointing me at the results you've posted, and > highlighting any failures to meet the release criteria. Hi Mark, I'm p

Re: Mainline build failure on i686-pc-linux-gnu

On Mon, Apr 11, 2005 at 10:59:46PM -0500, Gabriel Dos Reis wrote: >-c /home/gdr/redhat/egcs/gcc/crtstuff.c -DCRT_BEGIN \ > -o crtbegin.o > make[1]: *** [crtbegin.o] Aborted > make[1]: Leaving directory `/home/gdr/build/4.1/gcc' > make: *** [all-gcc] Error 2 > What's your top-of-ChangeLog?

Re: gcc-3.4-20050401 BUG? generates illegal instruction inX11R6.4.2/mkfontscale/freetypemacro (worksforme)

Clemens Koller wrote: > In the freetype-devel list, I got some suggestions: > This bug/problem seems to concentrate on ppc32/64 and s390 architectures. > Basically all Type1 fonts shipped with X11 are suspect to this > problem. I made tests agains UTBI.pfa > > The possible (temporary)fix: > If

Re: GCC 4.0 RC1 Available

On Sun, Apr 10, 2005 at 03:05:17PM -0700, Mark Mitchell wrote: > The first GCC 4.0 candidate is available from: > > /pub/gcc/prerelease-4.0.0-20050410/ My test results on i686-pc-linux-gnu: http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00812.html All looks good except for the libmudflap f

Mainline build failure on i686-pc-linux-gnu

Build of freshly updated mainline tree fails with: /home/gdr/build/4.1/./gcc/xgcc -B/home/gdr/build/4.1/./gcc/ -B/home/gdr/i686-pc- linux-gnu/bin/ -B/home/gdr/i686-pc-linux-gnu/lib/ -isystem /home/gdr/i686-pc-lin ux-gnu/include -isystem /home/gdr/i686-pc-linux-gnu/sys-include -O2 -DIN_GCC -W

Re: Major bootstrap time regression on March 30

On Fri, 2005-04-08 at 16:36, Daniel Berlin wrote: > Jim works on a machine: Athlon64 3400+, with 1GB main memory, running SuSE 9.1 x86_64-linux.

Re: GCC 4.0 RC1 Available

On 2005-04-11, Julian Brown <[EMAIL PROTECTED]> wrote: > On 2005-04-10, Mark Mitchell <[EMAIL PROTECTED]> wrote: >> >> * The DejaGNU testsuite has been run, and compared with a run of >> the testsuite on the previous release of GCC, and no regressions are >> observed. >> >> If you are willin

Re: GCC 4.0 RC1 Available

On 2005-04-10, Mark Mitchell <[EMAIL PROTECTED]> wrote: > > * The DejaGNU testsuite has been run, and compared with a run of > the testsuite on the previous release of GCC, and no regressions are > observed. > > If you are willing to help, please download the release candidate, build > it o

successful bootstrap/install of GCC 4.0 RC1 on OpenDarwin 7.2.1/x86

The system: === uname -a Darwin localhost 7.2.1 Darwin Kernel Version 7.2.1: Wed Jul 14 03:00:02 PDT 2004; root:tmp/xnu-7.2.1-1-root.obj/RELEASE_I386 x86 i386 gcc -v Reading specs from /usr/libexec/gcc/darwin/i386/3.3/specs Thread model: posix gcc version 3.3 20030304 (Apple Computer, Inc.

Re: GCC 4.0 RC1 Available

Per Bothner wrote: I can no longer build Kawa using the 4.0 branch. Some more information: The failing statement is: Class.forName("kawa.lib.prim_syntax", false, getClass().getClassLoader()); prim_syntax.class exists in the current directory, which is ../../kawa/lib. The program is r

Re: GCC 4.0 RC1 Available

I can no longer build Kawa using the 4.0 branch. This is with a 'cvs update' late last night. Kawa did built last time I tried the 4.0 branch. Unfortunately, I don't know how long ago that was, but it wasn't *that* long ago. The cause appears to failure to find a class in the CLASSPATH. That sug

Re: GCC 4.0 RC1 Available

> There was. We are now, for the first time ever, in a position where > we can run a large number of big Java applications using entirely free > software. Congratulations! > We're in a diffcult position here, because SPARC has few maintainers, > and Java has few maintainers. Frankly, I don't se

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

On Apr 11, 2005, at 4:58 AM, Nathan Sidwell wrote: > Might I refer you to Mike Stump's answer regarding swap :) I haven't seen it. It was basically 'get more memory'. Actually, an expanded version of it would be: If gcc swaps, you're in serious trouble, gcc won't perform very well well when it s

Re: bootstrap compare failure in ada/targparm.o on i686-pc-linux-gnu?

On Mon, Apr 11, 2005 at 05:41:56PM -0300, Alexandre Oliva wrote: > I take that back. The hash tables seem to be fine. I suspect it's > the sorting on pointers in the goto_queue that triggers the problem. > In fact, I'm pretty sure comparing pointers that are not guaranteed to > be in the same arr

Re: bootstrap compare failure in ada/targparm.o on i686-pc-linux-gnu?

On Apr 11, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > On Apr 4, 2005, Richard Henderson <[EMAIL PROTECTED]> wrote: >> On Mon, Apr 04, 2005 at 07:57:09PM -0300, Alexandre Oliva wrote: >>> My head hurts about the GGC implications of opaque pointers in such a >>> hash table, and retaining po

Re: Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0

> Kate Minola writes: Kate> Has anyone had success in building gcc-4.0.0 RC1 on a Kate> powerpc-ibm-aix5.2.0.0 (a primary platform)? Kate> After Kate> configure --enable-languages=c Kate> make bootstrap Kate> I get Kate> : [stuff deleted] Kate> : build/genattrtab /home/kate/gcc-4.0.0-2

Re: Can't build gcc cvs trunk 20050409 gnat tools on sparc-linux: tree check: accessed operand 2 of view_convert_expr with 1 operands in visit_assignment, at tree-ssa-ccp.c:1074

On Apr 11, 2005, at 3:55 PM, Alexandre Oliva wrote: Index: varasm.c === RCS file: /cvs/gcc/gcc/gcc/varasm.c,v retrieving revision 1.495 diff -u -p -d -u -p -d -u -p -r1.495 varasm.c --- varasm.c9 Apr 2005 20:41:49 - 1.495

Re: Can't build gcc cvs trunk 20050409 gnat tools on sparc-linux: tree check: accessed operand 2 of view_convert_expr with 1 operands in visit_assignment, at tree-ssa-ccp.c:1074

On Apr 10, 2005, Andreas Jaeger <[EMAIL PROTECTED]> wrote: > Laurent GUERBY <[EMAIL PROTECTED]> writes: >> stage1/xgcc -Bstage1/ >> -B/home/guerby/work/gcc/install/install-20050410T003153/i686-pc-linux-gnu/bin/ >> -c -O2 -g -fomit-frame-pointer -gnatpg -gnata -I--I. -Iada >> -I/home/guerb

Re: GCC 4.0 RC1 Available

> Please post the list of failures to [EMAIL PROTECTED] http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00671.html -- Eric Botcazou

Re: bootstrap compare failure in ada/targparm.o on i686-pc-linux-gnu?

On Apr 4, 2005, Richard Henderson <[EMAIL PROTECTED]> wrote: > On Mon, Apr 04, 2005 at 07:57:09PM -0300, Alexandre Oliva wrote: >> My head hurts about the GGC implications of opaque pointers in such a >> hash table, and retaining pointers in the hash table that have already >> been otherwise free

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

On Mon, 2005-04-11 at 13:03 -0400, Daniel Jacobowitz wrote: > On Mon, Apr 11, 2005 at 10:02:06AM -0700, Daniel Kegel wrote: > > BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1 > > or so... I still lean on that crutch. > > A user! Can you explain why? Actually, I still use

Re: GCC 4.0 RC1 Available

Btw, We still see some critical 4.0 problems, ordered by my view of importance: PR/20126 triggers a miscompilation of python (i386 and x86_64 at least). PR/20917 triggers a miscompilation of glibc (on s390). PR/20739 triggers a --enable-checking problem triggering in ncurses (all platforms) PR/

Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0

Has anyone had success in building gcc-4.0.0 RC1 on a powerpc-ibm-aix5.2.0.0 (a primary platform)? After configure --enable-languages=c make bootstrap I get : [stuff deleted] : build/genattrtab /home/kate/gcc-4.0.0-20050410/src/gcc-4.0.0-20050410/gcc/config/rs6000/ rs6000.md > tmp-attr

Re: GCC 4.0 RC1 Available

> --- here ---> > checking whether compiler driver understands > Ada... ../src/gcc-4.0.0-20050410/configure: line 2141: break: only > meaningful in a `for', `while', or `until' loop > yes > checking how to compare bootstrapped objects... cmp > --ignore-initial=16 $$f1 $$f2 > ... > looks li

Re: GCC 4.0 RC1 Available

Mark Mitchell <[EMAIL PROTECTED]> writes: > If you are willing to help, please download the release candidate, build > it on appropriate platforms, and post testresults by using > contrib/test_summary. Please use the release candidate itself, *not* > the CVS 4.0 release branch, as part of the goal

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

Daniel Jacobowitz wrote: On Mon, Apr 11, 2005 at 10:02:06AM -0700, Daniel Kegel wrote: BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1 or so... I still lean on that crutch. A user! Can you explain why? Hmm. I just looked, and it seems the only thing I still use it for is

re: GCC Cross Compilation

Vishal Kothari <[EMAIL PROTECTED]> wrote: How can I use GCC for cross compilation? I want to build an application for the EPOC platform. It is for a Psion 5MX device which has an 32-bit RISC-based ARM 710 processor. The application is in C. Is it possible to build the application using GCC for that

GCC Cross Compilation

Hi, How can I use GCC for cross compilation? I want to build an application for the EPOC platform. It is for a Psion 5MX device which has an 32-bit RISC-based ARM 710 processor. The application is in C. Is it possible to build the application using GCC for that platform? -- Regards, Vishal Kotha

Re: GCC 4.0 RC1 Available

On Apr 11, 2005, at 1:04 PM, Jakub Jelinek wrote: On Sun, Apr 10, 2005 at 03:05:17PM -0700, Mark Mitchell wrote: The first GCC 4.0 candidate is available from: /pub/gcc/prerelease-4.0.0-20050410/ on the usual gcc.gnu.org mirrors: http://gcc.gnu.org/mirrors.html I would like to know whether or not w

Re: GCC 4.0 RC1 Available

Jakub Jelinek wrote: On Sun, Apr 10, 2005 at 03:05:17PM -0700, Mark Mitchell wrote: The first GCC 4.0 candidate is available from: /pub/gcc/prerelease-4.0.0-20050410/ on the usual gcc.gnu.org mirrors: http://gcc.gnu.org/mirrors.html I would like to know whether or not we have achieved the objective

Re: GCC 4.0 RC1 Available

On Sun, Apr 10, 2005 at 03:05:17PM -0700, Mark Mitchell wrote: > The first GCC 4.0 candidate is available from: > > /pub/gcc/prerelease-4.0.0-20050410/ > > on the usual gcc.gnu.org mirrors: > > http://gcc.gnu.org/mirrors.html > > I would like to know whether or not we have achieved the objectiv

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

On Mon, Apr 11, 2005 at 10:02:06AM -0700, Daniel Kegel wrote: > BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1 > or so... I still lean on that crutch. A user! Can you explain why? -- Daniel Jacobowitz CodeSourcery, LLC

RE: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

"Rupert Wood" <[EMAIL PROTECTED]> wrote: I have a problem with getting rid of -fno-unit-at-a-time. Sometimes we compile huge Java programs; however, keeping all the method bodies consumes vast amouts of memory. AFAICT, MSVC solves this by generating some of the code when it reaches some memory li

Re: GCC 4.0 RC1 Available

On Sun, Apr 10, 2005 at 03:05:17PM -0700, Mark Mitchell wrote: > The first GCC 4.0 candidate is available from: > > /pub/gcc/prerelease-4.0.0-20050410/ My first build result is at http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00742.html However, the system info is wrong due to my error; it i

Re: GCC 4.0 RC1 Available

Andrew Haley wrote: We're in a diffcult position here, because SPARC has few maintainers, and Java has few maintainers. However, if you can let me have a logon I can have a look. That would be much appreciated. Java isn't release-critical, but it still seems like it would be nice to understand w

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

Marcin Dalecki writes: > > On 2005-04-11, at 14:01, Andrew Haley wrote: > > > Nathan Sidwell writes: > >> Andrew Haley wrote: > >>> Nathan Sidwell writes: > Andrew Haley wrote: > > > Might it still be possible for a front end to force all pending > > code > > to

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

On 2005-04-11, at 14:01, Andrew Haley wrote: Nathan Sidwell writes: Andrew Haley wrote: Nathan Sidwell writes: Andrew Haley wrote: Might it still be possible for a front end to force all pending code to be generated, even with -fno-unit-at-a-time gone? I think this is a bad idea. You're essential

Re: GCC 4.0 RC1 Available

Mark Mitchell wrote: The first GCC 4.0 candidate is available from: ... a minor issue with the configure script: ... checking whether gcc-3.4 accepts -g... yes checking for gnatbind... gnatbind --- here ---> checking whether compiler driver understands Ada... ../src/gcc-4.0.0-20050410/configure: l

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

On Apr 11, 2005 2:01 PM, Andrew Haley <[EMAIL PROTECTED]> wrote: > Nathan Sidwell writes: > > Andrew Haley wrote: > > > Nathan Sidwell writes: > > > > Andrew Haley wrote: > > > > > > > > > Might it still be possible for a front end to force all pending code > > > > > to be generated, even

Re: GCC 4.0 RC1 Available

Eric Botcazou writes: > > Tom, I presume there was a very good reason for installing such a > potentially > destabilizing patch a few days before the prerelease? In defence of my fellow maintainer: There was. We are now, for the first time ever, in a position where we can run a large nu

Re: reload-branch created

I guess the best solution is to change the place you modified, but to use a test that checks for autoinc codes. I'll come up with something. Try this. Bernd * reload.c (find_reloads): Only set INC field if we know we have an autoinc reload. * reload.h (struct reload): Update comment to match.

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

Nathan Sidwell writes: > Andrew Haley wrote: > > Nathan Sidwell writes: > > > > 1) The C++ programs are smaller than the java programs > > > > That's my guess. Usually, C++ users compile one source file at a > > time, whereas Java users find it convenient to compile a whole > > archive.

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

Andrew Haley <[EMAIL PROTECTED]> writes: > That's my guess. Usually, C++ users compile one source file at a > time, Unless you use --enable-final in KDE. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

Andrew Haley wrote: Nathan Sidwell writes: > 1) The C++ programs are smaller than the java programs That's my guess. Usually, C++ users compile one source file at a time, whereas Java users find it convenient to compile a whole archive. ok, thanks. This sounds like you're really in an IMA mode

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

Nathan Sidwell <[EMAIL PROTECTED]> writes: | Andrew Haley wrote: | > Nathan Sidwell writes: | > > Andrew Haley wrote: | > > > > Might it still be possible for a front end to force all | > pending code | > > > to be generated, even with -fno-unit-at-a-time gone? | > > > I think this is a bad

RE: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

Just as another idea - Steven Bosscher wrote: > (The proper solution is of course to have an IR that we can stream > to disk, *sigh* ;-) AFAICT, MSVC solves this by generating some of the code when it reaches some memory limit. So when GCC is under some memory pressure it could identify functio

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

Nathan Sidwell writes: > Andrew Haley wrote: > > Nathan Sidwell writes: > > > Andrew Haley wrote: > > > > > > > Might it still be possible for a front end to force all pending code > > > > to be generated, even with -fno-unit-at-a-time gone? > > > > > > I think this is a bad idea.

Re: gcc-3.4-20050401 BUG? generates illegal instruction in X11R6.4.2/mkfontscale/freetypemacro (worksforme)

Hello again! In the freetype-devel list, I got some suggestions: This bug/problem seems to concentrate on ppc32/64 and s390 architectures. Basically all Type1 fonts shipped with X11 are suspect to this problem. I made tests agains UTBI.pfa The possible (temporary)fix: If I re-compile freetype w

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

Andrew Haley wrote: Nathan Sidwell writes: > Andrew Haley wrote: > > > Might it still be possible for a front end to force all pending code > > to be generated, even with -fno-unit-at-a-time gone? > > I think this is a bad idea. You're essentially asking for the backend > to retain all th

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

Nathan Sidwell writes: > Andrew Haley wrote: > > > Might it still be possible for a front end to force all pending code > > to be generated, even with -fno-unit-at-a-time gone? > > I think this is a bad idea. You're essentially asking for the backend > to retain all the functionality of -

Re: reload-branch created

Ulrich Weigand wrote: - As mentioned in http://gcc.gnu.org/ml/gcc/2005-01/msg00911.html there is a code path in find_reloads that sets rld[].inc to a nonzero value even for a platform that doesn't actually *have* pre-/post-increment insns, leading to an ICE later on. Index: gcc/reload.c

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

Nathan Sidwell <[EMAIL PROTECTED]> writes: | Andrew Haley wrote: | | > Might it still be possible for a front end to force all pending code | > to be generated, even with -fno-unit-at-a-time gone? | | I think this is a bad idea. You're essentially asking for the backend | to retain all the func

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

Andrew Haley wrote on 11/04/2005 13:31:52: > Steven Bosscher writes: > > > > This is what C++ does now too. Why would this be a problem > > for Java but not for C++? > > I don't know why it's not a problem for C++; I do know why it's a > problem for Java. Perhaps the files we're compiling

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

Andrew Haley wrote: Might it still be possible for a front end to force all pending code to be generated, even with -fno-unit-at-a-time gone? I think this is a bad idea. You're essentially asking for the backend to retain all the functionality of -fno-unit-at-a-time. Might I refer you to Mike Stum

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

Steven Bosscher writes: > On Monday 11 April 2005 12:18, Andrew Haley wrote: > > Mark Mitchell writes: > > > Your primary objective (get rid of -fno-unit-at-a-time) is one that I > > > strongly support. > > > > I have a problem with getting rid of -fno-unit-at-a-time. Sometimes > > we com

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

On Monday 11 April 2005 12:18, Andrew Haley wrote: > Mark Mitchell writes: > > Your primary objective (get rid of -fno-unit-at-a-time) is one that I > > strongly support. > > I have a problem with getting rid of -fno-unit-at-a-time. Sometimes > we compile huge Java programs; however, keeping all

Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

Mark Mitchell writes: > Your primary objective (get rid of -fno-unit-at-a-time) is one that I > strongly support. I have a problem with getting rid of -fno-unit-at-a-time. Sometimes we compile huge Java programs; however, keeping all the method bodies consumes vast amouts of memory. So, we so

Re: GCC 4.0 RC1 Available

Eric Botcazou writes: > > > We severely regressed for Java (22*2 new failures) 3 days ago. Please post the list of failures to [EMAIL PROTECTED] Andrew.

Re: GCC 4.0 RC1 Available

> We severely regressed for Java (22*2 new failures) 3 days ago. Ugh. Not very surprising, given that a jumbo patch landed by that time: 2005-04-06 Tom Tromey <[EMAIL PROTECTED]> * Makefile.in: Rebuilt. * Makefile.am (lib_gnu_java_awt_peer_gtk_la_SOURCES): Removed gtk_