[Ada] strange errors with make check -j2 --target_board=\{-m32,-m64\}

Dear all, I get the following errors when running the GNAT testsuite on x86_64-unknown-linux-gnu with make check -j2 --target_board=\{-m32,-m64\}. Executing on host: /home/manuel/test/139674M/build/gcc/gnatmake -I/home/manuel/test/139674M/build/gcc/ada/rts --GCC=/home/manuel/test/139674M/build/gc

Re: Enabling IPCP by default

Hi, after IRA I've re-done x86-64 SPECint testing (SPECfp, CSiBE and C++ benchmark failed because tree was broken at that point, I will get results tomorrow, but there was no surprises already before) also with the new code to eliminate arguments. Luis also did PPC SPEC runs. The most important re

Re: [Ada] strange errors with make check -j2 --target_board=\{-m32,-m64\}

On Thu, Aug 28, 2008 at 12:36 PM, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote: > Dear all, > > I get the following errors when running the GNAT testsuite on > x86_64-unknown-linux-gnu with make check -j2 > --target_board=\{-m32,-m64\}. > > Executing on host: /home/manuel/test/139674M/build/gcc/gn

Re: GCC targets need updating for new register allocator

I will look into CRX port -Pompa Joseph S. Myers wrote: The new Integrated Register Allocator is now in GCC trunk, and the old allocator is scheduled for removal on or shortly after 25 September. All GCC targets need updating for the new allocator; targets that have not been updated when the

Re: GCC targets need updating for new register allocator

Joseph S. Myers wrote: The new Integrated Register Allocator is now in GCC trunk, and the old allocator is scheduled for removal on or shortly after 25 September. [ ... ] One more note, I would strongly recommend we tag the trunk when we remove the old allocator. There's some minor codegen iss

Re: Why --with-gmp doesn't default to --prefix for GCC-4.3.* ?

> But for GMP and MPFR, you need to set --with-gmp to the same path as > --prefix. > Would it be simpler to use the same --prefix to build binutils, GMP, > MPFR and GCC - so defaults --with-gmp to --prefix when present? Because it is more common to install GCC in /usr/local or /opt/gccX.Y.Z but

Re: GCC targets need updating for new register allocator

Jeff Law <[EMAIL PROTECTED]> writes: > Joseph S. Myers wrote: >> The new Integrated Register Allocator is now in GCC trunk, and the >> old allocator is scheduled for removal on or shortly after 25 >> September. > [ ... ] > One more note, I would strongly recommend we tag the trunk when we > remove

Re: GCC targets need updating for new register allocator

2008/8/28 Ian Lance Taylor <[EMAIL PROTECTED]>: > Jeff Law <[EMAIL PROTECTED]> writes: > >> Joseph S. Myers wrote: >>> The new Integrated Register Allocator is now in GCC trunk, and the >>> old allocator is scheduled for removal on or shortly after 25 >>> September. >> [ ... ] >> One more note, I w

Re: GCC targets need updating for new register allocator

"Joseph S. Myers" <[EMAIL PROTECTED]> writes: > The new Integrated Register Allocator is now in GCC trunk, and the old > allocator is scheduled for removal on or shortly after 25 September. All > GCC targets need updating for the new allocator; targets that have not > been updated when the old

Re: GCC targets need updating for new register allocator

Ian Lance Taylor wrote: Jeff Law <[EMAIL PROTECTED]> writes: Joseph S. Myers wrote: The new Integrated Register Allocator is now in GCC trunk, and the old allocator is scheduled for removal on or shortly after 25 September. [ ... ] One more note, I would strongly recommend we t

Boostrap failure on i686-apple-darwin9 at revision 139725

Boostrap fails on i686-apple-darwin9 at revision 139725 with: ... mkdir -p ./i686-apple-darwin9/bits/stdc++.h.gch /opt/gcc/i686-darwin/./gcc/xgcc -shared-libgcc -B/opt/gcc/i686-darwin/./gcc -nostdinc++ -L/opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/src -L/opt/gcc/i686-darwin/i686-apple-d

Re: Boostrap failure on i686-apple-darwin9 at revision 139725

On Thu, Aug 28, 2008 at 1:25 PM, Dominique Dhumieres <[EMAIL PROTECTED]> wrote: : > /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/i686-apple-darwin9/bits/gthr-default.h:776: > error: 'pthread_mutex_timedlock' was not declared in this scope More to the point, it looks like pthread_m

Re: Boostrap failure on i686-apple-darwin9 at revision 139725

Hi, On Thu, Aug 28, 2008 at 1:25 PM, Dominique Dhumieres <[EMAIL PROTECTED]> wrote: : /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/i686-apple-darwin9/bits/gthr-default.h:776: error: 'pthread_mutex_timedlock' was not declared in this scope More to the point, it looks li

Re: Boostrap failure on i686-apple-darwin9 at revision 139725

Paolo Carlini wrote: Ok, please give us a couple of hours to try reproducing it. I hope it's something simple like _POSIX_TIMEOUTS which must be not just defined but >= 0. Yes, looks like that's the reason of the breakage: I'm seeing it defined to -1 on Darwin. I'm going to prepare and test

Re: Boostrap failure on i686-apple-darwin9 at revision 139725

Hi again, I'm going to prepare and test on Darwin the trivial patch, if it fixes the bootstrap failure I will post and commit it as obvious. this is what I eventually committed. Apologies again for the breakage. Paolo. /// 2008-08-28 Paolo Carlini <[EMAIL PROTECTED]> * g

gcc-4.3-20080828 is now available

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

insn does not satisfy its constraints

Hi All, I am getting the error message bellow while hacking my gcc backend. Any suggestions on how to fix this? error: insn does not satisfy its constraints: (insn 25 50 26 2 (set (reg:HI 1 %r0 [33]) (plus:HI (mem/s/j:HI (plus:HI (reg:HI 3 %r2) (reg/v/f:HI 11 %i2h [

Re: Boostrap failure on i686-apple-darwin9 at revision 139725

Paolo, > I'm going to prepare and test on Darwin the trivial patch, if it fixes > the bootstrap failure I will post and commit it as obvious. Bootstrap completed at revision 139739. Thanks for the fix. Dominique