[Bug gcov-profile/113103] Segmentation fault with --coverage option

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

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

--- Comment #3 from Andrew Pinski  ---
Undefined means it might look like it works but it is not exactly doing a well
defined behavior.

[Bug gcov-profile/113103] Segmentation fault with --coverage option

[jiahaoxiang.hust at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Haoxiang Jia  ---
But when I remove --coverage option, the binary works normally.

# gcc -o test 1.c 2.c
# ./test
#

[Bug gcov-profile/113101] compilation error with --coverage option

[jiahaoxiang.hust at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Haoxiang Jia  ---
Thanks for your prompt help.

[Bug gcov-profile/113103] Segmentation fault with --coverage option

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
a[21][1];
main() {
  for (size_t b = 0; b < 21; ++b)
for (size_t c = 0; c < 21; ++c)
  a[b][c] = 60329;



That is an out of bounds access so undefined code.

[Bug tree-optimization/113091] Over-estimate SLP vector-to-scalar cost for non-live pattern statement

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-12-21
 Status|UNCONFIRMED |NEW

--- Comment #4 from Richard Biener  ---
"The use stmt is "_2 = (int) _1", whose pattern statement is "patt_64 = (int)
patt_63", which is not referenced by any original or other pattern statements.
Or in other word, the orig_stmt could be absorbed into a vector operation,
without any outlier scalar use."

That means the code sees that _2 = (int) _1 isn't vectorized (the pattern
stmt isn't actually used) which means _2 = (int) _1 stays in the code and
thus _1 is live.

The issue here is that because the "outer" pattern consumes
patt_64 = (int) patt_63 it should have adjusted _2 = (int) _1 stmt-to-vectorize
as being the outer pattern root stmt for all this logic to work correctly.

Otherwise we have no means of identifying whether a scalar stmt takes part
in vectorization or not.

I'm not sure what restrictions we place on pattern recognition of patterns - do
we require single-uses or do we allow the situation that one vectorization
path picks up the "inner" pattern while another picks the "outer" one?

In theory we can hack up the liveness analysis but as you noticed that
isn't the part doing the costing.  The costing part is just written in
the very same way (vect_bb_vectorization_profitable_p, specifically
vect_slp_gather_vectorized_scalar_stmts and vect_bb_slp_scalar_cost).
Basically the scalar cost is
the cost of the scalar stmts that are fully replaced (can be DCEd after
vectorization) by the vector stmts.

[Bug gcov-profile/113103] New: Segmentation fault with --coverage option

[jiahaoxiang.hust at gmail dot com via Gcc-bugs]

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

Bug ID: 113103
   Summary: Segmentation fault with --coverage option
   Product: gcc
   Version: 11.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jiahaoxiang.hust at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

I tried to collect the coverage information of these two programs. When
compilation with --coverage, the binary execution resulted in segmentation
fault. However, if we remove --coverage, the binary works well.

# gcov -v
gcov (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11.4.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --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-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-XeT9lY/gcc-11-11.4.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-XeT9lY/gcc-11-11.4.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)

# cat 1.c
extern a;
#define c(a, b)   
\
  {   
\
__typeof__(a) d = a;  
\
d;
\
  }
e;
f(g) {
  int *h = 0;
  for (long i;; i = e)
if (e)
  a = (c(h[i] ?: (long)g, ));
}

# cat 2.c
#include 
a[21][1];
main() {
  for (size_t b = 0; b < 21; ++b)
for (size_t c = 0; c < 21; ++c)
  a[b][c] = 60329;
}

# gcc --coverage -o test 1.c 2.c
# ./test
Segmentation fault (core dumped)

[Bug tree-optimization/113102] during GIMPLE pass: bitintlower ICE: SIGSEGV with _BitInt() at -O1 or -O2

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #1 from Zdenek Sojka  ---
Created attachment 56914
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56914&action=edit
testcase failing at -O2

$ x86_64-pc-linux-gnu-gcc -O2 testcase-O2.c -wrapper valgrind,-q
==16387== Invalid read of size 4
==16387==at 0x114FEA7: phi_nodes_ptr (gimple.h:4700)
==16387==by 0x114FEA7: gsi_start_phis (gimple-iterator.cc:935)
==16387==by 0x114FEA7: gsi_for_stmt(gimple*) (gimple-iterator.cc:620)
==16387==by 0x263223A: gimple_lower_bitint() (gimple-lower-bitint.cc:6695)
==16387==by 0x13C4DCA: execute_one_pass(opt_pass*) (passes.cc:2646)
==16387==by 0x13C56BF: execute_pass_list_1(opt_pass*) (passes.cc:2755)
==16387==by 0x13C56D1: execute_pass_list_1(opt_pass*) (passes.cc:2756)
==16387==by 0x13C56F8: execute_pass_list(function*, opt_pass*)
(passes.cc:2766)
==16387==by 0xFC60E5: expand (cgraphunit.cc:1842)
==16387==by 0xFC60E5: cgraph_node::expand() (cgraphunit.cc:1795)
==16387==by 0xFC742A: expand_all_functions (cgraphunit.cc:2025)
==16387==by 0xFC742A: symbol_table::compile() [clone .part.0]
(cgraphunit.cc:2399)
==16387==by 0xFC9FA7: compile (cgraphunit.cc:2312)
==16387==by 0xFC9FA7: symbol_table::finalize_compilation_unit()
(cgraphunit.cc:2584)
==16387==by 0x1506CF1: compile_file() (toplev.cc:473)
==16387==by 0xDE3BFB: do_compile (toplev.cc:2150)
==16387==by 0xDE3BFB: toplev::main(int, char**) (toplev.cc:2306)
==16387==by 0xDE53DA: main (main.cc:39)
==16387==  Address 0x50 is not stack'd, malloc'd or (recently) free'd
==16387== 
during GIMPLE pass: bitintlower
testcase-O2.c: In function 'foo':
testcase-O2.c:4:1: internal compiler error: Segmentation fault
4 | foo(void)
  | ^~~
0x150680f crash_signal
/repo/gcc-trunk/gcc/toplev.cc:316
0x114fea7 phi_nodes_ptr(basic_block_def*)
/repo/gcc-trunk/gcc/gimple.h:4700
0x114fea7 gsi_start_phis(basic_block_def*)
/repo/gcc-trunk/gcc/gimple-iterator.cc:935
0x114fea7 gsi_for_stmt(gimple*)
/repo/gcc-trunk/gcc/gimple-iterator.cc:620
0x263223a gimple_lower_bitint
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:6695
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 tree-optimization/113102] New: during GIMPLE pass: bitintlower ICE: SIGSEGV with _BitInt() at -O1 or -O2

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 113102
   Summary: during GIMPLE pass: bitintlower ICE: SIGSEGV with
_BitInt() at -O1 or -O2
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 56913
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56913&action=edit
reduced testcase

Thank you for the fixes so far.

I am observing SIGSEGV at various places at -O1 and -O2, when using _BitInt().
This happens also with the PR112941#c8 patch applied.

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O testcase-O1.c -wrapper valgrind,-q
testcase-O1.c: In function 'foo2':
testcase-O1.c:24:17: warning: division by zero [-Wdiv-by-zero]
   24 |   bi8 /= x >> 0 / 0;
  | ^
==16226== Invalid read of size 2
==16226==at 0x261843D: (anonymous
namespace)::bitint_large_huge::add_cast(tree_node*, tree_node*)
(gimple-lower-bitint.cc:1052)
==16226==by 0x2621F90: (anonymous
namespace)::bitint_large_huge::handle_cast(tree_node*, tree_node*, tree_node*)
(gimple-lower-bitint.cc:1501)
==16226==by 0x261F200: (anonymous
namespace)::bitint_large_huge::handle_operand(tree_node*, tree_node*)
(gimple-lower-bitint.cc:790)
==16226==by 0x262E269: (anonymous
namespace)::bitint_large_huge::lower_shift_stmt(tree_node*, gimple*)
(gimple-lower-bitint.cc:3137)
==16226==by 0x2631849: gimple_lower_bitint() (gimple-lower-bitint.cc:6469)
==16226==by 0x13C4D6A: execute_one_pass(opt_pass*) (passes.cc:2646)
==16226==by 0x13C565F: execute_pass_list_1(opt_pass*) (passes.cc:2755)
==16226==by 0x13C5671: execute_pass_list_1(opt_pass*) (passes.cc:2756)
==16226==by 0x13C5698: execute_pass_list(function*, opt_pass*)
(passes.cc:2766)
==16226==by 0xFC6085: expand (cgraphunit.cc:1842)
==16226==by 0xFC6085: cgraph_node::expand() (cgraphunit.cc:1795)
==16226==by 0xFC73CA: expand_all_functions (cgraphunit.cc:2025)
==16226==by 0xFC73CA: symbol_table::compile() [clone .part.0]
(cgraphunit.cc:2399)
==16226==by 0xFC9F47: compile (cgraphunit.cc:2312)
==16226==by 0xFC9F47: symbol_table::finalize_compilation_unit()
(cgraphunit.cc:2584)
==16226==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==16226== 
during GIMPLE pass: bitintlower
testcase-O1.c: In function 'foo0':
testcase-O1.c:9:1: internal compiler error: Segmentation fault
9 | foo0(void)
  | ^~~~
0x150673f crash_signal
/repo/gcc-trunk/gcc/toplev.cc:316
0x261843d add_cast
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:1052
0x2621f90 handle_cast
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:1501
0x261f200 handle_operand
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:790
0x262e269 lower_shift_stmt
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:3137
0x2631849 gimple_lower_bitint
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:6469
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.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-6769-20231221032123-g514ea1df444-checking-yes-rtl-df-extra-nobootstrap-pr112941-mul-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-6769-20231221032123-g514ea1df444-checking-yes-rtl-df-extra-nobootstrap-pr112941-mul-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231221 (experimental) (GCC)

[Bug gcov-profile/113101] compilation error with --coverage option

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
You need -mcmodel=large if you use a large array that is above 2GB in size.

See
https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/x86-Options.html#index-mcmodel_003dlarge-3

[Bug c/113050] __atomic_* builtins should use -Wdiscarded-qualifiers instead of -Wincompatible-pointer-types

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug gcov-profile/113101] New: compilation crash with option --coverage

[jiahaoxiang.hust at gmail dot com via Gcc-bugs]

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

Bug ID: 113101
   Summary: compilation crash with option --coverage
   Product: gcc
   Version: 11.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jiahaoxiang.hust at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

I tried to compile this C program with the --coverage option and the
compilation resulted in an error. The root cause might be the large array size.
The error can not be triggered under a smaller array.

# gcov -v
gcov (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11.4.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --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-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-XeT9lY/gcc-11-11.4.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-XeT9lY/gcc-11-11.4.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)

# cat test.cpp
int a[612220032];
int main() {}

# g++ --coverage -o test test.cpp
/usr/lib/gcc/x86_64-linux-gnu/11/libgcov.a(_gcov.o): in function
`gcov_write_block':
(.text+0x17): failed to convert GOTPCREL relocation against '__gcov_var';
relink with --no-relax
/usr/lib/gcc/x86_64-linux-gnu/11/libgcov.a(_gcov.o): in function
`gcov_read_words':
(.text+0x59): failed to convert GOTPCREL relocation against '__gcov_var';
relink with --no-relax
/usr/lib/gcc/x86_64-linux-gnu/11/libgcov.a(_gcov.o): in function `gcov_error':
(.text+0x1f6): failed to convert GOTPCREL relocation against
'__gcov_error_file'; relink with --no-relax
/usr/lib/gcc/x86_64-linux-gnu/11/libgcov.a(_gcov.o): in function
`gcov_write_words':
(.text+0x36b): failed to convert GOTPCREL relocation against '__gcov_var';
relink with --no-relax
/usr/lib/gcc/x86_64-linux-gnu/11/libgcov.a(_gcov.o): in function
`__gcov_rewrite':
(.text+0x3d7): failed to convert GOTPCREL relocation against '__gcov_var';
relink with --no-relax
/usr/lib/gcc/x86_64-linux-gnu/11/libgcov.a(_gcov.o): in function `__gcov_open':
(.text+0x430): failed to convert GOTPCREL relocation against '__gcov_var';
relink with --no-relax
/usr/lib/gcc/x86_64-linux-gnu/11/libgcov.a(_gcov.o): in function
`__gcov_close':
(.text+0x4e8): failed to convert GOTPCREL relocation against '__gcov_var';
relink with --no-relax
/usr/lib/gcc/x86_64-linux-gnu/11/libgcov.a(_gcov.o): in function
`gcov_do_dump':
(.text+0x67c): relocation truncated to fit: R_X86_64_PC32 against `.bss'
(.text+0x822): failed to convert GOTPCREL relocation against '__gcov_var';
relink with --no-relax
(.text+0x8c5): failed to convert GOTPCREL relocation against '__gcov_var';
relink with --no-relax
(.text+0x930): relocation truncated to fit: R_X86_64_PC32 against `.bss'
(.text+0xa5e): relocation truncated to fit: R_X86_64_PC32 against `.bss'
(.text+0xaad): relocation truncated to fit: R_X86_64_PC32 against `.bss'
(.text+0xc18): relocation truncated to fit: R_X86_64_PC32 against `.bss'
(.text+0xc75): relocation truncated to fit: R_X86_64_PC32 against `.bss'
(.text+0xecd): relocation truncated to fit: R_X86_64_PC32 against `.bss'
(.text+0x1377): failed to convert GOTPCREL relocation against '__gcov_var';
relink with --no-relax
(.text+0x1514): relocation truncated to fit: R_X86_64_PC32 against `.bss'
(.text+0x151d): relocation truncated to fit: R_X86_64_PC32 against `.bss'
(.text+0x154f): relocation truncated to fit: R_X86_64_PC32 against `

[Bug rtl-optimization/85099] [meta-bug] selective scheduling issues

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85099
Bug 85099 depends on bug 112995, which changed state.

Bug 112995 Summary: sel-sched2 ICE without checking verify_changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112995

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug rtl-optimization/112995] sel-sched2 ICE without checking verify_changes

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

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

