------- Comment #9 from jamborm at gcc dot gnu dot org 2009-12-16 20:58 ------- I'm now officially on vacation so I did not double check but...
(In reply to comment #8) > I think > > /* Put the integral type with the bigger precision first. */ > else if (INTEGRAL_TYPE_P (f1->type) > && INTEGRAL_TYPE_P (f2->type) > && TYPE_PRECISION (f1->type) != TYPE_PRECISION (f2->type)) > return TYPE_PRECISION (f1->type) > TYPE_PRECISION (f2->type) ? -1 : > 1; > > makes more sense. But still if both types are equal we still do not stabilize > the sort. > > Note > > /* Put any integral type with non-full precision last. */ > else if (INTEGRAL_TYPE_P (f1->type) > && (TREE_INT_CST_LOW (TYPE_SIZE (f1->type)) > != TYPE_PRECISION (f1->type))) > return 1; > else if (INTEGRAL_TYPE_P (f2->type) > && (TREE_INT_CST_LOW (TYPE_SIZE (f2->type)) > != TYPE_PRECISION (f2->type))) > return -1; > > isn't stable either. In fact - can't we have two exactly the same > accesses in the array? > Of course we can have multiple accesses that are exactly the same. The important thing is that we return zero for them. In fact we sometimes may not care which of two different accesses goes first and we have to return zero for such pairs too. As far as I can remember, we already do that for non-integer types (because there is a subtraction of type UIDS just below the snippet you pasted above and the branches you did paste do not trigger if both types are integers because that is handled by a branch earlier which causes the problems... and if only one of them is integer then we return 1 for one ordering and -1 for the other, just as expected). IIRC, we don't stabilize the sort only if both types are integers because the type UID subtraction is missing and my patch ads that, nothing more. Internet access is expensive here so I types this in a bit of a ruch but I hope it is understandable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42157
