------- Comment #5 from rguenth at gcc dot gnu dot org 2010-07-19 13:40 -------
The difference starts to appear with .030t.ealias, where with debug info
we get a massive re-ordering of immediate uses (diff from .029t.forwprop1):
prev_1 : -->2 uses.
-D.2738_7 = *prev_1;
info_6 = *prev_1;
# DEBUG prev => prev_1
+D.2738_7 = *prev_1;
dpy_2(D) : --> no uses.
# DEBUG D#1 => (long int) dpy_2(D)
info_6 : --> single use.
-if (info_6 != 0B)
# DEBUG info => info_6
+if (info_6 != 0B)
D.2738_7 : --> single use.
prev_8 = &D.2738_7->next;
prev_8 : --> single use.
-prev_1 = PHI <&_XftintInfo(2), prev_8(3)>
# DEBUG prev => prev_8
+prev_1 = PHI <&_XftintInfo(2), prev_8(3)>
.MEM_9(D) : -->2 uses.
# VUSE <.MEM_9(D)>
-D.2738_7 = *prev_1;
-# VUSE <.MEM_9(D)>
info_6 = *prev_1;
+# VUSE <.MEM_9(D)>
+D.2738_7 = *prev_1;
Caused by the additional
+No longer having address taken event_base
+
+
+Symbols to be put in SSA form
+
+{ event_base }
+
+
+Incremental SSA update started at block: 0
+
in the debug enabled build (TODO_update_address_taken). Still
in referenced-vars but only for the debug-enabled build
(it is in fact never added for the -g0 build, added by
remap_decl called from remap_block during inlining).
I may have a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44971
