On Mon, Nov 7, 2011 at 4:52 PM, Aldy Hernandez <al...@redhat.com> wrote > >> This won't work - DECL_UIDs are not stable -g vs. -g0 - only their >> _order_ is stable - thus you won't get comparison fails with code >> generated >> dependent on DECL_UID order, but you will if you depend on the DECL_UID >> value (which you do by using it as a hash). >> >> And we will still generate different object files based on garbage >> collector >> settings this way - GC can shrink hashtables, causing re-hashing, >> which changes the order of the elements. It also causes re-ordering >> with slight unrelated code changes (but if you say at runtime we always >> sort the thing that might not be an issue). > > Ah, I get it. > >> Thus, the patch isn't a fix to get a stable order (you can't get >> that for hashtable walks). A quick fix is to collect the elements >> into a VEC and qsort that after some stable key (like the DECL_UID). > > I've done so in the attached patch. > > Notice I am hijacking the alias_pair object, because it has everything we > need, though the DECL_UID goes in a field called emitted_diags. I am > avoiding having to create an exact same object with the exact same fields. > I can change duplicate this, if it's a big eye sore.
Yes, please duplicate this - alias_pairs are going away (hopefully for 4.7). And in that light, simply use a heap allocated vector - it's short-lived after all. > Preliminary tests show the TM tests all work, but a full test run is still > underway. OK pending tests? Otherwise ok. Thanks, Richard.
