Re: bootstrap broken on ppc-linux

Zack Weinberg wrote: This is close to obvious and should fix bootstrap, but I am hesitant to call anything about vec.h obvious. Nathan cc:ed. The vec patch looks ok. I see there's a duplicated line, + VEC_BASE (*vec_)->num = size_; \ + VEC_BASE (*vec_)

Re: bootstrap failure for Ada gcc 4.1 Revision 110108 on

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John David Anglin schrieb: >>> gnat1: out of memory allocating 19028192 bytes after a total of 92324 bytes >>> gmake[2]: *** [ada/ada.o] Error 1 > > My guess is that this is a problem with the bootstrap compiler. There > is a known issue with all 3.3

Re: [HELP] GCC 4.1 branch Ada status on powerpc-darwin?

> I'm not sure we'd be willing to trade minimal dependencies for "future binary > compatibility", but I see your point. I'll let Arnaud decide. Well if you ask me, I'd rather not put anything special for Darwin. Failing that, I'd rather see a very minimal change. Having systematically a depende

Re: Mainline bootstrap failure (revision 110017)

Hello, > On Fri, 20 Jan 2006, Zdenek Dvorak wrote: > > I propose the following workaround instead, that also restores > > bootstrap. It changes the way loop-iv uses df to more conservative one, > > that does not seem to cause problems. > > That's what I like to see... options. Yes, this is OK f

Regarding gcc Makefile.in

Hi, I am a newbie for GCC internals.Actually i want to build the GCC (say it compile the GCC).Now during this i want to study the build process of it. Can you please guide me how can i step ahead and can you give me an idea that how can i read through the Makefile.in which seems to be quite complic

Re: Mainline bootstrap failure (revision 110017)

OK to revert this workaround now? Mainline now passes bootstrap & regtesting on i686 without it. You can approve reversion of your own patches. svnwrite.html says that "no outside approval is needed to revert a patch that you checked in." Paolo

Re: bootstrap failure for Ada gcc 4.1 Revision 110108 on

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John David Anglin schrieb: >>> gnat1: out of memory allocating 19028192 bytes after a total of 92324 bytes >>> gmake[2]: *** [ada/ada.o] Error 1 > > My guess is that this is a problem with the bootstrap compiler. There > is a known issue with all 3.3

Unable to access archives on gcc-patches

Hi, I was having trouble with building gcc and found that the problem i was having had been reported earlier and a patch to fix that had been submitted in feb 2004. However when i try to access the mailing list archives i am able to reach the index page for feb 2004. the link to which is given as:

Re: Mainline bootstrap failure (revision 110017)

Zdenek Dvorak wrote: Hello, On Fri, 20 Jan 2006, Zdenek Dvorak wrote: I propose the following workaround instead, that also restores bootstrap. It changes the way loop-iv uses df to more conservative one, that does not seem to cause problems. That's what I like to see... optio

Re: Unable to access archives on gcc-patches

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 pranav bhandarkar wrote: > > However the patch that i am looking for is not accessible. the link to > the patch is > > http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00826.html Note that you can also use Gmane (news.gmane.org) for accessing archives o

Re: Regarding gcc Makefile.in

hi ashit, On Tue, 2006-01-24 at 15:39 +0530, Ashit Kumar wrote: > I am a newbie for GCC internals.Actually i want to build the GCC (say it > compile the GCC).Now during this i want to study the build process of it. a good starting point could be building gcc natively and looking at the build logs,

Re: [RFC/RFT] PR/25890 and PR/25905

On Mon, 23 Jan 2006, Paolo Bonzini wrote: > 2006-01-23 Paolo Bonzini <[EMAIL PROTECTED]> > > PR rtl-optimization/25890 > PR rtl-optimization/25905 > * combine.c (expand_compound_operation, expand_field_assignment): > Fail if the bitfield's final position is out of bounds.

Re: Mainline bootstrap failure (revision 110017)

