Prev-20 Home Next-20 6 msg How to control the offset for stack operation? GCC 4.2.0 Status Report (2007-04-15) \ Mark Mitchell (15 Apr 2007) . \ Dave Korn (15 Apr 2007) . . \ Mark Mitchell (15 Apr 2007) . \ John David Anglin (16 Apr 2007) . \ Daniel Berlin (16 Apr 2007) . . \ Brooks Moses (16 Apr 2007) . . . \ (Richard Kenner) (16 Apr 2007) . \ Eric Weddington (16 Apr 2007) . \ François-Xavier Coudert (16 Apr 2007) . . \ J.C. Pizarro (16 Apr 2007) . . . \ François-Xavier Coudert (16 Apr 2007) . . . . \ J.C. Pizarro (16 Apr 2007) . . . . . \ François-Xavier Coudert (16 Apr 2007) . . . . . . \ J.C. Pizarro (16 Apr 2007) . . . . . . . \ Dave Korn (16 Apr 2007) . . . . . . . . \ J.C. Pizarro (16 Apr 2007) . . . . . . . . . \ Dave Korn (16 Apr 2007) . . . . . . . . . . \ J.C. Pizarro (16 Apr 2007) . . . \ Andrew Pinski (16 Apr 2007) . . . . \ J.C. Pizarro (16 Apr 2007) . \ Gerald Pfeifer (16 Apr 2007) . \ Steven Bosscher (16 Apr 2007) . . \ Janis Johnson (16 Apr 2007) . . . \ Mark Mitchell (16 Apr 2007) . . . . \ Janis Johnson (16 Apr 2007) . . . . . \ Mark Mitchell (16 Apr 2007) . . . \ Tom Tromey (16 Apr 2007) . . . . \ Laurent GUERBY (16 Apr 2007) . . . . . \ Janis Johnson (18 Apr 2007) . . . \ Steven Bosscher (16 Apr 2007) . . \ Tom Tromey (16 Apr 2007) . . . \ Paolo Bonzini (16 Apr 2007) . . \ Maxim Kuvyrkov (17 Apr 2007) . . . \ Steven Bosscher (17 Apr 2007) . . . . \ Richard Guenther (17 Apr 2007) . . . . . \ Steven Bosscher (17 Apr 2007) 3 msg Status of PR21561 1 msg Maintainers for C preprocessor 1 msg libffi failures on powerpc-apple-darwin7.9.0 7 msg A question on gimplifier 1 msg gcc-4.1.2 testsuite report MAC OS 10.3.9 Power ... 1 msg manipulating VCG files 1 msg gcc-4.3-20070413 is now available 16 msg GIMPLE tuples document uploaded to wiki 6 msg RFC: Add target_isa_flags 1 msg tree_code and type safety 3 msg Nonzero result when left-shift greater than wid... 1 msg how to regenerate automake files 18 msg [MIPS] MADD issue 16 msg Call to arms: testsuite failures on various tar... 3 msg New wiki page on testing compile times and memo... 16 msg RFA: i386 is running out target mask bits 10 msg [RFA] C++ language compatibility in sources [wa... 7 msg libstdc++.dylib linking problem on Darwin Prev-20 Home Next-20

Prev-Msg Prev-Thread Gcc Apr-2007 Next-Thread Next-Msg Subject: GCC 4.2.0 Status Report (2007-04-15) Group: Gcc From: Mark Mitchell Date: 15 Apr 2007 As has been remarked on the GCC mailing lists, I've not succeeded in getting GCC 4.2.0 out the door. However, with the limited criteria that we target only P1 regressions not present in 4.1.x, we seem to be getting a bit closer. The only regressions in this category are: 26792 [4.2 Regression] need to use autoconf when using newly-ad... 29841 [4.2/4.3 regression] ICE with scheduling and __builtin_trap 30222 [4.2 Regression] gcc.target/i386/vectorize1.c ICEs 30700 [4.2 Regression] YA bogus undefined reference error to st... 31136 [4.2 Regression] FRE ignores bit-field truncation (C and ... 31360 [4.2/4.3 Regression] rtl loop invariant is broken 31513 [4.2/4.3 Regression] Miscompilation of Function Passing B... I'm disappointed that the patch for PR 30700 hasn't been applied to the 4.2 branch; according to bugzilla it looks like all that's needed is a build/test cycle there. I'll be tackling 31513 tonight. Perhaps I can get to one or two of the other PRs above. The broader question of why there are so many 124 P3 or higher regressions against 4.2.0 points to a more fundamental problem. Despite the fact that virtually all of the bugs open against 4.2.0 are also open against 4.1 or 4.3 -- or both! -- there seems to be little interest in fixing them. Some have suggested that I try to solve this by closing GCC 4.3 development until 4.2.0 is done. I've considered that, but I don't think it's a good idea. In practice, this whole software freedom thing means that people can go off and do things on their own anyhow; people who are more motivated to add features than fix bugs are likely just to keep doing that, and wait for mainline to reopen. However, I would consider asking the SC for permission to institute a rule that would prevent contributors responsible for P1 bugs (in the only possible bright-line sense: that the bug appeared as a result of their patch) from checking in changes on mainline until the P1 bug was resolved. This would provide an individual incentive for each of us to clean up our own mess. I'm certain that someone will raise the "latent bug" issue, but that's not the common case. And, we can always decide to make an exception if necessary. Of course, if we do this, I'd be happy to recuse myself as necessary, in order to avoid any appearance of favoritism towards CodeSourcery personnel. What do people think of that suggestion? -- Mark Mitchell CodeSourcery mark (650) 331-3385 x713 Prev-Msg Prev-Thread Gcc Apr-2007 Next-Thread Next-Msg

© 2004-2008 readlist.com