Re: [RFC] porting to gcc-4.3 docs

[Andrew Haley]

Benjamin Kosnik writes:
 > 
 > > Attached is a rough cut of a detailed portability document
 > 
 > I also put this up here temporarily:
 > 
 > http://people.redhat.com/~bkoz/porting_to_gcc43.html

The "Java issues" part isn't quite right.  It turns out that the java
1.2 problem with the new gcj is really a bug in Ant, and there's
already a patch in Ant trunk to fix it.

So, to build with gcc-4.3 and Ant you'll need this patch:

svn diff -r529854:529855 
http://svn.apache.org/repos/asf/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/compilers/DefaultCompilerAdapter.java


r529855 | bodewig | 2007-04-18 05:17:52 +0100 (Wed, 18 Apr 2007) | 1 line

Java 6's javac doesn't understand -source 1.1 either (found by Gump and the 
log4j build 
)

Index: 
src/main/org/apache/tools/ant/taskdefs/compilers/DefaultCompilerAdapter.java
===
--- 
src/main/org/apache/tools/ant/taskdefs/compilers/DefaultCompilerAdapter.java
(revision 529854)
+++ 
src/main/org/apache/tools/ant/taskdefs/compilers/DefaultCompilerAdapter.java
(revision 529855)
@@ -321,10 +321,10 @@
 if (attributes.getSource() != null && !assumeJava13()) {
 cmd.createArgument().setValue("-source");
 String source = attributes.getSource();
-if ((assumeJava14() || assumeJava15())
-&& (source.equals("1.1") || source.equals("1.2"))) {
+if (source.equals("1.1") || source.equals("1.2")) {
 // support for -source 1.1 and -source 1.2 has been
-// added with JDK 1.4.2 - and isn't present in 1.5.0 either
+// added with JDK 1.4.2 - and isn't present in 1.5.0
+// or 1.6.0 either
 cmd.createArgument().setValue("1.3");
 } else {
 cmd.createArgument().setValue(source);

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 
1TE, UK
Registered in England and Wales No. 3798903

Re: Changes in C++ FE regarding pedwarns to be errors are harmful

[Paolo Bonzini]

Andrew Pinski wrote:

On 1/8/08, Ismail Dönmez <[EMAIL PROTECTED]> wrote:

Oh that clears up my confusion. So the right fix would be downgrading this
redefinition problem to be pedwarn instead. But I see no point in creating a
bug report if its just gonna be closed as invalid, so I hope we can discuss
if its feasible to downgrade this error to be a pedwarn.


It is already a pedwarn.  Just the C++ front-end enables pedwarn as
being errors by default and downgrades them as being warnings with
-fpermissive.  This is the whole point of -fpermissive.


Not at all!!! -fpermissive can (in weird cases, agreed) change code 
generation.  I'm pretty sure you don't want to risk that only to silence 
an error.


I wonder if this requires a new diagnostic category, something like:

  if (pedantic)
pedwarn ("...")
  else
warning ("...")

Paolo

Re: internal compiler error: Segmentation fault

[FX]

[for [EMAIL PROTECTED] and [EMAIL PROTECTED] readers, seeshort  thread
starting at http://gcc.gnu.org/ml/fortran/2008-01/msg00103.html]

> Gcc gets the similar problem. It only works without optimization. It seems 
> not a problem with gfortran.

OK, then it'd be more appropriate to ask the mingw mailing-list or the
generic gcc@gcc.gnu.org list.

> GMP version is 4.2.2, and has been modified for x86_64. The original 4.2.2 
> does not support x86_64-pc-mingw32.

Does GMP pass tests? Have you built it with extra checking enabled? I
don't suspect what you're seeing is a GMP problem, but you can never
be too sure.

> I do not have gdb for windows for the time being.

That's why I gave you a download link for MS debuggers (I don't think
gdb is supported on x86_64-mingw32). I'm not sure much can be done
without a debugger.

FX

Re: internal compiler error: Segmentation fault

[Kai Tietz]

> [for [EMAIL PROTECTED] and [EMAIL PROTECTED] readers, seeshort  thread
> starting at http://gcc.gnu.org/ml/fortran/2008-01/msg00103.html]
> 
> > Gcc gets the similar problem. It only works without optimization. 
> It seems not a problem with gfortran.
> 
> OK, then it'd be more appropriate to ask the mingw mailing-list or the
> generic gcc@gcc.gnu.org list.
> 
> > GMP version is 4.2.2, and has been modified for x86_64. The 
> original 4.2.2 does not support x86_64-pc-mingw32.
> 
> Does GMP pass tests? Have you built it with extra checking enabled? I
> don't suspect what you're seeing is a GMP problem, but you can never
> be too sure.

To have a better chance to find the issue could you anwser these question?

a) Does this happens on a cross compiler, too? You can get on via the 
mingw-w64 pages on sourceforge.
b) Which runtime version of mingw-w64 you are using?
c) How did you compile gmp? As reference may take a look at 
http://terpstra.ca/lurker/message/20071208.235835.12a77213.en.html
This is a patch for gmp seems to work with mingw-w64 runtime as author 
tells.

> > I do not have gdb for windows for the time being.
> 
> That's why I gave you a download link for MS debuggers (I don't think
> gdb is supported on x86_64-mingw32). I'm not sure much can be done
> without a debugger.
I am currently on gdb support for x86_64 mingw target. But I expect, it 
will still take some time until I publish.

