[Bug 1890435]

[Rguenth]

The odd thing is we have

 <array_type 0x7ffff6665888
    type <integer_type 0x7ffff66655e8 a SI
        size <integer_cst 0x7ffff68120a8 constant 32>
        unit-size <integer_cst 0x7ffff68120c0 constant 4>
        user align:16 warn_if_not_align:0 symtab:-161040432 alias-set -1 canonical-type 0x7ffff68165e8 precision:32 min <integer_cst 0x7ffff68122e8 -2147483648> max <integer_cst 0x7ffff6812300 2147483647>>
    no-force-blk BLK size <integer_cst 0x7ffff68120a8 32> unit-size <integer_cst 0x7ffff68120c0 4>
    user align:16 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7ffff6665930
    domain <integer_type 0x7ffff66657e0

so the array type has alignment 2 and BLKmode but the component type has
SImode and alignment 2.  This is done by

      SET_TYPE_MODE (type, mode_for_array (TREE_TYPE (type),
                                           TYPE_SIZE (type))); <- sets SImode
      if (TYPE_MODE (type) != BLKmode
          && STRICT_ALIGNMENT && TYPE_ALIGN (type) < BIGGEST_ALIGNMENT
          && TYPE_ALIGN (type) < GET_MODE_ALIGNMENT (TYPE_MODE (type)))
        {
          TYPE_NO_FORCE_BLK (type) = 1;
          SET_TYPE_MODE (type, BLKmode);

now, you could argue having both types have the same TYPE_CANONICAL isn't
needed.  You don't need it for alias compatibility since that's keyed off the
element type of arrays only.  Likewise for value assignments between
array types.

That said, a possibility would be to simply declare having this type
combination with a mode mismatch OK, at least for aggregate types
where modes historically behave a bit "odd".

So something like the following (we now exempt record-or-union types for
mode processing already)

diff --git a/gcc/tree.cc b/gcc/tree.cc
index eab40008e8b..d30ccf7cb7f 100644
--- a/gcc/tree.cc
+++ b/gcc/tree.cc
@@ -13924,6 +13924,7 @@ gimple_canonical_types_compatible_p (const_tree t1, const_tree t2,
      flexible array members, we allow mismatching modes for structures or
      unions.  */
   if (!RECORD_OR_UNION_TYPE_P (t1)
+      && TREE_CODE (t1) != ARRAY_TYPE
       && TYPE_MODE (t1) != TYPE_MODE (t2))
     return false;
 
@@ -14255,6 +14256,7 @@ verify_type (const_tree t)
         flexible array members.  */
       && !RECORD_OR_UNION_TYPE_P (t)
       && !RECORD_OR_UNION_TYPE_P (TYPE_CANONICAL (t))
+      && TREE_CODE (t) != ARRAY_TYPE
       && TYPE_MODE (t) != TYPE_MODE (TYPE_CANONICAL (t)))
     {
       error ("%<TYPE_MODE%> of %<TYPE_CANONICAL%> is not compatible");

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to gcc-10 in Ubuntu.
https://bugs.launchpad.net/bugs/1890435

Title:
  gcc-10 breaks on armhf (flaky): internal compiler error: Segmentation
  fault

Status in gcc:
  In Progress
Status in gcc-10 package in Ubuntu:
  Confirmed

Bug description:
  Hi,
  this could be the same as bug 1887557 but as I don't have enough data I'm filing it as individual issue for now.

  I have only seen this happening on armhf so far.
  In 2 of 5 groovy builds of qemu 5.0 this week I have hit the issue, but it is flaky.

  Flakyness:
  1. different file
  first occurrence
  /<<PKGBUILDDIR>>/target/s390x/excp_helper.c:544:1: internal compiler error: Segmentation fault
  second occurrence
  /<<PKGBUILDDIR>>/linux-user/syscall.c:12479:1: internal compiler error: Segmentation fault

  Being so unreliable I can't provide mcuh more yet.
  I filed it mostly for awareness and so that I can be dup'ed onto the right but if there is a better one.

To manage notifications about this bug go to:
https://bugs.launchpad.net/gcc/+bug/1890435/+subscriptions