Kewen Lin  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
   Target Milestone|--- |14.0

--- Comment #5 from Kewen Lin  ---
Should be fixed on trunk, guessing we don't want a backport, so closing.

[Bug target/112778] ICE in ppc64-linux-gnu crosscompiler in store_by_pieces since r14-5946-g1ff6d9f7428b06

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Alexandre Oliva :

https://gcc.gnu.org/g:514ea1df444ca7f64c3f504ced05d8fb5fbfd62d

commit r14-6769-g514ea1df444ca7f64c3f504ced05d8fb5fbfd62d
Author: Alexandre Oliva 
Date:   Thu Dec 21 03:21:23 2023 -0300

-finline-stringops: drop obsolete comment [PR112778]

When fixing the PR, I failed to remove the comment that raised the
very concern that the PR confirmed, and that the earlier patch for the
PR fixed.


for  gcc/ChangeLog

PR target/112778
* builtins.cc (try_store_by_multiple_pieces): Drop obsolete
comment.

[Bug rtl-optimization/112995] sel-sched2 ICE without checking verify_changes

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Kewen Lin :

https://gcc.gnu.org/g:5fbc77726f68a35a938c829fe259d6c376d608ca

commit r14-6768-g5fbc77726f68a35a938c829fe259d6c376d608ca
Author: Kewen Lin 
Date:   Wed Dec 20 23:20:19 2023 -0600

sel-sched: Verify change before replacing dest in EXPR_INSN_RTX [PR112995]

PR112995 exposed one issue in current try_replace_dest_reg
that the result rtx insn after replace_dest_with_reg_in_expr
is probably unable to match any constraints.  Although there
are some checks on the changes onto dest or src of orig_insn,
none is performed on the EXPR_INSN_RTX.

Initially we have:

(insn 31 6 10 2 (set (reg/v:SI 9 9 [orig:119 c ] [119])
 (reg/v:SI 64 0 [orig:119 c ] [119]))
"test.i":5:5 555 {*movsi_internal1} ... )
...
(insn 25 10 27 2 (set (reg:DI 64 0 [135])
  (sign_extend:DI
 (reg/v:SI 9 9 [orig:119 c ] [119])))
 "test.i":6:5 31 {extendsidi2} ...)

with moving up, we have:

(insn 46 0 0 (set (reg:DI 64 0 [135])
  (sign_extend:DI
  (reg/v:SI 64 0 [orig:119 c ] [119])))
   31 {extendsidi2} ...)

in try_replace_dest_reg, we updated the above EXPR_INSN_RTX to:

(insn 48 0 0 (set (reg:DI 32 0)
  (sign_extend:DI
  (reg/v:SI 64 0 [orig:119 c ] [119])))
   31 {extendsidi2} ...)

The dest (reg 64) is a VR (also VSX REG), the updating makes
it become to (reg 32) which is a FPR (also VSX REG), we have
an alternative to match "VR,VR" but no one to match "FPR/VSX,
VR/VSX", so it fails with ICE.

This patch is to add the check before actually replacing dest
in expr with reg.

PR rtl-optimization/112995

gcc/ChangeLog:

* sel-sched.cc (try_replace_dest_reg): Check the validity of the
replaced insn before actually replacing dest in expr.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/pr112995.c: New test.

[Bug tree-optimization/113091] Over-estimate SLP vector-to-scalar cost for non-live pattern statement

[fxue at os dot amperecomputing.com via Gcc-bugs]

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

--- Comment #3 from Feng Xue  ---
The function vect_bb_vectorization_profitable_p resorts to a recursive way to
identify scalar use, for this case, setting STMT_VINFO_LIVE_P or not would not
change scalar cost computation.

[Bug tree-optimization/113091] Over-estimate SLP vector-to-scalar cost for non-live pattern statement

[fxue at os dot amperecomputing.com via Gcc-bugs]

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

