Bug 34255 - [4.3 Regression] scope-blocks-on-a-diet patch diverges -g from non-g output code
Summary: [4.3 Regression] scope-blocks-on-a-diet patch diverges -g from non-g output code
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: 4.3.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-11-28 00:53 UTC by Alexandre Oliva
Modified: 2007-12-04 20:09 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2007-11-28 10:14:58


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexandre Oliva 2007-11-28 00:53:06 UTC
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
Comment 1 Richard Biener 2007-11-28 10:14:58 UTC
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.
Comment 2 Richard Biener 2007-11-28 12:15:59 UTC
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).
Comment 3 Andrew Pinski 2007-11-28 21:54:25 UTC
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.
Comment 4 Richard Biener 2007-11-28 22:08:22 UTC
Also there isn't any regression now, but it works because the patch is (still) in.
Comment 5 Jakub Jelinek 2007-12-04 19:39:25 UTC
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.
Comment 6 Richard Biener 2007-12-04 20:09:32 UTC
No need to keep this bug open, the issue is fixed with Alex's patch.