Side effects on memory access

[Michael Hope]

Hi there.  I'm looking at porting GCC to a new architecture which has
a quite small instruction set and I'm afraid I can't figure out how to
represent unintended side effects on instructions.

My current problem is accessing memory.  Reading an aligned 32 bit
word is simple using LOADACC, (X).  Half words and bytes are harder as
the only instruction available is a load byte with post increment
'LOADACC, (X+)'.

How can I tell GCC that loading a byte also increases the pointer
register?  My first version reserved one of the pointer registers and
threw away the modified value but this is inefficient.  I suspect that
some type of clobber or define_expand is required but I can't figure
it out.

Thanks for any help,

-- Michael

Re: [m32c] IRA reload failures in libstdc++

[Joern Rennecke]

Any ideas?


This:

Reload 0: reload_in (SI) = (reg/f:SI 25 [ __i1$_M_current ])
A_REGS, RELOAD_FOR_OTHER_ADDRESS (opnum = 0)
reload_in_reg: (reg/f:SI 25 [ __i1$_M_current ])

cannot be satisfied because there is no A_REGS register
acceptable in SImode.

I suggest making reload reload the PSImode subreg instead, and
make the m32c machine description provide for a tertiary
reload so that the value can be loaded & truncated.


Any thoughts on why gcc has so many problems with this chip?


Having BASE_REG_CLASS with only two members is pretty extreme.
Likewise for not being able to reload an address in an integral
mode.
When you labour on keeping this port working, you are on the
bleeding edge of reload limitations.
I remember when DImode additions caused i386 (elf) PIC reload
problems - but compared with m32c, the i386 integer programming
model is compiler-friendly ;-)

[lto] Problems with cgraph_state updating

[Diego Novillo]

Jan,

I've run into a problem with cgraph_state that illustrates some of the
issues I have with the cgraph machinery.  We are currently relying on
pass_all_early_optimizations to move cgraph_state from
CGRAPH_STATE_IPA to CGRAPH_STATE_IPA_SSA:

static unsigned int
execute_early_local_optimizations (void)
{
  /* First time we start with early optimization we need to advance
 cgraph state so newly inserted functions are also early optimized.
 However we execute early local optimizations for lately inserted
 functions, in that case don't reset cgraph state back to IPA_SSA.  */
  if (cgraph_state < CGRAPH_STATE_IPA_SSA)
cgraph_state = CGRAPH_STATE_IPA_SSA;
  return 0;
}

The problem is that when lto1 is running, we do not execute this pass
because it is not needed (it was already executed during cc1/cc1plus),
so this state transition never takes place.

I think there are two problematic aspects to this.  First, the very
existence of cgraph_state as a global variable accessible from
anywhere.  This variable is checked during SSA verification, so the
verifiers are context sensitive.  We should, at the very least, hide
this variable from outside of the cgraph machinery.

The other problem is that we are relying on an optimization pass to
set properties for the cgraph, this should be something done by the
pass manager itself or the cgraph routines (maybe via a TODO_*).  I've
replicated this update inside ipa_passes() but this is sub-optimal.

So, there should be a clear state transition in the cgraph and the
transition should be controlled by cgraph/pass-manager code.  Where
could that be?


Thanks.  Diego.

Re: For backend maintainers: changes for C++ compatibility

[Nick Clifton]

Hi Ian,


I would like to ask the maintainers for backends which
I did not mention to bootstrap their targets if possible, and/or to
build them with a newly built mainline compiler, to see if there are new
warnings about C++ compatibility.


For the record I have tested the fr30, iq2000, m32r, mcore, v850 and 
xstormy16 backends and they have no problems.


Cheers
  Nick

[plugins] Branch closed

[Diego Novillo]

The only patch remaining to move from the plugins branch are the
testsuite changes, which are waiting for review
(http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01238.html).

I am closing the branch for now.  Any new plugin development should be
done on mainline.  However, we may want to reopen the branch if there
is any new development that would not be ready in time for
stage1/stage2.


Diego.

EH tree is invalid

[Piotr Wyderski]

On gcc-trunk my project fails with the following ICE. Whatever it means...

