[Bug other/99648] New: [11 regression] gcc.dg/torture/pr71522.c fails starting with r11-165 for 32 bits

[Bug other/99648] New: [11 regression] gcc.dg/torture/pr71522.c fails starting with r11-165 for 32 bits

[seurer at gcc dot gnu.org]

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

            Bug ID: 99648
           Summary: [11 regression] gcc.dg/torture/pr71522.c fails
                    starting with r11-165 for 32 bits
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:eb72dc663e9070b281be83a80f6f838a3a878822, r11-165
make  -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32}'
dg-torture.exp=gcc.dg/torture/pr71522.c"
FAIL: gcc.dg/torture/pr71522.c   -O1  execution test
FAIL: gcc.dg/torture/pr71522.c   -O2  execution test
FAIL: gcc.dg/torture/pr71522.c   -O3 -g  execution test
FAIL: gcc.dg/torture/pr71522.c   -Os  execution test
FAIL: gcc.dg/torture/pr71522.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.dg/torture/pr71522.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
# of expected passes            8
# of unexpected failures        6

This works fine for 64 bits and worked fine for BE 32 bits for r11-164 and
earlier.


(gdb) run
Starting program: /home/seurer/gcc/git/build/gcc-test/./pr71522.exe 

Program received signal SIGABRT, Aborted.
0x0fd4b7c8 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:55
55        return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb) where
#0  0x0fd4b7c8 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:55
#1  0x0fd4d584 in __GI_abort () at abort.c:90
#2  0x10000724 in main () at
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/torture/pr71522.c:24

The abort is coming from

  if (__builtin_strncmp (s, STR, sizeof s) != 0)
    __builtin_abort ();


commit eb72dc663e9070b281be83a80f6f838a3a878822
Author: Richard Biener <rguenther@suse.de>
Date:   Wed Apr 22 10:40:51 2020 +0200

    extend DECL_GIMPLE_REG_P to all types

[Bug other/99648] [11 regression] gcc.dg/torture/pr71522.c fails starting with r11-165 for 32 bits

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
With -O2 -m32 -mlong-double-128 I'm getting exactly the same code for r11-164
and r11-165.
With -O2 -m32 I'm getting different, but it still doesn't FAIL with r11-165.

Note, Richard's commit mentioned exactly that testcase as being problematic...

[Bug target/99648] [11 regression] gcc.dg/torture/pr71522.c fails starting with r11-165 for 32 bits

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
   Last reconfirmed|                            |2021-03-19
   Target Milestone|---                         |11.0
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1
          Component|other                       |target

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Yes, there's cfgexpand.c avoid_type_punning_on_regs which looks for integral
accesses of FP registers but only disables

+      && maybe_lt (GET_MODE_PRECISION (DECL_MODE (base)),
+                  GET_MODE_BITSIZE (GET_MODE_INNER (DECL_MODE (base))))

so the question is how the situation is with the case where it execute FAILs
(I can't check/verify that easily).  Can you please show failing assembler and
RTL?

[Bug target/99648] [11 regression] gcc.dg/torture/pr71522.c fails starting with r11-165 for 32 bits

[seurer at gcc dot gnu.org]

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

--- Comment #3 from seurer at gcc dot gnu.org ---
The assembler isn't that long so here it is (from -Os):

        .file   "pr71522.c"
        .machine power8
        .section        ".text"
        .section        .rodata.str1.1,"aMS",@progbits,1
.LC1:
        .string "AAAAAAAAAAAAAAA"
        .section        .text.startup,"ax",@progbits
        .align 2
        .globl main
        .type   main, @function
main:
.LFB0:
        .cfi_startproc
        lis 9,.LC0@ha
        stwu 1,-48(1)
        .cfi_def_cfa_offset 48
        mflr 0
        la 9,.LC0@l(9)
        lis 4,.LC1@ha
        la 4,.LC1@l(4)
        lfd 0,0(9)
        lfd 1,8(9)
        lis 9,0x4151
        ori 9,9,0x4141
        addi 3,1,8
        stw 0,52(1)
        .cfi_offset 65, 4
        stw 9,8(1)
        lis 9,0x4141
        ori 9,9,0x4120
        stfd 0,32(1)
        stfd 1,40(1)
        stw 9,12(1)
        lis 9,0x3e00
        stw 9,16(1)
        li 9,0
        stw 9,20(1)
        bl strcmp
        cmpwi 0,3,0
        beq 0,.L2
        bl abort
.L2:
        lwz 0,52(1)
        addi 1,1,48
        .cfi_def_cfa_offset 0
        mtlr 0
        .cfi_restore 65
        blr
        .cfi_endproc
.LFE0:
        .size   main,.-main
        .section        .rodata.cst16,"aM",@progbits,16
        .align 4
.LC0:
        .long   1095844161
        .long   1094795552
        .long   1040187392
        .long   0
        .ident  "GCC: (GNU) 11.0.1 20210329 (experimental) [remotes/origin/HEAD
revision c277abd:ad0a649:953624089be3f51c2ebacba65be8521bf6ae8430]"
        .gnu_attribute 4, 5
        .section        .note.GNU-stack,"",@progbits

