Re: Fishy build system: make_exports.pl called on darwin?
On 2005-10-03, at 06:05, Peter O'Gorman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marcin Dalecki wrote: | | On 2005-10-03, at 00:26, Andrew Pinski wrote: | |> |> This perl script works just fine for me on powerpc-darwin7.9.0 I don't |> see why are we piping the output to nm when it should be piping nm's |> output to c++filt. |> |> Also this perl script works fine on powerpc-darwin7.4.0 also. | | | Turns out it was rpm getting in the middle of the game for me... case | closed. I am quite curious as to how rpm got "in the middle of the game" here. Please explain. Pretty trivial after I noticed it. The spec I'm using was actually setting the host name itself explicitely. However this doesn't affect the actual primary problem that versioning turns out to be disfunctional on my tiger install.
problems with writing a new pass
Hi, I wrote a new pass following the examples listed in the wiki pages. However, when I "../gcc/configure; make bootstrap", I got error messages like: /xgcc -B./ -B/usr/local/i686-pc-linux-gnu/bin/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -L/backup/home/jianglx/softs/researchTools/parsetree/v2/gcc/gcccvs/gccbuild/gcc/../ld -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem /include -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame-pointer \ -c ../../gcc/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o In file included from /usr/include/stdio.h:831, from ../../gcc/gcc/tsystem.h:90, from ../../gcc/gcc/crtstuff.c:62: /usr/include/bits/stdio.h: In function 'vprintf': /usr/include/bits/stdio.h:37: internal compiler error: Segmentation fault The pass just iterates all statements using FOR_EACH_BB and bsi_start/bsi_next and counts the numbers of different kinds of statements. I only added a new file containing the code for counting and didn't touch other files except for tree-pass.h, timevar.def, passes.c, Makefile.in which are mentioned in the examples. There is a hash table structure written by myself in the new file, using some library functions, such as xmalloc, assert and strcmp. I have no clue what the error message implies. Can anybody shed some light on it? By the way, when I tried to build GCC using the code from the CVS repository, the bootstrap failed on my machine, showing error message like: config.status: error: cannot find input file: native/jawt/Makefile.in configure: error: /bin/sh '../../../../gcc/libjava/classpath/configure' failed for classpath make[1]: *** [configure-target-libjava] Error 1 make[1]: Leaving directory `/backup/gcc/gcccvs/gccbuild' make: *** [bootstrap] Error 2 However, if I disable Java support by "../gcc/configure --enable-language=c,c++,fortran,objc", bootstrap succeeds. Does it mean that certain configuration for Java is wrong? Thanks a lot. Skyhover
Re: problems with writing a new pass
> In file included from /usr/include/stdio.h:831, > from ../../gcc/gcc/tsystem.h:90, > from ../../gcc/gcc/crtstuff.c:62: > /usr/include/bits/stdio.h: In function 'vprintf': > /usr/include/bits/stdio.h:37: internal compiler error: Segmentation fault You are getting an error *compiling* vprintf, not *using* it. Paolo
Re: Cross GCC on Cygwin
On Oct 1, 2005, at 4:41 AM, Brian Rose wrote: I am an embedded software developer and I am interested in using GCC as a cross-compiler on the Cygwin/Windows platform. I would like to know which lists I should subscribe to in order to discuss this effort. There is not one. Each issue you may face, may require a different list. Political/licensing issues go to one list, compiler help goes to another, binutils to yet another, cygwin to yet another, compiler development of the compiler to yet another and so on... No one list fits the bill. Do your research up front on what lists there are, and what topics those lists cover. Also, you'll want to read up on the FAQ, cross FAQ and the manuals so that you don't just ask questions whose answers are already provided.
Re: Wishlish: GCC option for explicit booleans
On Oct 2, 2005, at 5:27 PM, Nicholas Nethercote wrote: [~] g++ -Wall a.cpp a.cpp: In function `int main()': a.cpp:4: warning: suggest parentheses around assignment used as truth value And -Werror turns it into a hard error...
Re: [URGENT] GCC 4.0 Nomination
On Sun, Oct 02, 2005 at 04:50:41PM +0100, Andrew Haley wrote: > Going from the mailing lists there are about ten of us heavily > involved in gcc here in the UK. I'm not sure how you'd choose > someone, given that gcc is a collective effort. My suggestion: anyone who is listed in the MAINTAINERS file, and who can make it to the dinner, could volunteer to accept the award. If more than one want to go, and the dinner hosts are willing, you can all go up on stage together, like they do at the Oscars. If more want to go than can be accomodated, then we have something to work out, but even in that case the people involved can discuss it among themselves and pick a representative.
[RFC][PATHC] Attack PR12245 by fiddling with CONSTRUCTOR
This is a summary report of a (failed) attempt to address memory and
compile-time usage of large (static array) initializers. The problem
is that we both use TREEs to do array indices arithmetic in
c-typeck.c:process_init_element and that we pin down memory for
INTEGER_CST tree nodes in both the large integer hashtable and the
CONSTRUCTOR elements.
The following patch tries to address this by
- using HOST_WIDE_INTs for the index arithmetic
- storing only the first index of a consecutive sequence of initializers,
the rest will have NULL_TREEs
Apart from some unresolved failures (gnu99 initializers, store-ccp) this
works, but really CONSTRUCTOR users don't cope with NULL_TREE indices.
A real solution would ditch TREE indices in favor of HOST_WIDE_INT ones,
but this won't work with RANGEs or FIELD_DECLs (though for the latter we
could store the decl offset, and I believe we could handle the fallout
for C and C++, dunno about possible initializers at non-constant offsets
in other languages).
With the patch memory usage for PR12245 is down to 160MB (from 250MB).
For a reduced testcase it is 160MB -> 80MB and 16s to 7s reduced compile
time.
Any ideas on how to proceed? Can we figure out (at output_init_element
time), if the array initializer is a static one?
Thanks for any input,
Richard.
Index: c-typeck.c
===
RCS file: /cvs/gcc/gcc/gcc/c-typeck.c,v
retrieving revision 1.480
diff -c -3 -p -r1.480 c-typeck.c
*** c-typeck.c 2 Oct 2005 19:15:58 - 1.480
--- c-typeck.c 3 Oct 2005 17:34:06 -
*** static char *print_spelling (char *);
*** 94,99
--- 94,100
static void warning_init (const char *);
static tree digest_init (tree, tree, bool, int);
static void output_init_element (tree, bool, tree, tree, int);
+ static void output_array_init_element (tree, bool, tree, HOST_WIDE_INT, int);
static void output_pending_init_elements (int);
static int set_designator (int);
static void push_range_stack (tree);
*** static tree constructor_fields;
*** 4682,4687
--- 4683,4689
/* For an ARRAY_TYPE, this is the specified index
at which to store the next element we get. */
static tree constructor_index;
+ static HOST_WIDE_INT aconstructor_index;
/* For an ARRAY_TYPE, this is the maximum index. */
static tree constructor_max_index;
*** static tree constructor_unfilled_fields;
*** 4692,4697
--- 4694,4700
/* For an ARRAY_TYPE, this is the index of the first element
not yet written out. */
static tree constructor_unfilled_index;
+ static HOST_WIDE_INT aconstructor_unfilled_index;
/* In a RECORD_TYPE, the byte index of the next consecutive field.
This is so we can generate gaps between fields, when appropriate. */
*** really_start_incremental_init (tree type
*** 4999,5015
&& TREE_CODE (constructor_max_index) != INTEGER_CST)
constructor_max_index = build_int_cst (NULL_TREE, -1);
! constructor_index
! = convert (bitsizetype,
! TYPE_MIN_VALUE (TYPE_DOMAIN (constructor_type)));
}
else
{
! constructor_index = bitsize_zero_node;
constructor_max_index = NULL_TREE;
}
! constructor_unfilled_index = constructor_index;
}
else if (TREE_CODE (constructor_type) == VECTOR_TYPE)
{
--- 5002,5017
&& TREE_CODE (constructor_max_index) != INTEGER_CST)
constructor_max_index = build_int_cst (NULL_TREE, -1);
! aconstructor_index = TREE_INT_CST_LOW (
! TYPE_MIN_VALUE (TYPE_DOMAIN (constructor_type)));
}
else
{
! aconstructor_index = 0;
constructor_max_index = NULL_TREE;
}
! aconstructor_unfilled_index = aconstructor_index;
}
else if (TREE_CODE (constructor_type) == VECTOR_TYPE)
{
*** push_init_level (int implicit)
*** 5054,5061
process_init_element (pop_init_level (1));
else if (TREE_CODE (constructor_type) == ARRAY_TYPE
&& constructor_max_index
! && tree_int_cst_lt (constructor_max_index,
! constructor_index))
process_init_element (pop_init_level (1));
else
break;
--- 5056,5063
process_init_element (pop_init_level (1));
else if (TREE_CODE (constructor_type) == ARRAY_TYPE
&& constructor_max_index
! && compare_tree_int (constructor_max_index,
! aconstructor_index) == -1)
process_init_element (pop_init_level (1));
else
break;
*** push_init_level (int implicit)
*** 5071,5077
&& constructor_fields)
value = find_init_member (constructor_fields);
else if (TR
Re: Cross GCC on Cygwin
I would subscribe to the MinGW list as this is a key technology to making cygwin/windows cross compiling work http://www.mingw.org/ On Oct 1, 2005, at 4:41 AM, Brian Rose wrote: I am an embedded software developer and I am interested in using GCC as a cross-compiler on the Cygwin/Windows platform. I would like to know which lists I should subscribe to in order to discuss this effort.
Re: [RFC][PATHC] Attack PR12245 by fiddling with CONSTRUCTOR
On Mon, Oct 03, 2005 at 07:52:41PM +0200, Richard Guenther wrote: > A real solution would ditch TREE indices in favor of HOST_WIDE_INT ones... A real solution would have a tree node that can represent an arbitrarily large block of target memory as a binary blob. As much as possible, the actual data in the constructor would be represented as bytes in the blob exactly as it will be arranged in target memory. For user data without obvious patterns, this is the most compact form we could use without actually compressing the data. The binary blob thing falls down when relocations are required. We'd need to have a second kind of node to represent these. A vector of sequential relocations comes to mind. I'd expect the top-level constructor node to have something like a splay tree arranging the sub-blocks of data and relocations. A tree is nice because we can fairly easily look up the data at a given offset, as well as being able to iterate over the elements in order when it comes time to write it out. That combined with a proper set of creation and access functions should be fairly clean. r~
Re: libjawtgnu linking borked
> "Richard" == Richard Guenther <[EMAIL PROTECTED]> writes: Richard> On current mainline-gcc install-pkglibLTLIBRARIES fails re-linking Richard> libjawtgnu: Richard> The -L/usr/lib/classpath -lgtkpeer seems bogous, we don't Richard> have classpath installed (yet). We shouldn't be installing this library at all. I have a fix, which I will check in soon. Tom
Re: Should -msse3 enable fisttp?
Hi Uros, Since you are the one who enabled fisttp, I figure I should send this email to you directly. Let me know what you think. I kind of agree with your argument. But for practical reasons I thinkg -msse3 should enable fisttp. Certainly here in Apple, a few folks have been surprised by this. Thanks, Evan Senior Compiler Engineer Apple Computers On Sep 29, 2005, at 1:48 PM, Evan Cheng wrote: Hi, I know this has been discussed in bug 18668. But I'd like to bring it up again. Currently, fisttp is only generated with -march=prescott. The argument is fisttp is not a SSE instruction. While this is technically true, it's likely to surprise the users. Intel, after all, does lump fisttp in SSE3. AMD64 architecture programmer's manual also explicitly state fisttp is a SSE3 instruction. Please consider enabling fisttp with -msse3. Thanks, Evan
Re: Should -msse3 enable fisttp
My mistake. I misunderstood the meaning of -msse3 (it only enables the sse3 builtins). Please ignore. On Sep 29, 2005, at 1:48 PM, Evan Cheng wrote: Hi, I know this has been discussed in bug 18668. But I'd like to bring it up again. Currently, fisttp is only generated with -march=prescott. The argument is fisttp is not a SSE instruction. While this is technically true, it's likely to surprise the users. Intel, after all, does lump fisttp in SSE3. AMD64 architecture programmer's manual also explicitly state fisttp is a SSE3 instruction. Please consider enabling fisttp with -msse3. Thanks, Evan Evan Cheng Senior Compiler Engineer Apple Computer, Inc.
Re: Should -msse3 enable fisttp
On Oct 3, 2005, at 5:56 PM, Evan Cheng wrote: My mistake. I misunderstood the meaning of -msse3 (it only enables the sse3 builtins). Please ignore. Actually it enables more than the builtins. It enables the use sse3 instructions. This is just like -maltivec on PowerPC and -msse and -msse on x86, etc. Hmm, but from the original patch: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01119.html "BTW: Regarding TARGET_FISTTP macro: according to documentation, fisttp insn indeed depends on (TARGET_80387 && TARGET_SSE3). However, this insn is not a SSE3 instruction, so it should not be disabled by -mno-sse3 flag." And then RTH agreed: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01432.html So from the sound of it fisttp is not a SSE3 instruction. Thanks, Andrew Pinski
Re: Should -msse3 enable fisttp
Well, both Intel and AMD calls fisttp a SSE3 instruction even though it operates on the x87 stack ST(0). My argument is users who specify - msse3 to turn on SSE3 instructions would expect fisttp be turned on as well. But according to the manual -msse3 does not turn on generation of SSE3 instructions: -mmmx -mno-mmx -msse -mno-sse -msse2 -mno-sse2 -msse3 -mno-sse3 -m3dnow -mno-3dnow These switches enable or disable the use of built-in functions that allow direct access to the MMX, SSE, SSE2, SSE3 and 3Dnow extensions of the instruction set. See X86 Built-in Functions, for details of the functions enabled and disabled by these switches. To have SSE/SSE2 instructions generated automatically from floating- point code, see -mfpmath=sse. Thus the confusion. Evan On Oct 3, 2005, at 3:25 PM, Andrew Pinski wrote: On Oct 3, 2005, at 5:56 PM, Evan Cheng wrote: My mistake. I misunderstood the meaning of -msse3 (it only enables the sse3 builtins). Please ignore. Actually it enables more than the builtins. It enables the use sse3 instructions. This is just like -maltivec on PowerPC and -msse and -msse on x86, etc. Hmm, but from the original patch: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01119.html "BTW: Regarding TARGET_FISTTP macro: according to documentation, fisttp insn indeed depends on (TARGET_80387 && TARGET_SSE3). However, this insn is not a SSE3 instruction, so it should not be disabled by -mno-sse3 flag." And then RTH agreed: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01432.html So from the sound of it fisttp is not a SSE3 instruction. Thanks, Andrew Pinski
Re: Should -msse3 enable fisttp
Actually it enables more than the builtins. It enables the use sse3 instructions. This is just like -maltivec on PowerPC and -msse and -msse on x86, etc. Right, so the manual disagrees and should probably be fixed. And then RTH agreed: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01432.html So from the sound of it fisttp is not a SSE3 instruction. Richard's response was that it shouldn't be turned off by -mno-sse3, not that it shouldn't be turned on for -msse3. I think it probably should be turned on there. -eric
Re: Moving to subversion, gonna eat me a lot of peaches
Daniel Berlin wrote: BJE has converted most of the client side scripts in the contrib directory. I have to see what is left and conver the rest. I looked pretty carefully through every file in that directory. You should find that it is all taken care of. Cheers, Ben
Re: Should -msse3 enable fisttp
On Oct 3, 2005, at 6:41 PM, Evan Cheng wrote: But according to the manual -msse3 does not turn on generation of SSE3 instructions: The manual is semi-confusing I had forgot about that. There is a bug about the issue recorded as PR 23809: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23809 Thanks, Andrew Pinski
Re: Moving to subversion, gonna eat me a lot of peaches
On Tue, Oct 04, 2005 at 08:46:20AM +1000, Ben Elliston wrote: > Daniel Berlin wrote: > > >BJE has converted most of the client side scripts in the contrib > >directory. I have to see what is left and conver the rest. > > I looked pretty carefully through every file in that directory. You should > find that it is all taken care of. I'm working on regression hunt scripts that search by patch rather than by date and hope to have those working with Subversion and ready to contribute by the time we switch over. Janis
Re: Moving to subversion, gonna eat me a lot of peaches
Kean Johnston wrote: I think svn is a great tool, don't get me wrong. Very well written and got all the features one could want. But I don't know (or see) the actual problem you are trying to solve. cvs seems to be wroking really well for gcc. I could have said the complete opposite. For my GCC work, I can practically hear CVS creaking. An hour and a half to tag a tree (blocking all other committers during that time) is becoming unacceptable. as stable and vital to teh community as gcc, changing something as fundamental as its SCM should come with a pretty big long set of justifictions (all coolness factors waived). There's This has been discussed over at least two GCC Summits (and possibly longer). I don't think this switch is being done on a whim. Ben
Question about Machine Description
Hi all,
I am currently developing a GCC port for my own generic 32 bit
processor. I have this following error when I tried to compile a
benchmark.
(insn 1497 1924 1756 2 (set (mem:BI (plus:SI (reg/f:SI 2 r2)
(const_int -137 [0xff77])) [72 S1 A8])
(le:BI (reg:SI 12 r12)
(const_int 0 [0x0]))) 0 {*cmpsi_normal}
(insn_list:REG_DEP_TRUE 86 (
nil))
(nil))
convolve.c:236: internal compiler error: in reload_cse_simplify_operands,
at postreload.c:391
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make: *** [convolve.o] Error 1
My question is that..what is the constaint/instruction I am missing? If
you could give me an assembly example tto illustrate an instrction that I
hvaent implemented, it would be nice too.
Any Help is highly appreciated.
Thanking You,
Yours Sincerely,
Balaji V. Iyer.
PS. Please CC me since I am not a subscribed member of this list.
Re: Question about Machine Description
"Balaji V. Iyer" <[EMAIL PROTECTED]> writes:
No need to send to both gcc@gcc.gnu.org and [EMAIL PROTECTED] I
removed gcc-help in this reply. Thanks.
>I am currently developing a GCC port for my own generic 32 bit
> processor. I have this following error when I tried to compile a
> benchmark.
>
> (insn 1497 1924 1756 2 (set (mem:BI (plus:SI (reg/f:SI 2 r2)
> (const_int -137 [0xff77])) [72 S1 A8])
> (le:BI (reg:SI 12 r12)
> (const_int 0 [0x0]))) 0 {*cmpsi_normal}
> (insn_list:REG_DEP_TRUE 86 (
> nil))
> (nil))
> convolve.c:236: internal compiler error: in reload_cse_simplify_operands,
> at postreload.c:391
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://gcc.gnu.org/bugs.html> for instructions.
> make: *** [convolve.o] Error 1
>
> My question is that..what is the constaint/instruction I am missing? If
> you could give me an assembly example tto illustrate an instrction that I
> hvaent implemented, it would be nice too.
This kind of error generally means that the operand predicate accepts
an operand which no constraint matches. If the predicate (e.g.,
register_operand) accepts an operand, then there must be a constraint
that matches it. Otherwise you will get an error in
constrain_operands, such as the above.
Ian
Re: Question about Machine Description
Thank you very much Ian and Shreyas for your quick response. So I guess,
my question now would be, what would be an exmple that matches this
constraint below?
((insn 1497 1924 1756 2 (set (mem:BI (plus:SI (reg/f:SI 2 r2)
(const_int -137 [0xff77])) [72 S1 A8])
(le:BI (reg:SI 12 r12)
(const_int 0 [0x0]))) 0 {*cmpsi_normal}
(insn_list:REG_DEP_TRUE 86 (
nil))
(nil))
The reason I ask is that, from my understanding it needs an instruction
that does the following:
if (r12 <= 0) then
(r2+ -137) = 1
else
(r2+ -137) = 0
Is this correct?
Thanks,
Balaji V. Iyer.
PS. I am sorry for posting in both the mailing list.
Ian Lance Taylor wrote:
> "Balaji V. Iyer" <[EMAIL PROTECTED]> writes:
>
> No need to send to both gcc@gcc.gnu.org and [EMAIL PROTECTED] I
> removed gcc-help in this reply. Thanks.
>
>>I am currently developing a GCC port for my own generic 32 bit
>> processor. I have this following error when I tried to compile a
>> benchmark.
>>
>> (insn 1497 1924 1756 2 (set (mem:BI (plus:SI (reg/f:SI 2 r2)
>> (const_int -137 [0xff77])) [72 S1 A8])
>> (le:BI (reg:SI 12 r12)
>> (const_int 0 [0x0]))) 0 {*cmpsi_normal}
>> (insn_list:REG_DEP_TRUE 86 (
>> nil))
>> (nil))
>> convolve.c:236: internal compiler error: in
>> reload_cse_simplify_operands,
>> at postreload.c:391
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See http://gcc.gnu.org/bugs.html> for instructions.
>> make: *** [convolve.o] Error 1
>>
>> My question is that..what is the constaint/instruction I am missing? If
>> you could give me an assembly example tto illustrate an instrction that
>> I
>> hvaent implemented, it would be nice too.
>
> This kind of error generally means that the operand predicate accepts
> an operand which no constraint matches. If the predicate (e.g.,
> register_operand) accepts an operand, then there must be a constraint
> that matches it. Otherwise you will get an error in
> constrain_operands, such as the above.
>
> Ian
>
Re: Question about Machine Description
"Balaji V. Iyer" <[EMAIL PROTECTED]> writes:
> Thank you very much Ian and Shreyas for your quick response. So I guess,
> my question now would be, what would be an exmple that matches this
> constraint below?
>
> ((insn 1497 1924 1756 2 (set (mem:BI (plus:SI (reg/f:SI 2 r2)
> (const_int -137 [0xff77])) [72 S1 A8])
> (le:BI (reg:SI 12 r12)
> (const_int 0 [0x0]))) 0 {*cmpsi_normal}
> (insn_list:REG_DEP_TRUE 86 (
> nil))
> (nil))
I don't think that question makes sense, at least not without more
context.
A constraint is one of the letters which appears after the operand
predicate in the .md file. For example, in
(define_insn "*cmpsi_ccno_1"
[(set (reg FLAGS_REG)
(compare (match_operand:SI 0 "nonimmediate_operand" "r,?mr")
(match_operand:SI 1 "const0_operand" "n,n")))]
"ix86_match_ccmode (insn, CCNOmode)"
"@
test{l}\t{%0, %0|%0, %0}
cmp{l}\t{%1, %0|%0, %1}"
[(set_attr "type" "test,icmp")
(set_attr "length_immediate" "0,1")
(set_attr "mode" "SI")])
there are two alternative; the constraints on operand 0 are "r" for
the first alternative and "?mr" for the second, and the constraints on
operand 1 is "n" for both alternatives. The operand predicates are
nonimmediate_operand for operand 0 and const0_operand for operand 1.
When I said this:
> > This kind of error generally means that the operand predicate accepts
> > an operand which no constraint matches. If the predicate (e.g.,
> > register_operand) accepts an operand, then there must be a constraint
> > that matches it. Otherwise you will get an error in
> > constrain_operands, such as the above.
I mean that, in the instruction above, any operand which matches
nonimmediate_operand must be matched by at least one of the
constraints 'm' or 'r', and any operand which matches const0_operand
must match the constraint 'n'.
Ian
GCC 4.1 Status Report (2005-10-02)
The number of bugs targeted at GCC 4.1 has declined to 225 from 250 in my September 7th status report: http://gcc.gnu.org/ml/gcc/2005-09/msg00179.html The number of critical (wrong-code, ice-on-valid, rejects-valid) regressions has declined to 61 from 77. So, we're still fixing about one net regression per day, and about 2/3rd of the regressions we're fixing are critical. Of the 61 critical bugs, about half (31) are 4.1 regressions, i.e., do not occur with 4.0. 18 of the critical bugs are C++; the rest are primarily middle-end optimizer problems. Since we're checking in something like 5 patches a day to gcc/, and we're in bug-fix mode, we're either fixing a lot of bugs that aren't regressions, or we're introducing a lot of bugs when we check in patches, or people are finding new regressions at a rate that exceeds our ability to fix them. It's time for a quality push so that we can actually get to 4.1. Starting Friday, at midnight PDT, the mainline will go to the mode normally used for branches: fixes for regressions only, including code-generation regressions. We will stay in that mode until we hit our 100-regression target. Then, we'll re-open briefly to allow any queued-up critical non-regression bug-fixes. Then we'll branch. All of the usual suspects (Berlin, Bosscher, Henderson, Hubicka, Mitchell, Novillo, etc.) have bugs with our names on them. I think we can knock quite a few these down relatively easily. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