/home/piotr.wyderski/topnotch/vm/test/main.cpp: In function 'int
main(int, char**)':
/home/piotr.wyderski/topnotch/vm/test/main.cpp:32: error: Wrong
prev_try pointer in EH region 123
Eh tree:
   100 catch tree_label: may_contain_throw prev: 97 type:
 102 must_not_throw tree_label: may_contain_throw
 101 cleanup tree_label: may_contain_throw
   97 catch tree_label: may_contain_throw prev: 94 next 100
type:struct exception
 99 must_not_throw tree_label: may_contain_throw
 98 cleanup tree_label: may_contain_throw
   94 catch tree_label: may_contain_throw next 97 type:struct rc_ptr
 96 must_not_throw tree_label: may_contain_throw
 95 cleanup tree_label: may_contain_throw
   1 try may_contain_throw catch regions: 94 97 100
 93 must_not_throw tree_label: may_contain_throw
 2 cleanup tree_label: may_contain_throw prev try:1
   92 must_not_throw tree_label: may_contain_throw
   3 cleanup tree_label: may_contain_throw prev try:1
 91 must_not_throw tree_label: may_contain_throw
 4 cleanup tree_label: may_contain_throw prev try:1
   90 must_not_throw tree_label: may_contain_throw
   5 cleanup tree_label: may_contain_throw prev try:1
 89 must_not_throw tree_label: may_contain_throw
 6 cleanup tree_label: may_contain_throw prev try:1
   88 must_not_throw tree_label: may_contain_throw
   7 cleanup tree_label: may_contain_throw prev try:1
 87 must_not_throw tree_label: may_contain_throw
 8 cleanup tree_label: may_contain_throw prev try:1
   86 must_not_throw tree_label: may_contain_throw
   9 cleanup tree_label: may_contain_throw prev try:1
 85 must_not_throw tree_label: may_contain_throw
 10 cleanup tree_label: may_contain_throw prev try:1
   84 must_not_throw tree_label: may_contain_throw
   11 cleanup tree_label: may_contain_throw prev try:1
 83 must_not_throw tree_label: may_contain_throw
 34 cleanup tree_label:
may_contain_throw prev try:1
   82 must_not_throw tree_label: may_contain_throw
   37 cleanup tree_label:
may_contain_throw prev try:1
 81 must_not_throw tree_label:
may_contain_throw
 40 cleanup tree_label:
may_contain_throw prev try:1
   80 must_not_throw tree_label:
may_contain_throw
   43 cleanup tree_label:
may_contain_throw prev try:1
 79 must_not_throw tree_label:
may_contain_throw
 46 cleanup tree_label:
may_contain_throw prev try:1
   78 must_not_throw tree_label:
may_contain_throw
   49 cleanup tree_label:
may_contain_throw prev try:1
 77 must_not_throw
tree_label: may_contain_throw
 52 cleanup tree_label:
may_contain_throw prev try:1
   76 must_not_throw
tree_label: may_contain_throw
   55 cleanup tree_label:
may_contain_throw prev try:1
 75 must_not_throw
 56 cleanup tree_label:
may_contain_throw prev try:1
   74 must_not_throw
tree_label: may_contain_throw
   57 cleanup tree_label:
may_contain_throw prev try:1
 73 must_not_throw
tree_label: may_contain_throw
 58 cleanup
tree_label: may_contain_throw prev try:1
   72 must_not_throw
tree_label: may_contain_throw
   59 cleanup
tree_label: may_contain_throw prev try:1
 71 must_not_throw
tree_label: may_contain_throw
 60 cleanup
tree_label: may_contain_throw prev try:1
   70 must_not_throw
tree_label: may_contain_throw
   61 cleanup
tree_label: may_contain_throw prev try:1
 69 must_not_throw
tree_label: may_contain_throw
 62 cleanup
tree_label: may_contain_throw prev try:1
   68
must_not_throw tree_label: may_contain_throw
   63 cleanup
tree_label: may_contain_throw prev try:1
 

Re: EH tree is invalid

[Richard Guenther]

On Tue, Apr 21, 2009 at 3:56 PM, Piotr Wyderski
 wrote:
> On gcc-trunk my project fails with the following ICE. Whatever it means...
>
> /home/piotr.wyderski/topnotch/vm/test/main.cpp: In function 'int
> main(int, char**)':
> /home/piotr.wyderski/topnotch/vm/test/main.cpp:32: error: Wrong
> prev_try pointer in EH region 123
> Eh tree:
>   100 catch tree_label: may_contain_throw prev: 97 type:
>     102 must_not_throw tree_label: may_contain_throw
>     101 cleanup tree_label: may_contain_throw
>   97 catch tree_label: may_contain_throw prev: 94 next 100
> type:struct exception
>     99 must_not_throw tree_label: may_contain_throw
>     98 cleanup tree_label: may_contain_throw
>   94 catch tree_label: may_contain_throw next 97 type:struct rc_ptr
>     96 must_not_throw tree_label: may_contain_throw
>     95 cleanup tree_label: may_contain_throw
>   1 try may_contain_throw catch regions: 94 97 100
>     93 must_not_throw tree_label: may_contain_throw
>     2 cleanup tree_label: may_contain_throw prev try:1
>       92 must_not_throw tree_label: may_contain_throw
>       3 cleanup tree_label: may_contain_throw prev try:1
>         91 must_not_throw tree_label: may_contain_throw
>         4 cleanup tree_label: may_contain_throw prev try:1
>           90 must_not_throw tree_label: may_contain_throw
>           5 cleanup tree_label: may_contain_throw prev try:1
>             89 must_not_throw tree_label: may_contain_throw
>             6 cleanup tree_label: may_contain_throw prev try:1
>               88 must_not_throw tree_label: may_contain_throw
>               7 cleanup tree_label: may_contain_throw prev try:1
>                 87 must_not_throw tree_label: may_contain_throw
>                 8 cleanup tree_label: may_contain_throw prev try:1
>                   86 must_not_throw tree_label: may_contain_throw
>                   9 cleanup tree_label: may_contain_throw prev try:1
>                     85 must_not_throw tree_label: may_contain_throw
>                     10 cleanup tree_label: may_contain_throw prev try:1
>                       84 must_not_throw tree_label: may_contain_throw
>                       11 cleanup tree_label: may_contain_throw prev 
> try:1
>                         83 must_not_throw tree_label: may_contain_throw
>                         34 cleanup tree_label:
> may_contain_throw prev try:1
>                           82 must_not_throw tree_label: may_contain_throw
>                           37 cleanup tree_label:
> may_contain_throw prev try:1
>                             81 must_not_throw tree_label:
> may_contain_throw
>                             40 cleanup tree_label:
> may_contain_throw prev try:1
>                               80 must_not_throw tree_label:
> may_contain_throw
>                               43 cleanup tree_label:
> may_contain_throw prev try:1
>                                 79 must_not_throw tree_label:
> may_contain_throw
>                                 46 cleanup tree_label:
> may_contain_throw prev try:1
>                                   78 must_not_throw tree_label:
> may_contain_throw
>                                   49 cleanup tree_label:
> may_contain_throw prev try:1
>                                     77 must_not_throw
> tree_label: may_contain_throw
>                                     52 cleanup tree_label:
> may_contain_throw prev try:1
>                                       76 must_not_throw
> tree_label: may_contain_throw
>                                       55 cleanup tree_label:
> may_contain_throw prev try:1
>                                         75 must_not_throw
>                                         56 cleanup tree_label:
> may_contain_throw prev try:1
>                                           74 must_not_throw
> tree_label: may_contain_throw
>                                           57 cleanup tree_label:
> may_contain_throw prev try:1
>                                             73 must_not_throw
> tree_label: may_contain_throw
>                                             58 cleanup
> tree_label: may_contain_throw prev try:1
>                                               72 must_not_throw
> tree_label: may_contain_throw
>                                               59 cleanup
> tree_label: may_contain_throw prev try:1
>                                                 71 must_not_throw
> tree_label: may_contain_throw
>                                                 60 cleanup
> tree_label: may_contain_throw prev try:1
>                                                   70 must_not_throw
> tree_label: may_contain_throw
>                                                   61 cleanup
> tree_label: may_contain_throw prev try:1
>                                                     69 must_not_throw
> tree_label: may_contain_throw
>                                                     62 cleanup
> tree_label: may_contain_throw prev try:1
>                                                       68
> must_not_t