Cheers,
 i.A. Kai Tietz

|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.

--
  OneVision Software Entwicklungs GmbH & Co. KG
  Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
  Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com
  Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
  Handelsregister: HRA 6744, Amtsgericht Regensburg
  Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH
  Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg
  Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: 
Ulrike Döhler, Manuela Kluger

Re: Changes in C++ FE regarding pedwarns to be errors are harmful

[Manuel López-Ibáñez]

On 09/01/2008, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> Andrew Pinski wrote:
> > On 1/8/08, Ismail Dönmez <[EMAIL PROTECTED]> wrote:
> >> Oh that clears up my confusion. So the right fix would be downgrading this
> >> redefinition problem to be pedwarn instead. But I see no point in creating 
> >> a
> >> bug report if its just gonna be closed as invalid, so I hope we can discuss
> >> if its feasible to downgrade this error to be a pedwarn.
> >
> > It is already a pedwarn.  Just the C++ front-end enables pedwarn as
> > being errors by default and downgrades them as being warnings with
> > -fpermissive.  This is the whole point of -fpermissive.
>
> Not at all!!! -fpermissive can (in weird cases, agreed) change code
> generation.  I'm pretty sure you don't want to risk that only to silence
> an error.

What? That doesn't make any sense. And it is certainly not documented
in the manual. I will be very interested in an example, no matter how
weird or uncommon.

As far as I understand, if you get an error, no code is generated. If
you use -fpermissive and downgrade it to a warning, then code is
generated. Yes, no code is different from code but I won't call that
"changing code generation". If the code is wrong, then what is the
point of allowing it to be downgraded to a warning? If the code is not
conforming that is what the warning is telling you anyway and if you
ignore, you assume your risk.

So, I still think my analysis above is valid.

Cheers,

Manuel.

Re: Changes in C++ FE regarding pedwarns to be errors are harmful

[Paolo Bonzini]

Not at all!!! -fpermissive can (in weird cases, agreed) change code
generation.  I'm pretty sure you don't want to risk that only to silence
an error.


What? That doesn't make any sense. And it is certainly not documented
in the manual. I will be very interested in an example, no matter how
weird or uncommon.


Uhm, I might be confusing it with -ffriend-injection (which is in some 
sense more permissive than -fno-friend-injection).


Reading "in some case name lookup will not be standard conforming" in 
bkoz's document at http://people.redhat.com/~bkoz/porting_to_gcc43.html 
added to my confusion.


Paolo

Re: internal compiler error: Segmentation fault

[FX]

> To have a better chance to find the issue could you anwser these question?

I'll let J. answer these himself, since I have no direct experience of
the bug myself (no Win64 machine), but...

> a) Does this happens on a cross compiler, too?

I doubt it, since he sees the bug even on trivial programs at -O1 and,
last time I tried, cross-compilers worked fairly well.

> b) Which runtime version of mingw-w64 you are using?

I've asked, but got no answer.

> I am currently on gdb support for x86_64 mingw target. But I expect, it
> will still take some time until I publish.

That's great news nonetheless!

-- 
FX Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

Re: hard_regno_nregs == 0 ?

[Ian Lance Taylor]

DJ Delorie <[EMAIL PROTECTED]> writes:

