* Is the gcc-3_3-branch creation still on target? @ 2002-10-04 8:23 David O'Brien 2002-10-04 8:50 ` H. J. Lu 2002-10-04 9:36 ` Andreas Jaeger 0 siblings, 2 replies; 30+ messages in thread From: David O'Brien @ 2002-10-04 8:23 UTC (permalink / raw) To: gcc Are things still on schedule to branch mainline, creating the gcc-3_3-branch, on 15-Oct-2002? FreeBSD 5.0 will use some form of GCC 3.3 snapshot. I know this isn't desired by the GCC Steering Committee to have another "gcc 2.96", but FreeBSD has little choice. It ICE's on many popular packages, X11 as just one example. It has serious optimization bugs for modern x86 processors, for which the PR's aren't getting fixed. It has regressions from 2.95 that aren't getting fixed. All in all, GCC 3.2 is poo. There needs to be a balance between adding new features, re-abstracting the code, etc; and basic usability. So far the 3.x series has leaned too far to the former. GCC 3.1.1 was the most stable of any of the 3.x compilers, but it has a broken C++ ABI and is EOL'ed by the GCC developers, which makes it a poor choice to base an OS on. -- -- David (obrien@FreeBSD.org) ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Is the gcc-3_3-branch creation still on target? 2002-10-04 8:23 Is the gcc-3_3-branch creation still on target? David O'Brien @ 2002-10-04 8:50 ` H. J. Lu 2002-10-04 9:29 ` David O'Brien 2002-10-04 9:36 ` Andreas Jaeger 1 sibling, 1 reply; 30+ messages in thread From: H. J. Lu @ 2002-10-04 8:50 UTC (permalink / raw) To: David O'Brien; +Cc: gcc On Fri, Oct 04, 2002 at 08:09:15AM -0700, David O'Brien wrote: > Are things still on schedule to branch mainline, creating the > gcc-3_3-branch, on 15-Oct-2002? > > FreeBSD 5.0 will use some form of GCC 3.3 snapshot. I know this isn't > desired by the GCC Steering Committee to have another "gcc 2.96", but > FreeBSD has little choice. It ICE's on many popular packages, X11 as > just one example. It has serious optimization bugs for modern x86 > processors, for which the PR's aren't getting fixed. It has regressions > from 2.95 that aren't getting fixed. All in all, GCC 3.2 is poo. There > needs to be a balance between adding new features, re-abstracting the > code, etc; and basic usability. So far the 3.x series has leaned too far > to the former. GCC 3.1.1 was the most stable of any of the 3.x > compilers, but it has a broken C++ ABI and is EOL'ed by the GCC > developers, which makes it a poor choice to base an OS on. > I am not saying 3.2.1 is great. I am still using gcc 2.96. I am just curious. Isn't the only difference between 3.1 and 3.2 is the C++ ABI change? How come 3.1.1 is more stable than 3.2.1? BTW, I applaud FreeBSD's decision to use gcc 3.x in FreeBSD 5.0. That is what is needed to make gcc 3.x as great as it can be. Without RedHat 8.0 and FreeBSD 5.0 which try to use gcc 3.x to compile everything, many very bad bugs won't be discovered in time. FWIW, RedHat has a bunch of patches for their gcc 3.2 in RedHat 8.0. I guess they make a difference. H.J. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Is the gcc-3_3-branch creation still on target? 2002-10-04 8:50 ` H. J. Lu @ 2002-10-04 9:29 ` David O'Brien 2002-10-04 9:34 ` H. J. Lu 0 siblings, 1 reply; 30+ messages in thread From: David O'Brien @ 2002-10-04 9:29 UTC (permalink / raw) To: H. J. Lu; +Cc: gcc On Fri, Oct 04, 2002 at 08:23:11AM -0700, H. J. Lu wrote: > I am just curious. Isn't the only difference between 3.1 and 3.2 is the > C++ ABI change? How come 3.1.1 is more stable than 3.2.1? 3.2[.0] was supose to have just the C++ ABI change (as shown in gcc/cp/ChangeLog), but it had a bit more in the base compiler. Since 3.2[.0]'s release, a lot of changes have gone into gcc-3_2-branch. Some things that did not compile with 3.2.1, now compile due to fixes in the gcc-3_2-branch. But now other things that did compile cause ICE's. It has been a never ending chase since 2.95.3 to find a truly usable GCC. cvs diff -u0 -r gcc_3_2_release -r gcc-3_2-branch, gcc/ChangeLog 508 lines of diff, and cp/ChangeLog has 63 lines of diff. Bugs have been added since 3.2.0. FreeBSD is using a GCC 3.2.1 20020916 snapshot, and it isn't anywhere near the quality what would have been 3.1.3 should be. Index: ChangeLog =================================================================== RCS file: /cvs/gcc/egcs/gcc/ChangeLog,v retrieving revision 1.13152.2.657 retrieving revision 1.13152.2.657.2.12 diff -u -r1.13152.2.657 -r1.13152.2.657.2.12 --- ChangeLog 25 Jul 2002 23:34:59 -0000 1.13152.2.657 +++ ChangeLog 14 Aug 2002 08:59:50 -0000 1.13152.2.657.2.12 @@ -1,3 +1,96 @@ +2002-08-14 Release Manager + + * GCC 3.2 Released. + +2002-08-08 Jakub Jelinek <jakub@redhat.com> + + * config/rs6000/rs6000.h, config/rs6000/aix.h, + config/rs6000/darwin.h, config/rs6000/linux64.h: Revert last + two patches. + * config/rs6000/sysv4.h: Likewise, remove #undef ADJUST_FIELD_ALIGN. + +2002-08-08 Jakub Jelinek <jakub@redhat.com> + + * config/rs6000/rs6000-protos.h (rs6000_field_alignment): Remove. + * config/rs6000/rs6000.c (rs6000_field_alignment): Move... + * config/rs6000/rs6000.h (ADJUST_FIELD_ALIGN): ...inline into the + macro. + +2002-08-08 Jakub Jelinek <jakub@redhat.com> + + * stor-layout.c (place_union_field): For bitfields if + PCC_BITFIELD_TYPE_MATTERS and TYPE_USER_ALIGN, set record's + TYPE_USER_ALIGN. + +2002-08-07 Jakub Jelinek <jakub@redhat.com> + Richard Henderson <rth@redhat.com> + + * stor-layout.c (place_union_field): Apply ADJUST_FIELD_ALIGN + to type_align when PCC_BITFIELD_TYPE_MATTERS. Only apply + ADJUST_FIELD_ALIGN if not DECL_USER_ALIGN resp. TYPE_USER_ALIGN. + (place_field): Likewise. + * config/i386/i386.c (x86_field_alignment): Don't check + TARGET_ALIGN_DOUBLE for the second time. + Apply min for all MODE_INT and MODE_CLASS_INT modes. + * config/rs6000/rs6000.c (rs6000_field_alignment): New. + * config/rs6000/rs6000-protos.h (rs6000_field_alignment): New + prototype. + * config/rs6000/rs6000.h (ADJUST_FIELD_ALIGN): Define. + * config/rs6000/aix.h (ADJUST_FIELD_ALIGN): Remove. + * config/rs6000/darwin.h (ADJUST_FIELD_ALIGN): Remove. + * config/rs6000/linux64.h (ADJUST_FIELD_ALIGN): Remove. + * config/rs6000/sysv4.h (ADJUST_FIELD_ALIGN): Remove. + * doc/tm.texi (ADJUST_FIELD_ALIGN): Update description. + +2002-08-06 Jakub Jelinek <jakub@redhat.com> + + * config/i386/mmintrin.h (__m64): Make the type 64-bit aligned. + +2002-08-06 Jakub Jelinek <jakub@redhat.com> + + * config.gcc (*-*-linux*): Default to --enable-threads=posix if no + --{enable,disable}-threads is given to configure. + (alpha*-*-linux*, hppa*-*-linux*, i[34567]86-*-linux*, + x86_64-*-linux*, ia64*-*-linux*, m68k-*-linux*, mips*-*-linux*, + powerpc-*-linux-gnualtivec*, powerpc-*-linux*, s390-*-linux*, + s390x-*-linux*, sh-*-linux*, sparc-*-linux*, sparc64-*-linux*): + Remove thread_file setting here. + +2002-08-04 Mark Mitchell <mark@codesourcery.com> + + * doc/install.texi (Installing GCC): Refer to buildstat.html, + rather than listing version-specific build status files. + +2002-08-04 Joseph S. Myers <jsm@polyomino.org.uk> + + * doc/include/gcc-common.texi (version-GCC): Increase to 3.2. + +2002-08-01 Benjamin Kosnik <bkoz@redhat.com> + + * gcc.c: Set __GXX_ABI_VERSION to 102. + +2002-07-30 Franz Sirl <Franz.Sirl-kernel@lauterbach.com> + + * gcc.c (cpp_unique_options): Define __GXX_ABI_VERSION, bump it to 101. + +2002-07-24 Frank van der Linden <fvdl@wasabisystems.com> + + PR optimization/7291 + * config/i386/i386.c (ix86_expand_clrstr): Fix bzero alignment + problem on x86_64. + +2002-05-16 Jason Merrill <jason@redhat.com> + + * config/mips/mips.c (mips_output_external): Don't do sdata + optimization for a variable with DECL_COMDAT set. + +2002-01-03 Jakub Jelinek <jakub@redhat.com> + + * c-decl.c (build_compound_literal): Set decl TREE_READONLY from TYPE. + + * c-decl.c (build_compound_literal): Defer compound literal decls + until until file end to emit them only if they are actually used. + 2002-07-25 Release Manager * GCC 3.1.1 Released. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Is the gcc-3_3-branch creation still on target? 2002-10-04 9:29 ` David O'Brien @ 2002-10-04 9:34 ` H. J. Lu 2002-10-04 9:44 ` David O'Brien 0 siblings, 1 reply; 30+ messages in thread From: H. J. Lu @ 2002-10-04 9:34 UTC (permalink / raw) To: David O'Brien; +Cc: gcc On Fri, Oct 04, 2002 at 08:45:15AM -0700, David O'Brien wrote: > On Fri, Oct 04, 2002 at 08:23:11AM -0700, H. J. Lu wrote: > > I am just curious. Isn't the only difference between 3.1 and 3.2 is the > > C++ ABI change? How come 3.1.1 is more stable than 3.2.1? > > 3.2[.0] was supose to have just the C++ ABI change (as shown in > gcc/cp/ChangeLog), but it had a bit more in the base compiler. Since > 3.2[.0]'s release, a lot of changes have gone into gcc-3_2-branch. Some > things that did not compile with 3.2.1, now compile due to fixes in the > gcc-3_2-branch. But now other things that did compile cause ICE's. It > has been a never ending chase since 2.95.3 to find a truly usable GCC. > I don't expect it will end any time soon after a new releae of gcc. I am talking months if not years. > cvs diff -u0 -r gcc_3_2_release -r gcc-3_2-branch, gcc/ChangeLog 508 > lines of diff, and cp/ChangeLog has 63 lines of diff. Bugs have been > added since 3.2.0. FreeBSD is using a GCC 3.2.1 20020916 snapshot, and I assume you have filed bug reports marked them as regression. H.J. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Is the gcc-3_3-branch creation still on target? 2002-10-04 9:34 ` H. J. Lu @ 2002-10-04 9:44 ` David O'Brien 2002-10-04 9:47 ` H. J. Lu ` (2 more replies) 0 siblings, 3 replies; 30+ messages in thread From: David O'Brien @ 2002-10-04 9:44 UTC (permalink / raw) To: H. J. Lu; +Cc: gcc On Fri, Oct 04, 2002 at 08:50:14AM -0700, H. J. Lu wrote: > I assume you have filed bug reports marked them as regression. Yes. One finally got fixed in mainline, but I'm sure it wont get back ported and I wonder if I could get permission to commit it if I back ported it. There are 6 Athlon and related PR's that I know of. A few also apply to Pentium-4. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Is the gcc-3_3-branch creation still on target? 2002-10-04 9:44 ` David O'Brien @ 2002-10-04 9:47 ` H. J. Lu 2002-10-04 9:53 ` David O'Brien 2002-10-04 10:06 ` Zack Weinberg 2002-10-04 10:25 ` Gerald Pfeifer 2 siblings, 1 reply; 30+ messages in thread From: H. J. Lu @ 2002-10-04 9:47 UTC (permalink / raw) To: David O'Brien; +Cc: gcc On Fri, Oct 04, 2002 at 09:29:36AM -0700, David O'Brien wrote: > On Fri, Oct 04, 2002 at 08:50:14AM -0700, H. J. Lu wrote: > > I assume you have filed bug reports marked them as regression. > > Yes. One finally got fixed in mainline, but I'm sure it wont get back > ported and I wonder if I could get permission to commit it if I back Is that a regression? If it is, why can't it be back ported? > ported it. There are 6 Athlon and related PR's that I know of. A few > also apply to Pentium-4. Are they also regression? H.J. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Is the gcc-3_3-branch creation still on target? 2002-10-04 9:47 ` H. J. Lu @ 2002-10-04 9:53 ` David O'Brien 2002-10-04 10:02 ` H. J. Lu 0 siblings, 1 reply; 30+ messages in thread From: David O'Brien @ 2002-10-04 9:53 UTC (permalink / raw) To: H. J. Lu; +Cc: gcc On Fri, Oct 04, 2002 at 09:36:29AM -0700, H. J. Lu wrote: > On Fri, Oct 04, 2002 at 09:29:36AM -0700, David O'Brien wrote: > > On Fri, Oct 04, 2002 at 08:50:14AM -0700, H. J. Lu wrote: > > > I assume you have filed bug reports marked them as regression. > > > > Yes. One finally got fixed in mainline, but I'm sure it wont get back > > ported and I wonder if I could get permission to commit it if I back > > Is that a regression? If it is, why can't it be back ported? It is. FreeBSD's bootloader had to loose some of it's strings as one could not produce a binary as small as one could with GCC 2.95. > > ported it. There are 6 Athlon and related PR's that I know of. A few > > also apply to Pentium-4. > > Are they also regression? Probably not seen as such as GCC 2.95 did not support Athon and Pentium-4 optimizations. But believe me, users are trying to use -march=athlon. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Is the gcc-3_3-branch creation still on target? 2002-10-04 9:53 ` David O'Brien @ 2002-10-04 10:02 ` H. J. Lu 2002-10-04 10:23 ` David O'Brien 0 siblings, 1 reply; 30+ messages in thread From: H. J. Lu @ 2002-10-04 10:02 UTC (permalink / raw) To: David O'Brien; +Cc: gcc On Fri, Oct 04, 2002 at 09:46:00AM -0700, David O'Brien wrote: > On Fri, Oct 04, 2002 at 09:36:29AM -0700, H. J. Lu wrote: > > On Fri, Oct 04, 2002 at 09:29:36AM -0700, David O'Brien wrote: > > > On Fri, Oct 04, 2002 at 08:50:14AM -0700, H. J. Lu wrote: > > > > I assume you have filed bug reports marked them as regression. > > > > > > Yes. One finally got fixed in mainline, but I'm sure it wont get back > > > ported and I wonder if I could get permission to commit it if I back > > > > Is that a regression? If it is, why can't it be back ported? > > It is. FreeBSD's bootloader had to loose some of it's strings as one > could not produce a binary as small as one could with GCC 2.95. > I guess no one else used it. It may be too bad for FreeBSD. I hope it won't happen again since you are testing gcc before it is branched. I tend to agree that back port it to 3.2 is not a very good idea in this case. But you can certainly do a private port for FreeBSD. > > > > ported it. There are 6 Athlon and related PR's that I know of. A few > > > also apply to Pentium-4. > > > > Are they also regression? > > Probably not seen as such as GCC 2.95 did not support Athon and Pentium-4 > optimizations. But believe me, users are trying to use -march=athlon. As long as they are fixed in gcc 3.3, I am happy. H.J. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Is the gcc-3_3-branch creation still on target? 2002-10-04 10:02 ` H. J. Lu @ 2002-10-04 10:23 ` David O'Brien 2002-10-04 10:28 ` Gerald Pfeifer 0 siblings, 1 reply; 30+ messages in thread From: David O'Brien @ 2002-10-04 10:23 UTC (permalink / raw) To: H. J. Lu; +Cc: gcc On Fri, Oct 04, 2002 at 09:52:59AM -0700, H. J. Lu wrote: > As long as they are fixed in gcc 3.3, I am happy. That is the stance I am starting to take. But no one is answering the main question of when will the branch be created. -- -- David (obrien@FreeBSD.org) ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Is the gcc-3_3-branch creation still on target? 2002-10-04 10:23 ` David O'Brien @ 2002-10-04 10:28 ` Gerald Pfeifer 0 siblings, 0 replies; 30+ messages in thread From: Gerald Pfeifer @ 2002-10-04 10:28 UTC (permalink / raw) To: David O'Brien; +Cc: H. J. Lu, gcc On Fri, 4 Oct 2002, David O'Brien wrote: >> As long as they are fixed in gcc 3.3, I am happy. > That is the stance I am starting to take. But no one is answering the > main question of when will the branch be created. I understood there has been some consensus to possibly delay generating to branch to allow mainline to further stabilize before the branch. As Zack mentioned, also 3.2.1 might be delayed to allow further back- porting a problems already fixed and to be fixed on mainline. Gerald -- Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Is the gcc-3_3-branch creation still on target? 2002-10-04 9:44 ` David O'Brien 2002-10-04 9:47 ` H. J. Lu @ 2002-10-04 10:06 ` Zack Weinberg 2002-10-04 10:25 ` Gerald Pfeifer 2 siblings, 0 replies; 30+ messages in thread From: Zack Weinberg @ 2002-10-04 10:06 UTC (permalink / raw) To: David O'Brien; +Cc: H. J. Lu, gcc On Fri, Oct 04, 2002 at 09:29:36AM -0700, David O'Brien wrote: > On Fri, Oct 04, 2002 at 08:50:14AM -0700, H. J. Lu wrote: > > I assume you have filed bug reports marked them as regression. > > Yes. One finally got fixed in mainline, but I'm sure it wont get back > ported and I wonder if I could get permission to commit it if I back > ported it. There are 6 Athlon and related PR's that I know of. A few > also apply to Pentium-4. Anything that is a regression, including from 2.x, should at least be considered for backport. Send me the PR numbers, and change log entries if you know they've been fixed for 3.3. I personally expect the release of 3.2.1 to be delayed so that the regressions can be addressed. zw ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Is the gcc-3_3-branch creation still on target? 2002-10-04 9:44 ` David O'Brien 2002-10-04 9:47 ` H. J. Lu 2002-10-04 10:06 ` Zack Weinberg @ 2002-10-04 10:25 ` Gerald Pfeifer 2 siblings, 0 replies; 30+ messages in thread From: Gerald Pfeifer @ 2002-10-04 10:25 UTC (permalink / raw) To: David O'Brien; +Cc: H. J. Lu, gcc On Fri, 4 Oct 2002, David O'Brien wrote: >> I assume you have filed bug reports marked them as regression. > Yes. One finally got fixed in mainline, but I'm sure it wont get back > ported and I wonder if I could get permission to commit it if I back > ported it. I'd say, let's try: Go ahead and submit a patch, Cc:ing our release manager (Mark). And if this is a regression in 3.2.x as well and the PR has been closed or is not of priority high, please reopen the PR and/or mark it as high priority. (Mark has been explicitly asking about the numbers of regression PRs, and I suppose he's still interested.) Gerald -- Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Is the gcc-3_3-branch creation still on target? 2002-10-04 8:23 Is the gcc-3_3-branch creation still on target? David O'Brien 2002-10-04 8:50 ` H. J. Lu @ 2002-10-04 9:36 ` Andreas Jaeger 2002-10-04 9:46 ` David O'Brien ` (2 more replies) 1 sibling, 3 replies; 30+ messages in thread From: Andreas Jaeger @ 2002-10-04 9:36 UTC (permalink / raw) To: obrien; +Cc: gcc "David O'Brien" <obrien@FreeBSD.org> writes: > Are things still on schedule to branch mainline, creating the > gcc-3_3-branch, on 15-Oct-2002? > > FreeBSD 5.0 will use some form of GCC 3.3 snapshot. I know this isn't > desired by the GCC Steering Committee to have another "gcc 2.96", but > FreeBSD has little choice. It ICE's on many popular packages, X11 as > just one example. It has serious optimization bugs for modern x86 > processors, for which the PR's aren't getting fixed. It has regressions Honza just fixed and verified a few PRs. Just getting off-topic: Honza, I noticed you commit them this way: Thu Oct 3 23:15:15 CEST 2002 Jan Hubicka <jh@suse.cz> * i386.h (CPP_SPECS): fix defines for -msse, -msse2, -mpentium2,3. The rule is to mention the PR number so that everybody knows which report is fixed, in this case the ChangeLog should be: Thu Oct 3 23:15:15 CEST 2002 Jan Hubicka <jh@suse.cz> PR c/7242 * i386.h (CPP_SPECS): fix defines for -msse, -msse2, -mpentium2,3. Can you follow the example please? Ok, back to your claims: Did you report everything? GCC 3.2 (and neither current CVS from last week) ICEs on Linux/x86 and Linux/x86-64 while compiling X11 nor on any package that is in the current SuSE distribution for these platforms. So, please send bug reports that are reproduceable. > from 2.95 that aren't getting fixed. All in all, GCC 3.2 is poo. There > needs to be a balance between adding new features, re-abstracting the > code, etc; and basic usability. So far the 3.x series has leaned too far > to the former. GCC 3.1.1 was the most stable of any of the 3.x > compilers, but it has a broken C++ ABI and is EOL'ed by the GCC > developers, which makes it a poor choice to base an OS on. GCC 3.2 is pretty good, e.g. Mandrake, Red Hat and SuSE use it as basis for their current Linux distribution. I understand that you want to switch to 3.3 but I would suggest the following (that's how we have done it at SuSE and I guess Red Hat did something similar): - use the current CVS mainline for your work and test everything with it - report all bugs that you encounter - integrate regularly (e.g. using the weekly snapshot) the current CVS version into your system and start from the beginning ;-) - release FreeBSD 3.0 with the final release of GCC 3.3. This is quite involved but if you follow the development closely, your permanent testing will help make GCC 3.3 a suitable compiler for your environment. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Is the gcc-3_3-branch creation still on target? 2002-10-04 9:36 ` Andreas Jaeger @ 2002-10-04 9:46 ` David O'Brien 2002-10-04 10:49 ` Andreas Jaeger 2002-10-04 10:47 ` Gerald Pfeifer 2002-10-04 11:18 ` Phil Edwards 2 siblings, 1 reply; 30+ messages in thread From: David O'Brien @ 2002-10-04 9:46 UTC (permalink / raw) To: Andreas Jaeger; +Cc: gcc On Fri, Oct 04, 2002 at 06:14:09PM +0200, Andreas Jaeger wrote: > Ok, back to your claims: Did you report everything? GCC 3.2 (and > neither current CVS from last week) ICEs on Linux/x86 and Linux/x86-64 > while compiling X11 nor on any package that is in the current SuSE > distribution for these platforms. So, please send bug reports that > are reproduceable. One from the GCC 3.1 is "-fno-align-functions regression from 2.95" http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6627 Some other things are reported, some things I know simply wont get fixed in the 3.2_branch. Trimming down why I get an ICE compiling the XFree86 4.2.0 server, isn't worth the time it would take to narrow it down as long as the below PR's are still open. From the ones that are reported (querry done in Sept): http://gcc.gnu.org/cgi-bin/gnatsweb.pl?database=gcc&category=all&severity=all&priority=all&responsible=all&submitter_id=all&state=all&ignoreclosed=Ignore%20Closed&class=all&synopsis=athlon&multitext=&columns=category&columns=state&columns=class&columns=responsible&columns=synopsis&displaydate=Display%20Current%20Date&cmd=submit%20query&sortby=Responsible&.cgifields=columns&.cgifields=originatedbyme&.cgifields=displaydate&.cgifields=ignoreclosed PR Category State Class Responsible Synopsis 6845 optimization open ice-on-legal-code unassigned ICE with -O -march=pentium3/pentium2/athlon 7034 optimization open ice-on-legal-code unassigned ICE on -march=athlon for CLAPACK code 7124 optimization open ice-on-legal-code unassigned -O2 -march=athlon produces ICE 7134 optimization open ice-on-legal-code unassigned Athlon: ICE in extract_insn, at recog.c:2130 7174 optimization open sw-bug unassigned ICE:seg fault with O2 and athlon-xp architecture 7390 optimization open ice-on-legal-code unassigned ICE with gcc 3.1, happens only with -march athlon http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6845 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7034 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7124 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7134 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7174 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7390 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Is the gcc-3_3-branch creation still on target? 2002-10-04 9:46 ` David O'Brien @ 2002-10-04 10:49 ` Andreas Jaeger 2002-10-04 10:51 ` Jan Hubicka 2002-10-04 13:40 ` David O'Brien 0 siblings, 2 replies; 30+ messages in thread From: Andreas Jaeger @ 2002-10-04 10:49 UTC (permalink / raw) To: obrien; +Cc: gcc "David O'Brien" <obrien@FreeBSD.org> writes: > On Fri, Oct 04, 2002 at 06:14:09PM +0200, Andreas Jaeger wrote: >> Ok, back to your claims: Did you report everything? GCC 3.2 (and >> neither current CVS from last week) ICEs on Linux/x86 and Linux/x86-64 >> while compiling X11 nor on any package that is in the current SuSE >> distribution for these platforms. So, please send bug reports that >> are reproduceable. > > One from the GCC 3.1 is "-fno-align-functions regression from 2.95" > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6627 > > Some other things are reported, some things I know simply wont get fixed > in the 3.2_branch. Trimming down why I get an ICE compiling the XFree86 > 4.2.0 server, isn't worth the time it would take to narrow it down as > long as the below PR's are still open. > >From the ones that are reported (querry done in Sept): > > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?database=gcc&category=all&severity=all&priority=all&responsible=all&submitter_id=all&state=all&ignoreclosed=Ignore%20Closed&class=all&synopsis=athlon&multitext=&columns=category&columns=state&columns=class&columns=responsible&columns=synopsis&displaydate=Display%20Current%20Date&cmd=submit%20query&sortby=Responsible&.cgifields=columns&.cgifields=originatedbyme&.cgifields=displaydate&.cgifields=ignoreclosed > > PR Category State Class Responsible Synopsis > 6845 optimization open ice-on-legal-code unassigned ICE with -O -march=pentium3/pentium2/athlon > 7034 optimization open ice-on-legal-code unassigned ICE on -march=athlon for CLAPACK code > 7124 optimization open ice-on-legal-code unassigned -O2 -march=athlon produces ICE > 7134 optimization open ice-on-legal-code unassigned Athlon: ICE in extract_insn, at recog.c:2130 > 7174 optimization open sw-bug unassigned ICE:seg fault with O2 and athlon-xp architecture > 7390 optimization open ice-on-legal-code unassigned ICE with gcc 3.1, happens only with -march athlon > > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6845 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7034 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7124 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7134 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7174 All of these are closed with comments that they got fixed or could not reproduced anymore. > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7390 This one is open and Honza mentioned "have tentative fix" So, let's get back to your original claim: > [...] It has serious optimization bugs for modern x86 > processors, for which the PR's aren't getting fixed. It has regressions From the 6 bugs "serious optimization bugs" that you mention, 5 are fixed and one is worked one. Is this really nothing "gets fixed"? I'm glad to see that the situation has improved since last time you looked at this... Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Is the gcc-3_3-branch creation still on target? 2002-10-04 10:49 ` Andreas Jaeger @ 2002-10-04 10:51 ` Jan Hubicka 2002-10-04 11:27 ` Alexander Kabaev 2002-10-04 13:40 ` David O'Brien 1 sibling, 1 reply; 30+ messages in thread From: Jan Hubicka @ 2002-10-04 10:51 UTC (permalink / raw) To: Andreas Jaeger; +Cc: obrien, gcc > > PR Category State Class Responsible Synopsis > > 6845 optimization open ice-on-legal-code unassigned ICE with -O -march=pentium3/pentium2/athlon > > 7034 optimization open ice-on-legal-code unassigned ICE on -march=athlon for CLAPACK code > > 7124 optimization open ice-on-legal-code unassigned -O2 -march=athlon produces ICE > > 7134 optimization open ice-on-legal-code unassigned Athlon: ICE in extract_insn, at recog.c:2130 > > 7174 optimization open sw-bug unassigned ICE:seg fault with O2 and athlon-xp architecture > > 7390 optimization open ice-on-legal-code unassigned ICE with gcc 3.1, happens only with -march athlon > > > > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6845 > > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7034 > > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7124 > > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7134 > > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7174 > > All of these are closed with comments that they got fixed or could > not reproduced anymore. Note that all of these manifest in some way the same bug where GCC decided to use MMX registers when it should not, so it is no surprise that they got fixed quickly. Some of bugs, like 7134 and 7390 are different and I am not sure why they has been fixed, but I din't investigated. Honza ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Is the gcc-3_3-branch creation still on target? 2002-10-04 10:51 ` Jan Hubicka @ 2002-10-04 11:27 ` Alexander Kabaev 2002-10-04 15:02 ` Richard Henderson 0 siblings, 1 reply; 30+ messages in thread From: Alexander Kabaev @ 2002-10-04 11:27 UTC (permalink / raw) To: Jan Hubicka; +Cc: aj, obrien, gcc On Fri, 4 Oct 2002 19:28:06 +0200 Jan Hubicka <jh@suse.cz> wrote: > Some of bugs, like 7134 and 7390 are different and I am not sure why > they has been fixed, but I din't investigated. 7134 has been fixed in mainline in April, and the fix has been merged back before September 16th. So far I only have two ICEs reported to me by FreeBSD users: one in XFree86 and one with GCC dumping core on invalid code. I will try to post a PR for the last one. The XFree86 looks like this: >I'm getting this when trying to compile XFree86-4-libraries with > CPUTYPE=k6-2: > miPck1Prim.c: In function `CheckFAreaPick1': > miPck1Prim.c:337: unable to find a register to spill in class `FLOAT_REGS' > miPck1Prim.c:337: this is the insn: > (insn 266 264 268 (set (subreg:SF (reg/v:DI 29 rmm0 [64]) 0) > (float:SF (mem/s/j:HI (reg/v/f:SI 1 edx [61]) [0 <variable>.x+0 S2 +A16]))) 167 {floathisf2} (insn_list 262 (nil)) > (nil)) > miPck1Prim.c:337: confused by earlier errors, bailing out Should this have been fixed by disabling moves between MMX and FP registers? I am just guessing here. -- Alexander Kabaev ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Is the gcc-3_3-branch creation still on target? 2002-10-04 11:27 ` Alexander Kabaev @ 2002-10-04 15:02 ` Richard Henderson 0 siblings, 0 replies; 30+ messages in thread From: Richard Henderson @ 2002-10-04 15:02 UTC (permalink / raw) To: Alexander Kabaev; +Cc: Jan Hubicka, aj, obrien, gcc On Fri, Oct 04, 2002 at 01:51:24PM -0400, Alexander Kabaev wrote: > > (insn 266 264 268 (set (subreg:SF (reg/v:DI 29 rmm0 [64]) 0) > > (float:SF (mem/s/j:HI (reg/v/f:SI 1 edx [61]) [0 > <variable>.x+0 S2 +A16]))) 167 {floathisf2} (insn_list 262 (nil)) > > (nil)) > > miPck1Prim.c:337: confused by earlier errors, bailing out > > Should this have been fixed by disabling moves between MMX and FP > registers? I am just guessing here. Yes. r~ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Is the gcc-3_3-branch creation still on target? 2002-10-04 10:49 ` Andreas Jaeger 2002-10-04 10:51 ` Jan Hubicka @ 2002-10-04 13:40 ` David O'Brien 2002-10-04 14:31 ` Joseph S. Myers 1 sibling, 1 reply; 30+ messages in thread From: David O'Brien @ 2002-10-04 13:40 UTC (permalink / raw) To: Andreas Jaeger; +Cc: gcc On Fri, Oct 04, 2002 at 07:23:53PM +0200, Andreas Jaeger wrote: > > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6845 > > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7034 > > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7124 Only yesterday (I do thank rth for fixing these). And the posted patch didn't mention anything about getting into the 3.2_branch line. > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7174 > > All of these are closed with comments that they got fixed or could > not reproduced anymore. Only today after my email. ;-) State-Changed-When: Thu Oct 3 09:38:14 2002 State-Changed-When: Thu Oct 3 09:40:44 2002 The PR#7174 closure didn't state if the test case was tested with mainline or a 3.2_branch compiler. It would have been useful to know. If possible please try to state that next time. [this is 110% with my freebsd.org hat on, not employer hat] The fact that serious bugs like these are just now getting fixed in the 4th release from a branch doesn't give one the warm fuzzies for basing a product on. (3.2.1 is equivlically 3.1.3) > So, let's get back to your original claim: > > [...] It has serious optimization bugs for modern x86 > > processors, for which the PR's aren't getting fixed. It has regressions > From the 6 bugs "serious optimization bugs" that you mention, 5 are > fixed and one is worked one. Is this really nothing "gets fixed"? > > I'm glad to see that the situation has improved since last time you > looked at this... It may be too late. We've been looking for six months for a GCC code base for FreeBSD 5.0. Everything we've tried has failed to not ICE on the base system + 8000 3rd party packages for i386. Based on past experiences with GCC branches this long in the tooth, we've mostly decided to go with GCC 3.3 where we have a chance of getting ICE's and other regressions fixed on a planable timeline.. -- -- David (obrien@FreeBSD.org) ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Is the gcc-3_3-branch creation still on target? 2002-10-04 13:40 ` David O'Brien @ 2002-10-04 14:31 ` Joseph S. Myers 2002-10-09 1:40 ` David O'Brien 0 siblings, 1 reply; 30+ messages in thread From: Joseph S. Myers @ 2002-10-04 14:31 UTC (permalink / raw) To: David O'Brien; +Cc: Andreas Jaeger, gcc On Fri, 4 Oct 2002, David O'Brien wrote: > It may be too late. We've been looking for six months for a GCC code > base for FreeBSD 5.0. Everything we've tried has failed to not ICE on > the base system + 8000 3rd party packages for i386. Based on past I'd favour having not ICEing on the 8000 packages be included in the application testing in the release criteria (rather than just the handful of software currently there). How long does it take to do a build of 8000 packages, and could there be an automatic regression tester for mainline doing those tests (and reporting regressions since last test to gcc-regression - ideally with .i files to reproduce the failures)? (The criterion needs to be "not ICEing" rather than actually successfully building the packages, because there will inevitably be changes breaking old invalid C++ code etc..) -- Joseph S. Myers jsm28@cam.ac.uk ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Is the gcc-3_3-branch creation still on target? 2002-10-04 14:31 ` Joseph S. Myers @ 2002-10-09 1:40 ` David O'Brien 2002-10-09 14:43 ` Joe Buck 0 siblings, 1 reply; 30+ messages in thread From: David O'Brien @ 2002-10-09 1:40 UTC (permalink / raw) To: Joseph S. Myers; +Cc: Andreas Jaeger, gcc On Fri, Oct 04, 2002 at 09:40:59PM +0100, Joseph S. Myers wrote: > I'd favour having not ICEing on the 8000 packages be included in the > application testing in the release criteria (rather than just the handful > of software currently there). How long does it take to do a build of 8000 > packages, and could there be an automatic regression tester for mainline > doing those tests (and reporting regressions since last test to > gcc-regression - ideally with .i files to reproduce the failures)? I spoke with our package builder about this. He says it takes 24 hours with a cluster of 8 build machines (pentium-III/800). With all the activities he already does; build packages for FreeBSD/4.x; for FreeBSD/5.x; experimental runs on both versions to flush out upgrading core packages like gtk, iconv, gettext, etc... there is little bandwidth on his time to try experimental compilers. :-( The scripts to do this are publically available though. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Is the gcc-3_3-branch creation still on target? 2002-10-09 1:40 ` David O'Brien @ 2002-10-09 14:43 ` Joe Buck 2002-10-09 21:04 ` David O'Brien 0 siblings, 1 reply; 30+ messages in thread From: Joe Buck @ 2002-10-09 14:43 UTC (permalink / raw) To: obrien; +Cc: Joseph S. Myers, Andreas Jaeger, gcc On Fri, Oct 04, 2002 at 09:40:59PM +0100, Joseph S. Myers wrote: > > I'd favour having not ICEing on the 8000 packages be included in the > > application testing in the release criteria (rather than just the handful > > of software currently there). How long does it take to do a build of 8000 > > packages, and could there be an automatic regression tester for mainline > > doing those tests (and reporting regressions since last test to > > gcc-regression - ideally with .i files to reproduce the failures)? David O'Brien writes: > I spoke with our package builder about this. He says it takes 24 hours > with a cluster of 8 build machines (pentium-III/800). That works out to 86.4 sec/package if each machine builds 1000 packages. Seems a bit on the slow side, but quite possible. > With all the activities he already does; build packages for FreeBSD/4.x; > for FreeBSD/5.x; experimental runs on both versions to flush out > upgrading core packages like gtk, iconv, gettext, etc... there is little > bandwidth on his time to try experimental compilers. :-( It seems that the main bottleneck is availability of machine time, as once the build process is set up, it can just be fired off. Unfortunately, if no volunteers can be found for such tasks, we tend to find these things out the hard way. You say you want to go to 3.3-pre because you're not satisfied with 3.2's quality, but there's no magic that's going to make 3.3 better, other than people building 8000 packages with "experimental compilers" (whether from the 3.2 or the 3.3 branch). I'd rather try to persuade people to put in the resources to bang on what will become 3.2.1. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Is the gcc-3_3-branch creation still on target? 2002-10-09 14:43 ` Joe Buck @ 2002-10-09 21:04 ` David O'Brien 0 siblings, 0 replies; 30+ messages in thread From: David O'Brien @ 2002-10-09 21:04 UTC (permalink / raw) To: Joe Buck; +Cc: Joseph S. Myers, Andreas Jaeger, gcc On Wed, Oct 09, 2002 at 11:56:08AM -0700, Joe Buck wrote: > David O'Brien writes: > > I spoke with our package builder about this. He says it takes 24 hours > > with a cluster of 8 build machines (pentium-III/800). > > That works out to 86.4 sec/package if each machine builds 1000 packages. > Seems a bit on the slow side, but quite possible. Oh, how I wish each of the gcc33, gcc32, and gcc31 ports built in only 86.4 seconds. Don't supose you could help with that? ;-) Seriously, each port is build in a clean chroot environment that takes a while to set up? Including pkg_add'ing dependent packages, etc. > Unfortunately, if no volunteers can be found for such tasks, we tend to > find these things out the hard way. You say you want to go to 3.3-pre > because you're not satisfied with 3.2's quality, but there's no magic > that's going to make 3.3 better, other than people building 8000 packages > with "experimental compilers" (whether from the 3.2 or the 3.3 branch). We still plan to move to 3.3; *and* do it before it is released. One reason is to feed into the pre-release testing phase, while things can be more easily fixed. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Is the gcc-3_3-branch creation still on target? 2002-10-04 9:36 ` Andreas Jaeger 2002-10-04 9:46 ` David O'Brien @ 2002-10-04 10:47 ` Gerald Pfeifer 2002-10-04 10:50 ` Jan Hubicka 2002-10-04 11:18 ` Phil Edwards 2 siblings, 1 reply; 30+ messages in thread From: Gerald Pfeifer @ 2002-10-04 10:47 UTC (permalink / raw) To: Andreas Jaeger; +Cc: obrien, gcc On Fri, 4 Oct 2002, Andreas Jaeger wrote: > Just getting off-topic: > Honza, I noticed you commit them this way: > > Thu Oct 3 23:15:15 CEST 2002 Jan Hubicka <jh@suse.cz> > > * i386.h (CPP_SPECS): fix defines for -msse, -msse2, -mpentium2,3. > > The rule is to mention the PR number so that everybody knows which > report is fixed, in this case the ChangeLog should be: > > Thu Oct 3 23:15:15 CEST 2002 Jan Hubicka <jh@suse.cz> > > PR c/7242 > * i386.h (CPP_SPECS): fix defines for -msse, -msse2, -mpentium2,3. > > Can you follow the example please? In fact, may I suggest you (Honza) update the ChangeLogs with these PR numbers? This is useful for people like Joe who destill list of fixed PRs on the release branch from these ChangeLogs. Gerald -- Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Is the gcc-3_3-branch creation still on target? 2002-10-04 10:47 ` Gerald Pfeifer @ 2002-10-04 10:50 ` Jan Hubicka 2002-10-04 10:58 ` Andreas Jaeger 0 siblings, 1 reply; 30+ messages in thread From: Jan Hubicka @ 2002-10-04 10:50 UTC (permalink / raw) To: Gerald Pfeifer; +Cc: Andreas Jaeger, obrien, gcc > On Fri, 4 Oct 2002, Andreas Jaeger wrote: > > Just getting off-topic: > > Honza, I noticed you commit them this way: > > > > Thu Oct 3 23:15:15 CEST 2002 Jan Hubicka <jh@suse.cz> > > > > * i386.h (CPP_SPECS): fix defines for -msse, -msse2, -mpentium2,3. > > > > The rule is to mention the PR number so that everybody knows which > > report is fixed, in this case the ChangeLog should be: > > > > Thu Oct 3 23:15:15 CEST 2002 Jan Hubicka <jh@suse.cz> > > > > PR c/7242 > > * i386.h (CPP_SPECS): fix defines for -msse, -msse2, -mpentium2,3. > > > > Can you follow the example please? > > In fact, may I suggest you (Honza) update the ChangeLogs with these PR > numbers? Will do at begining of next week (remind me if I will forged, but I am adding this to the todo folder). The queue has been rather long after returning from the trip and many of the bugreports has been just fixed independently. I tried to mention it in each closing email, so I guess it is better to harvest these. I didn't know we want to track fixed bugreports. THis opens interesting problems, like what to do if I find that some bug has been fixed by old change. Should I update CHangeLog? What to do in the case the testcase just works on the branch and I am unsure why? Honza > > This is useful for people like Joe who destill list of fixed PRs on the > release branch from these ChangeLogs. > > Gerald > -- > Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Is the gcc-3_3-branch creation still on target? 2002-10-04 10:50 ` Jan Hubicka @ 2002-10-04 10:58 ` Andreas Jaeger 2002-10-04 11:29 ` Zack Weinberg 0 siblings, 1 reply; 30+ messages in thread From: Andreas Jaeger @ 2002-10-04 10:58 UTC (permalink / raw) To: Jan Hubicka; +Cc: Gerald Pfeifer, obrien, gcc Jan Hubicka <jh@suse.cz> writes: >> On Fri, 4 Oct 2002, Andreas Jaeger wrote: >> > Just getting off-topic: >> > Honza, I noticed you commit them this way: >> > >> > Thu Oct 3 23:15:15 CEST 2002 Jan Hubicka <jh@suse.cz> >> > >> > * i386.h (CPP_SPECS): fix defines for -msse, -msse2, -mpentium2,3. >> > >> > The rule is to mention the PR number so that everybody knows which >> > report is fixed, in this case the ChangeLog should be: >> > >> > Thu Oct 3 23:15:15 CEST 2002 Jan Hubicka <jh@suse.cz> >> > >> > PR c/7242 >> > * i386.h (CPP_SPECS): fix defines for -msse, -msse2, -mpentium2,3. >> > >> > Can you follow the example please? >> >> In fact, may I suggest you (Honza) update the ChangeLogs with these PR >> numbers? > > Will do at begining of next week (remind me if I will forged, but I am > adding this to the todo folder). > The queue has been rather long after returning from the trip and many of > the bugreports has been just fixed independently. > I tried to mention it > in each closing email, so I guess it is better to harvest these. > I didn't know we want to track fixed bugreports. THis opens interesting > problems, like what to do if I find that some bug has been fixed by old > change. Should I update CHangeLog? What to do in the case the testcase The procedure is as far as I can see: - you look at bug report no. c/X - create a fix for bug c/X - add to the ChangeLog: PR c/X If you look at the report and notice it's fixed already, there's IMO nothing for you to do. Especially no need to commit a new ChangeLog. > just works on the branch and I am unsure why? I would simply ask ;-) Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Is the gcc-3_3-branch creation still on target? 2002-10-04 10:58 ` Andreas Jaeger @ 2002-10-04 11:29 ` Zack Weinberg 2002-10-04 13:47 ` David O'Brien 0 siblings, 1 reply; 30+ messages in thread From: Zack Weinberg @ 2002-10-04 11:29 UTC (permalink / raw) To: Andreas Jaeger; +Cc: Jan Hubicka, Gerald Pfeifer, obrien, gcc On Fri, Oct 04, 2002 at 07:47:36PM +0200, Andreas Jaeger wrote: > The procedure is as far as I can see: > - you look at bug report no. c/X > - create a fix for bug c/X > - add to the ChangeLog: PR c/X > > If you look at the report and notice it's fixed already, there's IMO > nothing for you to do. Especially no need to commit a new ChangeLog. Well, I would suggest annotating the PR with the change log entry of the patch that fixed it, if this can be determined, or just 'works for me with <platform>, <date>, <branch>' otherwise. zw ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Is the gcc-3_3-branch creation still on target? 2002-10-04 11:29 ` Zack Weinberg @ 2002-10-04 13:47 ` David O'Brien 2002-10-04 15:23 ` Jan Hubicka 0 siblings, 1 reply; 30+ messages in thread From: David O'Brien @ 2002-10-04 13:47 UTC (permalink / raw) To: Zack Weinberg; +Cc: Andreas Jaeger, Jan Hubicka, Gerald Pfeifer, gcc On Fri, Oct 04, 2002 at 10:58:36AM -0700, Zack Weinberg wrote: > Well, I would suggest annotating the PR with the change log entry of > the patch that fixed it, if this can be determined, or just 'works for > me with <platform>, <date>, <branch>' otherwise. That would be very good information to have in the PR. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Is the gcc-3_3-branch creation still on target? 2002-10-04 13:47 ` David O'Brien @ 2002-10-04 15:23 ` Jan Hubicka 0 siblings, 0 replies; 30+ messages in thread From: Jan Hubicka @ 2002-10-04 15:23 UTC (permalink / raw) To: David O'Brien Cc: Zack Weinberg, Andreas Jaeger, Jan Hubicka, Gerald Pfeifer, gcc > On Fri, Oct 04, 2002 at 10:58:36AM -0700, Zack Weinberg wrote: > > Well, I would suggest annotating the PR with the change log entry of > > the patch that fixed it, if this can be determined, or just 'works for > > me with <platform>, <date>, <branch>' otherwise. > > That would be very good information to have in the PR. OK, this looks good, I will try to use this scheme next time. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Is the gcc-3_3-branch creation still on target? 2002-10-04 9:36 ` Andreas Jaeger 2002-10-04 9:46 ` David O'Brien 2002-10-04 10:47 ` Gerald Pfeifer @ 2002-10-04 11:18 ` Phil Edwards 2 siblings, 0 replies; 30+ messages in thread From: Phil Edwards @ 2002-10-04 11:18 UTC (permalink / raw) To: Andreas Jaeger; +Cc: jh, gcc On Fri, Oct 04, 2002 at 06:14:09PM +0200, Andreas Jaeger wrote: > The rule is to mention the PR number so that everybody knows which > report is fixed, in this case the ChangeLog should be: > > Thu Oct 3 23:15:15 CEST 2002 Jan Hubicka <jh@suse.cz> > > PR c/7242 > * i386.h (CPP_SPECS): fix defines for -msse, -msse2, -mpentium2,3. Also, the CVS server will notice the text, and the commit log will be automatically appended to the PR's audit trail. Phil -- I would therefore like to posit that computing's central challenge, viz. "How not to make a mess of it," has /not/ been met. - Edsger Dijkstra, 1930-2002 ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2002-10-09 23:52 UTC | newest] Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-10-04 8:23 Is the gcc-3_3-branch creation still on target? David O'Brien 2002-10-04 8:50 ` H. J. Lu 2002-10-04 9:29 ` David O'Brien 2002-10-04 9:34 ` H. J. Lu 2002-10-04 9:44 ` David O'Brien 2002-10-04 9:47 ` H. J. Lu 2002-10-04 9:53 ` David O'Brien 2002-10-04 10:02 ` H. J. Lu 2002-10-04 10:23 ` David O'Brien 2002-10-04 10:28 ` Gerald Pfeifer 2002-10-04 10:06 ` Zack Weinberg 2002-10-04 10:25 ` Gerald Pfeifer 2002-10-04 9:36 ` Andreas Jaeger 2002-10-04 9:46 ` David O'Brien 2002-10-04 10:49 ` Andreas Jaeger 2002-10-04 10:51 ` Jan Hubicka 2002-10-04 11:27 ` Alexander Kabaev 2002-10-04 15:02 ` Richard Henderson 2002-10-04 13:40 ` David O'Brien 2002-10-04 14:31 ` Joseph S. Myers 2002-10-09 1:40 ` David O'Brien 2002-10-09 14:43 ` Joe Buck 2002-10-09 21:04 ` David O'Brien 2002-10-04 10:47 ` Gerald Pfeifer 2002-10-04 10:50 ` Jan Hubicka 2002-10-04 10:58 ` Andreas Jaeger 2002-10-04 11:29 ` Zack Weinberg 2002-10-04 13:47 ` David O'Brien 2002-10-04 15:23 ` Jan Hubicka 2002-10-04 11:18 ` Phil Edwards
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).