Re: EH tree is invalid

[Piotr Wyderski]

Richard Guenther wrote:

> Please file a bugreport in bugzilla and attach preprocessed source.

Impossible, the source code is proprietary. But perhaps
I can try to prepare a simplified testcase though...

Best regards
Piotr Wyderski

Re: EH tree is invalid

[Dave Korn]

Piotr Wyderski wrote:
> On gcc-trunk my project fails with the following ICE. Whatever it means...

  Are you using SJLJ or DW2 exceptions?  If SJLJ, does the patch at

http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01628.html

help the problem?

cheers,
  DaveK

Re: EH tree is invalid

[Piotr Wyderski]

Dave Korn wrote:

>  Are you using SJLJ or DW2 exceptions?

SJLJ only -- DW2 doesn't work on Windows if the exception
handling scope crosses DLL boundaries.

>  If SJLJ, does the patch at
>
>    http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01628.html
>
> help the problem?

Hm, it seems that rev 146517 does not build on Cygwin,
so I am unable to check it right now. But I'll try the patch
ASAB (as soon as buildable :D)

make[3]: Entering directory `/home/piotr.wyderski/build/gcc-trunk/objdir/gcc'
/home/piotr.wyderski/build/gcc-trunk/objdir/./prev-gcc/xgcc -B/home/piotr.wyders
ki/build/gcc-trunk/objdir/./prev-gcc/ -B/opt/gcc-4.5-trunk/i686-pc-cygwin/bin/ -
c  -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prot
otypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribut
e -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-fno-common  -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../in
clude -I../../gcc/../libcpp/include  -I../../gcc/../libdecnumber -I../../gcc/../
libdecnumber/dpd -I../libdecnumber../../gcc/sdbout.c -o sdbout.o
cc1: warnings being treated as errors
../../gcc/sdbout.c: In function 'sdbout_symbol':
../../gcc/sdbout.c:773: error: enum conversion when passing argument 2 of 'elimi
nate_regs' is invalid in C++
../../gcc/reload.h:346: note: expected 'enum machine_mode' but argument is of ty
pe 'int'
../../gcc/sdbout.c: In function 'sdbout_parms':
../../gcc/sdbout.c:1274: error: enum conversion when passing argument 2 of 'elim
inate_regs' is invalid in C++
../../gcc/reload.h:346: note: expected 'enum machine_mode' but argument is of ty
pe 'int'

Best regards
Piotr Wyderski

Re: Side effects on memory access

[Ian Lance Taylor]

Michael Hope  writes:

> Hi there.  I'm looking at porting GCC to a new architecture which has
> a quite small instruction set and I'm afraid I can't figure out how to
> represent unintended side effects on instructions.
>
> My current problem is accessing memory.  Reading an aligned 32 bit
> word is simple using LOADACC, (X).  Half words and bytes are harder as
> the only instruction available is a load byte with post increment
> 'LOADACC, (X+)'.

Wow.

> How can I tell GCC that loading a byte also increases the pointer
> register?  My first version reserved one of the pointer registers and
> threw away the modified value but this is inefficient.  I suspect that
> some type of clobber or define_expand is required but I can't figure
> it out.

Well, you can use a define_expand to generate the move in the first
place.  If can_create_pseudo_p() returns true, then you can call
copy_to_reg (addr) to get the address into a register, and you can
generate the post increment.

(define_expand "movhi"
  ...
  if (can_create_pseudo_p () && MEM_P (operands[1]))
{
  rtx reg = copy_to_reg (XEXP (operands[1], 0));
  emit_insn (gen_movhi_insn (operands[0], reg));
  DONE;
}
  ...
)

(define_insn "movhi_insn"
  [(set (match_operand:HI 0 ...)
(mem:HI (post_inc:P (match_operand:P 1 "register_operand" ...]
  ...
)

The difficulties are going to come in reload.  Reload will want to load
and store 16-bit values in order to spill registers.  You will need a
scratch register to dothis, and that means that you need to implement
TARGET_SECONDARY_RELOAD.  This is complicated:read the docs carefully
and look at the existing examples.

Ian

Re: GCC 4.3.2 bug (was: Illegal subtraction in tmp-dive_1.s)

[Vincent Lefevre]

On 2009-04-20 15:17:44 +0200, Vincent Lefevre wrote:
> On 2009-04-17 12:09:42 -0500, Gabriel Dos Reis wrote:
> > At least, let's get it archived on GCC mailing lists.
> 
> Is it a bug that has been identified?

FYI, this has been fixed in the 4.3 branch in r143494.
This was PR tree-optimization/36765.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: EH tree is invalid

[Dave Korn]

Piotr Wyderski wrote:
> Dave Korn wrote:
> 
>>  Are you using SJLJ or DW2 exceptions?
> 
> SJLJ only -- DW2 doesn't work on Windows if the exception
> handling scope crosses DLL boundaries.

  It does these days as long as you're using shared libraries, but that's a
separate issue.

>>  If SJLJ, does the patch at
>>
>>http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01628.html
>>
>> help the problem?
> 
> Hm, it seems that rev 146517 does not build on Cygwin,
> so I am unable to check it right now. But I'll try the patch
> ASAB (as soon as buildable :D)

  I just ran into this problem as well, try the attached.

cheers,
  DaveK
Index: gcc/sdbout.c
===
--- gcc/sdbout.c	(revision 146515)
+++ gcc/sdbout.c	(working copy)
@@ -771,7 +771,7 @@
 	return;
 
   SET_DECL_RTL (decl,
-		eliminate_regs (DECL_RTL (decl), 0, NULL_RTX));
+		eliminate_regs (DECL_RTL (decl), VOIDmode, NULL_RTX));
 #ifdef LEAF_REG_REMAP
   if (current_function_uses_only_leaf_regs)
 	leaf_renumber_regs_insn (DECL_RTL (decl));
@@ -1271,9 +1271,9 @@
 	/* Perform any necessary register eliminations on the parameter's rtl,
 	   so that the debugging output will be accurate.  */
 	DECL_INCOMING_RTL (parms)
-	  = eliminate_regs (DECL_INCOMING_RTL (parms), 0, NULL_RTX);
+	  = eliminate_regs (DECL_INCOMING_RTL (parms), VOIDmode, NULL_RTX);
 	SET_DECL_RTL (parms,
-		  eliminate_regs (DECL_RTL (parms), 0, NULL_RTX));
+		  eliminate_regs (DECL_RTL (parms), VOIDmode, NULL_RTX));
 
 	if (PARM_PASSED_IN_MEMORY (parms))
 	  {

GCC 4.4.1 Status Report (2009-04-21)

[Joseph S. Myers]

Status
==

GCC 4.4.0 has been built and uploaded today and 4.4 branch is open
under release branch rules for regression and documentation fixes
leading to the 4.4.1 release; the release will be announced once time
has been allowed for mirrors to pick up the files.  It is likely that
4.4.1 will be released in about two months' time.

Quality Data


Priority  # Change from Last Report
--- ---
P10 +- 0
P2   75 -  2
P39 +  8
--- ---
Total84 +  6

Previous Report
===

http://gcc.gnu.org/ml/gcc/2009-04/msg00406.html

The next report for 4.4.1 will be sent by Mark.

-- 
Joseph S. Myers
jos...@codesourcery.com

GCC 4.5.0 Status Report (2009-04-21)

[Joseph S. Myers]

Status
==

Trunk is in Stage 1.  It is expected that Stage 1 will last at least
four months (so ending no earlier than 27 July) and will be followed
by Stage 3 (bug-fix-only mode); whether it ends on 27 July may depend
on whether there remain unmerged features at that date that we wish to
merge for 4.5 and that seem sufficiently close to being ready to merge
to make it worth delaying the end of Stage 1.

Branches merged to trunk so far include alias-improvements,
c-4_5-branch and plugins.  Various changes have merged from gcc-in-cxx
and lto that are prerequisites for the main objects of those branches.

Quality Data


(Figures for changes are relative to today's 4.4 report as there have
been no previous 4.5 reports.)

Priority  # Change from Last Report
--- ---
P10 +- 0
P2   73 -  2
P3   15 +  6
--- ---
Total88 +  4

Previous Report
===

http://gcc.gnu.org/ml/gcc/2009-04/msg00564.html (4.4 report)

The next report for 4.5.0 will be sent by Mark.

-- 
Joseph S. Myers
jos...@codesourcery.com

http://gcc.gnu.org/gcc-4.4/changes.html

[Jack Howarth]

   A couple changes in gcc 4.4.0 were omitted for
the darwin target. The gcc 4.4.0 release now supports
a full multilib build on the x86_64-apple-darwin9 and
x86_64-apple-darwin10 targets. The gfortran compiler
is now capable of generating binaries linked against
the static libgfortran library using the compiler option
-static-libgfortran. FYI.
  Jack

Enable Ada when there is an Ada compiler? (Was: [PATCH] Simplified switch conversion in simple cases)

[Laurent GUERBY]

Hi,

What about enabling Ada build in 4.5 when configure finds out a suitable
Ada compiler?

Laurent

On Tue, 2009-04-21 at 22:28 +0200, Eric Botcazou wrote:
> This breaks Ada on x86:

Inefficient loads in certain loops depending on data declaration

[Jean Christophe Beyler]

Dear all,

As I work through handling load multiples and store multiples for my
target architecture, I came in front of this scenario:

int foo(int data[10240])
{
int w0, w1;
int part = 0,i ;

for (i=0; i<1;i+=2){
w0 = data[i];
w1 = data[i+1];
part += w0 + w1 ;
}

return part;
}


int bar(void)
{
int w0, w1;
int part = 0,i ;
int data[10240];

fillit (data);

for (i=0; i<1;i+=2){
w0 = data[i];
w1 = data[i+1];
part += w0 + w1 ;
}

return part;
}


In the case where data is defined as a parameter, I get two separate
loads with no offsets. GCC handles both loads separately. This means
more register pressure and more instructions in the loop. In essence I
get:

ld r1, (0)r5
ld r2, (0)r6

Instead of :

ld r1, (0)r5
ld r2, (8)r6

which I do get if the array is declared in the function.

I have written the address_cost function to handle this case and tell
the compiler that it is better to use the offsets but in this
scenario, the compiler is not calling the address cost function before
already getting those two different registers. So I don't why it's
already expanding those loads before getting to that call

Any ideas, thanks?
Jc

Re: Reserving a number of consecutive registers

[Jean Christophe Beyler]

Ok, I've been working at this and have actually made a bit of progress.

- I now have a framework that finds the group of loads (let's assume
they stay together).

- With the DF framework, I'm able to figure out which registers are
being used and which are free to be used.

- I've pretty much got it to change the registers to the ones I want
but there are still some corner cases where it seems to be badly
handling that and actually changing the semantics of the program.

I'll look into that, thanks,
Jc

On Mon, Apr 20, 2009 at 3:01 PM, Eric Botcazou  wrote:
>> Ok, I'll try to look at that. Is there an area where I can see how to
>> initialize the framework and get information about which registers are
>> free?
>
> The API is in df.h, see for example ifcvt.c.
>
> --
> Eric Botcazou
>

gcc-4.4-20090421 is now available

[gccadmin]

Snapshot gcc-4.4-20090421 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090421/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch 
revision 146539

You'll find:

gcc-4.4-20090421.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.4-20090421.tar.bz2 C front end and core compiler

gcc-ada-4.4-20090421.tar.bz2  Ada front end and runtime

gcc-fortran-4.4-20090421.tar.bz2  Fortran front end and runtime

gcc-g++-4.4-20090421.tar.bz2  C++ front end and runtime

gcc-java-4.4-20090421.tar.bz2 Java front end and runtime

gcc-objc-4.4-20090421.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.4-20090421.tar.bz2The GCC testsuite

Diffs from 4.4-20090414 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.4
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.