> In rtlanal.c we have these lines:
> 
>   nregs_ymode = hard_regno_nregs[xregno][ymode];
>   ...
>   && (GET_MODE_SIZE (ymode) % nregs_ymode) == 0)
> 
> The m32c cc1 crashes here because xregno is 1 and ymode is QI, and
> register 1 cannot hold a QI value (there are no QImode ops that take
> that register), so hard_regno_nregs[1][QI] is zero, which causes a
> SIGFPE.
> 
> Which assumption is wrong?  That hard_regno_nregs can be zero (m32c),
> or that hard_regno_nregs will never be zero (rtlanal)?

I would first ask why subreg_get_info is being called with ymode ==
QImode for a hard register which can not hold QImode.  That implies
that there is a QImode value in the register, which you say is
invalid.

Ian

Re: hard_regno_nregs == 0 ?

[DJ Delorie]

> I would first ask why subreg_get_info is being called with ymode ==
> QImode for a hard register which can not hold QImode.  That implies
> that there is a QImode value in the register, which you say is
> invalid.

Are there any ports besides m32c that have registers which can hold HI
(or SI I suppose) but not QI values?

What I've done as a workaround is check for the zero and fail nicely:

Index: rtlanal.c
===
--- rtlanal.c   (revision 131405)
+++ rtlanal.c   (working copy)
@@ -3135,12 +3135,20 @@ subreg_get_info (unsigned int xregno, en
   else
info->offset = 0;
   info->nregs = nregs_ymode;
   return;
 }
 
+  if (nregs_ymode == 0)
+{
+  info->representable_p = false;
+  info->nregs = 1;
+  info->offset = offset;
+  return false;
+}
+
   /* If registers store different numbers of bits in the different
  modes, we cannot generally form this subreg.  */
   if (!HARD_REGNO_NREGS_HAS_PADDING (xregno, xmode)
   && !HARD_REGNO_NREGS_HAS_PADDING (xregno, ymode)
   && (GET_MODE_SIZE (xmode) % nregs_xmode) == 0
   && (GET_MODE_SIZE (ymode) % nregs_ymode) == 0)

Re: Changes in C++ FE regarding pedwarns to be errors are harmful

[Ian Lance Taylor]

"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:

> Of course there is a third option:
> 
> * Make pedwarns warnings by default unless -Werror or
> --pedantic-errors are given (just like the C front-end).

This makes sense to me.  I have never understood why it is a good idea
for the C++ and C frontends to differ in this way.

Ian

Re: [RFC] porting to gcc-4.3 docs

[Ian Lance Taylor]

Benjamin Kosnik <[EMAIL PROTECTED]> writes:

> As such, I'd like to get a general indication from the greater GCC
> community as to this plan. Does this document seem like a good idea?
> (Previously, we've left this kind of document to the user community.
> Often the passage of time has not been particularly kind to these
> links.) Is the suggested placement ok for everybody?

I think this is a great idea.  Thanks for writing it.

Ian

Re: about regenerate new configure script file

[Ian Lance Taylor]

tian xiaonan <[EMAIL PROTECTED]> writes:

> Hi, All.  I don't know How to regenerate a new
> configure file while added new target on config.sub,
> and gcc/config.gcc. I am a newcomer in using GCC.

Changing config.sub and/or gcc/config.gcc does not require
regenerating the configure script.

If you change configure.in, you will need to regenerate the configure
script.  The tool for this is autoconf, as it says at the top of the
gnerated configure file.

Ian

Re: hard_regno_nregs == 0 ?

[Ian Lance Taylor]

DJ Delorie <[EMAIL PROTECTED]> writes:

> > I would first ask why subreg_get_info is being called with ymode ==
> > QImode for a hard register which can not hold QImode.  That implies
> > that there is a QImode value in the register, which you say is
> > invalid.
> 
> Are there any ports besides m32c that have registers which can hold HI
> (or SI I suppose) but not QI values?

Good point.  I would normally say that they can hold QI values--after
all, they can--but use register constraints for any QI operations.
Treat movqi for such registers as movhi, or whatever.

Ian

Re: Changes in C++ FE regarding pedwarns to be errors are harmful

[Benjamin Kosnik]

>> Of course there is a third option:
>> * Make pedwarns warnings by default unless -Werror or
>> --pedantic-errors are given (just like the C front-end).