[Bug target/99648] [11 regression] gcc.dg/torture/pr71522.c fails starting with r11-165 for 32 bits

[seurer at gcc dot gnu.org]

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

--- Comment #4 from seurer at gcc dot gnu.org ---
Which RTL do you want to see?

[Bug target/99648] [11 regression] gcc.dg/torture/pr71522.c fails starting with r11-165 for 32 bits

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to seurer from comment #4)
> Which RTL do you want to see?

So with a cross .expand shows we expand from

  MEM <unsigned long long> [(char * {ref-all})&d] = 4702111234474983680;
  MEM <unsigned char[8]> [(char * {ref-all})&s] = MEM <unsigned char[8]> [(char
* {ref-all})&d];
  _1 = __builtin_strcmp (&s, "AAAAAAA");
  if (_1 != 0)

doing

;; MEM <unsigned long long> [(char * {ref-all})&d] = 4702111234474983680;

(insn 5 4 6 (set (reg:SI 121)
        (high:SI (symbol_ref:SI ("*.LANCHOR0") [flags 0x182])))
"pr71522.c":20:3 -1
     (nil))

(insn 6 5 7 (set (reg/f:SI 120)
        (lo_sum:SI (reg:SI 121)
            (symbol_ref:SI ("*.LANCHOR0") [flags 0x182]))) "pr71522.c":20:3 -1
     (expr_list:REG_EQUAL (symbol_ref:SI ("*.LANCHOR0") [flags 0x182])
        (nil)))

(insn 7 6 0 (set (reg/v:DF 118 [ d ])
        (mem/u/c:DF (reg/f:SI 120) [0  S8 A64])) "pr71522.c":20:3 -1
     (expr_list:REG_EQUAL (const_double:DF 2.26163450980389118194580078125e+6
[0x0.8a0a0a0a0a08p+22])
        (nil)))

;; MEM <unsigned char[8]> [(char * {ref-all})&s] = MEM <unsigned char[8]>
[(char * {ref-all})&d];

(insn 8 7 0 (set (mem/c:DI (reg/f:SI 112 virtual-stack-vars) [0 MEM <unsigned
char[8]> [(char * {ref-all})&s]+0 S8 A64])
        (subreg:DI (reg/v:DF 118 [ d ]) 0)) "pr71522.c":21:3 -1
     (nil))


that looks OK, but then the assembly I get is

main:
.LFB0:
        stwu 1,-32(1)
.LCFI0:
        mflr 0
        stw 0,36(1)
.LCFI1:
        lis 9,.LANCHOR0@ha
        la 4,.LANCHOR0@l(9)
        lwz 10,0(4)
        lwz 11,4(4)
        stw 10,8(1)
        stw 11,12(1)
        addi 4,4,8
        addi 3,1,8
        bl strcmp

so no signs of 'lfd'.

How do you configure?  What subtarget do you use?  Problematic in the above
IL might be the reg-equal note.

[Bug target/99648] [11 regression] gcc.dg/torture/pr71522.c fails starting with r11-165 for 32 bits

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ok, I can finally reproduce, one needs -m32 -Os -mcpu=power7 (or power8 or
power9) to reproduce.
And the bug is created in store_bit_field_1 doing:
      rtx sub;
      HOST_WIDE_INT regnum;
      poly_uint64 regsize = REGMODE_NATURAL_SIZE (GET_MODE (op0));
      if (known_eq (bitnum, 0U)
          && known_eq (bitsize, GET_MODE_BITSIZE (GET_MODE (op0))))
        {
          sub = simplify_gen_subreg (GET_MODE (op0), value, fieldmode, 0);
          if (sub)
            {
              if (reverse)
                sub = flip_storage_order (GET_MODE (op0), sub);
              emit_move_insn (op0, sub);
              return true;
            }
        }
(there is similar code later on).
value is
(const_vector:V16QI [
        (const_int 65 [0x41]) repeated x15
        (const_int 0 [0])
    ])
simplify_gen_subreg from V16QImode to TFmode makes
(const_double:TF 4.5232690196078126318752765655517578125e+6
[0x0.8a0a0a0a0a0904p+23])
out of that and the problem is that this constant doesn't convert back to value
when simplify_gen_subreg converted back to V16QImode, instead it yields
(const_vector:V16QI [
        (const_int 65 [0x41])
        (const_int 81 [0x51])
        (const_int 65 [0x41]) repeated x5
        (const_int 32 [0x20])
        (const_int 62 [0x3e])
        (const_int 0 [0]) repeated x7
    ])