Zdenek Dvorak <[EMAIL PROTECTED]> writes: > OK to revert this workaround now? Mainline now passes bootstrap & > regtesting on i686 without it. > > Zdenek > > * loop-iv.c (iv_analysis_loop_init): Use df analysis in a more > efficient way. This is OK. Thanks. Ian

Re: bootstrap failure for Ada gcc 4.1 Revision 110108 on

> I tried bootstrapping the latest 4.0 revesion without luck. Suggest that you submit a GCC PR including the precise failure point, configure command, and preprocessed source if applicable. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Ca

Re: bootstrap failure for Ada gcc 4.1 Revision 110108 on

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John David Anglin schrieb: >> I tried bootstrapping the latest 4.0 revesion without luck. > > Suggest that you submit a GCC PR including the precise failure point, > configure command, and preprocessed source if applicable. > > Dave Perhaps I have t

Re: bootstrap failure for Ada gcc 4.1 Revision 110108 on

> I found the cause for the bootstrap failure. > > Normally I pass "-mpa-risc-2-0" to the boostrap compiler. This produces > PA-RISC2.0 optimized executables. As you can see: > > file gcc > gcc:PA-RISC2.0 shared executable dynamically linked -not stripped > > This option prevents a s

Re: bootstrap failure for Ada gcc 4.1 Revision 110108 on

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John David Anglin schrieb: >> I found the cause for the bootstrap failure. >> >> Normally I pass "-mpa-risc-2-0" to the boostrap compiler. This produces >> PA-RISC2.0 optimized executables. As you can see: >> >> file gcc >> gcc:PA-RISC2.0 s

Re: bootstrap failure for Ada gcc 4.1 Revision 110108 on

> Perhaps I have to be more precise. Bootstrapping ada failed! That's not enough! In order for someone else to duplicate the failure and investigate the problem, you need to provide the log of what happened, your configure command, etc. For example, I would have never guessed that you were usin

Re: insv vs one-bit fields

On Mon, Jan 23, 2006 at 10:29:20PM -0500, DJ Delorie wrote: > Ok, I can't really read ia64 assembler. Before: Close enough. Thanks for testing. r~

x86-64 linux, gomp ICE in trunk

x-gnu Configured with: ../configure --prefix=/usr/local/gomp --enable-languages=c++ --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-multilib --enable-bootstrap --with-gcc --with-gnu-as --with-gnu-ld Thread model: posix gcc version 4.2.0 20060124 (experimental) testcase: int

Re: insv vs one-bit fields

> Close enough. Thanks for testing. Ok to apply then?

sh-rtems still broken on head

This appears to be different from the previous failure. make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/joel/gcc-work/head/b-sh-rtems4.7/libdecnumber' make[2]: Entering directory `/home/joel/gcc-work/head/b-sh-rtems4.7/gcc' build/genextract ../../gcc/gcc/config/sh/sh.m

Re: sh-rtems still broken on head

> > > This appears to be different from the previous failure. > > make[2]: Nothing to be done for `all'. > make[2]: Leaving directory > `/home/joel/gcc-work/head/b-sh-rtems4.7/libdecnumber' > make[2]: Entering directory `/home/joel/gcc-work/head/b-sh-rtems4.7/gcc' > build/genextract ../../gcc/g

Re: sh-rtems still broken on head

Andrew Pinski wrote: Can you try after the following two patches: Thanks. It sure it hard to keep up around here. :) That did it for the sh. Ignoring the precise svn revision, either yesterday or today, I managed to build and install the following on the head: arm-rtems4.7

bootstrap broken on solaris8

Hello I can't hide :) I get the following bootstrap break on solaris 8: cc1: warnings being treated as errors insn-automata.c: In function 'internal_insn_latency': insn-automata.c:1969: warning: implicit declaration of function 'store_data_bypass_p' gmake[3]: *** [insn-automata.o] Error 1 Th

gcc-3.4-20060124 is now available

