https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126968
Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
--- Comment #5 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
The problem:
When an ASSOCIATE selector is a function that has not been parsed yet
(a contained function), gfc_match_varspec guesses the associate name's
type from the first component name. gfc_find_derived_types collects
every accessible derived type with a component of that name, and the
head of the list is used. resolve_assoc_var and
gfc_fixup_inferred_type_refs correct the guess later.
find_derived_types (symbol.cc) built the list with a PRE-ORDER walk of
the symtree (node, left, right). Pre-order visit order depends on the
tree's shape.
Symtrees are treaps (bbt.cc). Each node's priority comes from
static int x0 = 5341;
x0 = (22611 * x0 + 10) % 44071;
That sequence is deterministic, but it is ONE GLOBAL sequence shared by
every treap insertion in the whole compilation. A tree's shape depends
on how many numbers were drawn before its symbols were inserted.
Evidence (GDB on f951, breakpoint on gfc_insert_bbt):
-m64: 727 treap insertions -m32: 724 treap insertions
The missing symtree is __convert_i4_i8. With -m64 the index kind is 8,
so resolving module m creates an integer(4) -> integer(8) conversion
function symbol. With -m32 the index kind is 4 and it is not needed.
That one missing draw shifts every later priority, so program p's
symtree takes a different shape.
Result for associate_91, candidates for component 'c1':
-m64: guess = outer_t (correct type; the wrong-guess path the test
was written for never ran on x86_64)
-m32: guess = wrong_t (c1 is a scalar integer, so %c2 cannot be
parsed -> "Unclassifiable statement")
