Created attachment 1697827 [details]
Preprocessed source

Reproduced, reducing now.  Note the f33 gcc is the same as f32.

Unfortunately, this really can't be reduced in any way, because it depends on luck or thereof in the C++ FE template specialization hashing.
What I see in the debugger is that
bit_pun function template is specialized twice, once with <Vec, vector(4) float> and once with <Vec, __Float32x4_t>.
The former vector type is:
    elt:1 <vector_type 0x7fffea85cf18
        type <real_type 0x7fffea7742a0 float type_6 SF
            size <integer_cst 0x7fffea76e198 constant 32>
            unit-size <integer_cst 0x7fffea76e1b0 constant 4>
            align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffea7742a0 precision:32
            pointer_to_this <pointer_type 0x7fffea774888> reference_to_this <reference_type 0x7fffe378d7e0>>
        type_6 V4SF size <integer_cst 0x7fffea754f90 128> unit-size <integer_cst 0x7fffea754fa8 16>
        align:128 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffea85cf18 nunits:4>>
(and has TYPE_CANONICAL itself), while the other one is some vector type created by the aarch64 backend:
    elt:1 <vector_type 0x7fffea85f000 __Float32x4_t
        type <real_type 0x7fffea7742a0 float type_6 SF
            size <integer_cst 0x7fffea76e198 constant 32>
            unit-size <integer_cst 0x7fffea76e1b0 constant 4>
            align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffea7742a0 precision:32
            pointer_to_this <pointer_type 0x7fffea774888> reference_to_this <reference_type 0x7fffe378d7e0>>
        type_6 V4SF size <integer_cst 0x7fffea754f90 128> unit-size <integer_cst 0x7fffea754fa8 16>
        align:128 warn_if_not_align:0 symtab:0 alias-set -1 structural-equality nunits:4>>
(and has NULL TYPE_CANONICAL).
In iterative_hash_template_arg for these VECTOR_TYPEs we end up:
        default:
          if (tree canonical = TYPE_CANONICAL (arg))
            val = iterative_hash_object (TYPE_HASH (canonical), val);
and thus hash it differently between vector(4) float and __Float32x4_t.
But spec_hasher::equal calls comp_template_args for that and that in turn calls same_type_p on those and
structural_comptypes is called because one of those lacks TYPE_CANONICAL, and there it does:
    case VECTOR_TYPE:
      if (gnu_vector_type_p (t1) != gnu_vector_type_p (t2)
          || maybe_ne (TYPE_VECTOR_SUBPARTS (t1), TYPE_VECTOR_SUBPARTS (t2))
          || !same_type_p (TREE_TYPE (t1), TREE_TYPE (t2)))
        return false;
and considers the two the same.
Because it hashed differently, it is added twice into the hash table, and when we are unlucky, the two hash values modulo the size of the hash table are equal,
so we have two different specializations (instantiations?) for the same thing and the check that retrieve_specialization returns the one we are considering fails.

2020-06-17  Jakub Jelinek  <jakub>

	* pt.c (iterative_hash_template_arg): Handle VECTOR_TYPE.

--- gcc/cp/pt.c.jj	2020-06-17 18:48:53.506617982 +0200
+++ gcc/cp/pt.c	2020-06-17 19:34:28.551298600 +0200
@@ -1924,10 +1924,21 @@ iterative_hash_template_arg (tree arg, h
 	  }
 	  break;
 
-	case  DECLTYPE_TYPE:
+	case DECLTYPE_TYPE:
 	  val = iterative_hash_template_arg (DECLTYPE_TYPE_EXPR (arg), val);
 	  break;
 
+	case VECTOR_TYPE:
+	  {
+	    bool gnu_vec = gnu_vector_type_p (arg);
+	    val = iterative_hash_object (gnu_vec, val);
+	    val = iterative_hash_template_arg (TREE_TYPE (arg), val);
+	    inchash::hash hstate (val);
+	    hstate.add_poly_int (TYPE_VECTOR_SUBPARTS (arg));
+	    val = hstate.end ();
+	  }
+	  break;
+
 	default:
 	  if (tree canonical = TYPE_CANONICAL (arg))
 	    val = iterative_hash_object (TYPE_HASH (canonical), val);

fixes this for me, but I wonder if we don't need to handle at least POINTER_TYPE and REFERENCE_TYPE too, because if a template argument
is not a vector type, but e.g. a pointer to vector or reference to vector, due to the magic backend VECTOR_TYPEs with no TYPE_CANONICAL
pointers to them will also have structural equality and thus would hash differently from pointers/references to the C++ FE created vector types.

Thoughts on this?

The __Float32x4_t type is created in aarch64_init_simd_builtin_types using build_distinct_type_copy and
explicitly requests structural equality:
          aarch64_simd_types[i].itype
            = build_distinct_type_copy
              (build_vector_type (eltype, GET_MODE_NUNITS (mode)));
          SET_TYPE_STRUCTURAL_EQUALITY (aarch64_simd_types[i].itype);

For POINTER_TYPE/REFERENCE_TYPE, we could do:
	case REFERENCE_TYPE:
	  {
	    bool rval = TYPE_REF_IS_RVALUE (arg);
	    val = iterative_hash_object (rval, val);
	  }
	  /* FALLTHRU */
	case POINTER_TYPE:
	  {
	    machine_mode mode = TYPE_MODE (arg);
	    val = iterative_hash_object (mode, val);
	    val = iterative_hash_template_arg (TREE_TYPE (arg), val);
	  }
	  break;
or so.

With a param mentioned by Patrick I have been able to construct a small testcase for trunk from scratch.

Does the aarch64 port expect this type to be considered equivalent to the GNU vector type or not?  If so, why use build_distinct_type_copy over build_variant_type_copy?  If not, they probably want to set TYPE_INDIVISIBLE_P so that structural_comptypes treats them as different.

I have no idea.  Can you ask that question in PR95726, so that Richard Sandiford can answer it?
I think they want TYPE_INDIVISIBLE_P just for the SVE variable length vectors which are different beasts.

This is not going to be resolved in the build I'm going to do right now.
As a quick workaround, I'd suggest to copy
skia/include/private/SkVx.h bit_pun to bit_pun2 (different name, identical content) and
use bit_pun2 instead of bit_pun for instantiations with the ARM specific intrinsic types like 
uint32x4_t or float32x4_t (so sed -i -e 's/bit_pun<uint32x4_t>/bit_pun2<uint32x4_t>/g;s/bit_pun<float32x4_t>/bit_pun2<float32x4_t>/g' ).

Thanks Jakub. I've made that chromium patch and it looks like it resolves the issue for now.

This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.