>This makes sense to me.  I have never understood why it is a good idea
>for the C++ and C frontends to differ in this way.

Me too. The current error behavior just seems gratuitous. What was the
rationale for this change to error instead of warn? I am having
problems locating this discussion on gcc-patches.

-benjamin

Re: Changes in C++ FE regarding pedwarns to be errors are harmful

[Paolo Carlini]

Andrew Pinski wrote:
> constaint
*consistent*

Paolo.

Allocating scratch register

[Boris Boesler]

Hi!

 I'm trying to allocate a scratch register: write immediate constant  
into scratch register r, write register r into memory


;; write imm into memory
(define_insn_and_split "mov_imm_by_store"
  [(set (match_operand:I8I16 0 "memory_operand""=m")
(match_operand:I8I16 1 "immediate_operand" " i"))
  (clobber (match_scratch:I8I16 2 "=r"))]
  ""
  "#"
  ""
  [(parallel
[(set (match_dup 2) (match_dup 1))
 (set (match_dup 0) (match_dup 2))])]
  ""
)

 I found that in a mips back-end. But this pattern is not recognized  
during code-generation [char c1; c1 = 1;]:

simple-memory.c:19: error: unrecognizable insn:
(insn 12 11 14 3 (set (mem/c/i:QI (reg/f:SI 105) [0 c1+0 S8])
(const_int 1 [0x1])) -1 (nil)
(nil))

 If I remove the clobber command and replace (match_dup 2) by  
(reg:I8I16 A15_REGNUM) code will be generated (but not as wanted).


 What is wrong with the code above?

Thanks,
Boris

Re: Changes in C++ FE regarding pedwarns to be errors are harmful

[Andrew Pinski]

On 1/9/08, Benjamin Kosnik <[EMAIL PROTECTED]> wrote:
> Me too. The current error behavior just seems gratuitous. What was the
> rationale for this change to error instead of warn? I am having
> problems locating this discussion on gcc-patches.

The recent preprocessor change or the older front-end change?

The older front-end change was done at
http://gcc.gnu.org/ml/gcc-patches/1998-12/msg00137.html .

The preprocessor change was done so the front-end was constaint with
the preprocessor and this was
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24924.

Thanks,
Andrew Pinski

Re: hard_regno_nregs == 0 ?

[Jim Wilson]

DJ Delorie wrote:

Which assumption is wrong?  That hard_regno_nregs can be zero (m32c),
or that hard_regno_nregs will never be zero (rtlanal)?


I would say the m32c port is wrong.  HARD_REGNO_MODE_OK indicates 
whether a register can hold a mode.  HARD_REGNO_NREGS indicates how many 
registers we need to hold a value.  This is a number that can be larger 
than 1 if the value is larger than one register, but it makes no sense 
for it to be zero, as no (non-void) value can ever be held in zero 
registers.  The number of registers needed is irrespective of whether 
the register can actually hold the value, as that is specified by 
HARD_REGNO_MODE_OK.  There are lots of places that use HARD_REGNO_NREGS 
in division/modulus operations.  It would be complicated to fix them all 
to handle a zero value.


However, as Ian mentioned, there does seem to be something else wrong 
here, as it seems odd that you have an invalid subreg being passed in here.

--
Jim Wilson, GNU Tools Support, http://www.specifix.com

Re: Changes in C++ FE regarding pedwarns to be errors are harmful

[Mark Mitchell]

Ian Lance Taylor wrote:
> "Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
> 
>> Of course there is a third option:
>>
>> * Make pedwarns warnings by default unless -Werror or
>> --pedantic-errors are given (just like the C front-end).
> 
> This makes sense to me.  I have never understood why it is a good idea
> for the C++ and C frontends to differ in this way.

I think Jason's input would be helpful.  I remember having a discussion
about this years ago (1998?), but I don't remember the complete
rationale.  I think the idea was that we wanted many of these things
(ugly old ARM-era C++ things) to be errors, but didn't want to make it
impossible to compile old code.  They're not "pedantic" in the sense
that you only care if you're trying extremely hard to be ISO-conformant;
 they're things no sane C++ programmer would do at this point, but we
want to support for legacy C++ code.

I don't see any a priori problem with changing to match the C front end.
 We could of course change some of the pedwarns into errors if we really