Snapshot gcc-3.4-20060124 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20060124/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 3.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches

Re: [patch] Merge cfo-branch, RTL sequence abstraction (part 1)

=== --- gcc/cfgcleanup.c(revision 108405) +++ gcc/cfgcleanup.c(working copy) @@ -1151,11 +1151,43 @@ return false; } - /* We don't need to match the rest of edges as above checks should be enough - to ensure that

Re: insv vs one-bit fields

On Tue, Jan 24, 2006 at 12:56:51PM -0500, DJ Delorie wrote: > Ok to apply then? Yes. r~

Re: x86-64 linux, gomp ICE in trunk

On Tue, Jan 24, 2006 at 05:22:12PM +0100, tbp wrote: > /usr/local/gomp/bin/g++ -fopenmp main.cc -o omp c++ gomp is not merged to mainline. r~

Re: insv vs one-bit fields

Thanks. Done!

Re: bootstrap broken on solaris8

Andreas Tobler wrote: Hello I can't hide :) I get the following bootstrap break on solaris 8: cc1: warnings being treated as errors insn-automata.c: In function 'internal_insn_latency': insn-automata.c:1969: warning: implicit declaration of function 'store_data_bypass_p' gmake[3]: *** [insn-

Re: Calls to malloc during an exception

This is The difficulty is thread-safety. If we had some reliable way of allocating memory whenever a new thread was created on platforms that don't have TLS, it would be easy to fix.

Re: Calls to malloc during an exception

Geoffrey Keating wrote: This is Still, can you have a look to the last messages in the audit trail, in particulat #6-8? I'm under the impression that the problem is already fixed for targets using TLS. Paolo.

Re: x86-64 linux, gomp ICE in trunk

On 1/25/06, Richard Henderson <[EMAIL PROTECTED]> wrote: > c++ gomp is not merged to mainline. Indeed, that makes up for a solid reason not to work. Should i hold my breath?

Re: x86-64 linux, gomp ICE in trunk

tbp wrote: > On 1/25/06, Richard Henderson <[EMAIL PROTECTED]> wrote: > >> c++ gomp is not merged to mainline. >> > Indeed, that makes up for a solid reason not to work. > > Should i hold my breath? > A couple more weeks, or you can try the gomp branch.

Re: x86-64 linux, gomp ICE in trunk

On 1/25/06, Diego Novillo <[EMAIL PROTECTED]> wrote: > A couple more weeks, or you can try the gomp branch. Thanks, will do. Hopefully i won't fall for the ICE trick that easily next time.

Re: x86-64 linux, gomp ICE in trunk

tbp wrote: > Hopefully i won't fall for the ICE trick that easily next time. > Well, the compiler still shouldn't ICE. I'll send a fix shortly.

Re: bootstrap broken on solaris8

On Wed, Jan 25, 2006 at 12:17:00AM +0100, Andreas Tobler wrote: > Andreas Tobler wrote: > >I get the following bootstrap break on solaris 8: > > > >cc1: warnings being treated as errors > >insn-automata.c: In function 'internal_insn_latency': > >insn-automata.c:1969: warning: implicit declaration o

Bootstrap failure on sparc*-sun-solaris2.10

I'm getting the following new bootstrap failure on both sparc-sun-solaris2.10 and sparc64-sun-solaris2.10 when using cc for stage1: > cc -xildoff -xarch=v9 -c -g -DIN_GCC -DHAVE_CONFIG_H > -DGENERATOR_FILE -I. -Ibuild -I../../egcc-SVN20060124/gcc > -I../../egcc-SVN20060124/gcc/build

Re: Bootstrap failure on sparc*-sun-solaris2.10

On Jan 24, 2006, at 10:29 PM, Kaveh R. Ghazi wrote: I'm getting the following new bootstrap failure on both sparc-sun-solaris2.10 and sparc64-sun-solaris2.10 when using cc for stage1: At least some of this (e.g. bitmap_zero_bits) is due to uses in static inline functions where "inline" gets def

Re: Bootstrap failure on sparc*-sun-solaris2.10

> Not this issue again :(. > I thought I fixed it the last time it came up. > -- Pinski URL? -- Kaveh R. Ghazi [EMAIL PROTECTED]

Re: Bootstrap failure on sparc*-sun-solaris2.10

On Jan 24, 2006, at 10:41 PM, Kaveh R. Ghazi wrote: Not this issue again :(. I thought I fixed it the last time it came up. -- Pinski URL? Maybe I did not fix it but it was a problem in the past. This was PR 18058 for 4.0.0. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18058 -- Pinski

Re: Bootstrap failure on sparc*-sun-solaris2.10

On Tue, Jan 24, 2006 at 10:29:08PM -0500, Kaveh R. Ghazi wrote: > I'm getting the following new bootstrap failure on both > sparc-sun-solaris2.10 and sparc64-sun-solaris2.10 when using cc for > stage1: > > > "build/gencondmd.c", line 1943: warning: syntax error: empty initializer > > "build/gen

Re: Bootstrap failure on sparc*-sun-solaris2.10

> I'm not entirely understanding why this breaks now when > insn-conditions.o was fine, but a potential big-hammer fix is to put > #if GCC_VERSION >= 3001 ... #endif around most of the includes, like > in the appended patch. Would you please try it? > zw > > * genconditions.c (write_h

Re: x86-64 linux, gomp ICE in trunk

On 1/25/06, Diego Novillo <[EMAIL PROTECTED]> wrote: > Well, the compiler still shouldn't ICE. I'll send a fix shortly. I know i've exhausted my pseudo-ICE quota for the day, but i have another candidate knocking at the door with insistence: src/raytrace_packet.cpp: In member function 'void rt::ra

Re: bootstrap broken on solaris8

Zack Weinberg wrote: On Wed, Jan 25, 2006 at 12:17:00AM +0100, Andreas Tobler wrote: Andreas Tobler wrote: I get the following bootstrap break on solaris 8: cc1: warnings being treated as errors insn-automata.c: In function 'internal_insn_latency': insn-automata.c:1969: warning: implicit decla

Re: Problem with gfortran or did I messsed up GMP installation?

Eric Botcazou wrote: So, the question is, did I broke something by attempting to have both 32-bit and 64-bit GMP library installed simultaniously? Did I miss anything needed to have both 32-bit and 64-bit GMP available on the system? Do not install both 32-bit and 64-bit GMP, you only need one

Re: Patch: Boehm GC 6.6 merge

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bryce McKinlay wrote: > This patch merges the GC 6.6 sources into the libgcj trunk. Two patches [...] This little bit in "boehm-gc/include/private/gcconfig.h" (line 306): - - 8< - > +# else > +#if d

Re: Problem with gfortran or did I messsed up GMP installation?

> Now, the interesting part. I also built gcc 4.0.2 on > sparc-sun-solaris2.6. If I compile the "hello world" program on it > (obviously it will be 32-bit), it runs just fine (prints hello world in > endless loop). If I copy the executable to Solaris 2.9 system and run > it, it exits immediately

Re: bootstrap broken on solaris8

Zack Weinberg wrote: On Wed, Jan 25, 2006 at 12:17:00AM +0100, Andreas Tobler wrote: Andreas Tobler wrote: I get the following bootstrap break on solaris 8: cc1: warnings being treated as errors insn-automata.c: In function 'internal_insn_latency': insn-automata.c:1969: warning: implicit decla

Re: bootstrap broken on solaris8

Andreas Tobler wrote: Zack Weinberg wrote: On Wed, Jan 25, 2006 at 12:17:00AM +0100, Andreas Tobler wrote: Andreas Tobler wrote: I get the following bootstrap break on solaris 8: cc1: warnings being treated as errors insn-automata.c: In function 'internal_insn_latency': insn-automata.c:1969: