http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01745.html regresses the property that code output with -g must be the same as that without -g. make bootstrap-debug demonstrates that several files miscompare after this patch, and don't if the patch is reversed. The patch not only causes -g divergence, it also accidentally drops subblocks that need to be kept around for the sake of generating debug information for them. Both problems are fixed with the patch at http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00608.html
Confirmed. The mentioned patch has been applied to the trunk already. > The patch not only causes -g divergence, it also accidentally drops subblocks > that need to be kept around for the sake of generating debug information for > them. This is certainly bad and needs to be (is already) fixed. > http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01745.html regresses the property > that code output with -g must be the same as that without -g. make > bootstrap-debug demonstrates that several files miscompare after this patch, > and don't if the patch is reversed. This causes memory-usage regressions for non-debug builds, for example for tramp3d-v4 at -O2 -Dleafify=flatten which (peak) memory-usage grows from 807MB to 1248MB. (Worse if you also add -fopenmp, less worse if you drop -Dleafify=flatten) The following two patches http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00523.html http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00524.html probably address the latter problem in a more efficient way.
The two patches reduce the boostrap-debug failures that re-appear with reverting the part that fixes > http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01745.html regresses the property > that code output with -g must be the same as that without -g. make > bootstrap-debug demonstrates that several files miscompare after this patch, > and don't if the patch is reversed. to ./lcm.o differs ./cfghooks.o differs ./postreload.o differs ./cfgloopmanip.o differs from several dozen miscompares. My bet is that this is because we process the unexpanded_vars list in non-UID order at expansion time. I'm testing a patch that sorts them after UID before expanding (we could also keep a bitmap now with the first patch, but that would be more work now).
Only the RM should change the priority. And I don't think this is blocking as the difference is not different in working vs not working code.
Also there isn't any regression now, but it works because the patch is (still) in.
Alex's patch has not been reverted and it seems it was agreed on to keep it for 4.3 and only try something different, like Richard's patches, for 4.4. If so, this isn't a 4.3 regression, because 4.2 was AFAIK eating even more memory, so this should be just a target 4.4 non-regression memory saving request.
No need to keep this bug open, the issue is fixed with Alex's patch.