Re: GCC 4.2 branch comparision failure building Java
Paolo Bonzini wrote: > Mark Mitchell wrote: >> Paolo Bonzini wrote: >> >>> IIUC, the problem only manifests while *building* the release candidates, >>> not for users of the release candidate. >>> >>> For 4.2, my suggestion is to just use a bootstrap4 while building the RC. >> That's an attractive idea. But, I'd rather fix it correctly, because >> distributors may run into the same problem. > > Sorry, I meant 4.2.0 -- for 4.2.1, we can backport whatever fix is needed > for 4.3. It was fixed for 4.3 by replacing much of GCJ with ECJ. So, this is a 4.2-branch-only problem. In any case, it's now fixed, with the patch posted. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.2 branch comparision failure building Java
Mark Mitchell wrote: > Paolo Bonzini wrote: > >> IIUC, the problem only manifests while *building* the release candidates, >> not for users of the release candidate. >> >> For 4.2, my suggestion is to just use a bootstrap4 while building the RC. > > That's an attractive idea. But, I'd rather fix it correctly, because > distributors may run into the same problem. Sorry, I meant 4.2.0 -- for 4.2.1, we can backport whatever fix is needed for 4.3. >> For 4.3, we can use --enable-stage1-languages=all when building the RCs. >> I can prepare a patch to do that automatically when >> --enable-generated-files-in-srcdir >> is passed. > > That might work, but it seems like overkill; that just makes the > bootstrap process longer. It makes it longer by one-two minutes: the time to build the three front-ends without optimization. Paolo
Re: GCC 4.2 branch comparision failure building Java
Paolo Bonzini wrote: For 4.3, we can use --enable-stage1-languages=all when building the RCs. I can prepare a patch to do that automatically when --enable-generated-files-in-srcdir is passed. That should not be needed on the trunk, as the .y files in question (gcc/java/parse.y and gcc/java/parse-scan.y) do not exist on the trunk. They have been removed. David Daney
Re: GCC 4.2 branch comparision failure building Java
Paolo Bonzini wrote: > IIUC, the problem only manifests while *building* the release candidates, > not for users of the release candidate. > > For 4.2, my suggestion is to just use a bootstrap4 while building the RC. That's an attractive idea. But, I'd rather fix it correctly, because distributors may run into the same problem. > For 4.3, we can use --enable-stage1-languages=all when building the RCs. > I can prepare a patch to do that automatically when > --enable-generated-files-in-srcdir > is passed. That might work, but it seems like overkill; that just makes the bootstrap process longer. My preferred solution would be to remove --e-g-f-i-s. I think we should just require that users have the tools they need to build the compilers, and drop all of this complexity. However, I recognize that's probably not the consensus opinion. Assuming that we can't do that, I'd rather just fix the Makefiles, if there are any more such problems. As Joseph's noted, the Java problem is already gone on mainline, thanks to the ECJ integration. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.2 branch comparision failure building Java
On Fri, 16 Mar 2007, Mark Mitchell wrote: > I was thinking about trying to fix this by doing something similar -- > but avoiding the copy. You still need the srcextra rule around to do the copy, for use in generating gcc.pot without --egfis - or the regeneration instructions could change to require that option, which might be simpler. -- Joseph S. Myers [EMAIL PROTECTED]
Re: GCC 4.2 branch comparision failure building Java
> This didn't apply with 4.1 because then, without toplevel bootstrap, all > files to be copied to the source directory were generated and copied in > stage 1, so stage 2 and stage 3 both built them from the source directory. > Now, stage 1 is not only built as C only but the whole stage 1 build > directory is configured as C only, and so Java generated files don't get > copied until stage 2. IIUC, the problem only manifests while *building* the release candidates, not for users of the release candidate. For 4.2, my suggestion is to just use a bootstrap4 while building the RC. For 4.3, we can use --enable-stage1-languages=all when building the RCs. I can prepare a patch to do that automatically when --enable-generated-files-in-srcdir is passed. Paolo
Re: GCC 4.2 branch comparision failure building Java
Mark Mitchell <[EMAIL PROTECTED]> writes: > Ian Lance Taylor wrote: > > "Joseph S. Myers" <[EMAIL PROTECTED]> writes: > > > >> This is caused by --enable-generated-files-in-srcdir, as used by the > >> release script, hence not being seen by people configuring normally > >> without that option. > > Thanks for the analysis! Yes indeed, that was somewhat tricky. > Can we do: > > java_parse_c := java/parse.c > ifeq ($(GENINSRC),) > java_parse_c := $(srcdir)/$(java_parse_c) > endif > > $(java_parse_c): java/parse.y > -$(BISON) -t ... -o $@ $< > > And, then, just have java/parse.o depend on $(java_parse_c)? That is a better plan. It seems like it ought to work. Ian
Re: GCC 4.2 branch comparision failure building Java
Ian Lance Taylor wrote: > "Joseph S. Myers" <[EMAIL PROTECTED]> writes: > >> This is caused by --enable-generated-files-in-srcdir, as used by the >> release script, hence not being seen by people configuring normally >> without that option. Thanks for the analysis! > Since we require GNU make, we could do something along these lines: > > $(srcdir)/java/parse.c: java/parse.c > -cp -p $^ $(srcdir)/java > java.srcextra: $(srcdir)/java/parse.c > > ifeq ($(GENINSRC),) > java/parse.o: $(srcdir)/java/parse.c > else > java/parse.o: java/parse.c > endif I was thinking about trying to fix this by doing something similar -- but avoiding the copy. Can we do: java_parse_c := java/parse.c ifeq ($(GENINSRC),) java_parse_c := $(srcdir)/$(java_parse_c) endif $(java_parse_c): java/parse.y -$(BISON) -t ... -o $@ $< And, then, just have java/parse.o depend on $(java_parse_c)? I was going to give this a try, but if you know whether it's going to break, let me know. :-) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.2 branch comparision failure building Java
"Joseph S. Myers" <[EMAIL PROTECTED]> writes: > This is caused by --enable-generated-files-in-srcdir, as used by the > release script, hence not being seen by people configuring normally > without that option. The first time Java is built (stage 2), the file > java/parse.c is generated in the build directory and compiled from the > build directory; only some time after parse.o is built does parse.c get > copied to the source directory. The second time (stage 3) it's built from > the source directory because of the VPATH setting. Building from > different paths means different debug info. > > This didn't apply with 4.1 because then, without toplevel bootstrap, all > files to be copied to the source directory were generated and copied in > stage 1, so stage 2 and stage 3 both built them from the source directory. > Now, stage 1 is not only built as C only but the whole stage 1 build > directory is configured as C only, and so Java generated files don't get > copied until stage 2. > > I have no suggested solution, other than ceasing to include files > generated with bison, flex and makeinfo in releases for 4.2 and later. > (The GNU Coding Standards describe such generated files with "We commonly > include" rather than with a requirement to include them.) Interesting. Since we require GNU make, we could do something along these lines: $(srcdir)/java/parse.c: java/parse.c -cp -p $^ $(srcdir)/java java.srcextra: $(srcdir)/java/parse.c ifeq ($(GENINSRC),) java/parse.o: $(srcdir)/java/parse.c else java/parse.o: java/parse.c endif The generated files have disappeared from mainline, so this would be a 4.2 only hack. Ian
Re: GCC 4.2 branch comparision failure building Java
On Tue, 13 Mar 2007, Mark Mitchell wrote: > The GCC 4.2.0 RC1 build has failed (on x86_64-unknown-linux-gnu) with: > > Comparing stages 2 and 3 > Bootstrap comparison failure! > ./java/parse.o differs > ./java/parse-scan.o differs This is caused by --enable-generated-files-in-srcdir, as used by the release script, hence not being seen by people configuring normally without that option. The first time Java is built (stage 2), the file java/parse.c is generated in the build directory and compiled from the build directory; only some time after parse.o is built does parse.c get copied to the source directory. The second time (stage 3) it's built from the source directory because of the VPATH setting. Building from different paths means different debug info. This didn't apply with 4.1 because then, without toplevel bootstrap, all files to be copied to the source directory were generated and copied in stage 1, so stage 2 and stage 3 both built them from the source directory. Now, stage 1 is not only built as C only but the whole stage 1 build directory is configured as C only, and so Java generated files don't get copied until stage 2. I have no suggested solution, other than ceasing to include files generated with bison, flex and makeinfo in releases for 4.2 and later. (The GNU Coding Standards describe such generated files with "We commonly include" rather than with a requirement to include them.) I've found another issue that can cause comparison failures in some circumstances; I'll file a PR for that. -- Joseph S. Myers [EMAIL PROTECTED]
Re: GCC 4.2 branch comparision failure building Java
On Thu, Mar 15, 2007 at 05:48:12PM -0700, Joe Buck wrote: > At one point I considered trying a search to see which files get > miscompiled, by combining stage1 object files from a run with 3.2.3 and > 3.4.2 and trying to do the rest of the bootstrap with that, then varying > which .o files come from which compilers. But then I got much busier and > lost the motivation. I suppose another possibility would be to determine the first revision of the compiler that fails bootstrap compare when built with 3.2.3; it was months ago if I recall correctly (4.1.x works).
Re: GCC 4.2 branch comparision failure building Java
On Thu, Mar 15, 2007 at 05:30:48PM -0700, Mark Mitchell wrote: > Joe Buck wrote: > > >> For what it's worth, I bootstrapped on a few different GNU/Linux > >> systems with different kernels and base compilers. I only saw > >> bootstrap comparison failures on one; that one was running Red Hat 9 > >> and had gcc 3.2.2 installed in /usr/bin. On that one, a bootstrap4 > >> worked. So I assumed that that one was due to some miscompilation of > >> stage1. > > > > Yes, this has been reported before (I've also seen bootstrap failures > > when using Red Hat's version 3.2.3 on an x86 RHEL3 box). > > I do indeed generally build GCC releases on an RHEL3 box. However, I > believe that I was using a version of GCC 3.4.x (built by CodeSourcery) > as the bootstrap compiler. It does seem like a suspiciously similar > situation, though; I'm sure that Joseph will be able to tell us if the > problem is reproducible with GCC 3.4.x. The problem does not happen with 3.4.x at least for x==2. I regularly use gcc 3.4.2 as the bootstrap compiler for my gcc testing. Here's last night's run for the 4.2 branch: http://gcc.gnu.org/ml/gcc-testresults/2007-03/msg00710.html At one point I considered trying a search to see which files get miscompiled, by combining stage1 object files from a run with 3.2.3 and 3.4.2 and trying to do the rest of the bootstrap with that, then varying which .o files come from which compilers. But then I got much busier and lost the motivation.
Re: GCC 4.2 branch comparision failure building Java
Joe Buck wrote: >> For what it's worth, I bootstrapped on a few different GNU/Linux >> systems with different kernels and base compilers. I only saw >> bootstrap comparison failures on one; that one was running Red Hat 9 >> and had gcc 3.2.2 installed in /usr/bin. On that one, a bootstrap4 >> worked. So I assumed that that one was due to some miscompilation of >> stage1. > > Yes, this has been reported before (I've also seen bootstrap failures > when using Red Hat's version 3.2.3 on an x86 RHEL3 box). I do indeed generally build GCC releases on an RHEL3 box. However, I believe that I was using a version of GCC 3.4.x (built by CodeSourcery) as the bootstrap compiler. It does seem like a suspiciously similar situation, though; I'm sure that Joseph will be able to tell us if the problem is reproducible with GCC 3.4.x. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.2 branch comparision failure building Java
On Thu, Mar 15, 2007 at 04:11:29PM -0700, Ian Lance Taylor wrote: > "Joseph S. Myers" <[EMAIL PROTECTED]> writes: > > > On Tue, 13 Mar 2007, Mark Mitchell wrote: > > > > > The GCC 4.2.0 RC1 build has failed (on x86_64-unknown-linux-gnu) with: > > > > > > Comparing stages 2 and 3 > > > Bootstrap comparison failure! > > > ./java/parse.o differs > > > ./java/parse-scan.o differs > > > > > > Has anyone else seen this? > > > > I'm now looking at this (or at a possibly related bootstrap comparison > > failure seen on i686-pc-linux-gnu). > > For what it's worth, I bootstrapped on a few different GNU/Linux > systems with different kernels and base compilers. I only saw > bootstrap comparison failures on one; that one was running Red Hat 9 > and had gcc 3.2.2 installed in /usr/bin. On that one, a bootstrap4 > worked. So I assumed that that one was due to some miscompilation of > stage1. Yes, this has been reported before (I've also seen bootstrap failures when using Red Hat's version 3.2.3 on an x86 RHEL3 box). While we could tell people to use a different compiler to bootstrap, a lot of people will run into this, because there are still a lot of older systems with 3.2.x compilers out there. It might be possible to isolate and work around the failure.
Re: GCC 4.2 branch comparision failure building Java
"Joseph S. Myers" <[EMAIL PROTECTED]> writes: > On Tue, 13 Mar 2007, Mark Mitchell wrote: > > > The GCC 4.2.0 RC1 build has failed (on x86_64-unknown-linux-gnu) with: > > > > Comparing stages 2 and 3 > > Bootstrap comparison failure! > > ./java/parse.o differs > > ./java/parse-scan.o differs > > > > Has anyone else seen this? > > I'm now looking at this (or at a possibly related bootstrap comparison > failure seen on i686-pc-linux-gnu). For what it's worth, I bootstrapped on a few different GNU/Linux systems with different kernels and base compilers. I only saw bootstrap comparison failures on one; that one was running Red Hat 9 and had gcc 3.2.2 installed in /usr/bin. On that one, a bootstrap4 worked. So I assumed that that one was due to some miscompilation of stage1. I saw one other similar case recently: an older compiler miscompiled stage1 in a way that introduced a bootstrap comparison failure; unfortunately I don't recall the exact details. Anyhow, the point is: first see if a bootstrap4/compare3 works. If it does, look at your base compiler. Ian
Re: GCC 4.2 branch comparision failure building Java
Joseph S. Myers wrote: > On Tue, 13 Mar 2007, Mark Mitchell wrote: > >> The GCC 4.2.0 RC1 build has failed (on x86_64-unknown-linux-gnu) with: >> >> Comparing stages 2 and 3 >> Bootstrap comparison failure! >> ./java/parse.o differs >> ./java/parse-scan.o differs >> >> Has anyone else seen this? > > I'm now looking at this (or at a possibly related bootstrap comparison > failure seen on i686-pc-linux-gnu). Thanks! That's a big help. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.2 branch comparision failure building Java
On Tue, 13 Mar 2007, Mark Mitchell wrote: > The GCC 4.2.0 RC1 build has failed (on x86_64-unknown-linux-gnu) with: > > Comparing stages 2 and 3 > Bootstrap comparison failure! > ./java/parse.o differs > ./java/parse-scan.o differs > > Has anyone else seen this? I'm now looking at this (or at a possibly related bootstrap comparison failure seen on i686-pc-linux-gnu). -- Joseph S. Myers [EMAIL PROTECTED]