So, to me this looks like a dup of PR95450, except in simplify-rtx.c rather
than in fold-const.c.
Do we want to do the same thing in simplify_subreg and try to convert back for
MODE_COMPOSITE_P?

[Bug target/99648] [11 regression] gcc.dg/torture/pr71522.c fails starting with r11-165 for 32 bits

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
--- gcc/simplify-rtx.c.jj       2021-04-09 16:18:24.275668496 +0200
+++ gcc/simplify-rtx.c  2021-04-09 19:26:24.963134240 +0200
@@ -7059,12 +7059,19 @@ simplify_immed_subreg (fixed_size_mode o
       while (buffer.length () < buffer_bytes)
        buffer.quick_push (filler);
     }
-  else
+  else if (!native_encode_rtx (innermode, x, buffer, first_byte, inner_bytes))
+    return NULL_RTX;
+  rtx ret = native_decode_rtx (outermode, buffer, 0);
+  if (ret && MODE_COMPOSITE_P (outermode))
     {
-      if (!native_encode_rtx (innermode, x, buffer, first_byte, inner_bytes))
+      auto_vec<target_unit, 128> buffer2 (buffer_bytes);
+      if (!native_encode_rtx (outermode, ret, buffer2, 0, buffer_bytes))
        return NULL_RTX;
-      }
-  return native_decode_rtx (outermode, buffer, 0);
+      for (unsigned int i = 0; i < buffer_bytes; ++i)
+       if (buffer[i] != buffer2[i])
+         return NULL_RTX;
+    }
+  return ret;
 }

 /* Simplify SUBREG:OUTERMODE(OP:INNERMODE, BYTE)

Makes simplify_subreg fail when trying to subreg a constant into a composite
floating mode that doesn't decode back.
Unfortunately, this causes ICE:
pr71522.c: In function ‘main’:
pr71522.c:27:1: error: unrecognizable insn:
   27 | }
      | ^
(insn 5 2 6 2 (set (reg/v:TF 118 [ d ])
        (subreg:TF (const_vector:V16QI [
                    (const_int 65 [0x41]) repeated x15
                    (const_int 0 [0])
                ]) 0)) "pr71522.c":20:3 -1
     (nil))
during RTL pass: vregs

store_bit_field_1 calls simplify_gen_subreg and that when simplify_immed_subreg
fails will happily create the above subreg.
So I'm quite afraid the above change could break quite a lot and so might be
better to defer it for GCC12.

[Bug target/99648] [11 regression] gcc.dg/torture/pr71522.c fails starting with r11-165 for 32 bits

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #7)
> --- gcc/simplify-rtx.c.jj	2021-04-09 16:18:24.275668496 +0200
> +++ gcc/simplify-rtx.c	2021-04-09 19:26:24.963134240 +0200
> @@ -7059,12 +7059,19 @@ simplify_immed_subreg (fixed_size_mode o
>        while (buffer.length () < buffer_bytes)
>  	buffer.quick_push (filler);
>      }
> -  else
> +  else if (!native_encode_rtx (innermode, x, buffer, first_byte,
> inner_bytes))
> +    return NULL_RTX;
> +  rtx ret = native_decode_rtx (outermode, buffer, 0);
> +  if (ret && MODE_COMPOSITE_P (outermode))
>      {
> -      if (!native_encode_rtx (innermode, x, buffer, first_byte,
> inner_bytes))
> +      auto_vec<target_unit, 128> buffer2 (buffer_bytes);
> +      if (!native_encode_rtx (outermode, ret, buffer2, 0, buffer_bytes))
>  	return NULL_RTX;
> -      }
> -  return native_decode_rtx (outermode, buffer, 0);
> +      for (unsigned int i = 0; i < buffer_bytes; ++i)
> +	if (buffer[i] != buffer2[i])
> +	  return NULL_RTX;
> +    }
> +  return ret;
>  }
>  
>  /* Simplify SUBREG:OUTERMODE(OP:INNERMODE, BYTE)

I think this makes sense from a consistency point of view.

> Makes simplify_subreg fail when trying to subreg a constant into a composite
> floating mode that doesn't decode back.
> Unfortunately, this causes ICE:
> pr71522.c: In function ‘main’:
> pr71522.c:27:1: error: unrecognizable insn:
>    27 | }
>       | ^
> (insn 5 2 6 2 (set (reg/v:TF 118 [ d ])
>         (subreg:TF (const_vector:V16QI [
>                     (const_int 65 [0x41]) repeated x15
>                     (const_int 0 [0])
>                 ]) 0)) "pr71522.c":20:3 -1
>      (nil))
> during RTL pass: vregs
> 
> store_bit_field_1 calls simplify_gen_subreg and that when
> simplify_immed_subreg fails will happily create the above subreg.
> So I'm quite afraid the above change could break quite a lot and so might be
> better to defer it for GCC12.

Hmm, yeah.  I suppose we can force the constant to memory and do the subreg
via a load?

[Bug target/99648] [11 regression] gcc.dg/torture/pr71522.c fails starting with r11-165 for 32 bits

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #8)
> Hmm, yeah.  I suppose we can force the constant to memory and do the subreg
> via a load?

Or just force it into a register before creating a subreg and let the backend
decide if it wants it into memory or initialized directly as usually.

[Bug target/99648] [11 regression] gcc.dg/torture/pr71522.c fails starting with r11-165 for 32 bits

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 50566
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50566&action=edit
gcc11-pr99648.patch

Updated patch which doesn't ICE anymore.  While I think the right thing would
be to always punt on SUBREGs of constants, I think that is quite risky this
late and so restricting it to MODE_COMPOSITE_P outermodes will make it
restricted to
powerpc IBM double double format and nothing else (well, there is also
mips_extended_format, but no target seems to use it fortunately).

[Bug target/99648] [11 regression] gcc.dg/torture/pr71522.c fails starting with r11-165 for 32 bits

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #10)
> Created attachment 50566 [details]
> gcc11-pr99648.patch
> 
> Updated patch which doesn't ICE anymore.  While I think the right thing
> would be to always punt on SUBREGs of constants, I think that is quite risky
> this late and so restricting it to MODE_COMPOSITE_P outermodes will make it
> restricted to
> powerpc IBM double double format and nothing else (well, there is also
> mips_extended_format, but no target seems to use it fortunately).

  if (MODE_COMPOSITE_P (outermode)

7347    

      && (CONST_SCALAR_INT_P (op)

7348    

          || CONST_DOUBLE_AS_FLOAT_P (op)

7349    

          || CONST_FIXED_P (op)

7350    

          || GET_CODE (op) == CONST_VECTOR))

7351    

    return NULL_RTX;

it's odd to reject CONST_INT_P but not CONST_DOUBLE-as-int, no?  Did you
mean to do

   if (MODE_COMPOSITE_P (outermode))
     switch (GET_CODE (op))
      {
      CASE_CONST_ANY:
        return NULL_RTX;
      default:;
      }

?  (yeah, CONST_ANY_P is missing it seems)

[Bug target/99648] [11 regression] gcc.dg/torture/pr71522.c fails starting with r11-165 for 32 bits

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I've copied the conditions on when simplify_immed_subreg is called.
CONST_DOUBLE_AS_INT_P can appear only if not TARGET_SUPPORTS_WIDE_INT,
and in that case
#define CONST_SCALAR_INT_P(X) \
  (CONST_INT_P (X) || CONST_DOUBLE_AS_INT_P (X))

[Bug target/99648] [11 regression] gcc.dg/torture/pr71522.c fails starting with r11-165 for 32 bits

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:c0f772894b6b3cd8ed5c5dd09d0c7917f51cf70f

commit r11-8146-gc0f772894b6b3cd8ed5c5dd09d0c7917f51cf70f
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Apr 13 09:41:20 2021 +0200

    simplify-rtx: Punt on simplify_{,gen_}subreg to IBM double double if bits
are lost [PR99648]

    Similarly to PR95450 done on GIMPLE, this patch punts if we try to
    simplify_{gen_,}subreg from some constant into the IBM double double
    IFmode (or sometimes TFmode) if the double double format wouldn't preserve
    the bits.  Not all values are valid in IBM double double, e.g. the format
    requires that the upper double is the whole value rounded to double, and
    if in some cases such as in the pr71522.c testcase with -m32 -Os
-mcpu=power7
    some non-floating data is copied through long double variable, we can
    simplify a subreg into something that has different value.

    Fixed by punting if the planned simplify_immed_subreg result doesn't
    encode to bitwise identical values compared to what we were decoding.

    As for the simplify_gen_subreg change, I think it would be desirable
    to just avoid creating SUBREGs of constants on all targets and for all
    constants, if simplify_immed_subreg simplified, fine, otherwise punt,
    but as we are late in GCC11 development, the patch instead guards this
    behavior on MODE_COMPOSITE_P (outermode) - i.e. only conversions to
    powerpc{,64,64le} double double long double - and only for the cases where
    simplify_immed_subreg was called.

    2021-04-13  Jakub Jelinek  <jakub@redhat.com>

            PR target/99648
            * simplify-rtx.c (simplify_immed_subreg): For MODE_COMPOSITE_P
            outermode, return NULL if the result doesn't encode back to the
            original byte sequence.
            (simplify_gen_subreg): Don't create SUBREGs from constants to
            MODE_COMPOSITE_P outermode.

[Bug target/99648] [11 regression] gcc.dg/torture/pr71522.c fails starting with r11-165 for 32 bits

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.