--- Comment #2 from Feng Xue  ---
(In reply to Richard Biener from comment #1)
> It's the logic
> 
>   FOR_EACH_VEC_ELT (SLP_TREE_SCALAR_STMTS (node), i, stmt_info)
> {
>   if (svisited.contains (stmt_info))
> continue;
>   stmt_vec_info orig_stmt_info = vect_orig_stmt (stmt_info);
>   if (STMT_VINFO_IN_PATTERN_P (orig_stmt_info)
>   && STMT_VINFO_RELATED_STMT (orig_stmt_info) != stmt_info)
> /* Only the pattern root stmt computes the original scalar value.  */
> continue;
>   bool mark_visited = true;
>   gimple *orig_stmt = orig_stmt_info->stmt;
>   ssa_op_iter op_iter;
>   def_operand_p def_p;
>   FOR_EACH_PHI_OR_STMT_DEF (def_p, orig_stmt, op_iter, SSA_OP_DEF)
> {
>   imm_use_iterator use_iter;
>   gimple *use_stmt;
>   stmt_vec_info use_stmt_info;
>   FOR_EACH_IMM_USE_STMT (use_stmt, use_iter, DEF_FROM_PTR (def_p))
> if (!is_gimple_debug (use_stmt))
>   {
> use_stmt_info = bb_vinfo->lookup_stmt (use_stmt);
> if (!use_stmt_info
> || !PURE_SLP_STMT (vect_stmt_to_vectorize
> (use_stmt_info)))
>   {
> STMT_VINFO_LIVE_P (stmt_info) = true;
> 
> specifically the last check.  That's supposed to pick up the "main" pattern
> that's now covering the scalar stmt.
> 
> But somehow the "main" pattern,
> 
> patt_67 = .VEC_WIDEN_MINUS (_1, _3);  //  _5 = _2 - _4;
>  patt_68 = (signed short) patt_67; //  _5 = _2 - _4;
>  patt_69 = (int) patt_68;  //  _5 = _2 - _4;
> 
> doesn't get picked up here.  I wonder what's the orig_stmt and the def
> picked and what original scalar use we end up in where the
> vect_stmt_to_vectorize isn't the "last" pattern.  Maybe we really want


This problem happens at slp node:

 note: node 0x425bc38 (max_nunits=8, refcnt=1) vector(8) char
 note: op template: _1 = *a_50(D);
 note:  stmt 0 _1 = *a_50(D);
 note:  stmt 1 _7 = MEM[(char *)a_50(D) + 1B];
 note:  stmt 2 _13 = MEM[(char *)a_50(D) + 2B];
 note:  stmt 3 _19 = MEM[(char *)a_50(D) + 3B];
 note:  stmt 4 _25 = MEM[(char *)a_50(D) + 4B];
 note:  stmt 5 _31 = MEM[(char *)a_50(D) + 5B];
 note:  stmt 6 _37 = MEM[(char *)a_50(D) + 6B];
 note:  stmt 7 _43 = MEM[(char *)a_50(D) + 7B];

The orig_stmt is "_1 = *a_50(D)"

The use stmt is "_2 = (int) _1", whose pattern statement is "patt_64 = (int)
patt_63", which is not referenced by any original or other pattern statements.
Or in other word, the orig_stmt could be absorbed into a vector operation,
without any outlier scalar use.

The fore-mentioned "last check" in vect_bb_slp_mark_live_stmts would make the
orig_stmt to be STMT_VINFO_LIVE_P, which actually implies it has scalar use
(though it should not have), the difference is re-generating the def somewhere,
rather than retaining the original scalar statement. And the following
"vectorizable_live_operation" would account the new operations into
vectorization cost of the SLP instance.

The function vect_bb_vectorization_profitable_p resorts to a recursive way to
identify scalar use, for this case, setting STMT_VINFO_LIVE_P or not would
change scalar cost computation. If we can avoid such fake-liveness adjustment
on the statements we are interested in, vectorization cost could beat scalar
cost, and make the former succeed.

   Unvectorized: 
mov x2, x0
stp x29, x30, [sp, -48]!
mov x29, sp
ldrbw3, [x1]
ldrbw4, [x1, 1]
add x0, sp, 16
ldrbw9, [x2]
ldrbw8, [x2, 1]
sub w9, w9, w3
ldrbw7, [x2, 2]
ldrbw3, [x1, 2]
sub w8, w8, w4
ldrbw6, [x2, 3]
ldrbw4, [x1, 3]
sub w7, w7, w3
ldrbw10, [x1, 5]
ldrbw3, [x1, 4]
sub w6, w6, w4
ldrbw5, [x2, 4]
ldrbw4, [x2, 5]
sub w5, w5, w3
ldrbw3, [x2, 6]
sub w4, w4, w10
ldrbw2, [x2, 7]
ldrbw10, [x1, 6]
ldrbw1, [x1, 7]
sub w3, w3, w10
stp w9, w8, [sp, 16]
sub w1, w2, w1
stp w7, w6, [sp, 24]
stp w5, w4, [sp, 32]
stp w3, w1, [sp, 40]
bl  test
ldp x29, x30, [sp], 48
ret


Vectorized:
mov x2, x0
stp x29, x30, [sp, -48]!
mov x29, sp
ldr d1, [x1]
add x0, sp, 16
ldr d0, [x2]
usubl   v0.8h, v0.8b, v1.8b
sxtlv1.4s, v0.4h
sxtl2   v0.4s, v0.8h
stp q1, q0, [sp, 16]
bl  test
ldp x29, x30, [sp], 48
ret


> these "overlapping" patterns, but IMHO having "two entries" into
> a chain of scalar stmts is bad and we should link up the whole matched
> sequence to the final "root" instead?
> 
> That said, the c

[Bug middle-end/113100] [14 regression] many strub tests fail after r14-6737-g4e0a467302fea5

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug middle-end/113100] [14 regression] many strub tests fail after r14-6737-g4e0a467302fea5

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

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

   Host||powerpc64le-linux-gnu
  Build||powerpc64le-linux-gnu
 Target||powerpc64le-linux-gnu
 CC||aoliva at gcc dot gnu.org

--- Comment #1 from seurer at gcc dot gnu.org ---
commit 4e0a467302fea56d63b7a6d17f99c0f388960dc7 (HEAD, refs/bisect/bad)
Author: Alexandre Oliva 
Date:   Thu Dec 14 04:50:45 2023 -0300

strub: sparc64: unbias the stack address [PR112917]

[Bug middle-end/113100] New: [14 regression] many strub tests fail after r14-6737-g4e0a467302fea5

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

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

Bug ID: 113100
   Summary: [14 regression] many strub tests fail after
r14-6737-g4e0a467302fea5
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:4e0a467302fea56d63b7a6d17f99c0f388960dc7, r14-6737-g4e0a467302fea5

FAIL: c-c++-common/strub-defer-O1.c  -std=gnu++14 execution test
FAIL: c-c++-common/strub-defer-O1.c  -std=gnu++17 execution test
FAIL: c-c++-common/strub-defer-O1.c  -std=gnu++20 execution test
FAIL: c-c++-common/strub-defer-O1.c  -std=gnu++98 execution test
FAIL: c-c++-common/strub-defer-O2.c  -std=gnu++14 execution test
FAIL: c-c++-common/strub-defer-O2.c  -std=gnu++17 execution test
FAIL: c-c++-common/strub-defer-O2.c  -std=gnu++20 execution test
FAIL: c-c++-common/strub-defer-O2.c  -std=gnu++98 execution test
FAIL: c-c++-common/strub-defer-Os.c  -std=gnu++14 execution test
FAIL: c-c++-common/strub-defer-Os.c  -std=gnu++17 execution test
FAIL: c-c++-common/strub-defer-Os.c  -std=gnu++20 execution test
FAIL: c-c++-common/strub-defer-Os.c  -std=gnu++98 execution test
FAIL: c-c++-common/torture/strub-run1.c   -O0  execution test
FAIL: c-c++-common/torture/strub-run1.c   -O1  execution test
FAIL: c-c++-common/torture/strub-run1.c   -O2  execution test
FAIL: c-c++-common/torture/strub-run1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: c-c++-common/torture/strub-run1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: c-c++-common/torture/strub-run1.c   -Os  execution test
FAIL: c-c++-common/torture/strub-run2.c   -O0  execution test
FAIL: c-c++-common/torture/strub-run2.c   -O1  execution test
FAIL: c-c++-common/torture/strub-run2.c   -O2  execution test
FAIL: c-c++-common/torture/strub-run2.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: c-c++-common/torture/strub-run2.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: c-c++-common/torture/strub-run2.c   -Os  execution test
FAIL: c-c++-common/torture/strub-run3.c   -O0  execution test
FAIL: c-c++-common/torture/strub-run3.c   -O1  execution test
FAIL: c-c++-common/torture/strub-run3.c   -O2  execution test
FAIL: c-c++-common/torture/strub-run3.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: c-c++-common/torture/strub-run3.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: c-c++-common/torture/strub-run3.c   -Os  execution test
FAIL: c-c++-common/torture/strub-run4.c   -O0  execution test
FAIL: c-c++-common/torture/strub-run4.c   -O1  execution test
FAIL: c-c++-common/torture/strub-run4.c   -O2  execution test
FAIL: c-c++-common/torture/strub-run4.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: c-c++-common/torture/strub-run4.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: c-c++-common/torture/strub-run4.c   -Os  execution test
FAIL: c-c++-common/torture/strub-run4c.c   -O0  execution test
FAIL: c-c++-common/torture/strub-run4c.c   -O1  execution test
FAIL: c-c++-common/torture/strub-run4c.c   -O2  execution test
FAIL: c-c++-common/torture/strub-run4c.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: c-c++-common/torture/strub-run4c.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: c-c++-common/torture/strub-run4c.c   -Os  execution test
FAIL: c-c++-common/torture/strub-run4d.c   -O0  execution test
FAIL: c-c++-common/torture/strub-run4d.c   -O1  execution test
FAIL: c-c++-common/torture/strub-run4d.c   -O2  execution test
FAIL: c-c++-common/torture/strub-run4d.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: c-c++-common/torture/strub-run4d.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: c-c++-common/torture/strub-run4d.c   -Os  execution test
FAIL: c-c++-common/torture/strub-run4i.c   -O0  execution test
FAIL: c-c++-common/torture/strub-run4i.c   -O1  execution test
FAIL: c-c++-common/torture/strub-run4i.c   -O2  execution test
FAIL: c-c++-common/torture/strub-run4i.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: c-c++-common/torture/strub-run4i.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: c-c++-common/torture/strub-run4i.c   -Os  execution test
FAIL: g++.dg/strub-run1.C  -std=gnu++14 execution test
FAIL: g++.dg/strub-run1.C  -std=gnu++17 execution test
FAIL: g++.dg/strub-run1.C  -std=gnu++20 execution test
FAIL: g++.dg/strub-run1.C  -std=gnu++98 execution test

There is no output from any of the failures.  Running one in gdb I see:

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

[Bug middle-end/112917] Most strub execution tests FAIL on SPARC

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

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Alexandre Oliva  ---
Fixed

[Bug rtl-optimization/113002] ICE in commit_one_edge_insertion, at cfgrtl.cc:2095 with new -finline-stringops

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

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

Alexandre Oliva  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #5 from Alexandre Oliva  ---
Fixed

[Bug c++/52339] using delete ptr1->ptr2 where ptr2 destructor deletes a const ptr1 fails

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

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

--- Comment #11 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #10)
> (In reply to Jakub Jelinek from comment #7)
> > Created attachment 54994 [details]
> > gcc14-pr52339.patch
> > 
> > Untested fix.
> 
> I think this might fix PR 108789 too ...

And PR 53424 .

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #10 from Patrick O'Neill  ---
I've kicked off 2 spec runs (zvl 128 and 256) using r14-6765-g4d9e0f3f211. I'll
let you know the results when they finish.

Thanks for the quick fix on this bug!

[Bug middle-end/37722] destructors not called on computed goto

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

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
   Target Milestone|--- |14.0
 Resolution|--- |FIXED

--- Comment #8 from Jason Merrill  ---
Warning and documentation added for GCC 14.

[Bug middle-end/37722] destructors not called on computed goto

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

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

--- Comment #7 from GCC Commits  ---
The trunk branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:4d9e0f3f211c8c459f285b5cddabc9958ad170f8

commit r14-6765-g4d9e0f3f211c8c459f285b5cddabc9958ad170f8
Author: Jason Merrill 
Date:   Wed Dec 20 13:58:16 2023 -0500

c++: computed goto warning [PR37722]

PR37722 complains that a computed goto doesn't destroy objects that go out
of scope.  In the PR we agreed that it never will, but we can warn about
it.

PR c++/37722

gcc/ChangeLog:

* doc/extend.texi: Document that computed goto does not
call destructors.

gcc/cp/ChangeLog:

* decl.cc (identify_goto): Adjust for computed goto.
(struct named_label_use_entry): Add computed_goto field.
(poplevel_named_label_1): Add to computed_goto vec.
(check_previous_goto_1): Dump computed_goto vec.
(check_goto_1): Split out from check_goto.
(check_goto): Check all addressable labels for computed goto.
(struct named_label_entry): Add addressed field.
(mark_label_addressed): New.
* parser.cc (cp_parser_unary_expression): Call it.
* cp-tree.h (mark_label_addressed): Declare it.

gcc/testsuite/ChangeLog:

* g++.dg/ext/label15.C: New test.
* g++.dg/torture/pr42739.C: Expect warning.

[Bug c++/106213] -Werror=deprecated-copy-dtor does not trigger warning and error

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

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

--- Comment #4 from GCC Commits  ---
The trunk branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:32bab8b57ddf0df727f5eaf99a77e70882c4e6e2

commit r14-6764-g32bab8b57ddf0df727f5eaf99a77e70882c4e6e2
Author: Jason Merrill 
Date:   Tue Dec 19 15:33:07 2023 -0500

opts: -Werror=foo always implies -Wfoo [PR106213]

-Werror=foo implying -Wfoo wasn't working for -Wdeprecated-copy-dtor,
because it is specified as the value 2 of warn_deprecated_copy, which shows
up as CLVC_EQUAL, which is not one of the three var_types handled by
control_warning_option.  It seems to me that we can just unconditionally
handle_generated_option, and only have special argument handling for those
types.

PR c++/106213

gcc/ChangeLog:

* opts-common.cc (control_warning_option): Call
handle_generated_option for all cl_var_types.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/depr-copy5.C: New test.

[Bug sanitizer/113092] _BitInt of shift vs ubsan

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   See Also||https://github.com/llvm/llv
   ||m-project/issues/76113
   Last reconfirmed||2023-12-21
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Confirmed, Filed it upstream too:
https://github.com/llvm/llvm-project/issues/76113

[Bug sanitizer/113092] _BitInt of shift vs ubsan

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

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

--- Comment #1 from Andrew Pinski  ---
Looks like this fails even in clang trunk:
UndefinedBehaviorSanitizer: CHECK failed: ubsan_value.cpp:86 "((0 &&
"unexpected bit width")) != (0)" (0x0, 0x0) (tid=1)

[Bug libstdc++/113099] New: locale without RTTI uses dynamic_cast before gcc 13.2 or has ODR violation since gcc 13.2

[andysem at mail dot ru via Gcc-bugs]

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

Bug ID: 113099
   Summary: locale without RTTI uses dynamic_cast before gcc 13.2
or has ODR violation since gcc 13.2
   Product: gcc
   Version: 11.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andysem at mail dot ru
  Target Milestone: ---

Consider this test case:

```
#include 

class __attribute__((__visibility__("default"))) my_codecvt final :
public std::codecvt< wchar_t, char, std::mbstate_t >
{
public:
explicit my_codecvt(std::size_t refs = 0) :
std::codecvt< wchar_t, char, std::mbstate_t >(refs)
{
}

protected:
bool do_always_noconv() const noexcept override { return false; }

int do_encoding() const noexcept override { return 0; }
std::codecvt_base::result do_in(std::mbstate_t&, const char*,
const char*, const char*&, wchar_t*, wchar_t*, wchar_t*&)
const override
{ return ok; }
std::codecvt_base::result do_out(std::mbstate_t&, const wchar_t*,
const wchar_t*, const wchar_t*&, char*, char*, char*&)
const override
{ return ok; }
std::codecvt_base::result do_unshift(std::mbstate_t&, char*,
char*, char*&) const override
{ return ok; }
int do_length(std::mbstate_t&, const char*, const char*,
std::size_t) const override
{ return 0; }
int do_max_length() const noexcept override { return 0; }
};

int main()
{
std::locale loc(std::locale(), new my_codecvt());
auto const& fac = std::use_facet<
std::codecvt< wchar_t, char, std::mbstate_t > >(loc);
(void)fac;
}
```

```
g++ -std=c++17 -fno-rtti -o locale_no_rtti locale_no_rtti.cpp
```

When compiled with RTTI disabled, with the command line above, this code
crashes with the following backtrace:

```
#0  0x77caccd1 in __dynamic_cast () from
/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x77d5307f in std::codecvt const&
std::use_facet >(std::locale const&)
() from /lib/x86_64-linux-gnu/libstdc++.so.6
#2  0x539b in main ()
```

This reproduces on gcc 11.4 and 12 at least.

```
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11.4.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --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-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-XeT9lY/gcc-11-11.4.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-XeT9lY/gcc-11-11.4.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04) 
```

This was apparently fixed by accident in gcc 13.2 by this commit:

https://github.com/gcc-mirror/gcc/commit/b3ac43a3c05744d62a963d656bed782fc867ad79

The commit introduces shortcuts that use static_casts for the standard facets,
which allows to avoid the crash, but that still retains an ODR violation, where
the explicitly instantiated __try_use_facet templates in libstdc++ library use
dynamic_cast (even if unreachable) and the template definition that is visible
to user's code uses static_cast. The problematic code is here:

https://github.com/gcc-mirror/gcc/blob/d7e9ae4fa94afd5517536b4dfc7d6be0b3e8c2c3/libstdc%2B%2B-v3/include/bits/locale_classes.tcc#L142-L146

When libstdc++ is compiled, RTTI is enabled and __cpp_rtti is defined, but when
user's code is compiled with RTTI disabled, that macro is not defined, so the
__try_use_facet template definition is different.

It doesn't seem like the commit I mentioned above intended to fix the original
issue with dynamic_cast anyway, so I thought it was worth creating this bug
report, even though the original test case passes on the latest gcc.

I think, the code shoul

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #9 from JuzheZhong  ---
It's fixed on the trunk.

I wonder whether it can fix the issues that you (RIVOS) fail to run SPEC 527
and. 549

We have fixed several issues recently, could you use the latest trunk GCC to
run SPEC today ?

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Pan Li :

https://gcc.gnu.org/g:008b80e42eb7cb55c6a2ef55728241b8733dfd17

commit r14-6761-g008b80e42eb7cb55c6a2ef55728241b8733dfd17
Author: Juzhe-Zhong 
Date:   Wed Dec 20 14:55:26 2023 +0800

RISC-V: Optimize SELECT_VL codegen when length is known as smaller than VF

While trying to fix bugs of PR113097, notice this following situation we
generate redundant vsetvli

_255 = SELECT_VL (3, POLY_INT_CST [4, 4]);
COND_LEN (..., _255)

Before this patch:

vsetivli a5, 3...
...
vadd.vv (use a5)

After this patch:

...
vadd.vv (use AVL = 3)

The reason we can do this is because known_ge (3, [4,4]) is true.
It's safe to apply such optimization

Tested on both RV32 and RV64 full coverage testing, no regression.

PR target/113087

gcc/ChangeLog:

* config/riscv/riscv-v.cc (expand_select_vl): Optimize SELECT_VL.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/pr113087-2.c: New test.

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Pan Li :

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

commit r14-6760-gd82bb518fa372cc30cc3352e0a124d0bd6deb36f
Author: Juzhe-Zhong 
Date:   Wed Dec 20 14:50:11 2023 +0800

RISC-V: Fix bug of VSETVL fusion

This patch fixes bugs in the fusion of this following case:

li a5,-1
vmv.s.x v0,a5 -> demand any non-zero AVL
vsetvli a5, ...

Incorrect fusion after VSETVL PASS:

li a5,-1
vsetvli a5...
vmv.s.x v0, a5 --> a5 is modified as incorrect value.

We disallow this incorrect fusion above.

Full coverage testing of RV64 and RV32 no regression.

PR target/113087

gcc/ChangeLog:

* config/riscv/riscv-vsetvl.cc: Disallow fusion when VL
modification pollutes non AVL use.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/pr113087-1.c: New test.

[Bug c++/105841] [12 Regression] Change in behavior of CTAD for alias templates

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

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

Jason Merrill  changed:

   What|Removed |Added

   Target Milestone|12.4|13.0
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #14 from Jason Merrill  ---
This was a big enough change that I lean toward not backporting.

[Bug target/113094] [14 Regression][aarch64] ICE in extract_constrain_insn, at recog.cc:2713 since r14-6290-g9f0f7d802482a8

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

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

Richard Sandiford  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #4 from Richard Sandiford  ---
Testing a patch.  We're doing spurious work on insns that are slated for
deletion, but we can't simply delete them first because that would disrupt the
main iteration.  Easiest fix seems to be to replace them with NOTE_INSN_DELETED
first, then iterate, then delete.

[Bug rtl-optimization/113098] New: [14 Regression] LRA ICE building glibc for mips

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

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

Bug ID: 113098
   Summary: [14 Regression] LRA ICE building glibc for mips
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---
Target: mips*-*-*

Created attachment 56912
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56912&action=edit
preprocessed source

Compile the attached code, from glibc, with -mabi=32 -O2 for MIPS (I used a
mips64-linux-gnu compiler configured --with-mips-plt --with-nan=2008
--with-arch-64=mips64r2 --with-arch-32=mips32r2; the --with-arch-32 part may
well be required to reproduce the issue).

offtime.c: In function '__offtime':
offtime.c:86:1: error: unable to find a register to spill
offtime.c:86:1: error: this is the insn:
(insn 1015 3973 3974 24 (parallel [
(set (reg:SI 2971)
(plus:SI (mult:SI (reg:SI 2367)
(reg:SI 898))
(reg:SI 2972)))
(clobber (reg:SI 2881 [2814]))
(clobber (reg:SI 2815))
]) "offtime.c":67:84 42 {*mul_acc_si}
 (expr_list:REG_UNUSED (reg:SI 2815)
(expr_list:REG_UNUSED (reg:SI 2881 [2814])
(expr_list:REG_DEAD (reg:SI 2972)
(expr_list:REG_DEAD (reg:SI 2367)
(expr_list:REG_DEAD (reg:SI 898)
(nil)))
during RTL pass: reload
offtime.c:86:1: internal compiler error: in lra_split_hard_reg_for, at
lra-assigns.cc:1862
0x6f3f05 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/scratch/jmyers/glibc/many14/src/gcc/gcc/rtl-error.cc:108
0xd53048 lra_split_hard_reg_for()
/scratch/jmyers/glibc/many14/src/gcc/gcc/lra-assigns.cc:1862
0xd4c9c9 lra(_IO_FILE*, int)
/scratch/jmyers/glibc/many14/src/gcc/gcc/lra.cc:2518
0xd00d97 do_reload
/scratch/jmyers/glibc/many14/src/gcc/gcc/ira.cc:5973
0xd00d97 execute
/scratch/jmyers/glibc/many14/src/gcc/gcc/ira.cc:6161
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.

ICE introduced by

commit 989e67f827b74b76e58abe137ce12d948af2290c
Author: Vladimir N. Makarov 
Date:   Mon Dec 18 17:12:23 2023 -0500

[PR112918][LRA]: Fixing IRA ICE on m68k

Some GCC tests on m68K port of LRA is failed on `maximum number of
generated reload insns per insn achieved`.  The problem is in that for
subreg reload LRA can not narrow reg class more from ALL_REGS to
GENERAL_REGS and then to data regs or address regs.  The patch permits
narowing reg class from reload insns if this results in succesful
matching of reg operand.

[Bug rtl-optimization/113097] New: [14 Regression] LRA ICE building glibc for arc

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

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

Bug ID: 113097
   Summary: [14 Regression] LRA ICE building glibc for arc
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: vmakarov at gcc dot gnu.org
  Target Milestone: ---
Target: arc*-*-*

Created attachment 56911
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56911&action=edit
preprocessed source

Compile the attached code, from glibc, with -O2 for arc-linux-gnu.

during RTL pass: reload
In file included from gconv_simple.c:587:
../iconv/skeleton.c: In function '__gconv_transform_ascii_internal':
../iconv/skeleton.c:663:1: internal compiler error: maximum number of LRA
assignment passes is achieved (30)
0xd2b202 lra_assign(bool&)
/scratch/jmyers/glibc/many14/src/gcc/gcc/lra-assigns.cc:1696
0xd25164 lra(_IO_FILE*, int)
/scratch/jmyers/glibc/many14/src/gcc/gcc/lra.cc:2493
0xcdb80f do_reload
/scratch/jmyers/glibc/many14/src/gcc/gcc/ira.cc:5973
0xcdb80f execute
/scratch/jmyers/glibc/many14/src/gcc/gcc/ira.cc:6161
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.

ICE introduced by

commit 989e67f827b74b76e58abe137ce12d948af2290c
Author: Vladimir N. Makarov 
Date:   Mon Dec 18 17:12:23 2023 -0500

[PR112918][LRA]: Fixing IRA ICE on m68k

Some GCC tests on m68K port of LRA is failed on `maximum number of
generated reload insns per insn achieved`.  The problem is in that for
subreg reload LRA can not narrow reg class more from ALL_REGS to
GENERAL_REGS and then to data regs or address regs.  The patch permits
narowing reg class from reload insns if this results in succesful
matching of reg operand.

[Bug fortran/113096] [F2023] Allow deferred-length character argument to ERRMSG= specifier

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

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

--- Comment #1 from anlauf at gcc dot gnu.org ---
A little further down in the standards document:

• Intrinsic procedures:
...
"When a deferred-length allocatable actual argument of an intrinsic procedure
is assigned character data, it is allocated by the processor to the length
of the data."

The new intrinsic TOKENIZE needs this.

[Bug fortran/113096] New: [F2023] Allow deferred-length character argument to ERRMSG= specifier

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

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

Bug ID: 113096
   Summary: [F2023] Allow deferred-length character argument to
ERRMSG= specifier
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anlauf at gcc dot gnu.org
  Target Milestone: ---

Fortran 2023 specifies the following enhancement over Fortran 2018:

"A deferred-length allocatable errmsg-variable is allocated by the processor
to the length of the explanatory message."

This needs to be handled by statements translated by the compiler (e.g.
ALLOCATE/DEALLOCATE), image control statements, and intrinsic subroutines
MOVE_ALLOC, GET_COMMAND, GET_COMMAND_ARGUMENT, and GET_ENVIRONMENT_VARIABLE
implemented in libgfortran.

[Bug target/113094] [14 Regression][aarch64] ICE in extract_constrain_insn, at recog.cc:2713 since r14-6290-g9f0f7d802482a8

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

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

--- Comment #3 from Andrew Pinski  ---
I suspect FIRST_PSEUDO_REGISTER should really have been LAST_VIRTUAL_REGISTER
in some places ...


VIRTUAL_REGISTERs are still psedudo registers but not used post
instantiate_virtual_regs pass.

[Bug target/113094] [14 Regression][aarch64] ICE in extract_constrain_insn, at recog.cc:2713 since r14-6290-g9f0f7d802482a8

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

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

--- Comment #2 from Andrew Pinski  ---
```
(insn 18 2 13 2 (set (reg:V4SI 63 v31)
(reg:V4SI 94 virtual-incoming-args)) "/app/example.cpp":8:25 -1
 (nil))
```

Gets added by early-ra ...

[Bug target/113094] [14 Regression][aarch64] ICE in extract_constrain_insn, at recog.cc:2713 since r14-6290-g9f0f7d802482a8

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-12-20
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files

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

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

--- Comment #21 from GCC Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r14-6758-gba615557a4c698d27042a5fe058ea6e721a03b12
Author: Rimvydas Jasinskas 
Date:   Wed Dec 20 03:39:33 2023 +

Fortran: Use non conflicting file extensions for intermediates [PR81615]

gcc/ChangeLog:

* doc/invoke.texi: Document the new file extensions

gcc/fortran/ChangeLog:

PR fortran/81615
* lang-specs.h (F951_CPP_OPTIONS): Do not hardcode ".f90" extension
(F951_CPP_EXTENSION): Use .fi/.fii for fixed/free form sources
* options.cc (form_from_filename): Handle the new extensions

Signed-off-by: Rimvydas Jasinskas 

[Bug c++/113063] Strange linker error in special case involving local class with defaulted spaceship operator and static assert

[kristian.spangsege at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Kristian Spangsege  ---
Thanks for fixing it. Should it be back-ported to earlier GCC versions? From my
point of view, as far back as GCC 11 would be nice.

[Bug rtl-optimization/111702] [14 Regression] ICE: in insert_regs, at cse.cc:1114 with -O2 -fstack-protector-all -frounding-math

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

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

Richard Sandiford  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
 CC||rsandifo at gcc dot gnu.org

--- Comment #5 from Richard Sandiford  ---
Fixed.

[Bug rtl-optimization/111702] [14 Regression] ICE: in insert_regs, at cse.cc:1114 with -O2 -fstack-protector-all -frounding-math

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

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

--- Comment #4 from GCC Commits  ---
The trunk branch has been updated by Richard Sandiford :

https://gcc.gnu.org/g:08ab2293dcce442e139b163ba22f65a32e7ebd6c

commit r14-6757-g08ab2293dcce442e139b163ba22f65a32e7ebd6c
Author: Richard Sandiford 
Date:   Wed Dec 20 19:07:35 2023 +

cse: Fix handling of fake vec_select sets [PR111702]

If cse sees:

  (set (reg R) (const_vector [A B ...]))

it creates fake sets of the form:

  (set R[0] A)
  (set R[1] B)
  ...

(with R[n] replaced by appropriate rtl) and then adds them to the tables
in the same way as for normal sets.  This allows a sequence like:

  (set (reg R2) A)
  ...(reg R2)...

to try to use R[0] instead of (reg R2).

But the pass was taking the analogy too far, and was trying to simplify
these fake sets based on costs.  That is, if there was an earlier:

  (set (reg T) A)

the pass would go to considerable effort trying to work out whether:

  (set R[0] A)

or:

  (set R[0] (reg T))

was more profitable.  This included running validate*_change on the sets,
which has no meaning given that the sets are not part of the insn.

In this example, the equivalence A == T is already known, and the
purpose of the fake sets is to add A == T == R[0].  We can do that
just as easily (or, as the PR shows, more easily) if we keep the
original form of the fake set, with A instead of T.

The problem in the PR occurred if we had:

(1) something that establishes an equivalence between a vector V1 of
M-bit scalar integers and a hard register H

(2) something that establishes an equivalence between a vector V2 of
N-bit scalar integers, where Nnext_same_value)
if (rtx_equal_p (elt->exp, x))
  return elt;

to insert_with_costs, or by making cse_insn check whether previous
sets have recorded the same equivalence.  The latter seems more
appealing from a compile-time perspective.  But in this case,
doing that would be adding yet more spurious work to the handling
of fake sets.

The handling of fake sets therefore seems like the more fundamental bug.

While there, the patch also makes sure that we don't apply REG_EQUAL
notes to these fake sets.  They only describe the "real" (first) set.

gcc/
PR rtl-optimization/111702
* cse.cc (set::mode): Move earlier.
(set::src_in_memory, set::src_volatile): Convert to bitfields.
(set::is_fake_set): New member variable.
(add_to_set): Add an is_fake_set parameter.
(find_sets_in_insn): Update calls accordingly.
(cse_insn): Do not apply REG_EQUAL notes to fake sets.  Do not
try to optimize them either, or validate changes to them.

gcc/testsuite/
PR rtl-optimization/111702
* gcc.dg/rtl/aarch64/pr111702.c: New test.

[Bug target/113095] RISC-V: movcc no longer used for coremark crc functions with -mtune=sifive-7-series

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

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

--- Comment #4 from Andrew Pinski  ---
Anyways this was introduced by r13-4459-g6508d5e5a1a8c0

[Bug target/113095] RISC-V: movcc no longer used for coremark crc functions with -mtune=sifive-7-series

[craig.topper at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Craig Topper  ---
Our FPGA data is showing this as a 5% regression. I'll try to check on an
Unmatched board to confirm.

[Bug target/113095] RISC-V: movcc no longer used for coremark crc functions with -mtune=sifive-7-series

[craig.topper at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Craig Topper  ---
The branch+mv macrofusion should execute together. The visible latency to other
instructions is 1 cycle.

The hardware can predicate most ALU instructions, not just mv. So even better
would be putting the xor after the branch instead of a mv.

[Bug target/113095] RISC-V: movcc no longer used for coremark crc functions with -mtune=sifive-7-series

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

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

--- Comment #1 from Andrew Pinski  ---
What is the cost of the movcc here? IIRC this is really dependent on the cost
model in the backend?

[Bug target/113095] New: RISC-V: movcc no longer used for coremark crc functions with -mtune=sifive-7-series

[craig.topper at gmail dot com via Gcc-bugs]

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

Bug ID: 113095
   Summary: RISC-V: movcc no longer used for coremark crc
functions with -mtune=sifive-7-series
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: craig.topper at gmail dot com
  Target Milestone: ---

In gcc 12, the crc functions in coremark used the "movcc" macrofusion pattern
of a branch over a single mv. In gcc 13, a longer branchless sequence is used.

https://godbolt.org/z/9xvcxo5Y9

[Bug c++/92407] Destruction of objects returned from functions skipped by goto

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

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

Jason Merrill  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
   Target Milestone|--- |11.5

--- Comment #12 from Jason Merrill  ---
Fixed for 11.5/12.4/13.3/14.

[Bug c++/92145] -Wdeprecated-copy false-positive when inheriting base assignment operators

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

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

Jason Merrill  changed:

   What|Removed |Added

   Target Milestone|--- |11.5
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #5 from Jason Merrill  ---
Fixed for 11.5/12.

[Bug c++/92145] -Wdeprecated-copy false-positive when inheriting base assignment operators

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

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

--- Comment #4 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Jason Merrill
:

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

commit r11-11163-gf59cfce8ba6612c063a8f55267dc2caee7e0d381
Author: Jason Merrill 
Date:   Fri Apr 23 16:41:35 2021 -0400

c++: -Wdeprecated-copy and using operator= [PR92145]

For the purpose of [depr.impldec] "if the class has a user-declared copy
assignment operator", an operator= brought in from a base class with
'using'
may be a copy-assignment operator, but it isn't a copy-assignment operator
for the derived class.

gcc/cp/ChangeLog:

PR c++/92145
* class.c (classtype_has_depr_implicit_copy): Check DECL_CONTEXT
of operator=.

gcc/testsuite/ChangeLog:

PR c++/92145
* g++.dg/cpp0x/depr-copy3.C: New test.

(cherry picked from commit 37846c42f1f5ac4d9ba190d49c4373673c89c8b5)

[Bug c++/92407] Destruction of objects returned from functions skipped by goto

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

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

--- Comment #11 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:32bd8a1053d25cbb15172294e59a81bc134658aa

commit r11-11162-g32bd8a1053d25cbb15172294e59a81bc134658aa
Author: Jason Merrill 
Date:   Sun Jun 4 12:00:55 2023 -0400

c++: NRV and goto [PR92407]

Here our named return value optimization was breaking the required
destructor when the goto takes 'a' out of scope.  A simple fix for the
release branches is to disable the optimization in the presence of backward
goto.

We could do better by disabling the optimization only if there is a
backward
goto across the variable declaration, but we don't track that, and in GCC
14
we instead make the goto work with NRV.

PR c++/92407

gcc/cp/ChangeLog:

* cp-tree.h (struct language_function): Add backward_goto.
* decl.c (check_goto): Set it.
* typeck.c (check_return_expr): Prevent NRV if set.

gcc/testsuite/ChangeLog:

* g++.dg/opt/nrv22.C: New test.

(cherry picked from commit a645347c19b07cc7abd7bf276c6769fc41afc932)

[Bug c++/33799] Return value's destructor not executed when a local variable's destructor throws

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

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

--- Comment #28 from GCC Commits  ---
The trunk branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:02c0b49798228d777610f898cd9d63ebec43656d

commit r14-6754-g02c0b49798228d777610f898cd9d63ebec43656d
Author: Jason Merrill 
Date:   Wed Dec 20 11:06:27 2023 -0500

c++: throwing dtor and empty try [PR113088]

maybe_splice_retval_cleanup assumed that the function body can't be empty
if
there's a throwing cleanup, but when I added cleanups to try blocks in
r12-6333-gb10e031458d541 I didn't adjust that assumption.

PR c++/113088
PR c++/33799

gcc/cp/ChangeLog:

* except.cc (maybe_splice_retval_cleanup): Handle an empty block.

gcc/testsuite/ChangeLog:

* g++.dg/eh/return2.C: New test.

[Bug c++/113088] [12/13/14 Regression] Segmentation fault with empty try/catch following try/catch with returns + noexcept destructor

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

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

--- Comment #2 from GCC Commits  ---
The trunk branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:02c0b49798228d777610f898cd9d63ebec43656d

commit r14-6754-g02c0b49798228d777610f898cd9d63ebec43656d
Author: Jason Merrill 
Date:   Wed Dec 20 11:06:27 2023 -0500

c++: throwing dtor and empty try [PR113088]

maybe_splice_retval_cleanup assumed that the function body can't be empty
if
there's a throwing cleanup, but when I added cleanups to try blocks in
r12-6333-gb10e031458d541 I didn't adjust that assumption.

PR c++/113088
PR c++/33799

gcc/cp/ChangeLog:

* except.cc (maybe_splice_retval_cleanup): Handle an empty block.

gcc/testsuite/ChangeLog:

* g++.dg/eh/return2.C: New test.

[Bug c++/103185] [11/12/13/14 Regression] ind[arr] is rejected when arr is an array prvalue

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

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

--- Comment #2 from GCC Commits  ---
The trunk branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:8dfc52a75d4d6c8be1c61b4aa831b1812b14a10e

commit r14-6753-g8dfc52a75d4d6c8be1c61b4aa831b1812b14a10e
Author: Jason Merrill 
Date:   Tue Dec 19 16:12:02 2023 -0500

c++: xvalue array subscript [PR103185]

Normally we handle xvalue array subscripting with ARRAY_REF, but in this
case we weren't doing that because the operands were reversed.  Handle that
case better.

PR c++/103185

gcc/cp/ChangeLog:

* typeck.cc (cp_build_array_ref): Handle swapped operands.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/array-prvalue2.C: New test.
* g++.dg/cpp1z/eval-order3.C: Test swapped operands.

[Bug c++/113083] [14 Regression][arm] ICE in fold_convert_loc, at fold-const.cc:2602 since r14-5979-g99d114c15523e0

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

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

--- Comment #3 from Marek Polacek  ---
The ICE can be reproduced with -O -fdeclone-ctor-dtor as well.

[Bug c++/105221] [11/12 Regression] gcc rejects true ? [](auto) noexcept {} : [](int) {} in C++17+ (works for C++14) since r7-4383-g51dc660315ef83dc

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

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   Target Milestone|11.5|13.0
 Resolution|--- |FIXED

--- Comment #9 from Jason Merrill  ---
Fixed in 13.  The fix seems a bit risky for backporting, but I'm open to it if
there's any interest.

[Bug target/112787] Codegen regression of large GCC vector extensions when enabling SVE

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Andre Simoes Dias Vieira
:

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

commit r14-6752-ga3ff76278efe006dc0b50249c8e5baf565bff56b
Author: Andre Vieira 
Date:   Wed Dec 20 16:41:52 2023 +

veclower: improve selection of vector mode when lowering [PR 112787]

This patch addresses the issue reported in PR target/112787 by improving
the
compute type selection.  We do this by not considering types with more
elements
than the type we are lowering since we'd reject such types anyway.

gcc/ChangeLog:

PR target/112787
* tree-vect-generic.cc (type_for_widest_vector_mode): Change
function to
use original vector type and check widest vector mode has at most
the
same number of elements.
(get_compute_type): Pass original vector type rather than the
element
type to type_for_widest_vector_mode and remove now obsolete check
for
the number of elements.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/pr112787.c: New test.

[Bug target/113094] [14 Regression][aarch64] ICE in extract_constrain_insn, at recog.cc:2713 since r14-6290-g9f0f7d802482a8

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug c++/112908] __reference_{converts,constructs}_from_temporary checks for move constructor when binding prvalue to reference of the same type

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

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

Marek Polacek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

[Bug c/113050] __atomic_* builtins should use -Wdiscarded-qualifiers instead of -Wincompatible-pointer-types

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

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

Florian Weimer  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #6 from Florian Weimer  ---
I do not plan to backport this change.

[Bug c/113050] __atomic_* builtins should use -Wdiscarded-qualifiers instead of -Wincompatible-pointer-types

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

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

--- Comment #5 from GCC Commits  ---
The trunk branch has been updated by Florian Weimer :

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

commit r14-6751-ga48dd581bf917fcd52fb9eab60943825ed96b6d4
Author: Florian Weimer 
Date:   Wed Dec 20 17:23:40 2023 +0100

c-family: Use -Wdiscarded-qualifiers for ignored qualifiers in __atomic_*

This matches other compiler diagnostics.  No test updates are needed
because c-c++-common/pr95378.c does not match a specific -W option.

Fixes commit d2384b7b24f8557b66f6958a05ea99ff4307e75c ("c-family:
check qualifiers of arguments to __atomic built-ins (PR 95378)").

gcc/c-family/

PR c/113050
* c-common.cc (get_atomic_generic_size): Use
OPT_Wdiscarded_qualifiers instead of
OPT_Wincompatible_pointer_types.

[Bug c++/83264] std::initializer_list with a single element selects the wrong overload

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

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

--- Comment #14 from Jason Merrill  ---
Pinged CWG again.

[Bug c++/41727] partial specialization of member template of instantiation doesn't work

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

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

Jason Merrill  changed:

   What|Removed |Added

   Assignee|jason at gcc dot gnu.org   |unassigned at gcc dot 
gnu.org
 Status|ASSIGNED|NEW

[Bug c++/112908] __reference_{converts,constructs}_from_temporary checks for move constructor when binding prvalue to reference of the same type

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

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

Patrick Palka  changed:

   What|Removed |Added

   Last reconfirmed||2023-12-20
  Alias||lwg3819
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka  ---
This seems to be https://cplusplus.github.io/LWG/issue3819

[Bug c++/113088] [12/13/14 Regression] Segmentation fault with empty try/catch following try/catch with returns + noexcept destructor

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

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

[Bug target/113093] [14 Regression][aarch64] ICE in rtl_verify_bb_insn, at cfgrtl.cc:2796 since r14-6605-gc0911c6b357ba9

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

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

--- Comment #2 from Alex Coplan  ---
Testing a patch.

[Bug ada/110398] [12/13/14 regression] internal error on call with parameter of predicated subtype

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   Target Milestone|12.4|13.3
 Resolution|--- |FIXED

--- Comment #8 from Eric Botcazou  ---
Fixed on mainline and 13 branch.

[Bug ada/110398] [12/13/14 regression] internal error on call with parameter of predicated subtype

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

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

--- Comment #7 from Eric Botcazou  ---
https://gcc.gnu.org/g:0251e5582b8f841681c183477db3b5055e8fab5a

commit r13-8171-g0251e5582b8f841681c183477db3b5055e8fab5a
Author: Eric Botcazou 
Date:   Thu Sep 28 15:53:36 2023 +0200

ada: Fix internal error on call with parameter of predicated subtype

The problem is that the predicated subtype does not inherit all the
required
attributes of a string subtype with a static predicate.

gcc/ada/
* sem_ch3.adb (Analyze_Subtype_Declaration): Remove a short-circuit
for subtypes without aspects when it comes to predicates.
* sem_util.adb (Inherit_Predicate_Flags): Deal with private
subtypes
whose full view is an Itype.

[Bug ada/110398] [12/13/14 regression] internal error on call with parameter of predicated subtype

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

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

--- Comment #6 from Eric Botcazou  ---
https://gcc.gnu.org/g:a3626f49d64c8b81aadae61ae4fad7d4d0f9d6b8

commit r14-6711-ga3626f49d64c8b81aadae61ae4fad7d4d0f9d6b8
Author: Eric Botcazou 
Date:   Thu Sep 28 15:53:36 2023 +0200

ada: Fix internal error on call with parameter of predicated subtype

The problem is that the predicated subtype does not inherit all the
required
attributes of a string subtype with a static predicate.

gcc/ada/

* sem_ch3.adb (Analyze_Subtype_Declaration): Remove a short-circuit
for subtypes without aspects when it comes to predicates.
* sem_util.adb (Inherit_Predicate_Flags): Deal with private
subtypes
whose full view is an Itype.

[Bug target/113094] New: [14 Regression][aarch64] ICE in extract_constrain_insn, at recog.cc:2713 since r14-6290-g9f0f7d802482a8

[mjires at suse dot cz via Gcc-bugs]

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

Bug ID: 113094
   Summary: [14 Regression][aarch64] ICE in
extract_constrain_insn, at recog.cc:2713 since
r14-6290-g9f0f7d802482a8
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mjires at suse dot cz
  Target Milestone: ---
Target: aarch64

Compiling reduced testcase c-c++-common/torture/vector-subscript-2.c results in
ICE since r14-6290-g9f0f7d802482a8.


$ cat vector-subscript-2.c
struct TV4 {
  __attribute__((vector_size(sizeof(int) * 4))) int v;
};
void modify() {
  struct TV4 __trans_tmp_1, temp;
  temp.v[0] = temp.v[3] = 0;
  __trans_tmp_1 = temp;
}


$ aarch64-linux-gnu-gcc vector-subscript-2.c -fno-tree-dse -Ofast
-fno-tree-coalesce-vars -fno-dce -fno-tree-dce
vector-subscript-2.c: In function ‘modify’:
vector-subscript-2.c:8:1: error: insn does not satisfy its constraints:
8 | }
  | ^
(insn 18 2 13 2 (set (reg:V4SI 63 v31)
(reg:V4SI 94 virtual-incoming-args)) "vector-subscript-2.c":6:25 1270
{*aarch64_simd_movv4si}
 (nil))
during RTL pass: reload
vector-subscript-2.c:8:1: internal compiler error: in extract_constrain_insn,
at recog.cc:2713
0x16e5964 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/mjires/git/GCC/master/gcc/rtl-error.cc:108
0x16e59c4 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/mjires/git/GCC/master/gcc/rtl-error.cc:118
0x1696240 extract_constrain_insn(rtx_insn*)
/home/mjires/git/GCC/master/gcc/recog.cc:2713
0x14d253b check_rtl
/home/mjires/git/GCC/master/gcc/lra.cc:2189
0x14d3019 lra(_IO_FILE*, int)
/home/mjires/git/GCC/master/gcc/lra.cc:2610
0x147b0f5 do_reload
/home/mjires/git/GCC/master/gcc/ira.cc:5973
0x147b592 execute
/home/mjires/git/GCC/master/gcc/ira.cc:6161
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.


$ aarch64-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=aarch64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/mjires/built/master/libexec/gcc/aarch64-linux-gnu/14.0.0/lto-wrapper
Target: aarch64-linux-gnu
Configured with: /home/mjires/git/GCC/master/configure
--prefix=/home/mjires/built/master --target=aarch64-linux-gnu
--disable-bootstrap --enable-languages=c,c++,fortran --disable-multilib
--disable-libsanitizer --enable-checking : (reconfigured)
/home/mjires/git/GCC/master/configure --prefix=/home/mjires/built/master
--target=aarch64-linux-gnu --disable-bootstrap --enable-languages=c,c++,fortran
--disable-multilib --disable-libsanitizer --enable-checking
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231220 (experimental) (GCC)

[Bug tree-optimization/113015] ICE: verify_ssa failed: definition in block 12 does not dominate use in block 13 at -O with _BitInt()

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Jakub Jelinek  ---
Fixed in another PR.

*** This bug has been marked as a duplicate of bug 112941 ***

[Bug tree-optimization/112941] during GIMPLE pass: bitintlower ICE: in handle_operand_addr, at gimple-lower-bitint.cc:2126 (gimple-lower-bitint.cc:2134) at -O with _BitInt()

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

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

--- Comment #9 from Jakub Jelinek  ---
*** Bug 113015 has been marked as a duplicate of this bug. ***

[Bug target/113093] [14 Regression][aarch64] ICE in rtl_verify_bb_insn, at cfgrtl.cc:2796 since r14-6605-gc0911c6b357ba9

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

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

Alex Coplan  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-12-20
   Assignee|unassigned at gcc dot gnu.org  |acoplan at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Alex Coplan  ---
Confirmed, I think the pass is missing logic to prevent moving throwing insns,
should be an easy fix.

[Bug target/113093] [14 Regression][aarch64] ICE in rtl_verify_bb_insn, at cfgrtl.cc:2796 since r14-6605-gc0911c6b357ba9

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug tree-optimization/112941] during GIMPLE pass: bitintlower ICE: in handle_operand_addr, at gimple-lower-bitint.cc:2126 (gimple-lower-bitint.cc:2134) at -O with _BitInt()

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|NEW |ASSIGNED

--- Comment #8 from Jakub Jelinek  ---
Created attachment 56910
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56910&action=edit
gcc14-pr112941-mul.patch

Patch to punt merging of nested casts in mul/div/mod/float operands.

[Bug target/113093] New: [14 Regression][aarch64] ICE in rtl_verify_bb_insn, at cfgrtl.cc:2796 since r14-6605-gc0911c6b357ba9

[mjires at suse dot cz via Gcc-bugs]

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

Bug ID: 113093
   Summary: [14 Regression][aarch64] ICE in rtl_verify_bb_insn, at
cfgrtl.cc:2796 since r14-6605-gc0911c6b357ba9
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mjires at suse dot cz
CC: acoplan at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

Compiling reduced testcase gcc.dg/compat/scalar-return-3_y.c results in ICE
since  r14-6605-gc0911c6b357ba9.

$ cat scalar-return-3_y.c
_Complex long *c;
void init() { *c = 1.0; }


$ aarch64-linux-gnu-gcc scalar-return-3_y.c -Os
-fharden-control-flow-redundancy -fnon-call-exceptions
scalar-return-3_y.c: In function ‘init’:
scalar-return-3_y.c:2:25: error: in basic block 2:
2 | void init() { *c = 1.0; }
  | ^
scalar-return-3_y.c:2:25: error: flow control insn inside a basic block
(insn 12 11 66 2 (set (mem:V2x8QI (reg/f:DI 100 [ c.0_1 ]) [0 +0 S16 A64])
(unspec:V2x8QI [
(reg:DI 109)
(const_int 0 [0])
] UNSPEC_STP)) "scalar-return-3_y.c":2:18 91 {*store_pair_8}
 (expr_list:REG_EH_REGION (const_int 1 [0x1])
(nil)))
during RTL pass: ldp_fusion
scalar-return-3_y.c:2:25: internal compiler error: in rtl_verify_bb_insns, at
cfgrtl.cc:2802
0x16e5db4 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/mjires/git/GCC/master/gcc/rtl-error.cc:108
0x105e9d6 rtl_verify_bb_insns
/home/mjires/git/GCC/master/gcc/cfgrtl.cc:2802
0x105ec9e rtl_verify_flow_info_1
/home/mjires/git/GCC/master/gcc/cfgrtl.cc:2889
0x105f3fd rtl_verify_flow_info
/home/mjires/git/GCC/master/gcc/cfgrtl.cc:3134
0x10448c2 verify_flow_info()
/home/mjires/git/GCC/master/gcc/cfghooks.cc:283
0x103b2fa checking_verify_flow_info()
/home/mjires/git/GCC/master/gcc/cfghooks.h:214
0x2956e01 try_optimize_cfg
/home/mjires/git/GCC/master/gcc/cfgcleanup.cc:2980
0x29572da cleanup_cfg(int)
/home/mjires/git/GCC/master/gcc/cfgcleanup.cc:3143
0x1e2bd7f ldp_fusion_destroy
   
/home/mjires/git/GCC/master/gcc/config/aarch64/aarch64-ldp-fusion.cc:2426
0x1e2cb02 ldp_fusion()
   
/home/mjires/git/GCC/master/gcc/config/aarch64/aarch64-ldp-fusion.cc:2650
0x1e2cbec execute
   
/home/mjires/git/GCC/master/gcc/config/aarch64/aarch64-ldp-fusion.cc:2698
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.


$ aarch64-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=aarch64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/mjires/built/master/libexec/gcc/aarch64-linux-gnu/14.0.0/lto-wrapper
Target: aarch64-linux-gnu
Configured with: /home/mjires/git/GCC/master/configure
--prefix=/home/mjires/built/master --target=aarch64-linux-gnu
--disable-bootstrap --enable-languages=c,c++,fortran --disable-multilib
--disable-libsanitizer --enable-checking : (reconfigured)
/home/mjires/git/GCC/master/configure --prefix=/home/mjires/built/master
--target=aarch64-linux-gnu --disable-bootstrap --enable-languages=c,c++,fortran
--disable-multilib --disable-libsanitizer --enable-checking
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231220 (experimental) (GCC)

[Bug tree-optimization/113091] Over-estimate SLP vector-to-scalar cost for non-live pattern statement

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
It's the logic

  FOR_EACH_VEC_ELT (SLP_TREE_SCALAR_STMTS (node), i, stmt_info)
{
  if (svisited.contains (stmt_info))
continue;
  stmt_vec_info orig_stmt_info = vect_orig_stmt (stmt_info);
  if (STMT_VINFO_IN_PATTERN_P (orig_stmt_info)
  && STMT_VINFO_RELATED_STMT (orig_stmt_info) != stmt_info)
/* Only the pattern root stmt computes the original scalar value.  */
continue;
  bool mark_visited = true;
  gimple *orig_stmt = orig_stmt_info->stmt;
  ssa_op_iter op_iter;
  def_operand_p def_p;
  FOR_EACH_PHI_OR_STMT_DEF (def_p, orig_stmt, op_iter, SSA_OP_DEF)
{
  imm_use_iterator use_iter;
  gimple *use_stmt;
  stmt_vec_info use_stmt_info;
  FOR_EACH_IMM_USE_STMT (use_stmt, use_iter, DEF_FROM_PTR (def_p))
if (!is_gimple_debug (use_stmt))
  {
use_stmt_info = bb_vinfo->lookup_stmt (use_stmt);
if (!use_stmt_info
|| !PURE_SLP_STMT (vect_stmt_to_vectorize (use_stmt_info)))
  {
STMT_VINFO_LIVE_P (stmt_info) = true;

specifically the last check.  That's supposed to pick up the "main" pattern
that's now covering the scalar stmt.

But somehow the "main" pattern,

patt_67 = .VEC_WIDEN_MINUS (_1, _3);  //  _5 = _2 - _4;
 patt_68 = (signed short) patt_67; //  _5 = _2 - _4;
 patt_69 = (int) patt_68;  //  _5 = _2 - _4;

doesn't get picked up here.  I wonder what's the orig_stmt and the def
picked and what original scalar use we end up in where the
vect_stmt_to_vectorize isn't the "last" pattern.  Maybe we really want
these "overlapping" patterns, but IMHO having "two entries" into
a chain of scalar stmts is bad and we should link up the whole matched
sequence to the final "root" instead?

That said, the current code doesn't see that wherever we end up isn't
dead code (aka fully covered by the vectorization).

IMO vect_stmt_to_vectorize for each of those stmts should end up at

patt_69 = (int) patt_68;

[Bug target/113089] [14 Regression][aarch64] ICE in process_uses_of_deleted_def, at rtl-ssa/changes.cc:252 since r14-6605-gc0911c6b357ba9

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

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

--- Comment #10 from Alex Coplan  ---
So we have this RTL going into ldp_fusion2:

  103: x16:DI=[x15:DI--]
  REG_INC x15:DI
  104: x16:SI=zero_extend([x16:DI])
  105: x16:SI=x11:SI-x16:SI
  106: x16:SI=x8:SI*x16:SI+x16:SI
 1117: {x26:DI=unspec[[x10:DI-0x30]] 39;x27:DI=unspec[[x10:DI-0x30]] 40;}
 1118: x27:SI=zero_extend([x27:DI])
 1119: x27:SI=x11:SI-x27:SI
 1048: x20:DI=[x10:DI-0x10]
  REG_EQUIV [x10:DI-0x10]
 1049: x20:SI=zero_extend([x20:DI])
 1050: x20:SI=x11:SI-x20:SI
 1367: debug D#22 => x15:DI
 1025: x15:DI=[x15:DI]

and we try to fuse (103,1025):

fusing pair [L=1] (103,1025), base=15, hazards: (104,103), move_range:
(103,103)
  ldp: i103 has wb but subsequent i1025 has non-wb update of base (r15),
dropping wb

but we fail to update the debug insn 1367 which has a use of the def of x15 in
i103 that we're deleting.

[Bug sanitizer/113092] New: SanitizerTool: CHECK failed: ubsan_value.cpp:69 "((getType().isSignedIntegerTy())) != (0)" (0x0, 0x0) with _BitInt()

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 113092
   Summary: SanitizerTool: CHECK failed: ubsan_value.cpp:69
"((getType().isSignedIntegerTy())) != (0)" (0x0, 0x0)
with _BitInt()
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 56909
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56909&action=edit
reduced testcase

Using UBsan with _BitInt() fails at runtime:
$ x86_64-pc-linux-gnu-gcc -fsanitize=undefined testcase.c
$ ./a.out 
SanitizerTool: CHECK failed: ubsan_value.cpp:69
"((getType().isSignedIntegerTy())) != (0)" (0x0, 0x0) (tid=9442)


$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-6742-20231220113252-gbe9e8de6284-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-6742-20231220113252-gbe9e8de6284-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231220 (experimental) (GCC)

[Bug target/113034] Miscompilation of __m128 ne comparison on LoongArch

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #7 from Xi Ruoyao  ---
Fixed.

[Bug target/113033] GCC 14 (20231203 snapshot) ICE when building LSX vector rotate code on LoongArch

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #11 from Xi Ruoyao  ---
ICE fixed.  Missed-optimization is
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640872.html.

[Bug target/113048] [13/14 Regression] ICE: in lra_split_hard_reg_for, at lra-assigns.cc:1862 (unable to find a register to spill) {*andndi3_doubleword_bmi} with -march=cascadelake

[manuel.lauss at googlemail dot com via Gcc-bugs]

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

Manuel Lauss  changed:

   What|Removed |Added

 CC||manuel.lauss at googlemail dot 
com

--- Comment #2 from Manuel Lauss  ---
I'm seeing similar ICE in xgcc when trying to build GCC-14 for MIPS32;
it goes away when I drop "-fPIC" or "-march=mips32":

/build/./gcc/xgcc -B/build/./gcc -march=mips32 -O2 -c wlocale-inst.ii  -fPIC

/build/mipsel-softfloat-linux-gnu/libstdc++-v3/include/bits/locale_facets.tcc:588:7:
error: unable to find a register to spill
  588 |   }
  |   ^
/build/mipsel-softfloat-linux-gnu/libstdc++-v3/include/bits/locale_facets.tcc:588:7:
error: this is the insn:
(insn 470 2008 2009 82 (parallel [
(set (reg:SI 908)
(plus:SI (mult:SI (reg:SI 567 [ __result+4 ])
(reg/v:SI 220 [ __base ]))
(reg:SI 909)))
(clobber (reg:SI 796 [762]))
(clobber (reg:SI 763))
])
"/build/mipsel-softfloat-linux-gnu/libstdc++-v3/include/bits/locale_facets.tcc":493:14
42 {*mul_acc_si}
 (expr_list:REG_UNUSED (reg:SI 763)
(expr_list:REG_UNUSED (reg:SI 796 [762])
(expr_list:REG_DEAD (reg:SI 909)
(expr_list:REG_DEAD (reg:SI 567 [ __result+4 ])
(nil))
during RTL pass: reload
/build/mipsel-softfloat-linux-gnu/libstdc++-v3/include/bits/locale_facets.tcc:588:7:
internal compiler error: in lra_split_hard_reg_for, at lra-assigns.cc:1862

[Bug target/113034] Miscompilation of __m128 ne comparison on LoongArch

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Xi Ruoyao :

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

commit r14-6745-gc5651e9bc057f08bad3297cc2fe3eafffa31c95e
Author: Xi Ruoyao 
Date:   Sun Dec 17 01:09:20 2023 +0800

LoongArch: Fix FP vector comparsons [PR113034]

We had the following mappings between vfcmp submenmonics and RTX
codes:

(define_code_attr fcc
  [(unordered "cun")
   (ordered   "cor")
   (eq   "ceq")
   (ne   "cne")
   (uneq  "cueq")
   (unle  "cule")
   (unlt  "cult")
   (le   "cle")
   (lt   "clt")])

This is inconsistent with scalar code:

(define_code_attr fcond [(unordered "cun")
 (uneq "cueq")
 (unlt "cult")
 (unle "cule")
 (eq "ceq")
 (lt "slt")
 (le "sle")
 (ordered "cor")
 (ltgt "sne")
 (ne "cune")
 (ge "sge")
 (gt "sgt")
 (unge "cuge")
 (ungt "cugt")])

For every RTX code for which the LSX/LASX code is different from the
scalar code, the scalar code is correct and the LSX/LASX code is wrong.
Most seriously, the RTX code NE should be mapped to "cneq", not "cne".
Rewrite vfcmp define_insns in simd.md using the same mapping as
scalar fcmp.

Note that GAS does not support [x]vfcmp.{c/s}[u]{ge/gt} (pseudo)
instruction (although fcmp.{c/s}[u]{ge/gt} is supported), so we need to
switch the order of inputs and use [x]vfcmp.{c/s}[u]{le/lt} instead.

The vfcmp.{sult/sule/clt/cle}.{s/d} instructions do not have a single
RTX code, but they can be modeled as an inversed RTX code following a
"not" operation.  Doing so allows the compiler to optimized vectorized
__builtin_isless etc. to a single instruction.  This optimization should
be added for scalar code too and I'll do it later.

Tests are added for mapping between C code, IEC 60559 operations, and
vfcmp instructions.

[1]:https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640713.html

gcc/ChangeLog:

PR target/113034
* config/loongarch/lasx.md (UNSPEC_LASX_XVFCMP_*): Remove.
(lasx_xvfcmp_caf_): Remove.
(lasx_xvfcmp_cune_): Remove.
(FSC256_UNS): Remove.
(fsc256): Remove.
(lasx_xvfcmp__): Remove.
(lasx_xvfcmp__): Remove.
* config/loongarch/lsx.md (UNSPEC_LSX_XVFCMP_*): Remove.
(lsx_vfcmp_caf_): Remove.
(lsx_vfcmp_cune_): Remove.
(vfcond): Remove.
(fcc): Remove.
(FSC_UNS): Remove.
(fsc): Remove.
(lsx_vfcmp__): Remove.
(lsx_vfcmp__): Remove.
* config/loongarch/simd.md
(fcond_simd): New define_code_iterator.
(_vfcmp__):
New define_insn.
(fcond_simd_rev): New define_code_iterator.
(fcond_rev_asm): New define_code_attr.
(_vfcmp__):
New define_insn.
(fcond_inv): New define_code_iterator.
(fcond_inv_rev): New define_code_iterator.
(fcond_inv_rev_asm): New define_code_attr.
(_vfcmp__): New define_insn.
(_vfcmp__):
New define_insn.
(UNSPEC_SIMD_FCMP_CAF, UNSPEC_SIMD_FCMP_SAF,
UNSPEC_SIMD_FCMP_SEQ, UNSPEC_SIMD_FCMP_SUN,
UNSPEC_SIMD_FCMP_SUEQ, UNSPEC_SIMD_FCMP_CNE,
UNSPEC_SIMD_FCMP_SOR, UNSPEC_SIMD_FCMP_SUNE): New unspecs.
(SIMD_FCMP): New define_int_iterator.
(fcond_unspec): New define_int_attr.
(_vfcmp__): New define_insn.
* config/loongarch/loongarch.cc (loongarch_expand_lsx_cmp):
Remove unneeded special cases.

gcc/testsuite/ChangeLog:

PR target/113034
* gcc.target/loongarch/vfcmp-f.c: New test.
* gcc.target/loongarch/vfcmp-d.c: New test.
* gcc.target/loongarch/xvfcmp-f.c: New test.
* gcc.target/loongarch/xvfcmp-d.c: New test.
* gcc.target/loongarch/vector/lasx/lasx-vcond-2.c: Scan for cune
instead of cne.
* gcc.target/loongarch/vector/lsx/lsx-vcond-2.c: Likewise.

[Bug target/113033] GCC 14 (20231203 snapshot) ICE when building LSX vector rotate code on LoongArch

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

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

--- Comment #10 from GCC Commits  ---
The master branch has been updated by Xi Ruoyao :

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

commit r14-6746-gc7eefea622e70bd63b0e00e896f67cf9ee9916bc
Author: Xi Ruoyao 
Date:   Tue Dec 19 04:48:03 2023 +0800

LoongArch: Use force_reg instead of gen_reg_rtx + emit_move_insn in
vec_init expander [PR113033]

Jakub says:

Then that seems like a bug in the loongarch vec_init pattern(s).
Those really don't have a predicate in any of the backends on the
input operand, so they need to force_reg it if it is something it
can't handle. I've looked e.g. at i386 vec_init and that is exactly
what it does, see the various tests + force_reg calls in
ix86_expand_vector_init*.

So replace gen_reg_rtx + emit_move_insn with force_reg to fix PR 113033.

gcc/ChangeLog:

PR target/113033
* config/loongarch/loongarch.cc
(loongarch_expand_vector_init_same): Replace gen_reg_rtx +
emit_move_insn with force_reg.
(loongarch_expand_vector_init): Likewise.

gcc/testsuite/ChangeLog:

PR target/113033
* gcc.target/loongarch/pr113033.c: New test.

[Bug target/113089] [14 Regression][aarch64] ICE in process_uses_of_deleted_def, at rtl-ssa/changes.cc:252 since r14-6605-gc0911c6b357ba9

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

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

--- Comment #9 from Alex Coplan  ---
(In reply to Manolis Tsamis from comment #8)
> (In reply to Alex Coplan from comment #7)
> > (In reply to Manolis Tsamis from comment #6)
> > > (In reply to Alex Coplan from comment #5)
> > > > Also ICEs without -fno-strict-aliasing FWIW, so just -g -O2 
> > > > -funroll-loops
> > > > seems to be enough.
> > > 
> > > On my local build it doesn't reproduce without -fno-strict-aliasing; I 
> > > just
> > > double-checked (GCC master @ 4e0a467302fea56d63b7a6d17f99c0f388960dc7).
> > 
> > Hmm, that is odd, I definitely don't need that option even when built from
> > the same commit.  How are you configuring GCC?  I suppose it doesn't matter
> > since I can reproduce the problem as long as the fix works with/without
> > -fno-strict-aliasing.
> 
> Odd indeed, but probably something with my configure flags as you mentioned.
> Here's what I use:
> 
> --enable-shared \
> --enable-threads=posix \
> --enable-checking=release \
> --with-system-zlib \
> --enable-__cxa_atexit \
> --disable-libunwind-exceptions \
> --enable-linker-build-id \
> --enable-libstdcxx-backtrace \
> --enable-plugin \
> --enable-initfini-array \
> --enable-gnu-indirect-function \
> --with-isl \
> --enable-lto \
> --with-cpu=neoverse-n1 \
> --disable-multilib \
> --disable-bootstrap
> 
> (I think the most uncommon one here is --with-cpu=neoverse-n1 ?)

Ah, that explains it.  I have a much more vanilla config, and indeed with
-mcpu=neoverse-n1 then it needs -fno-strict-aliasing to reproduce.

[Bug target/113089] [14 Regression][aarch64] ICE in process_uses_of_deleted_def, at rtl-ssa/changes.cc:252 since r14-6605-gc0911c6b357ba9

[manolis.tsamis at vrull dot eu via Gcc-bugs]

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

--- Comment #8 from Manolis Tsamis  ---
(In reply to Alex Coplan from comment #7)
> (In reply to Manolis Tsamis from comment #6)
> > (In reply to Alex Coplan from comment #5)
> > > Also ICEs without -fno-strict-aliasing FWIW, so just -g -O2 -funroll-loops
> > > seems to be enough.
> > 
> > On my local build it doesn't reproduce without -fno-strict-aliasing; I just
> > double-checked (GCC master @ 4e0a467302fea56d63b7a6d17f99c0f388960dc7).
> 
> Hmm, that is odd, I definitely don't need that option even when built from
> the same commit.  How are you configuring GCC?  I suppose it doesn't matter
> since I can reproduce the problem as long as the fix works with/without
> -fno-strict-aliasing.

Odd indeed, but probably something with my configure flags as you mentioned.
Here's what I use:

--enable-shared \
--enable-threads=posix \
--enable-checking=release \
--with-system-zlib \
--enable-__cxa_atexit \
--disable-libunwind-exceptions \
--enable-linker-build-id \
--enable-libstdcxx-backtrace \
--enable-plugin \
--enable-initfini-array \
--enable-gnu-indirect-function \
--with-isl \
--enable-lto \
--with-cpu=neoverse-n1 \
--disable-multilib \
--disable-bootstrap

(I think the most uncommon one here is --with-cpu=neoverse-n1 ?)

[Bug target/112962] [14 Regression] ICE: SIGSEGV in operator() (recog.h:431) with -fexceptions -mssse3 and __builtin_ia32_pabsd128()

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

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

--- Comment #19 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:96e0b513717e25405aee36851d5164aab0d0403a

commit r14-6743-g96e0b513717e25405aee36851d5164aab0d0403a
Author: Jakub Jelinek 
Date:   Wed Dec 20 12:01:57 2023 +0100

i386: Make most MD builtins nothrow, leaf [PR112962]

The following patch makes most of x86 MD builtins nothrow,leaf
(like most middle-end builtins are).  For -fnon-call-exceptions it
doesn't nothrow, better might be to still add it if the builtins
don't read or write memory and can't raise floating point exceptions,
but we don't have such information readily available, so the patch
uses just !flag_non_call_exceptions for now.
Not sure if we shouldn't have some exceptions for the leaf attribute,
e.g. wonder about EMMS/FEMMS and the various xsave/xrstor etc. builtins,
pedantically none of those builtins do anything that leaf functions
are forbidden to do (having callbacks, calling functions from current TU,
longjump into the current TU), but sometimes non-leaf is also used on
really complex functions to prevent some unwanted optimizations.
That said, haven't run into any problems as is with the patch.

2023-12-20  Jakub Jelinek  

PR target/112962
* config/i386/i386-builtins.cc (ix86_builtins): Increase by one
element.
(def_builtin): If not -fnon-call-exceptions, set TREE_NOTHROW on
the builtin FUNCTION_DECL.  Add leaf attribute to DECL_ATTRIBUTES.
(ix86_add_new_builtins): Likewise.

[Bug testsuite/113085] New test case libgomp.c/alloc-pinned-1.c from r14-6499-g348874f0baac0f fails

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

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

--- Comment #1 from Andrew Stubbs  ---
That is a typo.

I don't want to make it pass on machines that have insufficient memory
configured because it will mask the case where it fails for another reason.

However, the testcase was originally supposed to fit in 64kB. Is your page size
larger than 4kB?

[Bug target/113089] [14 Regression][aarch64] ICE in process_uses_of_deleted_def, at rtl-ssa/changes.cc:252 since r14-6605-gc0911c6b357ba9

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

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

--- Comment #7 from Alex Coplan  ---
(In reply to Manolis Tsamis from comment #6)
> (In reply to Alex Coplan from comment #5)
> > Also ICEs without -fno-strict-aliasing FWIW, so just -g -O2 -funroll-loops
> > seems to be enough.
> 
> On my local build it doesn't reproduce without -fno-strict-aliasing; I just
> double-checked (GCC master @ 4e0a467302fea56d63b7a6d17f99c0f388960dc7).

Hmm, that is odd, I definitely don't need that option even when built from the
same commit.  How are you configuring GCC?  I suppose it doesn't matter since I
can reproduce the problem as long as the fix works with/without
-fno-strict-aliasing.

[Bug target/113089] [14 Regression][aarch64] ICE in process_uses_of_deleted_def, at rtl-ssa/changes.cc:252 since r14-6605-gc0911c6b357ba9

[manolis.tsamis at vrull dot eu via Gcc-bugs]

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

--- Comment #6 from Manolis Tsamis  ---
(In reply to Alex Coplan from comment #5)
> Also ICEs without -fno-strict-aliasing FWIW, so just -g -O2 -funroll-loops
> seems to be enough.

On my local build it doesn't reproduce without -fno-strict-aliasing; I just
double-checked (GCC master @ 4e0a467302fea56d63b7a6d17f99c0f388960dc7).

[Bug target/113089] [14 Regression][aarch64] ICE in process_uses_of_deleted_def, at rtl-ssa/changes.cc:252 since r14-6605-gc0911c6b357ba9

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

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

--- Comment #5 from Alex Coplan  ---
Also ICEs without -fno-strict-aliasing FWIW, so just -g -O2 -funroll-loops
seems to be enough.

[Bug tree-optimization/112941] during GIMPLE pass: bitintlower ICE: in handle_operand_addr, at gimple-lower-bitint.cc:2126 (gimple-lower-bitint.cc:2134) at -O with _BitInt()

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r14-6742-gbe9e8de628471399ee5abb1e6ba7738139256b67
Author: Jakub Jelinek 
Date:   Wed Dec 20 11:32:52 2023 +0100

lower-bitint: Fix up handling of nested casts in mergeable stmt handling
[PR112941]

The following patch fixes 2 issues in handling of casts for mergeable
stmts.
The first hunk fixes the case when we have two nested casts (typically
after optimization that is zero-extension of a sign-extension because
everything else should have been folded into a single cast).  If
the lowering of the outer cast needs to make the code conditional
(e.g.
  for (...)
{
  if (idx <= 32)
{
  if (idx < 32)
{ ... handle_operand (idx); ... }
  else
{ ... handle_operand (32); ... }
}
  ...
}
) and the lowering of the inner one as well, right now it creates invalid
SSA form, because even for the inner cast we need a PHI on the loop
and the PHI argument from the latch edge is a SSA_NAME initialized in
the conditionally executed bb.  The hunk fixes that by detecting such
a case and adding further PHI nodes at the end of the ifs such that
the right value propagates to the next loop iteration.  We can use
0 arguments for the other edges because the inner operand handling
is only done for the first set of iterations and then the other ifs take
over.

The rest fixes a case of again invalid SSA form, when for a sign extension
we need to use the 0 or -1 value initialized by earlier iteration in
a constant idx case, the code was using the value of the loop PHI argument
from latch edge rather than result; that is correct for cases expanded
in straight line code after the loop, but not inside of the loop for the
cases of handle_cast conditionals, there we should use PHI result.  This
is done in the second hunk and supported by the remaining hunks, where
it clears m_bb to tell the code we aren't in the loop anymore.

Note, this patch doesn't deal with similar problems during multiplication,
division, floating casts etc. where we just emit a library call.  I'll
need to make sure in that case we don't merge more than one cast per
operand.

2023-12-20  Jakub Jelinek  

PR tree-optimization/112941
* gimple-lower-bitint.cc (bitint_large_huge::handle_cast): If
save_cast_conditional, instead of adding assignment of t4 to
m_data[save_data_cnt + 1] before m_gsi, add phi nodes such that
t4 propagates to m_bb loop.  For constant idx, use
m_data[save_data_cnt] rather than m_data[save_data_cnt + 1] if
inside
of the m_bb loop.
(bitint_large_huge::lower_mergeable_stmt): Clear m_bb when no
longer
expanding inside of that loop.
(bitint_large_huge::lower_comparison_stmt): Likewise.
(bitint_large_huge::lower_addsub_overflow): Likewise.
(bitint_large_huge::lower_mul_overflow): Likewise.
(bitint_large_huge::lower_bit_query): Likewise.

* gcc.dg/bitint-55.c: New test.

[Bug target/113089] [14 Regression][aarch64] ICE in process_uses_of_deleted_def, at rtl-ssa/changes.cc:252 since r14-6605-gc0911c6b357ba9

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

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

Alex Coplan  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |acoplan at gcc dot 
gnu.org
 Status|WAITING |ASSIGNED

--- Comment #4 from Alex Coplan  ---
Confirmed, thanks for the reduced testcase, I can take a look.

[Bug target/113089] [14 Regression][aarch64] ICE in process_uses_of_deleted_def, at rtl-ssa/changes.cc:252 since r14-6605-gc0911c6b357ba9

[manolis.tsamis at vrull dot eu via Gcc-bugs]

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

--- Comment #3 from Manolis Tsamis  ---
Created attachment 56908
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56908&action=edit
Reduced testcase

[Bug target/113089] [14 Regression][aarch64] ICE in process_uses_of_deleted_def, at rtl-ssa/changes.cc:252 since r14-6605-gc0911c6b357ba9

[manolis.tsamis at vrull dot eu via Gcc-bugs]

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

Manolis Tsamis  changed:

   What|Removed |Added

 CC||manolis.tsamis at vrull dot eu

--- Comment #2 from Manolis Tsamis  ---
The following testcase, reduced from x264 intrapred_chroma_plane:

typedef unsigned short uint16;

void intrapred_chroma_plane(uint16 ***mb_preds, int* max_imgpel_values, int
crx, int cry, int px) {
  for (int uv = 0; uv < 2; uv++) {
uint16 **mb_pred = mb_preds[uv + 1];
uint16 **predU2 = &mb_pred[px - 2];
uint16 *upPred = &mb_pred[px][px];
int max_imgpel_value = max_imgpel_values[uv];

int ih = upPred[crx - 1];
for (int i = 0; i < crx*3; ++i)
  ih += upPred[crx*3];

int iv = (mb_pred[cry - 1][px+1]);  
for (int i = 0; i < cry - 1; ++i) {
  iv += (i + 1) * (*(mb_preds[uv][0]) - *(*predU2--));
}

for (int j = 0; j < cry; ++j)
  for (int i = 0; i < crx; ++i)
mb_pred[j][i] = (uint16) (max_imgpel_value * ((i * ih + iv)));
  }
}

reproduces the same ICE issue when compiled with:

gcc -g -O2 -funroll-loops -fno-strict-aliasing intra_chroma_pred.c

[Bug ada/113037] assertion failure on illegal use of aspect Type_Invariant

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

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org
Summary|GNAT BUG DETECTED when  |assertion failure on
   |instantiating generic   |illegal use of aspect
   |package with Type_Invariant |Type_Invariant
   |on a type derived from a|
   |generic type|
   Last reconfirmed||2023-12-20
   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
This looks illegal though:

"7.3.2 Type Invariants
1/5
{AI05-0146-1} {AI12-0041-1} {AI12-0396-1} For a private type, or private
extension, or interface, the following language-defined assertion aspects may
be specified with an aspect_specification (see 13.1.1):
2/3
{AI05-0146-1} {AI05-0250-1} Type_Invariant

This aspect shall be specified by an expression, called an invariant
expression. Type_Invariant may be specified on a private_type_declaration, on a
private_extension_declaration, or on a full_type_declaration that declares the
completion of a private type or private extension."

but

   type Positive_Number is new Number
 with Type_Invariant => Number (Positive_Number) > Zero;

is a full_type_declaration that declares a derived type.