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

[Manuel López-Ibáñez]

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/gcc/xgcc --GNATBIND=\
/home/manuel/test/139674M/build/gcc/gnatbind
--GNATLINK=/home/manuel/test/139674M/build/gcc/gnatlink -cargs
-B/home/manuel/test/139674M/build/gcc -largs --GCC=/home/man\
uel/test/139674M/build/gcc/xgcc -B/home/manuel/test/139674M/build/gcc
-margs -q -f /home/manuel/test/src/gcc/testsuite/gnat.dg/allocator_maxalign1.adb
   -I/home/manuel\
/test/139674M/build/gcc/ada/rts  -lm   -m32 -o
./allocator_maxalign1.exe(timeout = 300)
/usr/bin/ld: warning: i386:x86-64 architecture of input file
`b~allocator_maxalign1.o' is incompatible with i386 output^M
/usr/bin/ld: warning: i386:x86-64 architecture of input file
`/home/manuel/test/139674M/build/gcc/ada/rts/ada.o' is incompatible
with i386 output^M
/usr/bin/ld: warning: i386:x86-64 architecture of input file
`/home/manuel/test/139674M/build/gcc/ada/rts/interfac.o' is
incompatible with i386 output^M
/usr/bin/ld: warning: i386:x86-64 architecture of input file
`/home/manuel/test/139674M/build/gcc/ada/rts/system.o' is incompatible
with i386 output^M


It seems like some race condition to me. Any idea?

Cheers,

Manuel.

Re: Enabling IPCP by default

[Jan Hubicka]

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 regression I am aware of is equake on PPC, about 5%
with clonning enabled.  The problem here is that IPCP correctly propagate
operands array into initialization functions.  This makes them to be
called just once (since clonning avoids the fact that quake lacks static
modifiers) and we inline them.  Inlining cause branch prediction code to
misidentify hot portion of program to be the initialization loop instead
of simulation loop. Same problem happens e.g. with -fwhole-program or if 
"static" keywords are added.  Equake consist of single file.
So I don't think it is IPCP fault per se, we are just unlucky.

Other interesting issue happens with vortex, where we get quite high code
size growth, 660KB->720Kb.  The problem here is that vortex has statistic
code that is implemented by passing __FILE__, __LINE__ macros.
SPEC for some reason redefine it to NULL, 0.  This cause IPCP to
propagate those two constant into about every function and we end up
with a lot of clonning.  New operand removal code helps code size quite
a lot (originally we needed 800Kb), so I think it is within bounds for
-O3.   Argument skipping also makes propagation to actually help
performance here (1400->1460).

So my current plan is to wait for tomorrow results of the failed
benchmarks, get also IA-64 result and enable IPCP by default by
tomorrow.  I also hope that the argument skipping code will get reviewed
before stage1 so we don't get unnecesary code growth on VRP or we can
trottle down clonning even further for release.

Honza

> Hi,
> Since most of issues with IPCP should be fixed now and it should be as
> strong as possible with the elementary textbook quality algorithm it
> uses, I would like to enable it by default.  I've tested it on SPEC and
> C++ behcmarks yeterday and didn't measured any significant improvments.
> There is quite a lot of clonning happening now (as can be seen on size
> increase) on SPECint, but the benchmark performance don't care much.
> Today I fixed some isses and added code to avoid code size growth, so
> I expect IPCP to be mostly neutral.  Will re-run the tests tonight.
> 
> To some degree I would say it is expected as all those codebases are quite 
> well
> hand optimized and this is kind of optimization one does by hand if needed.
> 
> Ipcp can now run in tow modes: in pure constant propagation when clonning is
> not happening (well, in fact it does. We clone the function and the remove the
> original as in place replacement is not implement (yet)) and with clonning.
> With clonning overall unit growth is limited to 10% and ipcp performs very
> simplistic analysis of effectivity and will clone functions until the limit is
> met in priority order.
> 
> On CC1 binarry I get following results:
>   stripped size   clonned functions
> no ipcp   8863256 0
> ipcp only 8773432 45
> ipcp&clonning 8772344 154
> (with unlimited clonning we get about 180 clones)
> 
> Additionally ipcp and ipcp&clonning binary seems consistently 0.7%-1.5% faster
> on compiling C objects.
> 
> Since IPCP seems essentially free for compile time (i.e. intraprocedural
> analysis is performed for inlining anyway and interprocedural step is very
> cheap when nothing is transformed) and cause 1% code size savings on cc1 
> and speeds it up enough to pay back, I would like to propose:
>   - enable IPCP for -O2 and -Os
>   - enable IPCP clonning for -O3
> 
> Ipcp also carries basic IPA infrastructure we want to keep excercised
> (jump function analysis, clonning, propagation to function bodies and
> infrastructure to solve cgraph updates for future whopr mode).
> 
> I would still like to work on better ipcp cost model (i.e. estimates on how
> much function will simplify with constant propagation) and also to allow
> producing multiple clones when function is called with multiple constant
> arguments.
> 
> If there are no complains, I will enable ipcp as proposed after remaining
> patches are tested and comitted (that would be about day after tomorrow)
> Honza

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

[Richard Guenther]

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/gnatmake
> -I/home/manuel/test/139674M/build/gcc/ada/rts
> --GCC=/home/manuel/test/139674M/build/gcc/xgcc --GNATBIND=\
> /home/manuel/test/139674M/build/gcc/gnatbind
> --GNATLINK=/home/manuel/test/139674M/build/gcc/gnatlink -cargs
> -B/home/manuel/test/139674M/build/gcc -largs --GCC=/home/man\
> uel/test/139674M/build/gcc/xgcc -B/home/manuel/test/139674M/build/gcc
> -margs -q -f 
> /home/manuel/test/src/gcc/testsuite/gnat.dg/allocator_maxalign1.adb
>   -I/home/manuel\
> /test/139674M/build/gcc/ada/rts  -lm   -m32 -o
> ./allocator_maxalign1.exe(timeout = 300)
> /usr/bin/ld: warning: i386:x86-64 architecture of input file
> `b~allocator_maxalign1.o' is incompatible with i386 output^M
> /usr/bin/ld: warning: i386:x86-64 architecture of input file
> `/home/manuel/test/139674M/build/gcc/ada/rts/ada.o' is incompatible
> with i386 output^M
> /usr/bin/ld: warning: i386:x86-64 architecture of input file
> `/home/manuel/test/139674M/build/gcc/ada/rts/interfac.o' is
> incompatible with i386 output^M
> /usr/bin/ld: warning: i386:x86-64 architecture of input file
> `/home/manuel/test/139674M/build/gcc/ada/rts/system.o' is incompatible
> with i386 output^M
>
>
> It seems like some race condition to me. Any idea?

Ada doesn't support multi-libbing and is confused if you test with -m32.

Richard.

Re: GCC targets need updating for new register allocator

[Pompapathi V Gadad]

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 old allocator is removed will no longer work and 
will be added to the deprecation list for GCC 4.4.  (After that date 
target maintainers may remove their targets from the deprecation list as 
part of the patches updating them for the new allocator; any remaining 
unconverted targets will be removed from trunk after GCC 4.4 branches 
along with the other targets deprecated in 4.4.)


Updating a target is a matter of adding an IRA_COVER_CLASSES definition.  
If you need advice about defining this macro for a target, please ask 
Vladimir Makarov, not me.  It is of course possible that a target has 
become bit-rotten in other ways and so needs further fixes to build.  
Once GCC trunk is building for your target with IRA enabled (with all 
necessary changes having been committed to GCC trunk), please post test 
results for unmodified GCC trunk to gcc-testresults if at all possible to 
provide a record of the current state of that port, if test results for 
that port are not already being posted reasonably frequently.


The following targets are currently unconverted:

arc
cris
crx
fr30
frv
h8300
iq2000
m32c
m32r
m68hc11
m68k
mcore
mips
mmix
pa
pdp11
score
stormy16
v850
vax
xtensa

  

Re: GCC targets need updating for new register allocator

[Jeff Law]

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 issues that I'd 
like to be able to come back and work on further once we've got the 
ports converted to IRA.  Having a tag which allows me to checkout and do 
comparisons of IRA vs the old allocator would make that process much easier.


Jeff

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

[Paolo Bonzini]

>  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 use the distribution's GMP and MPFR in /usr.

Paolo

Re: GCC targets need updating for new register allocator

[Ian Lance Taylor]

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 the old allocator.  There's some minor codegen issues that I'd
> like to be able to come back and work on further once we've got the
> ports converted to IRA.  Having a tag which allows me to checkout and
> do comparisons of IRA vs the old allocator would make that process
> much easier.

We use subversion now, which has unique revision numbers.  Just check
out revision 139589.

Ian

Re: GCC targets need updating for new register allocator

[Manuel López-Ibáñez]

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 would strongly recommend we tag the trunk when we
>> remove the old allocator.  There's some minor codegen issues that I'd
>> like to be able to come back and work on further once we've got the
>> ports converted to IRA.  Having a tag which allows me to checkout and
>> do comparisons of IRA vs the old allocator would make that process
>> much easier.
>
> We use subversion now, which has unique revision numbers.  Just check
> out revision 139589.

On the other hand, tagging is free [*] and you do not need to remember
revision numbers

svn cp -r REVISION svn+ssh://gcc.gnu.org/svn/gcc/trunk \

svn+ssh://gcc.gnu.org/svn/gcc/tags/old-allocator-removed-from-trunk \
-m "Tag for the removal of the old allocator"

Cheers,

Manuel.

[*] http://svnbook.red-bean.com/en/1.1/ch04s02.html

Re: GCC targets need updating for new register allocator

[Richard Sandiford]

"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 allocator is removed will no longer work and 
> will be added to the deprecation list for GCC 4.4.  (After that date 
> target maintainers may remove their targets from the deprecation list as 
> part of the patches updating them for the new allocator; any remaining 
> unconverted targets will be removed from trunk after GCC 4.4 branches 
> along with the other targets deprecated in 4.4.)
>
> Updating a target is a matter of adding an IRA_COVER_CLASSES definition.  
> If you need advice about defining this macro for a target, please ask 
> Vladimir Makarov, not me.  It is of course possible that a target has 
> become bit-rotten in other ways and so needs further fixes to build.  
> Once GCC trunk is building for your target with IRA enabled (with all 
> necessary changes having been committed to GCC trunk), please post test 
> results for unmodified GCC trunk to gcc-testresults if at all possible to 
> provide a record of the current state of that port, if test results for 
> that port are not already being posted reasonably frequently.
>
> The following targets are currently unconverted:
>
> arc
> cris
> crx
> fr30
> frv
> h8300
> iq2000
> m32c
> m32r
> m68hc11
> m68k
> mcore
> mips
> mmix
> pa
> pdp11
> score
> stormy16
> v850
> vax
> xtensa

For the record, I have a WIP MIPS port, and have had for a while.
It got blocked by some IRA wrong-code regressions which I was discussing
with Vlad.  They were caused by incorrect livenes information for EH,
and my "fix" for this was to replace the current note_stores-based
forward scan with a DF-based backward scan, on the basis that using DF
gave us the corrected liveness information "for free".  The problem was
that, although this did indeed fix the wrong-code problem, it showed up
an interesting property of IRA: that it was very sensitive to the order
of numbers given to allocnos.  If you give IRA the same liveness
information, but give allocnos "inverted" numbers, IRA could sometimes
produce much worse results.  (Vlad measured a noticable difference on
SPEC.)

Also, I found what seemed to be a problem with the copy-reduction
heuristics: in certain cases, they could cause us to "deliberately"
pick the one register that would force a copy, even when there was
little register pressure.

Now that IRA is in mainline, I suppose I should move the discussion
on-list.  I'll try to update my notes and experiments for mainline
this weekend and post something to [EMAIL PROTECTED]

Richard

Re: GCC targets need updating for new register allocator

[Jeff Law]

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 tag the trunk when we
remove the old allocator.  There's some minor codegen issues that I'd
like to be able to come back and work on further once we've got the
ports converted to IRA.  Having a tag which allows me to checkout and
do comparisons of IRA vs the old allocator would make that process
much easier.



We use subversion now, which has unique revision numbers.  Just check
out revision 139589.

  

I'm aware of that, but:

 1. I don't want to have to remember an obscure version #.  It's much 
easier IMHO to have a symbolic

name representing the point in time when the old allocator disappears.

 2. I don't want the change when IRA was installed, I want the last 
version of the tree before

 the old allocator goes away.

jeff

Boostrap failure on i686-apple-darwin9 at revision 139725

