On Apr 11, 2005, Richard Henderson <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 11, 2005 at 05:41:56PM -0300, Alexandre Oliva wrote:
>> I take that back. The hash tables seem to be fine. I suspect it's
>> the sorting on pointers in the goto_queue that triggers the problem.
>> In fact, I'm pretty sure comparing pointers that are not guaranteed to
>> be in the same array invokes undefined behavior, and I do remember
>> having run into errors because of such abuse in bfd many moons ago.
> Technically, yes. I deny that it's a problem in practice except
> for segmented architectures. Which includes no gcc hosts.
The comparison of pointers may not be a problem for GCC hosts, but
it's indeed what breaks bootstraps. We sort the goto queue on
the address of its stmt, and then walk the array in sequential order
in lower_try_finally_switch(). This is exactly the sort of dependency
on pointers that we've just agreed we should avoid.
In case the problem isn't clear, we assign switch indexes growing from
0, then we sort the goto_queue VARRAY by stmt address, then generate
the switch stmt along with new artificial labels. Even though the
switch statement is later sorted by index, its label names and
redirecting BBs that follow are in a different order, so bootstrap
comparison fails. Here's a diff between two compiles of
targparm.adb's t12.eh dump:
@@ -1526,8 +1526,8 @@
system__soft_links__set_jmpbuf_address_soft (JMPBUF_SAVED.1373);
switch (finally_tmp.174D.3471)
{
- case 0: goto <D3476>;
- case 2: goto <D3475>;
+ case 0: goto <D3475>;
+ case 1: goto <D3476>;
case 3: goto <D3473>;
default : goto <D3477>;
}
@@ -1544,13 +1544,13 @@
goto <D3480>;
<D3481>:;
__builtin_stack_restore (saved_stack.54D.1849);
- goto <D1368>;
+ goto ploop_continueD.1185;
<D3482>:;
__builtin_stack_restore (saved_stack.54D.1849);
- goto ploop_continueD.1185;
+ goto line_loop_continueD.1186;
<D3483>:;
__builtin_stack_restore (saved_stack.54D.1849);
- goto line_loop_continueD.1186;
+ goto <D1368>;
<D3480>:;
ploop_continueD.1185:;
kD.1369 = kD.1369 + 1;
See how we've simply rotated the final target of the switch indexes?
The intermediate group of labels that are goto targets from the switch
statement are each followed by a goto statement to a label in the
second hunk of the diff, in the same order.
It looks like it wouldn't be too hard to overcome this problem by
generating the artificial labels in case_index order, instead of in
goto_queue order, but it's not obvious to me that the potential
randomness from sorting of stmt addresses in the goto_queue that have
the same index couldn't possibly affect the outcome.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