think they ought to be errors.  Or, some of them could be ordinary
warnings when not -pednatic, and pedwarns when -pedantic.

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: hard_regno_nregs == 0 ?

[Jim Wilson]

DJ Delorie wrote:

Are there any ports besides m32c that have registers which can hold HI
(or SI I suppose) but not QI values?


IA-64 has branch registers that are only allowed to hold DImode values. 
 We use CANNOT_CHANGE_MODE_CLASS to enforce this.


On x86, the vector registers can hold SImode, but do not allow 
HImode/QImode loads, and again CANNOT_CHANGE_MODE_CLASS is used to 
enforce this.


I'm sure that there are other examples out there.
--
Jim Wilson, GNU Tools Support, http://www.specifix.com

Re: hard_regno_nregs == 0 ?

[DJ Delorie]

How about this change, then?  (I'm still testing the m32c change, too)

2008-01-09  DJ Delorie  <[EMAIL PROTECTED]>

* doc/tm.texi (HARD_REGNO_NREGS): Note that this macro must not
return zero.

Index: doc/tm.texi
===
--- doc/tm.texi (revision 131434)
+++ doc/tm.texi (working copy)
@@ -2076,13 +2076,15 @@ This section discusses the macros that d
 (specifically, which machine modes) each register can hold, and how many
 consecutive registers are needed for a given mode.
 
 @defmac HARD_REGNO_NREGS (@var{regno}, @var{mode})
 A C expression for the number of consecutive hard registers, starting
 at register number @var{regno}, required to hold a value of mode
[EMAIL PROTECTED]
[EMAIL PROTECTED]  This macro must never return zero, even if a register
+cannot hold the requested mode - indicate that with HARD_REGNO_MODE_OK
+and/or CANNOT_CHANGE_MODE_CLASS instead.
 
 On a machine where all registers are exactly one word, a suitable
 definition of this macro is
 
 @smallexample
 #define HARD_REGNO_NREGS(REGNO, MODE)\

Re: hard_regno_nregs == 0 ?

[Paul Brook]

>  @defmac HARD_REGNO_NREGS (@var{regno}, @var{mode})
>  A C expression for the number of consecutive hard registers, starting
>  at register number @var{regno}, required to hold a value of mode
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]  This macro must never return zero, even if a register
> +cannot hold the requested mode - indicate that with HARD_REGNO_MODE_OK
> +and/or CANNOT_CHANGE_MODE_CLASS instead.

I find this somewhat unclear - It seems to imply that HARD_REGNO_NREGS may be 
called even when HARD_REGNO_MODE_OK returns false.

How about:

This macro must return a nonzero value for all combinations permitted by 
HARD_REGNO_MODE_OK and CANNOT_CHANGE_MODE_CLASS.

Paul

Re: hard_regno_nregs == 0 ?

[DJ Delorie]

> I find this somewhat unclear - It seems to imply that HARD_REGNO_NREGS may be 
> called even when HARD_REGNO_MODE_OK returns false.

That's exactly the case that's happening for m32c, and for which the
new text is needed.

gcc-4.2-20080109 is now available

[gccadmin]

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

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

You'll find:

gcc-4.2-20080109.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.2-20080109.tar.bz2 C front end and core compiler

gcc-ada-4.2-20080109.tar.bz2  Ada front end and runtime

gcc-fortran-4.2-20080109.tar.bz2  Fortran front end and runtime

gcc-g++-4.2-20080109.tar.bz2  C++ front end and runtime

gcc-java-4.2-20080109.tar.bz2 Java front end and runtime

gcc-objc-4.2-20080109.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.2-20080109.tar.bz2The GCC testsuite

Diffs from 4.2-20080102 are available in the diffs/ subdirectory.

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

Re: Allocating scratch register

[Ian Lance Taylor]

Boris Boesler <[EMAIL PROTECTED]> writes:

>   I'm trying to allocate a scratch register: write immediate constant  
> into scratch register r, write register r into memory
> 
> ;; write imm into memory
> (define_insn_and_split "mov_imm_by_store"
>[(set (match_operand:I8I16 0 "memory_operand""=m")
>   (match_operand:I8I16 1 "immediate_operand" " i"))
>(clobber (match_scratch:I8I16 2 "=r"))]
>""
>"#"
>""
>[(parallel
>  [(set (match_dup 2) (match_dup 1))
>   (set (match_dup 0) (match_dup 2))])]
>""
> )
> 
>   I found that in a mips back-end. But this pattern is not recognized  
> during code-generation [char c1; c1 = 1;]:
> simple-memory.c:19: error: unrecognizable insn:
> (insn 12 11 14 3 (set (mem/c/i:QI (reg/f:SI 105) [0 c1+0 S8])
>  (const_int 1 [0x1])) -1 (nil)
>  (nil))
> 
>   If I remove the clobber command and replace (match_dup 2) by  
> (reg:I8I16 A15_REGNUM) code will be generated (but not as wanted).
> 
>   What is wrong with the code above?

There is nothing wrong with that code, but nothing is going to make
the compiler use it.  Moves are special.  If you need a scratch
register to do a move, then you need to look at the
TARGET_SECONDARY_RELOAD hook.

But if the problem is only that you need a register to store a
constant into memory, then you should be able to do that using
register constraints on your mov insn.

Ian

basic queries regarding wchar_t

[Shoaib Naazir]

Hi,
   Am new to unicode programming and was playing with the following program..

#include 
#include 
#include 

int main(int narg, char *varg[])
{
 wprintf(L"%ls\n", L"This is a test of wprintf");
printf("%s\n", "This is a test of printf");
return 0;
}

Compiling it using the following gcc command:
gcc -Wall ./wchar_test.c -o ./wchar_test

First,
I get the following warning:
./wchar_test.c: In function 'main':
./wchar_test.c:7: warning: implicit declaration of function 'wprintf'

Can anyone explain me why??

Second,
The output is not what atleast i was expecting, the output is as follows:
This is a test of wprintf

Shouldn't the second string be printed as well

Thanks.

-- 
Lidz..

Resigning from GCC Steering Commitee

[Per Bothner]

I'm sorry to announce that I'm resigning from the GCC Steering
Committee.  I have been embarrassingly inactive in both GCC development
and on the committee the last few years.  There doesn't seem to be
any likelihood that this will change in the foreseeable future,
even less so now that I have a "day job" working for Sun.  The
Steering Committee and the Gcc community deserve someone more
informed and involved with what is going on in the GCC world;
The SC have been discussing possible "new blood" to take my place.

I have been a member of the Steering Committee since its start
almost 10 ago as the egcs project, and I've been involved
with GNU and GNU tools quite a bit longer than that.  It has been
a pleasure working with such a community of dedicated, smart,
and (most of the time) reasonable and friendly people!

I am still "around", working on GNU and other Free Software
(the Kawa project is still going strong, and my job at Sun
is also Free Software).  If you any questions about code I've
written - or just want to say "hi!" - feel free to contact me.
--
--Per Bothner
[EMAIL PROTECTED]   http://per.bothner.com/

Re: Resigning from GCC Steering Commitee

[龙海涛]

could a new bie say goodbye to you?

wave~~~

Per Bothner 写道:

I'm sorry to announce that I'm resigning from the GCC Steering
Committee.  I have been embarrassingly inactive in both GCC development
and on the committee the last few years.  There doesn't seem to be
any likelihood that this will change in the foreseeable future,
even less so now that I have a "day job" working for Sun.  The
Steering Committee and the Gcc community deserve someone more
informed and involved with what is going on in the GCC world;
The SC have been discussing possible "new blood" to take my place.

I have been a member of the Steering Committee since its start
almost 10 ago as the egcs project, and I've been involved
with GNU and GNU tools quite a bit longer than that.  It has been
a pleasure working with such a community of dedicated, smart,
and (most of the time) reasonable and friendly people!

I am still "around", working on GNU and other Free Software
(the Kawa project is still going strong, and my job at Sun
is also Free Software).  If you any questions about code I've
written - or just want to say "hi!" - feel free to contact me.

Patch Queue down

[Manuel López-Ibáñez]

Hi,

The patch queue http://www.dberlin.org/patches seems to be down. I
understand that Daniel is very busy and he is making some changes to
his site. However, I would argue that the queue was being quite
successful and provided a valuable service for many GCC developers. I
also provided a place to track patches that are waiting for stage1.

Therefore, I was wondering if there is a reason it couldn't be hosted
in the GCC servers, along with bugzilla and the wiki.

Cheers,

Manuel.