public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/95726] New: ICE with aarch64 __Float32x4_t as template argument
@ 2020-06-17 19:02 jakub at gcc dot gnu.org
  2020-06-17 19:07 ` [Bug c++/95726] " jason at gcc dot gnu.org
                   ` (14 more replies)
  0 siblings, 15 replies; 16+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-06-17 19:02 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726

            Bug ID: 95726
           Summary: ICE with aarch64 __Float32x4_t as template argument
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Following test ICEs on aarch64-linux:

// { dg-do compile }
// { dg-options "--param=hash-table-verification-limit=500 -O2" }

typedef __Float32x4_t float32x4_t;
typedef float V [[gnu::vector_size(4 * sizeof (float))]];

template <typename T>
int
foo ()
{
  return 0;
}

int
bar ()
{
  return foo <float32x4_t> () + foo <__Float32x4_t> () + foo <V> () + foo
<float [[gnu::vector_size(4 * sizeof (float))]]> ();
}

On 10.x branch I can reproduce the ICE even on a large unreduceable source
without that extra argument.

The function template is specialized twice, once with <vector(4) float> and
once with <__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@redhat.com>

        * 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.

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;

Thoughts on this?

^ permalink raw reply	[flat|nested] 16+ messages in thread
end of thread, other threads:[~2020-08-04 12:47 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-17 19:02 [Bug c++/95726] New: ICE with aarch64 __Float32x4_t as template argument jakub at gcc dot gnu.org
2020-06-17 19:07 ` [Bug c++/95726] " jason at gcc dot gnu.org
2020-06-17 19:08 ` jason at gcc dot gnu.org
2020-06-17 19:29 ` rsandifo at gcc dot gnu.org
2020-06-17 19:36 ` jakub at gcc dot gnu.org
2020-06-18 12:49 ` rsandifo at gcc dot gnu.org
2020-06-18 16:11 ` rsandifo at gcc dot gnu.org
2020-06-18 16:46 ` jakub at gcc dot gnu.org
2020-06-18 20:10 ` jason at gcc dot gnu.org
2020-06-19 16:23 ` jason at gcc dot gnu.org
2020-06-22 16:04 ` rsandifo at gcc dot gnu.org
2020-06-30 20:40 ` cvs-commit at gcc dot gnu.org
2020-06-30 21:10 ` rsandifo at gcc dot gnu.org
2020-07-10 18:07 ` cvs-commit at gcc dot gnu.org
2020-07-15 10:58 ` cvs-commit at gcc dot gnu.org
2020-08-04 12:47 ` jakub at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).