Re: [RFC] Cleaning up the pass manager

[Manuel López-Ibáñez]

On 15 June 2010 04:03, Diego Novillo  wrote:
> I have been thinking about doing some cleanups to the pass manager.
> The goal would be to have the pass manager be the central driver of
> every action done by the compiler.  In particular, the front ends
> should make use of it and the callgraph manager, instead of the
> twisted interactions we have now.
>
> Additionally, I would like to (at some point) incorporate some/most of
> the functionality provided by ICI
> (http://ctuning.org/wiki/index.php/CTools:ICI).  I'm not advocating
> for integrating all of ICI, but leave enough hooks so such
> experimentations are easier to do.

I don't think the ICI people follow this list. Perhaps you should contact them.

I would think that instead of hooks, a program should be able to call
pass_manager functions to query/add/remove/reorder passes within a
running program. That is, make the pass_manager a library that works
on passes. GCC would just call that library to implement its
particular pipeline.

But I understand that this is not low-hanging fruit.

Cheers,

Manuel.

Re: [RFC] Cleaning up the pass manager

[Joern Rennecke]

Quoting Manuel López-Ibáñez :


I would think that instead of hooks, a program should be able to call
pass_manager functions to query/add/remove/reorder passes within a
running program. That is, make the pass_manager a library that works
on passes. GCC would just call that library to implement its
particular pipeline.


With the ici low-level and ici pass-reordering plugins, you can already
use a file to specify pass ordering.

It should be straightforward to make a plugin that queries another program
about what pass reordering to do.

However, your description about reordering passes 'within a running program'
doesn't agree with how GCC is used today and what its passes are.

Of course, *plugins* can call pass manager functions - but in order to  
do this,

they first have to attain control.  So that'll be either in plugin_init or
in a hook.

Re: GCC 4.3.4 is casting my QImode vars to SImode for libcall

[Paulo J. Matos]

On Mon, Jun 14, 2010 at 8:56 PM, Joseph S. Myers
 wrote:
>
> Every hardcoded reference to a mode other than QImode in the
> target-independent compiler is suspicious and needs investigating if you
> are doing such a port.  In this case, the SImode references in
> expand_float are likely the problem.
>

Thanks for the tip Joseph, I will look into it.

-- 
PMatos

Re: GCC 4.3.4 is casting my QImode vars to SImode for libcall

[Paulo J. Matos]

On Mon, Jun 14, 2010 at 7:01 PM, Ian Lance Taylor  wrote:
> "Paulo J. Matos"  writes:
>
>> In gcc4.3.4, for my architecture: 16 BITS_PER_UNIT, 1 UNIT_PER_WORD,
>> with INT_TYPE_SIZE = 16 and FLOAT_TYPE_SIZE = 32, then an unsigned int
>> is QImode and a float is HFmode.
>>
>> However with:
>> float uitof(unsigned int x) { return x; }
>>
>> I get a call to the function __floatunsihf. Shouldn't this be __floatunqihf?
>
> Yes.  Something is wrong somewhere, but I don't know where.
>

Thanks for confirming this. I will look into it. Fortunately Joseph
Myers provided an insight of where the problem might be.

Cheers,
-- 
PMatos

Re: [RFC] Cleaning up the pass manager

[Richard Guenther]

On Tue, Jun 15, 2010 at 4:03 AM, Diego Novillo  wrote:
> I have been thinking about doing some cleanups to the pass manager.
> The goal would be to have the pass manager be the central driver of
> every action done by the compiler.  In particular, the front ends
> should make use of it and the callgraph manager, instead of the
> twisted interactions we have now.
>
> Additionally, I would like to (at some point) incorporate some/most of
> the functionality provided by ICI
> (http://ctuning.org/wiki/index.php/CTools:ICI).  I'm not advocating
> for integrating all of ICI, but leave enough hooks so such
> experimentations are easier to do.
>
> Initially, I'm going for some low hanging fruit:
>
> - Fields properties_required, properties_provided and
> properties_destroyed should Mean Something other than asserting
> whether they exist.
> - Whatever doesn't exist before a pass, needs to be computed.

How do you want to deal with dump-files needed by the
property computation?  How do we know that it is really only
the following pass that requires a property and not followup
passes (we have been very bad at asserting required properties
in passes).  I'm thinking of PRE which requires split critical
edges for example.

I think using properties can make things less obvious when
debugging what happens.

> - Pass scheduling can be done by simply declaring a pass and
> presenting it to the pass manager.  The property sets should be enough
> for the PM to know where to schedule a pass.

Ugh.  Please no - how should it know?  Do you want to
introduce PROP_run_after_ccp or what?  Or are you refering
to passes that are just information providers or massage
the IL, like crited or alias?

> - dump_file and dump_flags are no longer globals.

Ugh.

> Are there any particular pain points that people are currently
> experiencing that fit this?

No.  But I'd rather have somebody that wants to improve the
pass manager start to drive more things by it - that way we
will notice things we need before re-designing the whole thing
in a wrong way.

Thanks,
Richard.

Re: GCC 4.3.4 is casting my QImode vars to SImode for libcall

[Paulo J. Matos]

On Tue, Jun 15, 2010 at 9:17 AM, Paulo J. Matos  wrote:
> On Mon, Jun 14, 2010 at 8:56 PM, Joseph S. Myers
>  wrote:
>>
>> Every hardcoded reference to a mode other than QImode in the
>> target-independent compiler is suspicious and needs investigating if you
>> are doing such a port.  In this case, the SImode references in
>> expand_float are likely the problem.
>>
>
> Thanks for the tip Joseph, I will look into it.
>

The code in expand_float like you said seems to be the one causing the problem.

if (GET_MODE_SIZE (GET_MODE (from)) < GET_MODE_SIZE (SImode))
from = convert_to_mode (SImode, from, unsignedp);

I can't really see a reason why if the from mode has smaller size than
SImode than it has to be converted. Simply removing these lines
actually works.
However I can imagine that there _might_ be archs where the
non-integer modes are smaller than QImode and then there would be a
problem so the correct solution would be to change it to:

if (GET_MODE_SIZE (GET_MODE (from)) < GET_MODE_SIZE (QImode))
from = convert_to_mode (QImode, from, unsignedp);

Cheers,
-- 
PMatos

Re: GCC 4.3.4 is casting my QImode vars to SImode for libcall

[Paulo J. Matos]

On Tue, Jun 15, 2010 at 9:17 AM, Paulo J. Matos  wrote:
> On Mon, Jun 14, 2010 at 8:56 PM, Joseph S. Myers
>  wrote:
>>
>> Every hardcoded reference to a mode other than QImode in the
>> target-independent compiler is suspicious and needs investigating if you
>> are doing such a port.  In this case, the SImode references in
>> expand_float are likely the problem.
>>
>
> Thanks for the tip Joseph, I will look into it.
>
> --
> PMatos
>

Just noticed the following also in optabs.c:

  /* We can't do it with an insn, so use a library call.  But first ensure
 that the mode of TO is at least as wide as SImode, since those are the
 only library calls we know about.  */

  if (GET_MODE_SIZE (GET_MODE (to)) < GET_MODE_SIZE (SImode))
{
  target = gen_reg_rtx (SImode);
  expand_fix (target, from, unsignedp);
}


This comment provides some insight on to why gcc keeps converting to
SImode. However, I think (and it is at least applicable to my case)
that it should convert to  QImode and if there are no libraries, tell
the implementor of the backend to provide those functions. I can
imagine that in some archs, like mine SImode is just too big  and the
convertion turns out to be a pretty bad option.

-- 
PMatos

Re: Question about Machine Description

[yazdanbakhsh]

Hi,

I want to limit the size of immediate field of some operation. For example
somehow modify the machine description that the compiler supports only 0-255
for immediate operand.
I also want to change the compiler to the 2-address operand.
do you have any ideas?
I just need some hint

Best Regards,
-- 
View this message in context: 
http://old.nabble.com/Question-about-Machine-Description-tp1026428p2872.html
Sent from the gcc - Dev mailing list archive at Nabble.com.

typed gengtype & GCC plugins for both 4.5 & 4.6 - e.g. MELT

[Basile Starynkevitch]

Hello All,

I am in the process of merging 4.6 (i.e. current trunk) into the GCC
MELT branch. However, I want very much the same source code to be able
to run as a plugin to 4.5 & as a plugin to 4.6. So precisely, I want
to have gcc/melt-runtime.c from the MELT branch compilable as a plugin
melt.so both for GCC 4.5 & for GCC 4.6. Of course I am only speaking
of *source* compatibility (I do not want the *same* melt.so shared
object binary to be usable as a plugin for both 4.5 & 4.6, and I
believe it is not possible and should not be wished; obviously
compiling melt-runtime.c to melt.so would need different flags for 4.5
& 4.6).

For those unfamiliar with MELT http://gcc.gnu.org/wiki/MELT it is a
lispy domain specific language to code GCC extensions in, with
powerful pattern matching suitable to match GCC tree-s & gimple-s
etc., translated (by itself) into C code suitable for GCC. MELT has
its own copying garbage collector, built above ggc (so the copying is
done from the MELT nursery, and the old generation is GGC's heap).

The minor issue is to distinguish compilation for 4.5 from compilation
for 4.6. I believe that a simple trick like below is enough. This is
code I am adding inside my gcc/melt-runtime.h

   /*** NOTE: june 2010.  

GCC 4.6 has a new typed garbage collected allocator; so any
GTY-ed struct FOO_ST should be allocated using ggc_alloc_FOO_ST
or ggc_alloc_cleared_FOO_ST.
   ***/
   #if BUILDING_GCC_VERSION >= 4006 && defined(ggc_alloc_typed)
   #define MELT_HAS_TYPED_GGC_ALLOC 1
   #else
   #define MELT_HAS_TYPED_GGC_ALLOC 0
   #endif

By the way, perhaps defined(ggc_alloc_typed) would be enough above.


Of course the GGC allocation code should be different. For instance,
in my gcc/melt-runtime.c the function forwarded_copy would contain the
following piece of code, where struct meltobject_st is a GTY-ed struct
from gcc/melt-runtime.h

  #if MELT_HAS_TYPED_GGC_ALLOC
struct meltobject_st *dst =
  ggc_alloc_cleared_meltobject_st (oblen * sizeof (src->obj_vartab[0]));
  #else /*!MELT_HAS_TYPED_GGC_ALLOC*/
struct meltobject_st *dst = (struct meltobject_st *)
  ggc_alloc_cleared (offsetof (struct meltobject_st,
   obj_vartab) +
 oblen * sizeof (src->obj_vartab[0]));
  #endif /*MELT_HAS_TYPED_GGC_ALLOC*/

MELT uses a lot of "varying size" structures. For example MELT objects
are declared as

  typedef union melt_un *melt_ptr_t;
  typedef struct meltobject_st *meltobject_ptr_t;

  struct 
  GTY ((variable_size))
  meltobject_st
  {
/* for objects, the discriminant is their class */
meltobject_ptr_t obj_class;
unsigned obj_hash;  /* hash code of the object */
unsigned short obj_num;
  /* discriminate the melt_un containing it as discr */
  #define object_magic obj_num
unsigned short obj_len;
melt_ptr_t GTY ((length ("%h.obj_len"))) obj_vartab[FLEXIBLE_DIM];
  };

A small but annoying issue is that GCC 4.5's gengtype does not accept
the variable_size annotation, and I would want to have it ignore
it. As far as I know, gengtype don't like CPP conditionals; what I
really want is something like:


  #if MELT_HAS_TYPED_GGC_ALLOC
  struct 
  GTY ((variable_size))
  #else
  struct GTY (())
  #endif
  meltobject_st
  {
/* for objects, the discriminant is their class */
meltobject_ptr_t obj_class;
unsigned obj_hash;  /* hash code of the object */
unsigned short obj_num;
  /* discriminate the melt_un containing it as discr */
  #define object_magic obj_num
unsigned short obj_len;
melt_ptr_t GTY ((length ("%h.obj_len"))) obj_vartab[FLEXIBLE_DIM];
  };

But I am not sure it would work. What is the status of gengtype with
respect to preprocessor conditionals?

A possible hack for that would be to change in GCC 4.5.1 gengtype the error 

  build/gengtype /usr/src/Lang/basile-melt-gcc/gcc gtyp-input.list
  /usr/src/Lang/basile-melt-gcc/gcc/melt-runtime.h:431: unknown option 
`variable_size'

to a warning, perhaps specific to variable_size, something like
  /usr/src/Lang/basile-melt-gcc/gcc/melt-runtime.h:431: warning: 
`variable_size' is ignored

Is that possible, or is GCC 4.5.1 gengtype code frozen for every 4.5.x?

Other comments are welcome.

Cheers.

PS. I think this discussion is of general interest, because I could
imagine that some plugins will try hard to be compilable & used both
on gcc 4.5 & gcc 4.6. Of course, we cannot guarantee that it is doable
in the general case.

-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: Question about Machine Description

[Revital1 Eres]

Hello,

> I want to limit the size of immediate field of some operation.

I think you can look at SIGNED_INT_FITS_N_BITS definition at
config/crx/crx.c
for such example.
You can write a predicate like the following; and use it when describing
the immediate
operand in the md file.

(define_predicate "s24bits_operand"
  (match_code "const_int")
  {
return (SIGNED_INT_FITS_N_BITS(INTVAL(op), 24)) ? 1 : 0;
  }
)

Thanks,
Revital

Re: GCC 4.3.4 is casting my QImode vars to SImode for libcall

[Joseph S. Myers]

On Tue, 15 Jun 2010, Paulo J. Matos wrote:

> This comment provides some insight on to why gcc keeps converting to
> SImode. However, I think (and it is at least applicable to my case)
> that it should convert to  QImode and if there are no libraries, tell
> the implementor of the backend to provide those functions. I can
> imagine that in some archs, like mine SImode is just too big  and the
> convertion turns out to be a pretty bad option.

For targets with 8-bit bytes and 32-bit registers (and without hardware 
floating point), there is probably no point in having most conversion 
functions to/from QImode or HImode separate from those to/from SImode, as 
they likely wouldn't be any more efficient so would just make libgcc 
larger or add unnecessary aliases.  So maybe there should be a target hook 
indicating the narrowest integer mode for which there are conversion 
functions in libgcc, or something similar to that.  (Perhaps conversions 
from HImode to SFmode do make sense as separate from those from SImode to 
SFmode, in that they don't need to handle rounding so could be smaller and 
faster - but then you expand libgcc by having two functions instead of 
one.  On 8-bit and 16-bit targets it seems more likely conversion 
functions for QImode and HImode are useful, though again you are expanding 
libgcc and any program that uses both those and the SImode functions.)

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

Re: typed gengtype & GCC plugins for both 4.5 & 4.6 - e.g. MELT

[Richard Guenther]

On Tue, Jun 15, 2010 at 11:26 AM, Basile Starynkevitch
 wrote:
> Hello All,
>
> I am in the process of merging 4.6 (i.e. current trunk) into the GCC
> MELT branch. However, I want very much the same source code to be able
> to run as a plugin to 4.5 & as a plugin to 4.6. So precisely, I want
> to have gcc/melt-runtime.c from the MELT branch compilable as a plugin
> melt.so both for GCC 4.5 & for GCC 4.6. Of course I am only speaking
> of *source* compatibility (I do not want the *same* melt.so shared
> object binary to be usable as a plugin for both 4.5 & 4.6, and I
> believe it is not possible and should not be wished; obviously
> compiling melt-runtime.c to melt.so would need different flags for 4.5
> & 4.6).
>
> For those unfamiliar with MELT http://gcc.gnu.org/wiki/MELT it is a
> lispy domain specific language to code GCC extensions in, with
> powerful pattern matching suitable to match GCC tree-s & gimple-s
> etc., translated (by itself) into C code suitable for GCC. MELT has
> its own copying garbage collector, built above ggc (so the copying is
> done from the MELT nursery, and the old generation is GGC's heap).
>
> The minor issue is to distinguish compilation for 4.5 from compilation
> for 4.6. I believe that a simple trick like below is enough. This is
> code I am adding inside my gcc/melt-runtime.h
>
>   /*** NOTE: june 2010.
>
>        GCC 4.6 has a new typed garbage collected allocator; so any
>        GTY-ed struct FOO_ST should be allocated using ggc_alloc_FOO_ST
>        or ggc_alloc_cleared_FOO_ST.
>   ***/
>   #if BUILDING_GCC_VERSION >= 4006 && defined(ggc_alloc_typed)
>   #define MELT_HAS_TYPED_GGC_ALLOC 1
>   #else
>   #define MELT_HAS_TYPED_GGC_ALLOC 0
>   #endif
>
> By the way, perhaps defined(ggc_alloc_typed) would be enough above.
>
>
> Of course the GGC allocation code should be different. For instance,
> in my gcc/melt-runtime.c the function forwarded_copy would contain the
> following piece of code, where struct meltobject_st is a GTY-ed struct
> from gcc/melt-runtime.h
>
>  #if MELT_HAS_TYPED_GGC_ALLOC
>        struct meltobject_st *dst =
>          ggc_alloc_cleared_meltobject_st (oblen * sizeof 
> (src->obj_vartab[0]));
>  #else /*!MELT_HAS_TYPED_GGC_ALLOC*/
>        struct meltobject_st *dst = (struct meltobject_st *)
>          ggc_alloc_cleared (offsetof (struct meltobject_st,
>                                       obj_vartab) +
>                             oblen * sizeof (src->obj_vartab[0]));
>  #endif /*MELT_HAS_TYPED_GGC_ALLOC*/
>
> MELT uses a lot of "varying size" structures. For example MELT objects
> are declared as
>
>  typedef union melt_un *melt_ptr_t;
>  typedef struct meltobject_st *meltobject_ptr_t;
>
>  struct
>  GTY ((variable_size))
>  meltobject_st
>  {
>    /* for objects, the discriminant is their class */
>    meltobject_ptr_t obj_class;
>    unsigned obj_hash;          /* hash code of the object */
>    unsigned short obj_num;
>  /* discriminate the melt_un containing it as discr */
>  #define object_magic obj_num
>    unsigned short obj_len;
>    melt_ptr_t GTY ((length ("%h.obj_len"))) obj_vartab[FLEXIBLE_DIM];
>  };
>
> A small but annoying issue is that GCC 4.5's gengtype does not accept
> the variable_size annotation, and I would want to have it ignore
> it. As far as I know, gengtype don't like CPP conditionals; what I
> really want is something like:
>
>
>  #if MELT_HAS_TYPED_GGC_ALLOC
>  struct
>  GTY ((variable_size))
>  #else
>  struct GTY (())
>  #endif
>  meltobject_st
>  {
>    /* for objects, the discriminant is their class */
>    meltobject_ptr_t obj_class;
>    unsigned obj_hash;          /* hash code of the object */
>    unsigned short obj_num;
>  /* discriminate the melt_un containing it as discr */
>  #define object_magic obj_num
>    unsigned short obj_len;
>    melt_ptr_t GTY ((length ("%h.obj_len"))) obj_vartab[FLEXIBLE_DIM];
>  };
>
> But I am not sure it would work. What is the status of gengtype with
> respect to preprocessor conditionals?
>
> A possible hack for that would be to change in GCC 4.5.1 gengtype the error
>
>  build/gengtype /usr/src/Lang/basile-melt-gcc/gcc gtyp-input.list
>  /usr/src/Lang/basile-melt-gcc/gcc/melt-runtime.h:431: unknown option 
> `variable_size'
>
> to a warning, perhaps specific to variable_size, something like
>  /usr/src/Lang/basile-melt-gcc/gcc/melt-runtime.h:431: warning: 
> `variable_size' is ignored
>
> Is that possible, or is GCC 4.5.1 gengtype code frozen for every 4.5.x?

Yes, gengtype is frozen for functional changes on the branch.

> Other comments are welcome.
>
> Cheers.
>
> PS. I think this discussion is of general interest, because I could
> imagine that some plugins will try hard to be compilable & used both
> on gcc 4.5 & gcc 4.6. Of course, we cannot guarantee that it is doable
> in the general case.

And we specifically said this is not going to be possible.

Richard.

Re: typed gengtype & GCC plugins for both 4.5 & 4.6 - e.g. MELT

[Joern Rennecke]

Quoting Basile Starynkevitch :


A small but annoying issue is that GCC 4.5's gengtype does not accept
the variable_size annotation, and I would want to have it ignore
it. As far as I know, gengtype don't like CPP conditionals;


You can have a separate Makefile rule generate a header file without
conditionals using cpp, and then put the generated header file instead
of the original, so that gengtype will see the preprocessed header file.

Or if you still need conditional compilation in the header file that is
evaluated later, you could generate it with some other mechanism,
e.g. selecting from separate prepared files (or sets of file fragments)
during configure, or use a different preprocessor, e.g. m4.

Re: GCC 4.3.4 is casting my QImode vars to SImode for libcall

[Joern Rennecke]

Quoting "Joseph S. Myers" :


For targets with 8-bit bytes and 32-bit registers (and without hardware
floating point), there is probably no point in having most conversion
functions to/from QImode or HImode separate from those to/from SImode, as
they likely wouldn't be any more efficient so would just make libgcc
larger or add unnecessary aliases.


I think it is also a reflection of an 'all the world is (at least) 32 bit'
attitude - in part supported by the GNU coding standard as it was then
aimed at making an easily maintainable workstation / server operating system.
I.e. the C "int" type was assumed to be 32 bit.  And gcc stood for
'GNU C compiler' - and C has type promotion rules that mean you don't need
to convert floating point from/to integer types narrower than int.

Thus, it doesn't make sense to force extension to an integer mode wider than
an int.
Ports where int is smaller than SImode are few, and if you really want
an expansion, you can always force it with a define_expand.

Re: GCC 4.3.4 is casting my QImode vars to SImode for libcall

[Paulo J. Matos]

On Tue, Jun 15, 2010 at 10:42 AM, Joseph S. Myers
 wrote:
> On Tue, 15 Jun 2010, Paulo J. Matos wrote:
>
> For targets with 8-bit bytes and 32-bit registers (and without hardware
> floating point), there is probably no point in having most conversion
> functions to/from QImode or HImode separate from those to/from SImode, as
> they likely wouldn't be any more efficient so would just make libgcc
> larger or add unnecessary aliases.  So maybe there should be a target hook
> indicating the narrowest integer mode for which there are conversion
> functions in libgcc, or something similar to that.  (Perhaps conversions
> from HImode to SFmode do make sense as separate from those from SImode to
> SFmode, in that they don't need to handle rounding so could be smaller and
> faster - but then you expand libgcc by having two functions instead of
> one.
> On 8-bit and 16-bit targets it seems more likely conversion
> functions for QImode and HImode are useful, though again you are expanding
> libgcc and any program that uses both those and the SImode functions.)
>

I would think that the best would be to avoid implicit convertions to
SFmode that might awe backend devs for 'wierd' archs like me.
The target hook looks like a neat idea as it would keep current modes
as they are and for those of us in these archs, when we would get
undefined symbol errors for, lets say, floatunqihf, then we know that
we need to provide a definition for that as libgcc does not.

I don't think that libgcc should provide all possible conversions but
enabling the developer to know which conversions he has to include for
his particular backend seems rather important.

-- 
PMatos

Re: GCC 4.3.4 is casting my QImode vars to SImode for libcall

[Paulo J. Matos]

On Tue, Jun 15, 2010 at 11:46 AM, Joern Rennecke  wrote:
>
> I think it is also a reflection of an 'all the world is (at least) 32 bit'
> attitude - in part supported by the GNU coding standard as it was then
> aimed at making an easily maintainable workstation / server operating
> system.
> I.e. the C "int" type was assumed to be 32 bit.  And gcc stood for
> 'GNU C compiler' - and C has type promotion rules that mean you don't need
> to convert floating point from/to integer types narrower than int.
>

I can't understand those statements in the sense that GCC was meant to
be a generic compiler framework therefore having code tying GCC to
specific archs should be specific in the manual or elsewhere. I have
yet to understand what's the position of the GCC committee (or whoever
has the ultimate word on this) thinks. Is GCC slowly losing support
for certain archs or it is still striving to be as generic as
possible?

-- 
PMatos

Re: GCC 4.3.4 is casting my QImode vars to SImode for libcall

[Joern Rennecke]

Quoting "Paulo J. Matos" :


On Tue, Jun 15, 2010 at 11:46 AM, Joern Rennecke  wrote:


I think it is also a reflection of an 'all the world is (at least) 32 bit'
attitude - in part supported by the GNU coding standard as it was then
aimed at making an easily maintainable workstation / server operating
system.
I.e. the C "int" type was assumed to be 32 bit.  And gcc stood for
'GNU C compiler' - and C has type promotion rules that mean you don't need
to convert floating point from/to integer types narrower than int.



I can't understand those statements in the sense that GCC was meant to
be a generic compiler framework therefore having code tying GCC to
specific archs should be specific in the manual or elsewhere.


I was merely trying to give some historical context to help interpret
what that SImode check should really be.


Is GCC slowly losing support
for certain archs or it is still striving to be as generic as
possible?


GCC looses and gains support for architectures depending on the availability
of competent volunteer maintainers for these architectures.
Of course, 'volunteer' in this context can also mean that a company
volunteers to employ / contract with a developer to do this work.

Re: Question about Machine Description

[yazdanbakhsh]

Hi,

I'm working with GCC 2.7. I think, It doesn't support define_predict.
I define a c function in the mips.c file and add the following lines:

int
new_arith_operand (op, mode)
 rtx op;
 enum machine_mode mode;
{
  if (GET_CODE (op) == CONST_INT)
if(NEW_INT_UNSIGNED (op))
return TRUE;
else
return FALSE;

  return register_operand (op, mode);
}

I use the name of this function to check the value of the input operand.
When I compile the gcc the following error happens:

./libgcc2.c: In function `__divdi3':
./libgcc2.c:669: internal error--unrecognizable insn:
(insn 787 786 780 (set (reg:SI 104)
(ior:SI (reg:SI 104)
(const_int 65535))) -1 (insn_list 786 (nil))
(expr_list:REG_EQUAL (const_int 16777215)
(nil)))


I appreciate any help.

Regards
-- 
View this message in context: 
http://old.nabble.com/Question-about-Machine-Description-tp1026428p28890399.html
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: Question about Machine Description

[Manuel López-Ibáñez]

On 15 June 2010 14:01, yazdanbakhsh  wrote:
>
> I'm working with GCC 2.7. I think, It doesn't support define_predict.
> I define a c function in the mips.c file and add the following lines:
[...]
> I appreciate any help.

I think the best advice I can give you is: Use a recent GCC version.
GCC 2.7 is almost 10 years old.

Manuel.

Re: GCC 4.3.4 is casting my QImode vars to SImode for libcall

[Paulo J. Matos]

On Tue, Jun 15, 2010 at 1:00 PM, Joern Rennecke  wrote:
> Quoting "Paulo J. Matos" :
>
>> On Tue, Jun 15, 2010 at 11:46 AM, Joern Rennecke 
>> wrote:
>>>
>>> I think it is also a reflection of an 'all the world is (at least) 32
>>> bit'
>>> attitude - in part supported by the GNU coding standard as it was then
>>> aimed at making an easily maintainable workstation / server operating
>>> system.
>>> I.e. the C "int" type was assumed to be 32 bit.  And gcc stood for
>>> 'GNU C compiler' - and C has type promotion rules that mean you don't
>>> need
>>> to convert floating point from/to integer types narrower than int.
>>>
>>
>> I can't understand those statements in the sense that GCC was meant to
>> be a generic compiler framework therefore having code tying GCC to
>> specific archs should be specific in the manual or elsewhere.
>
> I was merely trying to give some historical context to help interpret
> what that SImode check should really be.
>

Yes, I understand, thanks. I am sorry if my reply seemed a bit
confrontational. That was not the intent.

>> Is GCC slowly losing support
>> for certain archs or it is still striving to be as generic as
>> possible?
>
> GCC looses and gains support for architectures depending on the availability
> of competent volunteer maintainers for these architectures.
> Of course, 'volunteer' in this context can also mean that a company
> volunteers to employ / contract with a developer to do this work.
>

But while the backends might vary as much as they like, the core gcc
code such as optabs.c should be as generic as possible, right?

-- 
PMatos

Re: Question about Machine Description

[yazdanbakhsh]

Actually, I'm working with simplescalar and it only supports gcc 2.9.
-- 
View this message in context: 
http://old.nabble.com/Question-about-Machine-Description-tp1026428p28890565.html
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: GCC 4.3.4 is casting my QImode vars to SImode for libcall

[Michael Matz]

Hi,

On Tue, 15 Jun 2010, Paulo J. Matos wrote:

> >> Is GCC slowly losing support for certain archs or it is still 
> >> striving to be as generic as possible?
> >
> > GCC looses and gains support for architectures depending on the 
> > availability of competent volunteer maintainers for these 
> > architectures. Of course, 'volunteer' in this context can also mean 
> > that a company volunteers to employ / contract with a developer to do 
> > this work.
> 
> But while the backends might vary as much as they like, the core gcc 
> code such as optabs.c should be as generic as possible, right?

That's the goal, yes.  Of course there are multiple level of generality, 
and some levels tend to bit-rot faster than others.  In particular support 
for QImode != 8 bits and mode(int)

Floating Point Representation in libgcc (is IEEE?)

[Paulo J. Matos]

Hi all,

I am implementing some function for conversion between modes (QI ->
HF, SF -> HI, etc). For this it would be useful to know the floating
point representation using in libgcc. However, I can't find any
description of it anywhere. Is it using IEEE floating point
representation?

Cheers,

-- 
PMatos

Re: typed gengtype & GCC plugins for both 4.5 & 4.6 - e.g. MELT

[Laurynas Biveinis]

2010/6/15 Basile Starynkevitch :
>   /*** NOTE: june 2010.
>
>        GCC 4.6 has a new typed garbage collected allocator; so any
>        GTY-ed struct FOO_ST should be allocated using ggc_alloc_FOO_ST
>        or ggc_alloc_cleared_FOO_ST.
>   ***/
>   #if BUILDING_GCC_VERSION >= 4006 && defined(ggc_alloc_typed)
>   #define MELT_HAS_TYPED_GGC_ALLOC 1
>   #else
>   #define MELT_HAS_TYPED_GGC_ALLOC 0
>   #endif
>
> By the way, perhaps defined(ggc_alloc_typed) would be enough above.

There is no guarantee ggc_alloc_typed won't change for 4.7 or even
4.6. If you really want to pursue this, perhaps try checking for a
typed allocator of a well-known GCC data type:
#if defined (ggc_alloc_rtx_def)
...

But then again, it may become a function instead of macro in 4.7,
breaking the test.

>  #if MELT_HAS_TYPED_GGC_ALLOC
>        struct meltobject_st *dst =
>          ggc_alloc_cleared_meltobject_st (oblen * sizeof 
> (src->obj_vartab[0]));
>  #else /*!MELT_HAS_TYPED_GGC_ALLOC*/
>        struct meltobject_st *dst = (struct meltobject_st *)
>          ggc_alloc_cleared (offsetof (struct meltobject_st,
>                                       obj_vartab) +
>                             oblen * sizeof (src->obj_vartab[0]));
>  #endif /*MELT_HAS_TYPED_GGC_ALLOC*/

I'd say, use a common ggc_alloc_cleared_meltobject_st which is made by
gengtype in 4.6+ and provide its suitable definition yourself for 4.5.

-- 
Laurynas

Re: Floating Point Representation in libgcc (is IEEE?)

[Joern Rennecke]

Quoting "Paulo J. Matos" :


Hi all,

I am implementing some function for conversion between modes (QI ->
HF, SF -> HI, etc). For this it would be useful to know the floating
point representation using in libgcc. However, I can't find any
description of it anywhere. Is it using IEEE floating point
representation?


It is using whatever floating point format the target has.
If you don't have hardware floating point support, then you get to
choose the format when you design your ABI.
Of course, basing the floating point format on IEEE is a popular choice,
albeit it is common to cut corners on subnormals / rounding modes / signals.
(This is merely an observation, not advocating for or against these
 practices.)

There are two C implementations of IEEE software floating point in the
GCC runtime:
- fp-bit.c, which is fairly old and slow, but requires little work to use
  if longlong.h supports your processor (which is also needed for GNU mp).
  It only has round-to-nearest, no signals, but subnormals work except for
  one rounding issue with division.
- soft-fp.  This is supposed to be a bit faster, but you need to define
  various primitives.  The default configuration is similar in features
  to fp-bit.c, but you can customize it for support of signals ('exceptions')
  and other rounding modes.

Some targets also have their own implementation in optimized assembly code.

Re: subreg against register allocation?

[Ian Lance Taylor]

"Amker.Cheng"  writes:

> here are three more questions
> 1 , If I am talking the right thing, there are two insns like
>"*mulsi3_1" and "*smulsi3_highpart_insn",
>  which set two parts of DImode pseudo regs of DImode mult.
>
> Since both parts pf result are used in the original example,
> I am not sure how to make split pattern to handle this case
> without generating two duplicate mult insns in parallel.

The idea is that you would have a single insn which sets two registers
in parallel, one to the high part of the mult and one to the low part.


> 2 , If I could set the two parts of result in parallel insn, I also have to
> handle mips specific constraints in this case, i.e, constraints
> for HI/LO registers.
> Unfortunately, There is no "h" constraint now according to patch
> http://gcc.gnu.org/ml/gcc-patches/2008-05/msg01750.html
>
> It is not possible to write hi reg without clobbering the lo reg now,
> How should I handle this?

That is kind of a fatal problem for this approach.  You would have to
reintroduce the "h" constraint, I guess.


> 3 , Since I am studying IRA right now, I am very curious about whether
> possible to solve this in IRA. e.g, by shrinking live ranges
> of multi-word pseudo regs?

I don't know.  My intuition is that it would be better to keep subreg
splitting separate from IRA, to avoid overcomplicating IRA.

Ian

Re: subreg against register allocation?

[Ian Lance Taylor]

Jeff Law  writes:

> Note that lower-subreg is rather conservative when determining what
> subregs to lower, particularly when the pseudo appears in different
> modes (ie, some accesses are via SUBREGs, others are naked REGs).  So
> this approach may not necessarily work.

Right; it only works if all uses of the subreg can be split.

Ian

Re: [Patch,Fortran,Committed] Re: Incorrect format of copyright statement for Fortran manuals

[Tobias Burnus]

On 06/13/2010 03:09 PM, Gerald Pfeifer wrote:
> On Mon, 7 Jun 2010, Tobias Burnus wrote:
>   
>>> It has been reported via the FSF that 'gfortran.info' is copyrighted by 
>>> the FSF '1999-2008', although it should be under the form '1999, 2000, 
>>> [other years], 2008'.
>>>   
>> Fixed in Rev. 160390 using the attached patch.
>> 
> Thanks, Tobias!
>
> Any chance you could make the similar change for GCC 4.5 as our active
> release as well?
>   
Fixed in Rev. 160797 using the attached patch.


Index: gfortran.texi
===
--- gfortran.texi   (revision 160796)
+++ gfortran.texi   (working copy)
@@ -1,7 +1,7 @@
 \input texinfo  @c -*-texinfo-*-
 @c %**start of header
 @setfilename gfortran.info
-...@set copyrights-gfortran 1999-2008
+...@set copyrights-gfortran 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010

 @include gcc-common.texi

Index: ChangeLog
===
--- ChangeLog   (revision 160796)
+++ ChangeLog   (working copy)
@@ -1,3 +1,8 @@
+2010-06-15  Tobias Burnus  
+
+   * gfc-internals.texi (copyrights-gfortran): Fix copyright year
format.
+   * gfortran.texi (copyrights-gfortran): Ditto.
+
 2010-06-15  Jakub Jelinek  

PR fortran/44536
Index: gfc-internals.texi
===
--- gfc-internals.texi  (revision 160796)
+++ gfc-internals.texi  (working copy)
@@ -1,7 +1,7 @@
 \input texinfo  @c -*-texinfo-*-
 @c %**start of header
 @setfilename gfc-internals.info
-...@set copyrights-gfortran 2007-2008
+...@set copyrights-gfortran 2007, 2008, 2009

 @include gcc-common.texi

Re: [RFC] Cleaning up the pass manager

[Jan Hubicka]

> I have been thinking about doing some cleanups to the pass manager.
> The goal would be to have the pass manager be the central driver of
> every action done by the compiler.  In particular, the front ends
> should make use of it and the callgraph manager, instead of the
> twisted interactions we have now.

This has been my goal for years, but somehow it always got off the top of
TODO list ;)
> 
> Additionally, I would like to (at some point) incorporate some/most of
> the functionality provided by ICI
> (http://ctuning.org/wiki/index.php/CTools:ICI).  I'm not advocating
> for integrating all of ICI, but leave enough hooks so such
> experimentations are easier to do.
> 
> Initially, I'm going for some low hanging fruit:
> 
> - Fields properties_required, properties_provided and
> properties_destroyed should Mean Something other than asserting
> whether they exist.
> - Whatever doesn't exist before a pass, needs to be computed.
> - Pass scheduling can be done by simply declaring a pass and
> presenting it to the pass manager.  The property sets should be enough
> for the PM to know where to schedule a pass.
> - dump_file and dump_flags are no longer globals.

One thing I would like to see (i.e. plan to add once I have time for it)
is to commonize normal 
> Are there any particular pain points that people are currently
> experiencing that fit this?
> 
> 
> Thanks.  Diego.

Re: typed gengtype & GCC plugins for both 4.5 & 4.6 - e.g. MELT

[Basile Starynkevitch]

On Tue, 2010-06-15 at 14:56 +0200, Laurynas Biveinis wrote:
> I'd say, use a common ggc_alloc_cleared_meltobject_st which is made by
> gengtype in 4.6+ and provide its suitable definition yourself for 4.5.

Thanks for the good advice.

BTW, I only want if possible MELT to work for 4.5 & 4.6, and "work"
simply means for me "ability to bootstrap itself" in the precise sense
of being able to regenerate the warmelt*.c files from the warmelt*.melt
files. In practice, this mostly depends upon the GGC & gengtype stuff
(for instance, it does not depend upon the gimple or tree APIs).

For the real useful stuff (for MELT users), that is for the ability to
code easily pattern-matching on Gimple etc etc, there are already all
the required features inside MELT (a MELT primitive can emit code which
is conditional on the targetted version of GCC, etc etc). 

Besides, the social organization of GCC makes quite difficult any major,
incompatible, changes on core GCC internal representations (like Gimple
or Tree-s). In practice, the API on Gimple or Tree-s is quite stable
(the last major evolution was the Tree -> Gimple transition of 4.4, and
MELT went thru it without pains).

Cheers.

-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: [RFC] Cleaning up the pass manager

[Basile Starynkevitch]

On Tue, 2010-06-15 at 18:38 +0200, Jan Hubicka wrote:

Citing Diego Novillo:
> > I have been thinking about doing some cleanups to the pass manager.

> This has been my goal for years, but somehow it always got off the top of
> TODO list ;)
> > 
> > Additionally, I would like to (at some point) incorporate some/most of
> > the functionality provided by ICI
> > (http://ctuning.org/wiki/index.php/CTools:ICI).  I'm not advocating
> > for integrating all of ICI, but leave enough hooks so such
> > experimentations are easier to do.

Good.

> > 
> > Initially, I'm going for some low hanging fruit:
> > 
> > - Fields properties_required, properties_provided and
> > properties_destroyed should Mean Something other than asserting
> > whether they exist.
> > - Whatever doesn't exist before a pass, needs to be computed.
> > - Pass scheduling can be done by simply declaring a pass and
> > presenting it to the pass manager.  The property sets should be enough
> > for the PM to know where to schedule a pass.
> > - dump_file and dump_flags are no longer globals.
> 
> One thing I would like to see (i.e. plan to add once I have time for it)
> is to commonize normal At the moment WHOPR WPA somehow stands away and LTO is implemented by breaking
> up the previously continuous pass queue into pieces.

I would also suggest a tiny incremental progress in documentation.
Perhaps it could be as simple as suggesting a common comment template
for passes. Also, some more conventions could be helpful, for example
that each pass is named FOO_pass and its name field should be "FOO" or
"*FOO" 

What I still don't understand well are simple things like:

what is the name (in the opt_pass sense) of a given pass?

what are the passes providing a valid cfun?

what are the passes keeping the function-s?

etc.

I believe that a structured comment could help. When - in many
years :-( - the powerful people (Steering Committee, FSF, RMS, ...)
would accept the idea of generating documentation from code [and
implement the legalese allowing it thru appropriate exceptions, or legal
notices, or licenses], we could even imagine have an automatically
generated chapter documenting the passes. We could also imagine a
Graphviz *.dot file describing the graph of all passes.

Cheers!
-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: subreg against register allocation?

[Ulrich Weigand]

Bernd Schmidt wrote:
> On 06/15/2010 12:06 AM, Ian Lance Taylor wrote:
> > Well, as you know, subregs have two meanings which look similar but
> > are in fact entirely different.  It's valid to set subregs of the same
> > pseudo in parallel if the subregs represent different hard registers.
> > It's not valid if the subregs represent different pieces of the same
> > hard register.
> 
> Are you aware of any examples of this in the compiler?  The explanation
> is of course plausible, but do we know that we handle this correctly
> everywhere?

I ran into problems trying to do this on s390; that's why e.g. the
divmod patterns now look like

  [(set (match_operand:TI 0 "register_operand" "=d,d")
(ior:TI
  (ashift:TI
(zero_extend:TI
  (mod:DI (match_operand:DI 1 "register_operand" "0,0")
  (match_operand:DI 2 "general_operand" "d,RT")))
(const_int 64))
  (zero_extend:TI (div:DI (match_dup 1) (match_dup 2)]

instead of a parallel set of two subregs.  In particular, there seemed
to be problems with dataflow not recognizing a parallel set of two
subregs as actually fully setting the whole register ...

But of course, that was a long time ago, maybe the new dataflow
mechanism has fixed this now.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  ulrich.weig...@de.ibm.com

Re: Question about Machine Description

[Ian Lance Taylor]

yazdanbakhsh  writes:

> I'm working with GCC 2.7.

I think I see your problem.


> I think, It doesn't support define_predict.
> I define a c function in the mips.c file and add the following lines:
>
> int
> new_arith_operand (op, mode)
>  rtx op;
>  enum machine_mode mode;
> {
>   if (GET_CODE (op) == CONST_INT)
>   if(NEW_INT_UNSIGNED (op))
>   return TRUE;
>   else
>   return FALSE;
>
>   return register_operand (op, mode);
> }
>
> I use the name of this function to check the value of the input operand.
> When I compile the gcc the following error happens:
>
> ./libgcc2.c: In function `__divdi3':
> ./libgcc2.c:669: internal error--unrecognizable insn:
> (insn 787 786 780 (set (reg:SI 104)
> (ior:SI (reg:SI 104)
> (const_int 65535))) -1 (insn_list 786 (nil))
> (expr_list:REG_EQUAL (const_int 16777215)
> (nil)))

Make sure your constraint characters are consistent with your
predicate.  If your constraint has an 'i', then reload won't know that
it needs to push the out-of-range constant into a register.

Ian

Re: [RFC] Cleaning up the pass manager

[Manuel López-Ibáñez]

On 15 June 2010 10:40, Richard Guenther  wrote:
> On Tue, Jun 15, 2010 at 4:03 AM, Diego Novillo  wrote:
>
>> - Pass scheduling can be done by simply declaring a pass and
>> presenting it to the pass manager.  The property sets should be enough
>> for the PM to know where to schedule a pass.
>
> Ugh.  Please no - how should it know?  Do you want to
> introduce PROP_run_after_ccp or what?  Or are you refering
> to passes that are just information providers or massage
> the IL, like crited or alias?

It seems someone has done this before, so, in principle, it is possible:

http://llvm.org/docs/WritingAnLLVMPass.html#passmanager

Cheers,

Manuel.

Re: [RFC] Cleaning up the pass manager

[Joern Rennecke]

Quoting Basile Starynkevitch :


I believe that a structured comment could help. When - in many
years :-( - the powerful people (Steering Committee, FSF, RMS, ...)
would accept the idea of generating documentation from code [and
implement the legalese allowing it thru appropriate exceptions, or legal
notices, or licenses], we could even imagine have an automatically
generated chapter documenting the passes. We could also imagine a
Graphviz *.dot file describing the graph of all passes.


If you add the autogenerating feature first, before the source input
of the document autogenerator, each contributor can provide the
diffs of the autogenerated documentation long with a GFDL license
when (s)he submits a patch.

While that is not as nice as being able to have source-only patches and
let anyone generate the documentation, it is something that we can do
now, and at the same time we can show more specifically how a licensing
change would benefit Free Software documentation, and is indeed necessary
to have truly Free software and documentation.
I really would like to see a new version of the GPL so that what RMS / the
FSF currently deems necessary to put in GFDL invariant sections can be put
in author's notices under extended version of the current GPL 7b provision,
so that we can have our code and documentation under single license.

Re: Floating Point Representation in libgcc (is IEEE?)

[Basile Starynkevitch]

On Tue, 2010-06-15 at 13:28 +0100, Paulo J. Matos wrote:
> Hi all,
> 
> I am implementing some function for conversion between modes (QI ->
> HF, SF -> HI, etc). For this it would be useful to know the floating
> point representation using in libgcc. However, I can't find any
> description of it anywhere. Is it using IEEE floating point
> representation?


I might be very wrong (back-ends & floating points are things I don't
really know much about), but I would imagine that libgcc implement the
minimal runtime code -used to run your applications compiled by GCC-
useful for floating point. If this is true, then libgcc implement the
floating point number as provided, supported, or suggested by the target
hardware & system [which is different on Vax & on x86, for instance].

Within the GCC compiler, floating points are represented by the struct
real_value defined in gcc/real.h, and not by the native double numbers
of the host system (the one running GCC). This is probably needed to
permit bizarre GCC uses like cross-compiling from an IBM Serie Z (the
successor to IBM 370 etc.) to e.g. a Dec Alpha.

Of course, most GCC users probably run it on some x86 under Linux or
Cygwin (and perhaps cross-compile for an ARM target), but GCC is
designed to support very strange hosts & targets, in particular systems
with non IEEE 754 floating point numbers.

Cheers.
-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

gcc-4.4-20100615 is now available

[gccadmin]

Snapshot gcc-4.4-20100615 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100615/
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 160814

You'll find:

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

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

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

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

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

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

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

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

Diffs from 4.4-20100608 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.

Write permission but connection refused

[Douglas B Rupp]

I can no longer make check ins to the gcc repository, it's been a few 
months since my last check in, which worked fine.


I get:
ssh: connect to host gcc.gnu.org port 22: Connection refused
svn: Connection closed unexpectedly

anonymouse access works fine.

I'm "r...@gcc.gnu.org"

If someone could point me to the correct person to contact for help, it 
would be much appreciated.

Re: Write permission but connection refused

[Dave Korn]

On 16/06/2010 02:08, Douglas B Rupp wrote:
> 
> I can no longer make check ins to the gcc repository, it's been a few
> months since my last check in, which worked fine.
> 
> I get:
> ssh: connect to host gcc.gnu.org port 22: Connection refused
> svn: Connection closed unexpectedly
> 
> anonymouse access works fine.
> 
> I'm "r...@gcc.gnu.org"
> 
> If someone could point me to the correct person to contact for help, it
> would be much appreciated.

  If it's not just a transient failure but continues to play up, (and after
checking the firewall and networking config in general at your end), the
maintenance of gcc.gnu.org and sourceware.org is handled by the overseers
mailing list: overseers sourceware org (insert at and dot where appropriate).

http://sourceware.org/ml/overseers/

cheers,
  DaveK