[Bug c/111677] New: arm64 build fails unrecognizable insn [REGRESSION]

[Bug c/111677] New: arm64 build fails unrecognizable insn [REGRESSION]

[costamagnagianfranco at yahoo dot it]

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

            Bug ID: 111677
           Summary: arm64 build fails unrecognizable insn [REGRESSION]
           Product: gcc
           Version: 13.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: costamagnagianfranco at yahoo dot it
  Target Milestone: ---

Created attachment 56038
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56038&action=edit
build log and dump

Hello, according to
https://buildd.debian.org/status/fetch.php?pkg=darktable&arch=arm64&ver=4.4.2-1&stamp=1692542143&raw=0

The build was fine with gcc-13 13.2.0-2 and fails with 13.2.0-4

So, the regression if this is really a gcc regression might be in the following
changes:
   * Update to git 20230902 from the gcc-13 branch.
     - Fix PR target/111127 (x86), PR middle-end/111017 (x86),
       PR tree-optimization/111070, PR tree-optimization/111039,
       PR tree-optimization/111019, PR tree-optimization/110702,
       PR tree-optimization/111109, PR debug/111080, PR target/111010 (x86),
       PR c++/106652, PR c++/110927, PR c++/109678, PR c++/106310,
       PR fortran/87477, PR modula2/110779, PR modula2/108119,
       PR libgcc/110956, PR middle-end/111017, PR libstdc++/110860,
       PR libstdc++/110990, PR libstdc++/110970, PR libstdc++/110974,
       PR libstdc++/110968, PR target/110484 (loong64),
       PR tree-optimization/110914, PR tree-optimization/111015,
       PR target/109725 (riscv), PR c++/109751, PR c++/92407.
 .
   [ Aurelien Jarno ]
   * Fix PR target/110066 (RISCV), taken from the trunk.
 .
   [ Matthias Klose ]
   * Remove test protocols in clean target. Addresses: #1044154.
   * Disable Ada, Go, D, Modula-2 frontends on loong64.
 .
   [ Nicolas Boulenguez ]
   * Ada: deprecate the gnatgcc symbolic link.
   * Ada: move README.gnat to debian/ada/.
   * Ada: remove the obsolete acats-killer script.
   * Ada: let gnat-BV provide a versioned virtual package.
or
   * Update to git 20230913 from the gcc-13 branch.
     - Fix PR target/96762 (PPC), PR target/111340 (x86),
       PR target/111306 (x86), PR target/111335 (x86),
       PR modula2/111330.
     - Address stack protector and stack clash protection weaknesses
       on AArch64. CVE-2023-4039.
 .
   [ Matthias Klose ]
   * Fix PR fortran/88552, taken from the trunk. LP: #1842164.
 .
   [ Aurelien Jarno ]
   * Update libasan8 symbols for riscv64.


I'm attaching the gcc dump report

[Bug target/111677] arm64 build fails unrecognizable insn [REGRESSION]

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |MOVED
          Component|c                           |target

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Since debian backported patches and not using the 13 branch, this is a bug in
debian sources only.

Anyways it was introduced by:
Address stack protector and stack clash protection weaknesses
       on AArch64

You need r13-7827-g4bb1ae3c13ce4fb72129229de66f5ffbcd45fe4c (PR 111411) also.

[Bug target/111677] arm64 build fails unrecognizable insn [REGRESSION]

[costamagnagianfranco at yahoo dot it]

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

--- Comment #2 from Gianfranco <costamagnagianfranco at yahoo dot it> ---
Thanks, Debian syncs the branch fixes from time to time,
last time was up to
   * Update to git 20230913 from the gcc-13 branch.

Indeed, I requested to sync again sources.

thanks!

[Bug target/111677] arm64 build fails unrecognizable insn [REGRESSION]

[costamagnagianfranco at yahoo dot it]

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

Gianfranco <costamagnagianfranco at yahoo dot it> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|MOVED                       |---
             Status|RESOLVED                    |UNCONFIRMED

--- Comment #3 from Gianfranco <costamagnagianfranco at yahoo dot it> ---
Hello, after syncing gcc-13 with last fixes, the bug still occurs

 gcc-13 (13.2.0-5) unstable; urgency=medium
 .
   * Update to git 20231005 from the gcc-13 branch.
     - Fix PR tree-optimization/111331, PR tree-optimization/110386,
       PR target/111121 (AArch64), PR tree-optimization/110315,
       PR target/111411 (AArch64), PR target/111412 (riscv),
       PR ada/110488, PR c++/111493, PR c++/111485, PR c++/99631,
       PR c++/111471, PR fortran/37336, PR fortran/111674, PR fortran/92586,
       PR fortran/68155, PR modula2/111510, PR libstdc++/111050,
       PR libstdc++/111102, PR libstdc++/108046, PR libstdc++/111511,
       PR c++/111512, PR c++/111357.
   * Provide symlinks for the shared Modula-2 runtime libraries in
     the private gcc library directory. Closes: #1052008.
   * Install the static Modula-2 libraries.
   * Add autopkg test for Modula-2.
   * Don't assume that hppa64-linux-gnu has the sys/mman.h header,
     use the fallback for libgcov.
   * Update the libquadmath portions of the copyright file. Closes: #1052314.

cd /<<PKGBUILDDIR>>/obj-aarch64-linux-gnu/bin/external/LibRaw-cmake &&
/usr/bin/c++ -DDT_HAVE_SIGNAL_TRACE -DGDK_DISABLE_DEPRECATED
-DGDK_VERSION_MIN_REQUIRED=GDK_VERSION_3_24
-DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_MIN_REQUIRED
-DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_56 -DGTK_DISABLE_DEPRECATED
-DGTK_DISABLE_SINGLE_INCLUDES -DHAVE_CONFIG_H -DHAVE_GAME -DHAVE_GPHOTO2
-DHAVE_GRAPHICSMAGICK -DHAVE_ICU -DHAVE_IMATH -DHAVE_ISO_CODES -DHAVE_KWALLET
-DHAVE_LIBEXIV2_WITH_ISOBMFF=1 -DHAVE_LIBHEIF=1 -DHAVE_LIBJXL -DHAVE_LIBRAW=1
-DHAVE_LIBSECRET -DHAVE_MAP -DHAVE_OPENCL -DHAVE_OPENEXR -DHAVE_OPENJPEG
-DHAVE_OSMGPSMAP_110_OR_NEWER -DHAVE_OSMGPSMAP_NEWER_THAN_110 -DHAVE_PRINT
-DHAVE_SQLITE_324_OR_NEWER -DHAVE_WEBP -DLIBRAW_NODLL -DSQLITE_CORE
-DSQLITE_ENABLE_ICU -DUSE_COLORDGTK -DUSE_LUA -DUSE_ZLIB -D_RELEASE
-D_XOPEN_SOURCE=700
-I/<<PKGBUILDDIR>>/obj-aarch64-linux-gnu/bin/external/LibRaw-cmake
-I/<<PKGBUILDDIR>>/src/external/LibRaw-cmake -I/<<PKGBUILDDIR>>/src
-I/<<PKGBUILDDIR>>/src/external/LuaAutoC -I/<<PKGBUILDDIR>>/src/external/LibRaw
-isystem /<<PKGBUILDDIR>>/src/external -isystem
/<<PKGBUILDDIR>>/src/external/OpenCL -isystem /usr/include/glib-2.0 -isystem
/usr/lib/aarch64-linux-gnu/glib-2.0/include -isystem /usr/include/gtk-3.0
-isystem /usr/include/pango-1.0 -isystem /usr/include/harfbuzz -isystem
/usr/include/freetype2 -isystem /usr/include/libpng16 -isystem
/usr/include/libmount -isystem /usr/include/blkid -isystem /usr/include/fribidi
-isystem /usr/include/cairo -isystem /usr/include/pixman-1 -isystem
/usr/include/gdk-pixbuf-2.0 -isystem /usr/include/webp -isystem
/usr/include/gio-unix-2.0 -isystem /usr/include/cloudproviders -isystem
/usr/include/atk-1.0 -isystem /usr/include/at-spi2-atk/2.0 -isystem
/usr/include/at-spi-2.0 -isystem /usr/include/dbus-1.0 -isystem
/usr/lib/aarch64-linux-gnu/dbus-1.0/include -isystem /usr/include/libxml2
-isystem /usr/include/lensfun -isystem /usr/include/librsvg-2.0 -isystem
/usr/include/json-glib-1.0 -isystem /usr/include/openjpeg-2.5 -isystem
/usr/include/libsecret-1 -isystem /usr/include/GraphicsMagick -isystem
/usr/include/lua5.4 -isystem /usr/include/osmgpsmap-1.0 -isystem
/usr/include/libsoup-2.4 -isystem /usr/include/colord-1 -g -O2
-ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong
-fstack-clash-protection -Wformat -Werror=format-security
-mbranch-protection=standard -O3 -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wformat
-Wformat-security -Wshadow -Wtype-limits -Wvla -Wmaybe-uninitialized
-Wno-unknown-pragmas -Wno-error=varargs -Wno-format-truncation
-Wno-error=address-of-packed-member -fopenmp -mtune=generic  -g -O3 -DNDEBUG
-O3 -ffast-math -fno-finite-math-only -fexpensive-optimizations -std=c++17
-fPIC -fopenmp -w -MD -MT
bin/external/LibRaw-cmake/CMakeFiles/raw_r.dir/__/LibRaw/src/write/apply_profile.cpp.o
-MF CMakeFiles/raw_r.dir/__/LibRaw/src/write/apply_profile.cpp.o.d -o
CMakeFiles/raw_r.dir/__/LibRaw/src/write/apply_profile.cpp.o -c
/<<PKGBUILDDIR>>/src/external/LibRaw/src/write/apply_profile.cpp
/<<PKGBUILDDIR>>/src/common/bilateral.c:468:6: warning: GCC does not currently
support mixed size types for ‘simd’ functions
  468 | void dt_bilateral_slice_to_output(const dt_bilateral_t *const b,
      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/<<PKGBUILDDIR>>/src/common/bilateral.c:420:6: warning: GCC does not currently
support mixed size types for ‘simd’ functions
  420 | void dt_bilateral_slice(const dt_bilateral_t *const b,
      |      ^~~~~~~~~~~~~~~~~~
/<<PKGBUILDDIR>>/src/common/bilateral.c: In function
‘dt_bilateral_splat.simdclone.1’:
/<<PKGBUILDDIR>>/src/common/bilateral.c:297:1: error: unrecognizable insn:
  297 | }
      | ^
(insn 563 562 564 3 (set (mem/c:TF (plus:DI (reg/f:DI 31 sp)
                (const_int 512 [0x200])) [63  S16 A8])
        (reg:TF 54 v22)) -1
     (expr_list:REG_DEAD (reg:TF 54 v22)
        (nil)))
during RTL pass: sched_fusion
/<<PKGBUILDDIR>>/src/common/bilateral.c:297:1: internal compiler error: in
get_attr_type, at config/aarch64/aarch64.md:24655
0xb1c083 internal_error(char const*, ...)
        ???:0
0xb0f58b fancy_abort(char const*, int, char const*)
        ???:0
0x77453f _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
        ???:0
0x774573 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
        ???:0
0x1148503 get_attr_type(rtx_insn*)
        ???:0
0x10f5a2f schedule_block(basic_block_def**, void*)
        ???:0
0x10cb843 schedule_insns()
        ???:0

[Bug target/111677] arm64 build fails unrecognizable insn [REGRESSION]

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
           Keywords|                            |ice-on-valid-code
   Last reconfirmed|                            |2023-10-24
     Ever confirmed|0                           |1

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Gianfranco from comment #3)
> Hello, after syncing gcc-13 with last fixes, the bug still occurs

Can you attach the preprocessed source?

[Bug target/111677] [12/13/14 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Really I wished the -fstack-protector changes were NOT backported since it was
not a regression and not a security issue (according to GCC's own security
policy).

[Bug target/111677] [12/13/14 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.4

[Bug target/111677] [12/13/14 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[costamagnagianfranco at yahoo dot it]

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

--- Comment #6 from Gianfranco <costamagnagianfranco at yahoo dot it> ---
@Andrew, can you please get it from the build log?
https://buildd.debian.org/status/fetch.php?pkg=darktable&arch=arm64&ver=4.4.2-1%2Bb1&stamp=1696847922&raw=0


there are the === BEGIN GCC DUMP === and === END GCC DUMP === that should
contain it, right?

[Bug target/111677] [12/13/14 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[costamagnagianfranco at yahoo dot it]

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

--- Comment #7 from Gianfranco <costamagnagianfranco at yahoo dot it> ---
I'm reducing it, 8.2%

[Bug target/111677] [12/13/14 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[costamagnagianfranco at yahoo dot it]

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

--- Comment #8 from Gianfranco <costamagnagianfranco at yahoo dot it> ---
reduced testcase:

typedef struct {
  int width
} dt_bilateral_t;
typedef dt_aligned_pixel_t[4];
#pragma omp declare simd
void dt_bilateral_splat(dt_bilateral_t *b) {
  int oy = b;
  float *buf;
  long offsets[8];
  for (int slice; slice < b; slice++) {
    for (int i; i < b->width; i++) {
      dt_aligned_pixel_t contrib;
      for (int k = 0; k < 4; k++)
        buf[offsets[k]] += contrib[k];
    }
    float *dest, *src = oy;
    for (int i = 0; i < oy; i++)
      dest[i] += src[i];
  }
}

removing openmp, fstack-protector-strong or ffast-math works.

[Bug target/111677] [12/13/14 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[costamagnagianfranco at yahoo dot it]

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

--- Comment #9 from Gianfranco <costamagnagianfranco at yahoo dot it> ---
/usr/libexec/gcc/aarch64-linux-gnu/13/cc1 -quiet -imultiarch aarch64-linux-gnu 
-D _FORTIFY_SOURCE=2 -D NDEBUG -isystem -dumpbase -mbranch-protection=standard
-mtune=generic -mlittle-endian -mabi=lp64 -g -g -O2 -O3 -Wformat=1
-Werror=format-security -Wdate-time -Wall -Wformat=1 -Wformat-security -Wshadow
-Wtype-limits -Wvla -Wold-style-declaration -Wmaybe-uninitialized
-Wno-unknown-pragmas -Wno-error=varargs -Wformat-truncation=0
-Wno-error=address-of-packed-member -std=c99 -fstack-protector-strong
-fstack-clash-protection -fopenmp -ffast-math -fno-finite-math-only
-fexpensive-optimizations -fPIC -fasynchronous-unwind-tables -o -
-frandom-seed=0 -fdump-noaddr -freport-bug testcase.i

This reproduces the issue.

[Bug target/111677] [12/13/14 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[costamagnagianfranco at yahoo dot it]

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

--- Comment #10 from Gianfranco <costamagnagianfranco at yahoo dot it> ---
$ gcc -O3  -fstack-protector-strong  -fopenmp -ffast-math 
-fexpensive-optimizations testcase.i -c

This is the minimal cmdline to trigger the issue I could find.


cat testcase.i
typedef struct {
  int width
} dt_bilateral_t;
typedef dt_aligned_pixel_t[4];
#pragma omp declare simd
void dt_bilateral_splat(dt_bilateral_t *b) {
  int oy = b;
  float *buf;
  long offsets[8];
  for (int slice; slice < b; slice++) {
    for (int i; i < b->width; i++) {
      dt_aligned_pixel_t contrib;
      for (int k = 0; k < 4; k++)
        buf[offsets[k]] += contrib[k];
    }
    float *dest, *src = oy;
    for (int i = 0; i < oy; i++)
      dest[i] += src[i];
  }
}

testcase.i:3:1: warning: no semicolon at end of struct or union
    3 | } dt_bilateral_t;
      | ^
testcase.i:4:9: warning: type defaults to 'int' in declaration of
'dt_aligned_pixel_t' [-Wimplicit-int]
    4 | typedef dt_aligned_pixel_t[4];
      |         ^~~~~~~~~~~~~~~~~~
testcase.i: In function 'dt_bilateral_splat':
testcase.i:7:12: warning: initialization of 'int' from 'dt_bilateral_t *' makes
integer from pointer without a cast [-Wint-conversion]
    7 |   int oy = b;
      |            ^
testcase.i:10:25: warning: comparison between pointer and integer
   10 |   for (int slice; slice < b; slice++) {
      |                         ^
testcase.i:16:25: warning: initialization of 'float *' from 'int' makes pointer
from integer without a cast [-Wint-conversion]
   16 |     float *dest, *src = oy;
      |                         ^~
testcase.i: In function 'dt_bilateral_splat.simdclone.3':
testcase.i:20:1: error: unrecognizable insn:
   20 | }
      | ^
(insn 1109 1108 462 62 (set (mem/c:TF (plus:DI (reg/f:DI 31 sp)
                (const_int 512 [0x200])) [9  S16 A8])
        (reg:TF 55 v23)) -1
     (expr_list:REG_DEAD (reg:TF 55 v23)
        (nil)))
during RTL pass: sched_fusion
testcase.i:20:1: internal compiler error: in get_attr_type, at
config/aarch64/aarch64.md:24655
0xb1c083 internal_error(char const*, ...)
        ???:0
0xb0f58b fancy_abort(char const*, int, char const*)
        ???:0
0x77453f _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
        ???:0
0x774573 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
        ???:0
0x1148503 get_attr_type(rtx_insn*)
        ???:0
0x10f5a2f schedule_block(basic_block_def**, void*)
        ???:0
0x10cb843 schedule_insns()
        ???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <file:///usr/share/doc/gcc-13/README.Bugs> for instructions.

[Bug target/111677] [12/13/14 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[acoplan at gcc dot gnu.org]

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

Alex Coplan <acoplan at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
                 CC|                            |acoplan at gcc dot gnu.org

--- Comment #11 from Alex Coplan <acoplan at gcc dot gnu.org> ---
Confirmed. The testcase in #c10 ICEs for me on the GCC 12 and 13 branches with
-Ofast -fstack-protector-strong -fopenmp -fpic . It doesn't seem to ICE on the
trunk.

[Bug target/111677] [12/13/14 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |needs-bisection

--- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Someone needs to figure why it works on the trunk ...

[Bug target/111677] [12/13/14 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[acoplan at gcc dot gnu.org]

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

Alex Coplan <acoplan at gcc dot gnu.org> changed:

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

--- Comment #13 from Alex Coplan <acoplan at gcc dot gnu.org> ---
The problem seems to be this code in aarch64_process_components:

  while (regno != last_regno)
    {
      bool frame_related_p = aarch64_emit_cfi_for_reg_p (regno);
      machine_mode mode = aarch64_reg_save_mode (regno);

      rtx reg = gen_rtx_REG (mode, regno);
      poly_int64 offset = frame.reg_offset[regno];
      if (frame_pointer_needed)
        offset -= frame.bytes_below_hard_fp;

      rtx addr = plus_constant (Pmode, ptr_reg, offset);
      rtx mem = gen_frame_mem (mode, addr);

which emits a TFmode mem with offset 512, which is out of range for TFmode (so
we later ICE with an unrecognisable insn).  Presumably this just needs tweaking
to emit a new base anchor in the case of large offsets like this.  It looks
like the code in aarch64_save_callee_saves already does this.

[Bug target/111677] [12/13/14 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[costamagnagianfranco at yahoo dot it]

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

--- Comment #14 from Gianfranco <costamagnagianfranco at yahoo dot it> ---
Hello, any news for this issue?

[Bug target/111677] [12/13/14 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[germano.massullo at gmail dot com]

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

--- Comment #15 from Germano Massullo <germano.massullo at gmail dot com> ---
Hello, any news please?

[Bug target/111677] [12/13/14 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[jakub at gcc dot gnu.org]

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

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

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

[Bug target/111677] [12/13/14 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

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

--- Comment #16 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Can you attach the original preprocessed source?  The reduced testcase does NOT
compile on the trunk and fixing the warnings/errors on it still works.

[Bug target/111677] [12/13/14 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[pinskia at gcc dot gnu.org]

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

--- Comment #17 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The log file has `2844156: ...` where the preprocessed source is but it is hard
to figure out how to extract correctly.

[Bug target/111677] [12/13/14 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[costamagnagianfranco at yahoo dot it]

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

--- Comment #18 from Gianfranco <costamagnagianfranco at yahoo dot it> ---
Created attachment 57159
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57159&action=edit
unreduced testcase

// works: /usr/lib/gcc-snapshot/bin/gcc -O3  -fstack-protector-strong  -fopenmp
-ffast-math  -fexpensive-optimizations foo.c -Wno-int-conversion
-Wno-implicit-int -c
// /usr/lib/gcc-snapshot/bin/gcc -v
//Using built-in specs.
//COLLECT_GCC=/usr/lib/gcc-snapshot/bin/gcc
//COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/aarch64-linux-gnu/14/lto-wrapper
//OFFLOAD_TARGET_NAMES=nvptx-none
//OFFLOAD_TARGET_DEFAULT=1
//Target: aarch64-linux-gnu
//Configured with: ../src/configure -v --with-pkgversion='Debian 20240117-1'
--with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2
--prefix=/usr/lib/gcc-snapshot --with-gcc-major-version-only --program-prefix=
--enable-shared --enable-linker-build-id --disable-nls --enable-bootstrap
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--enable-fix-cortex-a53-843419 --disable-werror
--enable-offload-targets=nvptx-none=/build/reproducible-path/gcc-snapshot-20240117/debian/tmp-nvptx/usr/lib/gcc-snapshot
--enable-offload-defaulted --without-cuda-driver
--enable-checking=yes,extra,rtl --build=aarch64-linux-gnu
--host=aarch64-linux-gnu --target=aarch64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=4
//Thread model: posix
//Supported LTO compression algorithms: zlib zstd
//gcc version 14.0.1 20240117 (experimental) [master r14-8187-gb00be6f1576]
(Debian 20240117-1) 

// fails: gcc -O3  -fstack-protector-strong  -fopenmp -ffast-math 
-fexpensive-optimizations foo.c -Wno-int-conversion -Wno-implicit-int -c
// gcc -v
// Using built-in specs.
//COLLECT_GCC=gcc
//COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-linux-gnu/13/lto-wrapper
//OFFLOAD_TARGET_NAMES=nvptx-none
//OFFLOAD_TARGET_DEFAULT=1
//Target: aarch64-linux-gnu
//Configured with: ../src/configure -v --with-pkgversion='Debian 13.2.0-9'
--with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-13
--program-prefix=aarch64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--enable-fix-cortex-a53-843419 --disable-werror
--enable-offload-targets=nvptx-none=/build/reproducible-path/gcc-13-13.2.0/debian/tmp-nvptx/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=4
//Thread model: posix
//Supported LTO compression algorithms: zlib zstd
//gcc version 13.2.0 (Debian 13.2.0-9)
//bilateral.c:468:6: warning: GCC does not currently support mixed size types
for 'simd' functions
//  468 | void dt_bilateral_slice_to_output(const dt_bilateral_t *const b,
//      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
//bilateral.c:420:6: warning: GCC does not currently support mixed size types
for 'simd' functions
//  420 | void dt_bilateral_slice(const dt_bilateral_t *const b,
//      |      ^~~~~~~~~~~~~~~~~~
//bilateral.c: In function 'dt_bilateral_splat.simdclone.1':
//bilateral.c:297:1: error: unrecognizable insn:
//  297 | }
//      | ^
//(insn 463 462 464 3 (set (mem/c:TF (plus:DI (reg/f:DI 31 sp)
//                (const_int 512 [0x200])) [63  S16 A8])
//        (reg:TF 54 v22)) -1
//     (expr_list:REG_DEAD (reg:TF 54 v22)
// //       (nil)))
//during RTL pass: sched_fusion
//bilateral.c:297:1: internal compiler error: in get_attr_type, at
config/aarch64/aarch64.md:24655
//0xb1cb33 internal_error(char const*, ...)
//        ???:0
//0xb10093 fancy_abort(char const*, int, char const*)
//        ???:0
//0x77401b _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
//        ???:0
//0x77404f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
//        ???:0
//0x1145723 get_attr_type(rtx_insn*)
//        ???:0
//0x10f1cdf schedule_block(basic_block_def**, void*)
//        ???:0
//0x10c7543 schedule_insns()
//        ???:0
//Please submit a full bug report, with preprocessed source (by using
-freport-bug).
//Please include the complete backtrace with any bug report.
//See <file:///usr/share/doc/gcc-13/README.Bugs> for instructions.

[Bug target/111677] [12/13/14 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[costamagnagianfranco at yahoo dot it]

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

--- Comment #19 from Gianfranco <costamagnagianfranco at yahoo dot it> ---
looks like branch 14 is not FTBFS.

[Bug target/111677] [12/13/14 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[acoplan at gcc dot gnu.org]

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

--- Comment #20 from Alex Coplan <acoplan at gcc dot gnu.org> ---
I think the testcase in #c10 went latent on the 13 branch but the following
(reduced from the attachment) still ICEs on the tip of the 13 branch with
-Ofast -fopenmp -fstack-protector-strong:

typedef struct {
  long size_z;
  int width;
} dt_bilateral_t;
typedef float dt_aligned_pixel_t[4];
#pragma omp declare simd
void dt_bilateral_splat(dt_bilateral_t *b) {
  float *buf;
  long offsets[8];
  for (; b;) {
    int firstrow;
    for (int j = firstrow; j; j++)
      for (int i; i < b->width; i++) {
        dt_aligned_pixel_t contrib;
        for (int k = 0; k < 4; k++)
          buf[offsets[k]] += contrib[k];
      }
    float *dest;
    for (int j = (long)b; j; j++) {
      float *src = (float *)b->size_z;
      for (int i = 0; i < (long)b; i++)
        dest[i] += src[i];
    }
  }
}

[Bug target/111677] [12/13 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
            Summary|[12/13/14 Regression]       |[12/13 Regression]
                   |darktable build on aarch64  |darktable build on aarch64
                   |fails with unrecognizable   |fails with unrecognizable
                   |insn due to                 |insn due to
                   |-fstack-protector changes   |-fstack-protector changes

[Bug target/111677] [12/13 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[rsandifo at gcc dot gnu.org]

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

--- Comment #21 from Richard Sandiford <rsandifo at gcc dot gnu.org> ---
(In reply to Alex Coplan from comment #13)
> The problem seems to be this code in aarch64_process_components:
> 
>   while (regno != last_regno)
>     {
>       bool frame_related_p = aarch64_emit_cfi_for_reg_p (regno);
>       machine_mode mode = aarch64_reg_save_mode (regno);
> 
>       rtx reg = gen_rtx_REG (mode, regno);
>       poly_int64 offset = frame.reg_offset[regno];
>       if (frame_pointer_needed)
>         offset -= frame.bytes_below_hard_fp;
> 
>       rtx addr = plus_constant (Pmode, ptr_reg, offset);
>       rtx mem = gen_frame_mem (mode, addr);
> 
> which emits a TFmode mem with offset 512, which is out of range for TFmode
> (so we later ICE with an unrecognisable insn).  Presumably this just needs
> tweaking to emit a new base anchor in the case of large offsets like this. 
> It looks like the code in aarch64_save_callee_saves already does this.
We shouldn't emit new anchor registers here, since unlike in the prologue,
we don't have any guarantee that certain registers are free.

aarch64_get_separate_components is supposed to vet shrink-wrappable
offsets, but in this case the offset looks valid, since:

        str     q22, [sp, #512]

is a valid instruction.  Perhaps the constraints are too narrow?

[Bug target/111677] [12/13 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[acoplan at gcc dot gnu.org]

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

Alex Coplan <acoplan at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |acoplan at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #22 from Alex Coplan <acoplan at gcc dot gnu.org> ---
(In reply to Richard Sandiford from comment #21)
> 
> aarch64_get_separate_components is supposed to vet shrink-wrappable
> offsets, but in this case the offset looks valid, since:
> 
>         str     q22, [sp, #512]
> 
> is a valid instruction.  Perhaps the constraints are too narrow?

Yeah, as discussed offline, for T{I,F}mode we deliberately restrict the range
to the ldp x-reg range, since at least for TImode we don't know pre-RA how it
will be allocated (a single q reg or a pair of x regs).

We could look at using a different mode for the save that doesn't have those
restrictions, I'll try to do that.

[Bug target/111677] [12/13/14 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[acoplan at gcc dot gnu.org]

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

Alex Coplan <acoplan at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|needs-bisection             |
      Known to fail|13.2.1                      |14.0
      Known to work|14.0                        |
            Version|13.2.0                      |13.2.1
            Summary|[12/13 Regression]          |[12/13/14 Regression]
                   |darktable build on aarch64  |darktable build on aarch64
                   |fails with unrecognizable   |fails with unrecognizable
                   |insn due to                 |insn due to
                   |-fstack-protector changes   |-fstack-protector changes

--- Comment #23 from Alex Coplan <acoplan at gcc dot gnu.org> ---
Discovered by accident while working on a patch for trunk, but adding
-funroll-loops to the testcase in #c20 is enough to make the ICE trigger on the
trunk, too.

Testing a fix for trunk and a backport to 13 (to start with).

To reproduce on the trunk (t.c as in #c20):

$ gcc/xgcc -B gcc -c t.c -O3 -ffast-math -fopenmp -fstack-protector-strong
-funroll-loops
t.c: In function ‘dt_bilateral_splat.simdclone.1’:
t.c:25:1: error: unrecognizable insn:
   25 | }
      | ^
(insn 2182 2181 406 85 (set (mem/c:TF (plus:DI (reg/f:DI 31 sp)
                (const_int 512 [0x200])) [7  S16 A8])
        (reg:TF 55 v23)) -1
     (expr_list:REG_DEAD (reg:TF 55 v23)
        (nil)))
during RTL pass: sched_fusion
t.c:25:1: internal compiler error: in get_attr_type, at
config/aarch64/aarch64.md:29678
0x74a68f _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
        /home/alecop01/toolchain/src/gcc/gcc/rtl-error.cc:108
0x74a6c3 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
        /home/alecop01/toolchain/src/gcc/gcc/rtl-error.cc:116
0x18cf03b get_attr_type(rtx_insn*)
        /home/alecop01/toolchain/src/gcc/gcc/config/aarch64/aarch64.md:29678
0x13278b7 aarch64_sched_variable_issue
        /home/alecop01/toolchain/src/gcc/gcc/config/aarch64/aarch64.cc:15827
0x13278b7 aarch64_sched_variable_issue
        /home/alecop01/toolchain/src/gcc/gcc/config/aarch64/aarch64.cc:15818
0x1e25057 schedule_block(basic_block_def**, void*)
        /home/alecop01/toolchain/src/gcc/gcc/haifa-sched.cc:6912
0xeb307f schedule_region
        /home/alecop01/toolchain/src/gcc/gcc/sched-rgn.cc:3203
0xeb307f schedule_insns()
        /home/alecop01/toolchain/src/gcc/gcc/sched-rgn.cc:3525
0xeb34a3 schedule_insns()
        /home/alecop01/toolchain/src/gcc/gcc/sched-rgn.cc:3511
0xeb34a3 rest_of_handle_sched_fusion
        /home/alecop01/toolchain/src/gcc/gcc/sched-rgn.cc:3760
0xeb34a3 execute
        /home/alecop01/toolchain/src/gcc/gcc/sched-rgn.cc:3938
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug target/111677] [12/13/14 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[acoplan at gcc dot gnu.org]

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

Alex Coplan <acoplan at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch

--- Comment #24 from Alex Coplan <acoplan at gcc dot gnu.org> ---
Proposed fix for trunk:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644441.html

[Bug target/111677] [12/13/14 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[acoplan at gcc dot gnu.org]

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

--- Comment #25 from Alex Coplan <acoplan at gcc dot gnu.org> ---
Proposed fix for GCC 13:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644459.html

[Bug target/111677] [12/13/14 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[cvs-commit at gcc dot gnu.org]

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

--- Comment #26 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Alex Coplan <acoplan@gcc.gnu.org>:

https://gcc.gnu.org/g:0529ba8168c89f24314e8750237d77bb132bea9c

commit r14-8657-g0529ba8168c89f24314e8750237d77bb132bea9c
Author: Alex Coplan <alex.coplan@arm.com>
Date:   Tue Jan 30 10:22:48 2024 +0000

    aarch64: Avoid out-of-range shrink-wrapped saves [PR111677]

    The PR shows us ICEing due to an unrecognizable TFmode save emitted by
    aarch64_process_components.  The problem is that for T{I,F,D}mode we
    conservatively require mems to be in range for x-register ldp/stp.  That
    is because (at least for TImode) it can be allocated to both GPRs and
    FPRs, and in the GPR case that is an x-reg ldp/stp, and the FPR case is
    a q-register load/store.

    As Richard pointed out in the PR, aarch64_get_separate_components
    already checks that the offsets are suitable for a single load, so we
    just need to choose a mode in aarch64_reg_save_mode that gives the full
    q-register range.  In this patch, we choose V16QImode as an alternative
    16-byte "bag-of-bits" mode that doesn't have the artificial range
    restrictions imposed on T{I,F,D}mode.

    For T{F,D}mode in GCC 15 I think we could consider relaxing the
    restriction imposed in aarch64_classify_address, as typically T{F,D}mode
    should be allocated to FPRs.  But such a change seems too invasive to
    consider for GCC 14 at this stage (let alone backports).

    Fortunately the new flexible load/store pair patterns in GCC 14 allow
    this mode change to work without further changes.  The backports are
    more involved as we need to adjust the load/store pair handling to cater
    for V16QImode in a few places.

    Note that for the testcase we are relying on the torture options to add
    -funroll-loops at -O3 which is necessary to trigger the ICE on trunk
    (but not on the 13 branch).

    gcc/ChangeLog:

            PR target/111677
            * config/aarch64/aarch64.cc (aarch64_reg_save_mode): Use
            V16QImode for the full 16-byte FPR saves in the vector PCS case.

    gcc/testsuite/ChangeLog:

            PR target/111677
            * gcc.target/aarch64/torture/pr111677.c: New test.

[Bug target/111677] [12/13 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[acoplan at gcc dot gnu.org]

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

Alex Coplan <acoplan at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[12/13/14 Regression]       |[12/13 Regression]
                   |darktable build on aarch64  |darktable build on aarch64
                   |fails with unrecognizable   |fails with unrecognizable
                   |insn due to                 |insn due to
                   |-fstack-protector changes   |-fstack-protector changes

--- Comment #27 from Alex Coplan <acoplan at gcc dot gnu.org> ---
Fixed on trunk for GCC 14, keeping open for backports.

[Bug target/111677] [12/13 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[cvs-commit at gcc dot gnu.org]

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

--- Comment #28 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Alex Coplan
<acoplan@gcc.gnu.org>:

https://gcc.gnu.org/g:2bd8264a131ee1215d3bc6181722f9d30f5569c3

commit r13-8293-g2bd8264a131ee1215d3bc6181722f9d30f5569c3
Author: Alex Coplan <alex.coplan@arm.com>
Date:   Tue Jan 30 09:39:59 2024 +0000

    aarch64: Avoid out-of-range shrink-wrapped saves [PR111677]

    The PR shows us ICEing due to an unrecognizable TFmode save emitted by
    aarch64_process_components.  The problem is that for T{I,F,D}mode we
    conservatively require mems to be in range for x-register ldp/stp.  That
    is because (at least for TImode) it can be allocated to both GPRs and
    FPRs, and in the GPR case that is an x-reg ldp/stp, and the FPR case is
    a q-register load/store.

    As Richard pointed out in the PR, aarch64_get_separate_components
    already checks that the offsets are suitable for a single load, so we
    just need to choose a mode in aarch64_reg_save_mode that gives the full
    q-register range.  In this patch, we choose V16QImode as an alternative
    16-byte "bag-of-bits" mode that doesn't have the artificial range
    restrictions imposed on T{I,F,D}mode.

    Unlike for GCC 14 we need additional handling in the load/store pair
    code as various cases are not expecting to see V16QImode (particularly
    the writeback patterns, but also aarch64_gen_load_pair).

    This is a backport of
    r14-8657-g0529ba8168c89f24314e8750237d77bb132bea9c.

    gcc/ChangeLog:

            PR target/111677
            * config/aarch64/aarch64.cc (aarch64_reg_save_mode): Use
            V16QImode for the full 16-byte FPR saves in the vector PCS case.
            (aarch64_gen_storewb_pair): Handle V16QImode.
            (aarch64_gen_loadwb_pair): Likewise.
            (aarch64_gen_load_pair): Likewise.
            * config/aarch64/aarch64.md (loadwb_pair<TX:mode>_<P:mode>):
            Rename to ...
            (loadwb_pair<TX_V16QI:mode>_<P:mode>): ... this, extending to
            V16QImode.
            (storewb_pair<TX:mode>_<P:mode>): Rename to ...
            (storewb_pair<TX_V16QI:mode>_<P:mode>): ... this, extending to
            V16QImode.
            * config/aarch64/iterators.md (TX_V16QI): New.

    gcc/testsuite/ChangeLog:

            PR target/111677
            * gcc.target/aarch64/torture/pr111677.c: New test.

[Bug target/111677] [12 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[acoplan at gcc dot gnu.org]

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

Alex Coplan <acoplan at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[12/13 Regression]          |[12 Regression] darktable
                   |darktable build on aarch64  |build on aarch64 fails with
                   |fails with unrecognizable   |unrecognizable insn due to
                   |insn due to                 |-fstack-protector changes
                   |-fstack-protector changes   |

--- Comment #29 from Alex Coplan <acoplan at gcc dot gnu.org> ---
Should be fixed for GCC 13, I'll work on a backport for GCC 12 too.

[Bug target/111677] [12 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[acoplan at gcc dot gnu.org]

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

--- Comment #30 from Alex Coplan <acoplan at gcc dot gnu.org> ---
Backport for GCC 12 submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645415.html

[Bug target/111677] [12 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[cvs-commit at gcc dot gnu.org]

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

--- Comment #31 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Alex Coplan
<acoplan@gcc.gnu.org>:

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

commit r12-10156-gfddce05d67f34174be0f306e1015d3868bbe7c31
Author: Alex Coplan <alex.coplan@arm.com>
Date:   Tue Jan 30 09:39:59 2024 +0000

    aarch64: Avoid out-of-range shrink-wrapped saves [PR111677]

    The PR shows us ICEing due to an unrecognizable TFmode save emitted by
    aarch64_process_components.  The problem is that for T{I,F,D}mode we
    conservatively require mems to be in range for x-register ldp/stp.  That
    is because (at least for TImode) it can be allocated to both GPRs and
    FPRs, and in the GPR case that is an x-reg ldp/stp, and the FPR case is
    a q-register load/store.

    As Richard pointed out in the PR, aarch64_get_separate_components
    already checks that the offsets are suitable for a single load, so we
    just need to choose a mode in aarch64_reg_save_mode that gives the full
    q-register range.  In this patch, we choose V16QImode as an alternative
    16-byte "bag-of-bits" mode that doesn't have the artificial range
    restrictions imposed on T{I,F,D}mode.

    Unlike for GCC 14 we need additional handling in the load/store pair
    code as various cases are not expecting to see V16QImode (particularly
    the writeback patterns, but also aarch64_gen_load_pair).

    gcc/ChangeLog:

            PR target/111677
            * config/aarch64/aarch64.cc (aarch64_reg_save_mode): Use
            V16QImode for the full 16-byte FPR saves in the vector PCS case.
            (aarch64_gen_storewb_pair): Handle V16QImode.
            (aarch64_gen_loadwb_pair): Likewise.
            (aarch64_gen_load_pair): Likewise.
            * config/aarch64/aarch64.md (loadwb_pair<TX:mode>_<P:mode>):
            Rename to ...
            (loadwb_pair<TX_V16QI:mode>_<P:mode>): ... this, extending to
            V16QImode.
            (storewb_pair<TX:mode>_<P:mode>): Rename to ...
            (storewb_pair<TX_V16QI:mode>_<P:mode>): ... this, extending to
            V16QImode.
            * config/aarch64/iterators.md (TX_V16QI): New.

    gcc/testsuite/ChangeLog:

            PR target/111677
            * gcc.target/aarch64/torture/pr111677.c: New test.

    (cherry picked from commit 2bd8264a131ee1215d3bc6181722f9d30f5569c3)

[Bug target/111677] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[acoplan at gcc dot gnu.org]

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

Alex Coplan <acoplan at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[12 Regression] darktable   |darktable build on aarch64
                   |build on aarch64 fails with |fails with unrecognizable
                   |unrecognizable insn due to  |insn due to
                   |-fstack-protector changes   |-fstack-protector changes

--- Comment #32 from Alex Coplan <acoplan at gcc dot gnu.org> ---
Fixed for GCC 12, keeping open for a final backport to GCC 11 (since the stack
protector patches were also backported there, and the underlying issue is
latent there).

[Bug target/111677] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[cvs-commit at gcc dot gnu.org]

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

--- Comment #33 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Alex Coplan
<acoplan@gcc.gnu.org>:

https://gcc.gnu.org/g:0b308e2f27b087049fde9fbc64e432de47868a90

commit r11-11247-g0b308e2f27b087049fde9fbc64e432de47868a90
Author: Alex Coplan <alex.coplan@arm.com>
Date:   Tue Jan 30 09:39:59 2024 +0000

    aarch64: Avoid out-of-range shrink-wrapped saves [PR111677]

    The PR shows us ICEing due to an unrecognizable TFmode save emitted by
    aarch64_process_components.  The problem is that for T{I,F,D}mode we
    conservatively require mems to be in range for x-register ldp/stp.  That
    is because (at least for TImode) it can be allocated to both GPRs and
    FPRs, and in the GPR case that is an x-reg ldp/stp, and the FPR case is
    a q-register load/store.

    As Richard pointed out in the PR, aarch64_get_separate_components
    already checks that the offsets are suitable for a single load, so we
    just need to choose a mode in aarch64_reg_save_mode that gives the full
    q-register range.  In this patch, we choose V16QImode as an alternative
    16-byte "bag-of-bits" mode that doesn't have the artificial range
    restrictions imposed on T{I,F,D}mode.

    Unlike for GCC 14 we need additional handling in the load/store pair
    code as various cases are not expecting to see V16QImode (particularly
    the writeback patterns, but also aarch64_gen_load_pair).

    gcc/ChangeLog:

            PR target/111677
            * config/aarch64/aarch64.c (aarch64_reg_save_mode): Use
            V16QImode for the full 16-byte FPR saves in the vector PCS case.
            (aarch64_gen_storewb_pair): Handle V16QImode.
            (aarch64_gen_loadwb_pair): Likewise.
            (aarch64_gen_load_pair): Likewise.
            * config/aarch64/aarch64.md (loadwb_pair<TX:mode>_<P:mode>):
            Rename to ...
            (loadwb_pair<TX_V16QI:mode>_<P:mode>): ... this, extending to
            V16QImode.
            (storewb_pair<TX:mode>_<P:mode>): Rename to ...
            (storewb_pair<TX_V16QI:mode>_<P:mode>): ... this, extending to
            V16QImode.
            * config/aarch64/iterators.md (TX_V16QI): New.

    gcc/testsuite/ChangeLog:

            PR target/111677
            * gcc.target/aarch64/torture/pr111677.c: New test.

    (cherry picked from commit fddce05d67f34174be0f306e1015d3868bbe7c31)

[Bug target/111677] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[acoplan at gcc dot gnu.org]

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

Alex Coplan <acoplan at gcc dot gnu.org> changed:

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

--- Comment #34 from Alex Coplan <acoplan at gcc dot gnu.org> ---
Fixed for all active branches.