[Dominique Dhumieres]

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-darwin9/libstdc++-v3/src/.libs 
-B/opt/gcc/gcc4.4w/i686-apple-darwin9/bin/ 
-B/opt/gcc/gcc4.4w/i686-apple-darwin9/lib/ -isystem 
/opt/gcc/gcc4.4w/i686-apple-darwin9/include -isystem 
/opt/gcc/gcc4.4w/i686-apple-darwin9/sys-include -Winvalid-pch -x c++-header -g 
-O2   
-I/opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/i686-apple-darwin9
 -I/opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include 
-I/opt/gcc/gcc-4.4-work/libstdc++-v3/libsupc++ -O0 -g 
/opt/gcc/gcc-4.4-work/libstdc++-v3/include/precompiled/stdc++.h -o 
i686-apple-darwin9/bits/stdc++.h.gch/O0g.gch
In file included from 
/opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/i686-apple-darwin9/bits/gthr.h:165,
 from 
/opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/ext/atomicity.h:39,
 from 
/opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/bits/basic_string.h:46,
 from 
/opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/string:58,
 from 
/opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/bitset:54,
 from 
/opt/gcc/gcc-4.4-work/libstdc++-v3/include/precompiled/stdc++.h:67:
/opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/i686-apple-darwin9/bits/gthr-default.h:
 In function 'int __gthread_mutex_timedlock(__gthread_mutex_t*, const 
__gthread_time_t*)':
/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
make[4]: *** [i686-apple-darwin9/bits/stdc++.h.gch/O0g.gch] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-target-libstdc++-v3] Error 2
make: *** [all] Error 2
...

This seems related to revision  139704

Jump to revision:
Author: paolo
Date:   Thu Aug 28 09:20:57 2008 UTC (11 hours, 3 minutes ago)
Log Message:
2008-08-28  Chris Fairles  <[EMAIL PROTECTED]>

* gthr-posix.h (__gthread_create,  __gthread_join, __gthread_detach,
__gthread_mutex_timed_lock, __gthread_recursive_mutex_timed_lock,
__gthread_cond_signal, __gthread_cond_timedwait,
__gthread_cond_timedwait_recursive): New functions.
* gthr-posix.c (pthread_mutex_timedlock, pthread_cond_timedwait):
Likewise.
* gthr.h: Comment on defining __GTHREADS_CXX0X macro in conforming
thread interfaces.

TIA

Dominique

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

[Andrew Pinski]

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_mutex_timedlock was only
added to issue 6 of POSIX which was just released in 2004.  This
function is too new for most pthreads implementation.

See 
http://www.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_timedlock.html
for more information on this new function.

-- Pinski

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

[Paolo Carlini]

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 like pthread_mutex_timedlock was only
added to issue 6 of POSIX which was just released in 2004.  This
function is too new for most pthreads implementation.

See 
http://www.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_timedlock.html
for more information on this new function.
  


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.


Paolo.

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

[Paolo Carlini]

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 on Darwin the trivial patch, if it fixes 
the bootstrap failure I will post and commit it as obvious.


Paolo.

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

[Paolo Carlini]

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]>

* gtrh-posix.h: Fix uses of _POSIX_TIMEOUTS per the normal Posix
rule that a symbolic constant must be defined and >= 0 for the
corresponding facility to be present at compile-time.
* gthr-posix.c: Likewise.
Index: gthr-posix.c
===
--- gthr-posix.c(revision 139737)
+++ gthr-posix.c(working copy)
@@ -112,12 +112,14 @@
 }
 
 #ifdef _POSIX_TIMEOUTS
+#if _POSIX_TIMEOUTS >= 0
 int
 pthread_mutex_timedlock (pthread_mutex_t *mutex ATTRIBUTE_UNUSED,
 const struct timespec *abs_timeout ATTRIBUTE_UNUSED)
 {
   return 0;
 }
+#endif
 #endif /* _POSIX_TIMEOUTS */
 
 int
Index: gthr-posix.h
===
--- gthr-posix.h(revision 139737)
+++ gthr-posix.h(working copy)
@@ -104,7 +104,9 @@
 __gthrw3(pthread_mutex_lock)
 __gthrw3(pthread_mutex_trylock)
 #ifdef _POSIX_TIMEOUTS
+#if _POSIX_TIMEOUTS >= 0
 __gthrw3(pthread_mutex_timedlock)
