[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 via Gcc-bugs]

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

--- Comment #26 from GCC Commits  ---
The master branch has been updated by Alex Coplan :

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

commit r14-8657-g0529ba8168c89f24314e8750237d77bb132bea9c
Author: Alex Coplan 
Date:   Tue Jan 30 10:22:48 2024 +

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/14 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[acoplan at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #25 from Alex Coplan  ---
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

[acoplan at gcc dot gnu.org via Gcc-bugs]

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

Alex Coplan  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #24 from Alex Coplan  ---
Proposed fix for trunk:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/61.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 via Gcc-bugs]

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

Alex Coplan  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  ---
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  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 via Gcc-bugs]

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

--- Comment #20 from Alex Coplan  ---
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/14 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

[costamagnagianfranco at yahoo dot it via Gcc-bugs]

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

--- Comment #19 from Gianfranco  ---
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

[costamagnagianfranco at yahoo dot it via Gcc-bugs]

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

--- Comment #18 from Gianfranco  ---
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
-frepor

[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 via Gcc-bugs]

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

--- Comment #17 from Andrew Pinski  ---
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

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #16 from Andrew Pinski  ---
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

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  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

[germano.massullo at gmail dot com via Gcc-bugs]

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

--- Comment #15 from Germano Massullo  ---
Hello, any news please?

[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 via Gcc-bugs]

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

--- Comment #14 from Gianfranco  ---
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

[acoplan at gcc dot gnu.org via Gcc-bugs]

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

Alex Coplan  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #13 from Alex Coplan  ---
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

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #12 from Andrew Pinski  ---
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 via Gcc-bugs]

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

Alex Coplan  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||acoplan at gcc dot gnu.org

--- Comment #11 from Alex Coplan  ---
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

[costamagnagianfranco at yahoo dot it via Gcc-bugs]

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

--- Comment #10 from Gianfranco  ---
$ 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  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 via Gcc-bugs]

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

--- Comment #9 from Gianfranco  ---
/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 via Gcc-bugs]

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

--- Comment #8 from Gianfranco  ---
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 via Gcc-bugs]

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

--- Comment #7 from Gianfranco  ---
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 via Gcc-bugs]

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

--- Comment #6 from Gianfranco  ---
@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

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  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

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Andrew Pinski  ---
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).