This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] 19/n: trans-mem: middle end/misc patches (LAST PATCH)
On Mon, Nov 7, 2011 at 4:52 PM, Aldy Hernandez <aldyh@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.