+#endif
 #endif /* _POSIX_TIMEOUTS */
 __gthrw3(pthread_mutex_unlock)
 __gthrw3(pthread_mutex_init)
@@ -131,7 +133,9 @@
 __gthrw(pthread_mutex_lock)
 __gthrw(pthread_mutex_trylock)
 #ifdef _POSIX_TIMEOUTS
+#if _POSIX_TIMEOUTS >= 0
 __gthrw(pthread_mutex_timedlock)
+#endif
 #endif /* _POSIX_TIMEOUTS */
 __gthrw(pthread_mutex_unlock)
 __gthrw(pthread_mutex_init)
@@ -768,6 +772,7 @@
 }
 
 #ifdef _POSIX_TIMEOUTS
+#if _POSIX_TIMEOUTS >= 0
 static inline int
 __gthread_mutex_timedlock (__gthread_mutex_t *mutex,
   const __gthread_time_t *abs_timeout)
@@ -778,6 +783,7 @@
 return 0;
 }
 #endif
+#endif
 
 static inline int
 __gthread_mutex_unlock (__gthread_mutex_t *mutex)
@@ -823,6 +829,7 @@
 }
 
 #ifdef _POSIX_TIMEOUTS
+#if _POSIX_TIMEOUTS >= 0
 static inline int
 __gthread_recursive_mutex_timedlock (__gthread_recursive_mutex_t *mutex,
 const __gthread_time_t *abs_timeout)
@@ -830,6 +837,7 @@
   return __gthread_mutex_timedlock (mutex, abs_timeout);
 }
 #endif
+#endif
 
 static inline int
 __gthread_recursive_mutex_unlock (__gthread_recursive_mutex_t *mutex)

gcc-4.3-20080828 is now available

[gccadmin]

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/gcc-4_3-branch 
revision 139739

You'll find:

gcc-4.3-20080828.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.3-20080828.tar.bz2 C front end and core compiler

gcc-ada-4.3-20080828.tar.bz2  Ada front end and runtime

gcc-fortran-4.3-20080828.tar.bz2  Fortran front end and runtime

gcc-g++-4.3-20080828.tar.bz2  C++ front end and runtime

gcc-java-4.3-20080828.tar.bz2 Java front end and runtime

gcc-objc-4.3-20080828.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.3-20080828.tar.bz2The GCC testsuite

Diffs from 4.3-20080821 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.3
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

insn does not satisfy its constraints

[Omar Torres]

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 [orig:28 cell ] [28])) [0
.dod S2 A8])
 (reg:HI 1 %r0 [43]))) 8 {*addhi3} (insn_list:REG_DEP_TRUE 3
(insn_list:REG_DEP_TRUE 24 (nil)))
 (nil))


The md description for this instruction is:

;; addhi3
(define_expand "addhi3"
   [(set (match_operand:HI 0 "register_operand" "")
(plus:HI (match_operand:HI 1 "cool_addhi_operand"  "")
 (match_operand:HI 2 "cool_addhi_operand"  "")))]
   ""
   "")

(define_insn "*addhi3"
   [(set (match_operand:HI 0 "register_operand""=r ,r  ,r")
(plus:HI (match_operand:HI 1 "cool_addhi_operand" "%0 ,rim,r")
 (match_operand:HI 2 "cool_addhi_operand" "rim,0  ,r")))]
   ""
  {
operands[3] = simplify_gen_subreg (QImode, operands[0], HImode, 1);
operands[4] = simplify_gen_subreg (QImode, operands[0], HImode, 0);

operands[5] = simplify_gen_subreg (QImode, operands[1], HImode, 1);
operands[6] = simplify_gen_subreg (QImode, operands[1], HImode, 0);

operands[7] = simplify_gen_subreg (QImode, operands[2], HImode, 1);
operands[8] = simplify_gen_subreg (QImode, operands[2], HImode, 0);

if (!which_alternative)
return "ADD\t%3,%7\n\tADDC\t%4,%8";
else if (1 == which_alternative)
return "ADD\t%3,%5\n\tADDC\t%4,%6";
else
return "ADD\t%3,%5,%8\n\tADDC\t%4,%5,%8";
   })

Regards,
  -Omar

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

[Dominique Dhumieres]

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