[Bug target/112598] RISC-V regression testsuite errors with rv64gcv_zvl512b

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

  Attachment #56700|0   |1
is obsolete||

--- Comment #18 from Patrick O'Neill  ---
Created attachment 56794
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56794=edit
rv64gcv_zvl512b testsuite failures 2023-12-03

Tested with hash 806789e6daa39ab0503d91c71b3faeb5d5cdd317
CI run:
https://github.com/patrick-rivos/gcc-postcommit-ci/actions/runs/7077949347

Comparison with zvl128b (pr112583):

Resolved failures (present on zvl128b but not zvl512b):
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++14  scan-tree-dump optimized
"return 15;"
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++17  scan-tree-dump optimized
"return 15;"
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++20  scan-tree-dump optimized
"return 15;"
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++98  scan-tree-dump optimized
"return 15;"
XPASS: gcc.dg/tree-ssa/pr84512.c scan-tree-dump optimized "return 285;"

New failures (present on zvl512b but not zvl128b):
FAIL: gfortran.dg/matmul_1.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/matmul_1.f90   -O3 -g  execution test
FAIL: gfortran.dg/proc_ptr_comp_12.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/proc_ptr_comp_12.f90   -O3 -g  execution test
FAIL: gcc.c-torture/compile/20090907-1.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal compiler
error: in partial_subreg_p, at rtl.h:3187)
FAIL: gcc.c-torture/compile/20090907-1.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
FAIL: gcc.dg/no-strict-overflow-6.c scan-tree-dump optimized "return 0"
FAIL: gcc.dg/pr30957-1.c execution test
FAIL: gcc.dg/pr30957-1.c scan-rtl-dump loop2_unroll "Expanding Accumulator"
FAIL: gcc.dg/tree-ssa/ivopts-lt-2.c scan-tree-dump-times ivopts "PHI  i" 2
FAIL: gcc.dg/torture/pr58955-2.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gcc.dg/tree-prof/time-profiler-3.c scan-ipa-dump-times profile "Read
tp_first_run: 0" 1
FAIL: gcc.dg/tree-prof/time-profiler-3.c scan-ipa-dump-times profile "Read
tp_first_run: 2" 1


New failures:
FAIL: gcc.target/riscv/rvv/autovec/pr112552.c -O3 -ftree-vectorize (test for
excess errors)

This new failure is also seen on pr112583 - looks like a simple issue.

[Bug middle-end/112830] internal compiler error: in convert_memory_address_addr_space_1, at explow.cc:302

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

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

--- Comment #9 from Georg-Johann Lay  ---
(In reply to Richard Biener from comment #8)
> Is there a valid testcase that has __memx as the destination?  Or is there
> an address space with similar constraints that allows non-const accesses?

No.  The avr backend throws an error when a non-generic address space thing is
not const, like

__memx int var;

int f1 (__memx int *p)
{
return *p;
}

foo.c:1:12: error: variable 'var' must be const in order to be put into
read-only section by means of '__memx'
1 | __memx int var;
  |^~~
foo.c:3:21: error: pointer targeting address space '__memx' must be const in
function parameter 'p'
3 | int f1 (__memx int *p)
  | ^

__memx covers all address spacec, including generic.  But in order to write one
has to cast it to a generic pointer (after checking that it actually points to
generic and not somewhere else (flash)).

(In reply to Richard Biener from comment #3)
> I think the assert can be relaxed to make truncation OK.

A truncation from 24-bit __memx address to some other AS (all 16 bits) would
require a run-time check which 16-bit AS it encodes, and depending on that
execute code fit for that AS.

This is ok when the user is doing it, but the compiler should never require any
kind of truncation.  And extension / casts are handled by
TARGET_ADDR_SPACE_CONVERT.

[Bug target/112597] RISC-V regression testsuite errors with rv64gcv_zvl256b

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

  Attachment #56699|0   |1
is obsolete||

--- Comment #11 from Patrick O'Neill  ---
Created attachment 56793
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56793=edit
rv64gcv_zvl256b testsuite failures 2023-12-03

Tested with hash 806789e6daa39ab0503d91c71b3faeb5d5cdd317
CI run:
https://github.com/patrick-rivos/gcc-postcommit-ci/actions/runs/7077949347

Comparison with zvl128b (pr112583):

Resolved failures (present on zvl128b but not zvl256b):
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++14  scan-tree-dump optimized
"return 15;"
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++17  scan-tree-dump optimized
"return 15;"
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++20  scan-tree-dump optimized
"return 15;"
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++98  scan-tree-dump optimized
"return 15;"

New failures (present on zvl256b but not zvl128b):
FAIL: gfortran.dg/matmul_1.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/matmul_1.f90   -O3 -g  execution test
FAIL: gcc.dg/pr30957-1.c execution test
FAIL: gcc.dg/pr30957-1.c scan-rtl-dump loop2_unroll "Expanding Accumulator"
FAIL: gcc.dg/tree-ssa/ivopts-lt-2.c scan-tree-dump-times ivopts "PHI  i" 2
FAIL: gcc.dg/tree-prof/time-profiler-3.c scan-ipa-dump-times profile "Read
tp_first_run: 0" 1
FAIL: gcc.dg/tree-prof/time-profiler-3.c scan-ipa-dump-times profile "Read
tp_first_run: 2" 1

New failures:
FAIL: gcc.target/riscv/rvv/autovec/pr112552.c -O3 -ftree-vectorize (test for
excess errors)

This new failure is also seen on pr112583 - looks like a simple issue.

[Bug c/107016] [meta-bug] tracker bug for supporting "sparse" attributes in GCC

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

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

David Malcolm  changed:

   What|Removed |Added

 Blocks|106358  |

--- Comment #2 from David Malcolm  ---
I'm no longer looking at this for my -fanalyzer work; removing from
analyzer-linux tracker (PR 106358).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106358
[Bug 106358] [meta-bug] tracker bug for building the Linux kernel with
-fanalyzer

[Bug tree-optimization/112856] [14 regression] ICE when building clustal-omega in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:647

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-12-05
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |14.0
 Status|UNCONFIRMED |ASSIGNED

--- Comment #3 from Richard Biener  ---
Testing patch.

[Bug target/112858] New: nvptx: 'unresolved symbol __cxa_thread_atexit_impl'

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

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

Bug ID: 112858
   Summary: nvptx: 'unresolved symbol __cxa_thread_atexit_impl'
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: vries at gcc dot gnu.org
  Target Milestone: ---

With commit r14-6082-gf4dd9416843308d4ae519983415fe62212662536 "libsupc++: try
cxa_thread_atexit_impl at runtime", there's one regression in nvptx target
testing (only visible on top of my WIP C++ enablement changes):

[-PASS:-]{+FAIL:+} g++.dg/tls/thread_local6.C  -std=c++14 (test for excess
errors)
[-PASS:-]{+UNRESOLVED:+} g++.dg/tls/thread_local6.C  -std=c++14 [-execution
test-]{+compilation failed to produce executable+}
[-PASS:-]{+FAIL:+} g++.dg/tls/thread_local6.C  -std=c++17 (test for excess
errors)
[-PASS:-]{+UNRESOLVED:+} g++.dg/tls/thread_local6.C  -std=c++17 [-execution
test-]{+compilation failed to produce executable+}
[-PASS:-]{+FAIL:+} g++.dg/tls/thread_local6.C  -std=c++20 (test for excess
errors)
[-PASS:-]{+UNRESOLVED:+} g++.dg/tls/thread_local6.C  -std=c++20 [-execution
test-]{+compilation failed to produce executable+}
UNSUPPORTED: g++.dg/tls/thread_local6.C  -std=c++98

unresolved symbol __cxa_thread_atexit_impl
collect2: error: ld returned 1 exit status

Very likely, this isn't an issue with that commit, but rather due to GCC/nvptx'
deficient implementation of weak symbols.

[Bug tree-optimization/112857] Missing optimzation: fold (b + ~a) > 0 to a - b ＜ -1

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

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

--- Comment #2 from Richard Biener  ---
careful about overflow.  Also note compares against zero might be cheaper (but
that's eventually an RTL expansion thing).

[Bug target/112583] RISC-V regression testsuite errors with rv64gcv_zvl128b

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

  Attachment #56698|0   |1
is obsolete||

--- Comment #13 from Patrick O'Neill  ---
Created attachment 56792
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56792=edit
rv32gcv_zvl128b testsuite failures 2023-12-03

Tested with hash 806789e6daa39ab0503d91c71b3faeb5d5cdd317
CI run:
https://github.com/patrick-rivos/gcc-postcommit-ci/actions/runs/7077949347

Resolved failures (improved from 9866c98e1015d98b8fc346d7cf73a0070cce5f69)
FAIL: g++.dg/contracts/contracts-tmpl-spec2.C   output pattern test
XPASS: gcc.dg/uninit-pred-9_b.c bogus warning (test for bogus messages, line
20)
FAIL: gcc.dg/vla-1.c scan-tree-dump-times optimized " s=> i" 2
FAIL: gcc.dg/tree-prof/time-profiler-3.c scan-ipa-dump-times profile "Read
tp_first_run: 0" 1
FAIL: gcc.dg/tree-prof/time-profiler-3.c scan-ipa-dump-times profile "Read
tp_first_run: 2" 1

New failures (regression from 9866c98e1015d98b8fc346d7cf73a0070cce5f69)
FAIL: gcc.target/riscv/rvv/autovec/pr112552.c -O3 -ftree-vectorize (test for
excess errors)

Debug log for new failure:
Executing on host:
/github/patrick-postcommit-runner-2/_work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/build/build-gcc-linux-stage2/gcc/xgcc
-B/github/patrick-postcommit-runner-2/_work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/build/build-gcc-linux-stage2/gcc/

/github/patrick-postcommit-runner-2/_work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/gcc/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr112552.c
 -march=rv64gcv_zvl128b -mabi=lp64d -mcmodel=medlow  
-fdiagnostics-plain-output  -O3 -ftree-vectorize -O3 -march=rv64gcv -mabi=lp64d
--param=riscv-autovec-preference=fixed-vlmax -w -S   -o pr112552.s(timeout
= 600)
spawn -ignore SIGHUP
/github/patrick-postcommit-runner-2/_work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/build/build-gcc-linux-stage2/gcc/xgcc
-B/github/patrick-postcommit-runner-2/_work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/build/build-gcc-linux-stage2/gcc/
/github/patrick-postcommit-runner-2/_work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/gcc/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr112552.c
-march=rv64gcv_zvl128b -mabi=lp64d -mcmodel=medlow -fdiagnostics-plain-output
-O3 -ftree-vectorize -O3 -march=rv64gcv -mabi=lp64d
--param=riscv-autovec-preference=fixed-vlmax -w -S -o pr112552.s
/github/patrick-postcommit-runner-2/_work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/gcc/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr112552.c:
In function 'h':
/github/patrick-postcommit-runner-2/_work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/gcc/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr112552.c:11:15:
error: initialization of 'char *' from incompatible pointer type 'void (*)()'
[-Wincompatible-pointer-types]
compiler exited with status 1
FAIL: gcc.target/riscv/rvv/autovec/pr112552.c -O3 -ftree-vectorize (test for
excess errors)
Excess errors:
/github/patrick-postcommit-runner-2/_work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/gcc/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr112552.c:11:15:
error: initialization of 'char *' from incompatible pointer type 'void (*)()'
[-Wincompatible-pointer-types]

This new failure just looks like fallout from:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=9715c545d33b3a32ddc1ae817ba9356ade1fb9df

[Bug target/112853] RISC-V: RVV: SPEC2017 525.x264 regression

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

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

--- Comment #4 from JuzheZhong  ---
Could you give me a test ?

[Bug target/112583] RISC-V regression testsuite errors with rv64gcv_zvl128b

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

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

--- Comment #14 from Robin Dapp  ---
Yes, that's the culprit.  I already pushed a fix yesterday.

[Bug debug/112849] New: btf: wrong BTF_KIND_DATSEC entries for extern variables without known section

[david.faust at oracle dot com via Gcc-bugs]

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

Bug ID: 112849
   Summary: btf: wrong BTF_KIND_DATSEC entries for extern
variables without known section
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: btf-debug, wrong-debug
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.faust at oracle dot com
CC: cupertino.miranda at oracle dot com, ibhagat at gcc dot 
gnu.org,
jemarch at gcc dot gnu.org
  Target Milestone: ---

When building bpf-next selftests with gcc trunk, we get the following
error from libbpf:

libbpf: linker: adding object file 'linked_vars1.bpf.o'...
libbpf: linker: adding object file 'linked_vars2.bpf.o'...
libbpf: global 'input_data1': section mismatch 4 vs 5
Error: failed to link 'linked_vars2.bpf.o': Invalid argument (22)

Here libbpf is doing some form of linking of the two objects.
'input_data1' is declared and initialized in linked_vars1, and
placed in .data. In linked_vars2 it is declared extern, however
an entry for it is added in the .bss BTF_KIND_DATASEC record in
linked_vars2.bpf.o.

clang does not emit entries in BTF_KIND_DATASEC for extern variable
decls without an explicit section e.g. via __attribute__((section(...))).

gcc
[7237] DATASEC '.bss' size=0 vlen=8
type_id=7059 offset=0 size=4 (VAR 'input_data1')  <-
type_id=7167 offset=0 size=4 (VAR 'input_bss1')   <-
type_id=7100 offset=0 size=4 (VAR 'output_sink2')
type_id=7111 offset=0 size=4 (VAR 'output_rodata2')
type_id=7065 offset=0 size=4 (VAR 'output_data2')
type_id=7090 offset=0 size=4 (VAR 'output_bss2')
type_id=7079 offset=0 size=4 (VAR 'input_bss_weak')
type_id=7192 offset=0 size=4 (VAR 'input_bss2')

clang
[34] DATASEC '.bss' size=0 vlen=6
type_id=18 offset=0 size=4 (VAR 'input_bss2')
type_id=19 offset=0 size=4 (VAR 'input_bss_weak')
type_id=20 offset=0 size=4 (VAR 'output_bss2')
type_id=21 offset=0 size=4 (VAR 'output_data2')
type_id=22 offset=0 size=4 (VAR 'output_rodata2')
type_id=23 offset=0 size=4 (VAR 'output_sink2')


The problem is that when creating the BTF_KIND_DATASEC entires,
gcc is incorrectly falling back to a default section name (like .bss)
for variables, even if they are 'extern' decls. 

gcc should be changed to not emit entries in any BTF_KIND_DATASEC
for extern variable decls without a known section.

[Bug debug/112849] btf: wrong BTF_KIND_DATSEC entries for extern variables without known section

[david.faust at oracle dot com via Gcc-bugs]

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

--- Comment #1 from David Faust  ---
Simple reproducer. Note how clang does not emit an entry
in BTF_KIND_DATASEC for 'extern int a'.

$ cat a.c
extern int a;
int b;

int foo (void)
{
  return a + b;
}

$ ~/toolchains/bpf/bin/bpf-unknown-none-gcc -gbtf -c a.c -o a.o
$ /usr/sbin/bpftool btf dump file a.o
[1] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
[2] FUNC_PROTO '(anon)' ret_type_id=1 vlen=0
[3] VAR 'a' type_id=1, linkage=extern
[4] VAR 'b' type_id=1, linkage=global
[5] FUNC 'foo' type_id=2 linkage=global
[6] DATASEC '.bss' size=0 vlen=2
type_id=3 offset=0 size=4 (VAR 'a')
type_id=4 offset=0 size=4 (VAR 'b')

$ ~/toolchains/llvm/bin/clang -target bpf -c -g a.c -o a.o
$ /usr/sbin/bpftool btf dump file a.o
[1] FUNC_PROTO '(anon)' ret_type_id=2 vlen=0
[2] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
[3] FUNC 'foo' type_id=1 linkage=global
[4] VAR 'a' type_id=2, linkage=extern
[5] VAR 'b' type_id=2, linkage=global
[6] DATASEC '.bss' size=0 vlen=1
type_id=5 offset=0 size=4 (VAR 'b')

[Bug c++/107687] [C++23] P2564 - consteval needs to propagate up

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

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

Bug 110997 Summary: [13/14 Regression] internal compiler error: in 
cxx_eval_constant_expression, at cp/constexpr.cc:8005
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110997

   What|Removed |Added

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

[Bug fortran/100988] Missed optimization: RESTRICT missing for optional arguments

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org

--- Comment #3 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2023-December/059985.html

[Bug target/112757] RISC-V regression testsuite errors with rv32gcv_zvl1024b

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

  Attachment #56713|0   |1
is obsolete||

--- Comment #2 from Patrick O'Neill  ---
Created attachment 56799
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56799=edit
rv32gcv_zvl1024b testsuite failures 2023-12-04

Tested with hash 0c2ea80a4ffbddc0bc29f5badaf2ae43e59483b2
CI run:
https://github.com/patrick-rivos/gcc-postcommit-ci/actions/runs/7089317318

Comparison with zvl128b (pr112754):

Resolved failures (present on zvl128b but not zvl1024b):
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++14  scan-tree-dump optimized
"return 15;"
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++17  scan-tree-dump optimized
"return 15;"
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++20  scan-tree-dump optimized
"return 15;"
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++98  scan-tree-dump optimized
"return 15;"
XPASS: gcc.dg/tree-ssa/pr84512.c scan-tree-dump optimized "return 285;"
XPASS: gcc.dg/vect/slp-reduc-11.c -flto -ffat-lto-objects  scan-tree-dump vect
"vectorizing stmts using SLP"
XPASS: gcc.dg/vect/slp-reduc-11.c scan-tree-dump vect "vectorizing stmts using
SLP"

New failures (present on zvl1024b but not zvl128b):
FAIL: gfortran.dg/array_constructor_12.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/array_constructor_12.f90   -O3 -g  execution test
FAIL: gcc.dg/no-strict-overflow-6.c scan-tree-dump optimized "return 0"
FAIL: gcc.dg/pr30957-1.c execution test
FAIL: gcc.dg/pr30957-1.c scan-rtl-dump loop2_unroll "Expanding Accumulator"
FAIL: gcc.dg/pr53265.c (test for excess errors)
FAIL: gcc.dg/torture/pr109219.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error: in
partial_subreg_p, at rtl.h:3187)
FAIL: gcc.dg/torture/pr109219.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gcc.dg/tree-ssa/ivopts-lt-2.c scan-tree-dump-times ivopts "PHI "
FAIL: gcc.dg/tree-ssa/ssa-sink-16.c (internal compiler error: verify_gimple
failed)
FAIL: gcc.dg/tree-ssa/ssa-sink-16.c (test for excess errors)
FAIL: gcc.target/riscv/rvv/autovec/pr112552.c -O3 -ftree-vectorize (test for
excess errors)


All new failures are also seen on zvl128b: pr112754

[Bug c++/55004] [meta-bug] constexpr issues

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

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

Bug 110997 Summary: [13/14 Regression] internal compiler error: in 
cxx_eval_constant_expression, at cp/constexpr.cc:8005
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110997

   What|Removed |Added

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

[Bug c++/110997] [13/14 Regression] internal compiler error: in cxx_eval_constant_expression, at cp/constexpr.cc:8005

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed.

[Bug target/89270] [11/12/13 regression] AVR ICE: verify_gimple failed

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

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org
  Known to work||14.0
 Status|ASSIGNED|NEW
Summary|[11/12/13/14 regression]|[11/12/13 regression] AVR
   |AVR ICE: verify_gimple  |ICE: verify_gimple failed
   |failed  |
  Component|c   |target

--- Comment #14 from Richard Biener  ---
Fixed on trunk sofar.  Joseph correctly mentioned that iff AVR would define
__int24 using INT_N in avr-modes.def the issue would have been mitigated as
well
(that's a comparatively "modern" way of registering additional integer types).

So it's really also a target issue.

I'm not planning to backport this frontend change given a more targeted fix
would be available.

[Bug c/89270] [11/12/13/14 regression] AVR ICE: verify_gimple failed

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

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

--- Comment #13 from GCC Commits  ---
The master branch has been updated by Richard Biener :

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

commit r14-6134-g4dd02d62abd76a69f65d9f3fed6febeed53fc90a
Author: Richard Biener 
Date:   Mon Dec 4 14:03:37 2023 +0100

c/89270 - honor registered_builtin_types in type_for_size

The following fixes the intermediate conversions inserted by
convert_to_integer when facing address-spaces and converts
to their effective [u]intptr_t when they are registered_builtin_types
by considering those also from c_common_type_for_size and not
only from c_common_type_for_mode.

PR c/89270
gcc/c-family/
* c-common.cc (c_common_type_for_size): Consider
registered_builtin_types.

gcc/testsuite/
* gcc.target/avr/pr89270.c: New testcase.

[Bug target/112852] [14 Regression] RISCV ICE: vsetvl pass: in partial_subreg_p, at rtl.h:3187 on rv64gcv_zvl512b

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

 Target||riscv
   Keywords||ice-on-valid-code
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=112851
 CC||juzhe.zhong at rivai dot ai,
   ||patrick at rivosinc dot com,
   ||rdapp at gcc dot gnu.org

--- Comment #1 from Patrick O'Neill  ---
Looks related to pr112851.

[Bug target/112852] New: [14 Regression] RISCV ICE: vsetvl pass: in partial_subreg_p, at rtl.h:3187 on rv64gcv_zvl512b

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 112852
   Summary: [14 Regression] RISCV ICE: vsetvl pass: in
partial_subreg_p, at rtl.h:3187 on rv64gcv_zvl512b
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Created attachment 56801
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56801=edit
-freport-bug output

Only seen on rv64gcv_zvl512b:
pr112598

FAIL: gcc.c-torture/compile/20090907-1.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal compiler
error: in partial_subreg_p, at rtl.h:3187)

Command:
> /scratch/tc-testing/tc-dec-4-trunk/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc
>  -march=rv64gcv_zvl512b -mabi=lp64d -O3 20090907-1.c -ftracer -funroll-loops 
> -freport-bug
during RTL pass: vsetvl
20090907-1.c: In function 'metronomefb_probe':
20090907-1.c:84:1: internal compiler error: in partial_subreg_p, at rtl.h:3187
   84 | }
  | ^
0xb3a42b partial_subreg_p(machine_mode, machine_mode)
../../../gcc/gcc/rtl.h:3187
0xb3a42b partial_subreg_p(machine_mode, machine_mode)
../../../gcc/gcc/rtl.h:3181
0xb3a42b
rtl_ssa::function_info::record_use(rtl_ssa::function_info::build_info&,
rtl_ssa::insn_info*, rtx_obj_reference)
../../../gcc/gcc/rtl-ssa/insns.cc:524
0x23ee521
rtl_ssa::function_info::add_insn_to_block(rtl_ssa::function_info::build_info&,
rtx_insn*)
../../../gcc/gcc/rtl-ssa/insns.cc:662
0x2a0876d
rtl_ssa::function_info::add_block_contents(rtl_ssa::function_info::build_info&)
../../../gcc/gcc/rtl-ssa/blocks.cc:948
0x2a08e8a
rtl_ssa::function_info::start_block(rtl_ssa::function_info::build_info&,
rtl_ssa::bb_info*)
../../../gcc/gcc/rtl-ssa/blocks.cc:1064
0x2a08f1c
rtl_ssa::function_info::bb_walker::before_dom_children(basic_block_def*)
../../../gcc/gcc/rtl-ssa/blocks.cc:117
0x225c207 dom_walker::walk(basic_block_def*)
../../../gcc/gcc/domwalk.cc:311
0x2a0a5c9 rtl_ssa::function_info::process_all_blocks()
../../../gcc/gcc/rtl-ssa/blocks.cc:1281
0x23ebb68 rtl_ssa::function_info::function_info(function*)
../../../gcc/gcc/rtl-ssa/functions.cc:50
0x1734d12 pre_vsetvl::pre_vsetvl()
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:2218
0x1733527 pass_vsetvl::lazy_vsetvl()
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:3454
0x173391f pass_vsetvl::execute(function*)
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:3518
0x173391f pass_vsetvl::execute(function*)
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:3501
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
Preprocessed source stored into /scratch/tmp/ccO9eL35.out file, please attach
this to your bugreport.

Testcase:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/testsuite/gcc.c-torture/compile/20090907-1.c;h=12cf1185b93b973ce21e24039c00d9b7be855894;hb=HEAD

Godbolt:
https://godbolt.org/z/chdK4TnKx

creduced testcase:
char a;
char *b;
int c;
void d() {
  int e = 0, f = 0;
  for (; f <= a; f++)
if (b[f])
  e = f - 1;
  c = e;
}

[Bug target/112852] [14 Regression] RISCV ICE: vsetvl pass: in partial_subreg_p, at rtl.h:3187 on rv64gcv_zvl512b

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug target/112851] [14 Regression] RISCV ICE: vsetvl pass: in partial_subreg_p, at rtl.h:3187 on rv32gcv_zvl256b

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug tree-optimization/112848] [14 regression] ICE compiling gcc.dg/tree-ssa/ssa-sink-16.c after r14-6114-gde0ab339a79535

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Fixed.

[Bug c++/112847] [14 Regression] nvptx: 'FAIL: g++.dg/cpp2a/concepts-explicit-inst1.C -std=c++20 scan-assembler _Z1gI1XEvT_', 'scan-assembler _Z1gI1YEvT_'

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug c++/112846] [14 Regression] nvptx: 'FAIL: g++.dg/abi/anon6.C -std=c++20 scan-assembler _Z5dummyIXtl8wrapper1IdEtlNS1_Ut_Edi9RightNametlNS2_Ut_Edi9RightNameLd405ec00000000000EEEEEEvv'

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug c/86869] ICE when taking address of array member of __memx struct pointer

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Fixed on trunk.

[Bug c/86869] ICE when taking address of array member of __memx struct pointer

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Richard Biener :

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

commit r14-6133-ge00c00730912cd6072954cd2c29ca44e33dbb598
Author: Richard Biener 
Date:   Mon Dec 4 13:31:35 2023 +0100

c/86869 - preserve address-space info when building qualified ARRAY_TYPE

The following adjusts the C FE specific qualified type building
to preserve address-space info also for ARRAY_TYPE.

PR c/86869
gcc/c/
* c-typeck.cc (c_build_qualified_type): Preserve address-space
info for ARRAY_TYPE.

gcc/testsuite/
* gcc.target/avr/pr86869.c: New testcase.

[Bug tree-optimization/112827] [14 Regression] ICE on valid code at -O1 on x86_64-linux-gnu: Segmentation fault

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:50f2a3370d177f8fe9bea0461feb710523e048a2

commit r14-6132-g50f2a3370d177f8fe9bea0461feb710523e048a2
Author: Richard Biener 
Date:   Mon Dec 4 15:46:38 2023 +0100

tree-optimization/112827 - more SCEV cprop fixes

The insert iteration can be corrupted by foldings of replace_uses_by,
within this particular PHI replacement but also with subsequent ones.
Recompute the insert location before insertion instead.

This fixes an obvserved ICE of gcc.dg/tree-ssa/ssa-sink-16.c.

PR tree-optimization/112827
PR tree-optimization/112848
* tree-scalar-evolution.cc (final_value_replacement_loop):
Compute the insert location for each insert.

[Bug target/112756] RISC-V regression testsuite errors with rv32gcv_zvl512b

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

  Attachment #56712|0   |1
is obsolete||

--- Comment #2 from Patrick O'Neill  ---
Created attachment 56798
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56798=edit
rv32gcv_zvl512b testsuite failures 2023-12-04

Tested with hash 0c2ea80a4ffbddc0bc29f5badaf2ae43e59483b2
CI run:
https://github.com/patrick-rivos/gcc-postcommit-ci/actions/runs/7089317318

Comparison with zvl128b (pr112754):

Resolved failures (present on zvl128b but not zvl512b):
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++14  scan-tree-dump optimized
"return 15;"
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++17  scan-tree-dump optimized
"return 15;"
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++20  scan-tree-dump optimized
"return 15;"
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++98  scan-tree-dump optimized
"return 15;"
XPASS: gcc.dg/tree-ssa/pr84512.c scan-tree-dump optimized "return 285;"
XPASS: gcc.dg/vect/slp-reduc-11.c -flto -ffat-lto-objects  scan-tree-dump vect
"vectorizing stmts using SLP"
XPASS: gcc.dg/vect/slp-reduc-11.c scan-tree-dump vect "vectorizing stmts using
SLP"

New failures (present on zvl512b but not zvl128b):
FAIL: gfortran.dg/array_constructor_12.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/array_constructor_12.f90   -O3 -g  execution test
FAIL: gcc.dg/no-strict-overflow-6.c scan-tree-dump optimized "return 0"
FAIL: gcc.dg/pr30957-1.c execution test
FAIL: gcc.dg/pr30957-1.c scan-rtl-dump loop2_unroll "Expanding Accumulator"
FAIL: gcc.dg/torture/pr109219.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error: in
partial_subreg_p, at rtl.h:3187)
FAIL: gcc.dg/torture/pr109219.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gcc.dg/tree-ssa/ivopts-lt-2.c scan-tree-dump-times ivopts "PHI "
FAIL: gcc.dg/tree-ssa/ssa-sink-16.c (internal compiler error: verify_gimple
failed)
FAIL: gcc.dg/tree-ssa/ssa-sink-16.c (test for excess errors)
FAIL: gcc.target/riscv/rvv/autovec/pr112552.c -O3 -ftree-vectorize (test for
excess errors)


All new failures are also seen on zvl128b: pr112754

[Bug target/112707] [14 regression] gcc 14 outputs invalid assembly on ppc: Error: unrecognized opcode: `fctid'

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

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

--- Comment #11 from Peter Bergner  ---
(In reply to Kewen Lin from comment #10)
> (In reply to HaoChen Gui from comment #9)
>
>> My question is: can "fctid" be executed on powerpc7450 such a 32bit
>> processor? If it's supported, should the assembler be changed also (replace
>> the PPC64 with PPC for fctid)?
> 
> Good question, I think it's no, the assembler implementation looks to match
> the documentation, as I can't find insn fctid in powerpc7450 doc:
> https://www.nxp.com.cn/docs/en/reference-manual/MPC7450UM.pdf

I believe the only 32-bit cpu that supports fctid is the 476 which has
explicitly enabled it here.

[Bug tree-optimization/112848] [14 regression] ICE compiling gcc.dg/tree-ssa/ssa-sink-16.c after r14-6114-gde0ab339a79535

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:50f2a3370d177f8fe9bea0461feb710523e048a2

commit r14-6132-g50f2a3370d177f8fe9bea0461feb710523e048a2
Author: Richard Biener 
Date:   Mon Dec 4 15:46:38 2023 +0100

tree-optimization/112827 - more SCEV cprop fixes

The insert iteration can be corrupted by foldings of replace_uses_by,
within this particular PHI replacement but also with subsequent ones.
Recompute the insert location before insertion instead.

This fixes an obvserved ICE of gcc.dg/tree-ssa/ssa-sink-16.c.

PR tree-optimization/112827
PR tree-optimization/112848
* tree-scalar-evolution.cc (final_value_replacement_loop):
Compute the insert location for each insert.

[Bug tree-optimization/112857] New: Missing optimzation: fold (b + ~a) > 0 to a - b ＜ -1

[xxs_chy at outlook dot com via Gcc-bugs]

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

Bug ID: 112857
   Summary: Missing optimzation: fold (b + ~a) > 0 to a - b ＜ -1
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xxs_chy at outlook dot com
  Target Milestone: ---

Godbolt link example: https://godbolt.org/z/Pba4Y164f
For c code like:


bool src(int a, int b){
return (b + ~a) > 0;
}

can be folded to:


bool tgt(int a, int b){
return a - b < -1;
}


But both GCC and LLVM missed it.

[Bug target/112855] New: [14] RISC-V vector: overwriting stack args

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 112855
   Summary: [14] RISC-V vector: overwriting stack args
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

reduced testcase:
int printf(char *, ...);
int a;
int b = 100;
int c[25];
int d;
int main() {
  int e;
  d = 0;
  for (; d < 5; d++) {
e = 0;
for (; e < 5; e++)
  c[d * 5 + e] = 0;
  }
  if (b)
if (a)
  for (;;)
;
  b++;
  int volatile f = *c;
  printf("%d\n", b);
}

Tested using qemu with these commands:
> ./bin/riscv64-unknown-linux-gnu-gcc -march=rv64gcv -mabi=lp64d -O3 red.c -o 
> rv64gcv.out

> ./bin/riscv64-unknown-linux-gnu-gcc -march=rv64gc -mabi=lp64d -O3 red.c -o 
> rv64gc.out

> QEMU_CPU=rv64,vlen=128,v=true,vext_spec=v1.0,Zve32f=true,Zve64f=true 
> ./bin/qemu-riscv64 rv64gc.out
101

> QEMU_CPU=rv64,vlen=128,v=true,vext_spec=v1.0,Zve32f=true,Zve64f=true 
> ./bin/qemu-riscv64 rv64gcv.out
5

rv64gcv should match rv64gc and output 101. I'm not sure where it's getting "5"
from.

When you comment out the b++, the behavior is fixed (and both rv64gcv and
rv64gc output 100):
https://godbolt.org/z/chqGo6fj8

Changing other aspects of the program will also fix the behavior, it's just
that commenting out b++ was the least-disruptive change on the assembly code
that I could find.

You can also set b to zero. I just have it at 100 to make it more obvious that
the arg is getting overwritten, not just added/subtracted.

[Bug c++/98940] Implement C++23 language features

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

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

Bug 107687 Summary: [C++23] P2564 - consteval needs to propagate up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107687

   What|Removed |Added

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

[Bug c++/107687] [C++23] P2564 - consteval needs to propagate up

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Implemented in GCC 14.

[Bug c++/112658] [12/13 Regression] ICE: finish_expr_stmt with casting an temp array to pointer and constructor call

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

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

Patrick Palka  changed:

   What|Removed |Added

Summary|[12/13/14 Regression] ICE:  |[12/13 Regression] ICE:
   |finish_expr_stmt with   |finish_expr_stmt with
   |casting an temp array to|casting an temp array to
   |pointer and constructor |pointer and constructor
   |call|call

--- Comment #6 from Patrick Palka  ---
GCC trunk accepts (and correctly compiles) the testcase after the r14-5941 fix
for PR94264.

[Bug analyzer/112850] New: -Wanalyzer-tainted-allocation-size false positive seen in Linux kernel's sound/core/rawmidi.c

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

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

Bug ID: 112850
   Summary: -Wanalyzer-tainted-allocation-size false positive seen
in Linux kernel's sound/core/rawmidi.c
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
Blocks: 106358
  Target Milestone: ---

False positive at -O1 and above with:

/* { dg-do compile } */
/* { dg-options "-fanalyzer -O2" } */
/* { dg-require-effective-target analyzer } */

typedef unsigned long __kernel_ulong_t;
typedef __kernel_ulong_t __kernel_size_t;
typedef __kernel_size_t size_t;
typedef unsigned int gfp_t;

extern unsigned long copy_from_user(void* to, const void* from, unsigned long
n);

extern
__attribute__((__alloc_size__(1)))
__attribute__((__malloc__)) void*
kvzalloc(size_t size, gfp_t flags);

struct snd_rawmidi_params
{
  int stream;
  size_t buffer_size;
};

char *newbuf;

static int
resize_runtime_buffer(struct snd_rawmidi_params* params)
{
  if (params->buffer_size < 32 || params->buffer_size > 1024L * 1024L)
return -22;
  newbuf = kvzalloc(params->buffer_size, /* { dg-bogus "use of
attacker-controlled value '\\*params.buffer_size' as allocation size without
upper-bounds checking" } */
(((gfp_t)(0x400u | 0x800u)) | ((gfp_t)0x40u) |
((gfp_t)0x80u)));
  if (!newbuf)
return -12;
  return 0;
}

long
snd_rawmidi_ioctl(unsigned long arg)
{
  void* argp = (void*)arg;
  struct snd_rawmidi_params params;
  if (copy_from_user(, argp, sizeof(struct snd_rawmidi_params)))
return -14;
  return resize_runtime_buffer();
}

with the analyzer_kernel_plugin.so:

gcc/testsuite/gcc.dg/plugin/taint-sound-core-rawmidi.c:30:12: warning: use of
attacker-controlled value ‘*params.buffer_size’ as allocation size without
upper-bounds checking [CWE-789] [-Wanalyzer-tainted-allocation-size]
   30 |   newbuf = kvzalloc(params->buffer_size, /* { dg-bogus "use of
attacker-controlled value '\\*params.buffer_size' as allocation size without
upper-bounds checking" } */
  |   
^~~~
   31 | (((gfp_t)(0x400u | 0x800u)) | ((gfp_t)0x40u) |
((gfp_t)0x80u)));
  |
~~~
  ‘snd_rawmidi_ioctl’: events 1-4
|
|   38 | snd_rawmidi_ioctl(unsigned long arg)
|  | ^
|  | |
|  | (1) entry to ‘snd_rawmidi_ioctl’
|..
|   42 |   if (copy_from_user(, argp, sizeof(struct
snd_rawmidi_params)))
|  |  ~
|  |  |
|  |  (2) following ‘false’ branch...
|   43 | return -14;
|   44 |   return resize_runtime_buffer();
|  |  ~~
|  |  |
|  |  (3) ...to here
|  |  (4) calling ‘resize_runtime_buffer’ from
‘snd_rawmidi_ioctl’
|
+--> ‘resize_runtime_buffer’: events 5-8
   |
   |   26 | resize_runtime_buffer(struct snd_rawmidi_params* params)
   |  | ^
   |  | |
   |  | (5) entry to ‘resize_runtime_buffer’
   |   27 | {
   |   28 |   if (params->buffer_size < 32 || params->buffer_size >
1024L * 1024L)
   |  |  ~
   |  |  |
   |  |  (6) following ‘false’ branch...
   |   29 | return -22;
   |   30 |   newbuf = kvzalloc(params->buffer_size, /* { dg-bogus "use
of attacker-controlled value '\\*params.buffer_size' as allocation size without
upper-bounds checking" } */
   |  |   

   |  ||
   |  |(7) ...to here
   |  |(8) use of attacker-controlled value
‘*params.buffer_size’ as allocation size without upper-bounds checking
   |   31 | (((gfp_t)(0x400u | 0x800u)) |
((gfp_t)0x40u) | ((gfp_t)0x80u)));
   |  |
~~~
   |

Reduced from sound/core/rawmidi.c in Linux kernel


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106358
[Bug 106358] [meta-bug] tracker bug for building the Linux kernel with
-fanalyzer

[Bug target/112754] RISC-V regression testsuite errors with rv32gcv_zvl128b

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

  Attachment #56710|0   |1
is obsolete||

--- Comment #2 from Patrick O'Neill  ---
Created attachment 56796
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56796=edit
rv32gcv_zvl128b testsuite failures 2023-12-04

Tested with hash 0c2ea80a4ffbddc0bc29f5badaf2ae43e59483b2
CI run:
https://github.com/patrick-rivos/gcc-postcommit-ci/actions/runs/7089317318

Resolved failures (improved from ad3e759c172272f6f2ba66631e7e7bd03fb2b436)
FAIL: g++.dg/other/pr55650.C  -std=gnu++14 (test for excess errors)
FAIL: g++.dg/other/pr55650.C  -std=gnu++17 (test for excess errors)
FAIL: g++.dg/other/pr55650.C  -std=gnu++20 (test for excess errors)
FAIL: g++.dg/other/pr55650.C  -std=gnu++98 (test for excess errors)
FAIL: g++.dg/tree-prof/indir-call-prof-2.C compilation,  -fprofile-generate
-D_PROFILE_GENERATE
FAIL: g++.dg/tree-prof/indir-call-prof.C compilation,  -fprofile-generate
-D_PROFILE_GENERATE
FAIL: g++.dg/tree-prof/indir-call-recursive-inlining.C compilation, 
-fprofile-generate -D_PROFILE_GENERATE
FAIL: g++.dg/tree-prof/inline_mismatch_args.C compilation,  -fprofile-generate
-D_PROFILE_GENERATE
FAIL: g++.dg/tree-prof/morefunc.C compilation,  -fprofile-generate
-D_PROFILE_GENERATE
FAIL: g++.dg/tree-prof/partition1.C compilation,  -fprofile-generate
-D_PROFILE_GENERATE
FAIL: g++.dg/tree-prof/partition2.C compilation,  -fprofile-generate
-D_PROFILE_GENERATE
FAIL: g++.dg/tree-prof/partition3.C compilation,  -fprofile-generate
-D_PROFILE_GENERATE
FAIL: g++.dg/tree-prof/pr35545.C compilation,  -fprofile-generate
-D_PROFILE_GENERATE
FAIL: g++.dg/tree-prof/pr51719.C compilation,  -fprofile-generate
-D_PROFILE_GENERATE
FAIL: g++.dg/tree-prof/pr53460.C compilation,  -fprofile-generate
-D_PROFILE_GENERATE
FAIL: g++.dg/tree-prof/pr57451.C compilation,  -fprofile-generate
-D_PROFILE_GENERATE
FAIL: g++.dg/tree-prof/pr59255.C compilation,  -fprofile-generate
-D_PROFILE_GENERATE
FAIL: g++.dg/tree-prof/pr63581.C compilation,  -fprofile-generate
-D_PROFILE_GENERATE
FAIL: g++.dg/tree-prof/pr79259.C compilation,  -fprofile-generate
-D_PROFILE_GENERATE
FAIL: g++.dg/tree-prof/reorder.C compilation,  -fprofile-generate
-D_PROFILE_GENERATE
FAIL: gfortran.dg/class_67.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/prof/dynamic_dispatch_6.f03 compilation,  -fprofile-generate
-D_PROFILE_GENERATE
FAIL: gcc.dg/profile-generate-3.c (test for excess errors)
FAIL: gcc.dg/lto/pr69188 c_lto_pr69188_0.o-c_lto_pr69188_1.o link,  -flto -O0
-fprofile-generate
FAIL: gcc.dg/tree-prof/20041218-1.c compilation,  -fprofile-generate
-D_PROFILE_GENERATE
FAIL: gcc.dg/tree-prof/20050826-2.c compilation,  -fprofile-generate
-D_PROFILE_GENERATE
FAIL: gcc.dg/tree-prof/bb-reorg.c compilation,  -fprofile-generate
-D_PROFILE_GENERATE
FAIL: gcc.dg/tree-prof/cmpsf-1.c compilation,  -fprofile-generate
-D_PROFILE_GENERATE
FAIL: gcc.dg/tree-prof/cold_partition_label.c compilation,  -fprofile-generate
-D_PROFILE_GENERATE
FAIL: gcc.dg/tree-prof/comp-goto-1.c compilation,  -fprofile-generate
-D_PROFILE_GENERATE
FAIL: gcc.dg/tree-prof/crossmodule-indir-call-topn-1.c compilation, 
-fprofile-generate -D_PROFILE_GENERATE
FAIL: gcc.dg/tree-prof/crossmodule-indir-call-topn-1a.c compilation, 
-fprofile-generate -D_PROFILE_GENERATE
FAIL: gcc.dg/tree-prof/crossmodule-indir-call-topn-2.c compilation, 
-fprofile-generate -D_PROFILE_GENERATE
FAIL: gcc.dg/tree-prof/crossmodule-indircall-1.c compilation, 
-fprofile-generate -D_PROFILE_GENERATE
FAIL: gcc.dg/tree-prof/crossmodule-indircall-1a.c compilation, 
-fprofile-generate -D_PROFILE_GENERATE
FAIL: gcc.dg/tree-prof/ic-misattribution-1.c compilation,  -fprofile-generate
-D_PROFILE_GENERATE
FAIL: gcc.dg/tree-prof/ic-misattribution-1a.c compilation,  -fprofile-generate
-D_PROFILE_GENERATE
FAIL: gcc.dg/tree-prof/indir-call-prof-2.c compilation,  -fprofile-generate
-D_PROFILE_GENERATE
FAIL: gcc.dg/tree-prof/indir-call-prof-malloc.c compilation, 
-fprofile-generate -D_PROFILE_GENERATE
FAIL: gcc.dg/tree-prof/indir-call-prof-topn.c compilation,  -fprofile-generate
-D_PROFILE_GENERATE
FAIL: gcc.dg/tree-prof/indir-call-prof.c compilation,  -fprofile-generate
-D_PROFILE_GENERATE
FAIL: gcc.dg/tree-prof/init-array.c compilation,  -fprofile-generate
-D_PROFILE_GENERATE
FAIL: gcc.dg/tree-prof/inliner-1.c compilation,  -fprofile-generate
-D_PROFILE_GENERATE
FAIL: gcc.dg/tree-prof/loop-split-1.c compilation,  -fprofile-generate
-D_PROFILE_GENERATE
FAIL: gcc.dg/tree-prof/loop-split-2.c compilation,  -fprofile-generate
-D_PROFILE_GENERATE
FAIL: gcc.dg/tree-prof/loop-split-3.c compilation,  -fprofile-generate
-D_PROFILE_GENERATE
FAIL: gcc.dg/tree-prof/merge_block.c compilation,  -fprofile-generate

[Bug middle-end/112824] Stack spills and vector splitting with vector builtins

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

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

--- Comment #7 from Hongtao Liu  ---
(In reply to Chris Elrod from comment #6)
> Hongtao Liu, I do think that one should ideally be able to get optimal
> codegen when using 512-bit builtin vectors or vector intrinsics, without
> needing to set `-mprefer-vector-width=512` (and, currently, also setting
> `-mtune-ctrl=avx512_move_by_pieces`).
> 
> 
> GCC respects the vector builtins and uses 512 bit ops, but then does splits
> and spills across function boundaries.
> So, what I'm arguing is, while it would be great to respect
> `-mprefer-vector-width=512`, it should ideally also be able to respect
> vector builtins/intrinsics, so that one can use full width vectors without
> also having to set `-mprefer-vector-width=512
> -mtune-control=avx512_move_by_pieces`.
If it's designed the way you want it to be， another issue would be like, should
we lower 512-bit vector builtins/intrinsic to ymm/xmm when
-mprefer-vector-width=256, the answer is we'd rather not. The intrinsic should
be closer to a one-to-one correspondence of instructions.(Though there're
several instrinics which are lowered to a sequence of instructions)
There're also others users using 512-bit intriniscs for specific kernel loops,
but still want compiler to generate xmm/ymm for other codes,
-mprefer-vector-width=256.

Originally -mprefer-vector-width=XXX is designed for auto-vectorization, and
-mtune-ctrl=avx512_move_by_pieces is for memory movement. Both of which are
orthogonal to codegen for builtin, intrinsic or explicit vector types. If user
explicitly use 512-bit vector type, builtins or intrinsics, gcc will generate
zmm no matter -mprefer-vector-width=.

And yes, there could be some mismatches between 512-bit intrinsic and
architecture tuning when you're using 512-bit intrinsic, and also rely on
compiler autogen to handle struct
(struct Dual {
  Vector data;
};). 
For such case, an explicit -mprefer-vector-width=512 is needed.

[Bug tree-optimization/112857] Missing optimzation: fold (b + ~a) > 0 to a - b ＜ -1

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Last reconfirmed||2023-12-05
 Ever confirmed|0   |1
 CC||pinskia at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed. I was actually going to file this one but my access to gcc.gnu.org
was not working all day.

Note all of the following testcases should produce the same code too:
```
int g0(int a, int b)
{
return b > a;
}

int g10(int a, int b)
{
return (b-a) > 0;
}

int g(int a, int b)
{
  return (b + ~ a) >= 0;
}


int g1(int a, int b)
{
  return (b - a) -1 >= 0;
}

int g2(int a, int b)
{
  return (b +  (-a-1)) >= 0;
}



int g3(int a, int b)
{
  return (b + ~ a) + 1 > 0;
}

int g4(int a, int b)
{
  return (b + (~ a + 1)) > 0;
}
```

For the above, GCC is able to get the best code for g0, g10, g1, and g4 (though
g1 and g4 are still `(b-a) > 0` at the gimple level. While LLVM is able to get
it for g0, g10 and g4 (g3 is close though with `(b-a) > 0`).

[Bug middle-end/112824] Stack spills and vector splitting with vector builtins

[elrodc at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Chris Elrod  ---
> If it's designed the way you want it to be， another issue would be like, 
> should we lower 512-bit vector builtins/intrinsic to ymm/xmm when 
> -mprefer-vector-width=256, the answer is we'd rather not. 

To be clear, what I meant by

>  it would be great to respect
> `-mprefer-vector-width=512`, it should ideally also be able to respect
> vector builtins/intrinsics

is that when someone uses 512 bit vector builtins, that codegen should generate
512 bit code regardless of `mprefer-vector-width` settings.
That is, as a developer, I would want 512 bit builtins to mean we get 512-bit
vector code generation.

>  If user explicitly use 512-bit vector type, builtins or intrinsics, gcc will 
> generate zmm no matter -mprefer-vector-width=.

This is what I would want, and I'd also want it to apply to movement of
`struct`s holding vector builtin objects, instead of the `ymm` usage as we see
here.

> And yes, there could be some mismatches between 512-bit intrinsic and 
> architecture tuning when you're using 512-bit intrinsic, and also rely on 
> compiler autogen to handle struct
> For such case, an explicit -mprefer-vector-width=512 is needed.

Note the template partial specialization

template  struct Vector{
static constexpr ptrdiff_t W = N >= VecWidth ? VecWidth :
ptrdiff_t(std::bit_ceil(size_t(N))); 
static constexpr ptrdiff_t L = (N/W) + ((N%W)!=0);
using V = Vec;
V data[L];
static constexpr auto size()->ptrdiff_t{return N;}
};

Thus, `Vector`s in this example may explicitly be structs containing arrays of
vector builtins. I would expect these structs to not need an
`mprefer-vector-width=512` setting for producing 512 bit code handling this
struct.
Given small `L`, I would also expect passing this struct as an argument by
value to a non-inlined function to be done in `zmm` registers when possible,
for example.

[Bug target/112853] New: RISC-V: RVV: SPEC2017 525.x264 regression

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

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

Bug ID: 112853
   Summary: RISC-V: RVV: SPEC2017 525.x264 regression
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vineetg at gcc dot gnu.org
CC: juzhe.zhong at rivai dot ai, patrick at rivosinc dot com,
rdapp at gcc dot gnu.org
  Target Milestone: ---

As of commit 3d104d93a701 ("ARC: Consistent use of whitespace in assembler
templates.") x264 build for RVV is segfaulting.

```
QEMU_CPU=rv64,vlen=256,zba=true,zbb=true,zbs=true,zicond=true,vext_spec=v1.0,Zve32f=true,Zve64f=true
qemu-riscv64  ./ldecod_r_base.rivos_rv64-m64 -i BuckBunny.264 -o BuckBunny.yuv

Setting Default Parameters...
Parsing Configfile decoder.cfg

- JM 17.1 (FRExt) -
--
 Input H.264 bitstream  : BuckBunny.264 
 Output decoded YUV : BuckBunny.yuv 
 Input reference file   : test_rec.yuv 
--
POC must = frame# or field# for SNRs to be correct
--
  Frame  POC  Pic#   QPSnrY SnrU SnrV   Y:U:V Time(ms)
--
 Input reference file   : test_rec.yuv does not exist 
  SNR values are not available
Segmentation fault (core dumped)
```

It was fine at my prev checkpoint: 
2023-11-22 6f59f959e751 hppa: Define MAX_FIXED_MODE_SIZE

Built with following flags

-Ofast -fno-lto -static -march=rv64gcv_zba_zbb_zbc_zbs_zicond -ftree-vectorize
--param=riscv-autovec-preference=scalable

[Bug tree-optimization/112856] New: [14 regression] ICE when building clustal-omega

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

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

Bug ID: 112856
   Summary: [14 regression] ICE when building clustal-omega
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 56803
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56803=edit
hhalign.ii.xz

I've never heard of 'clustal-omega' either but it's one of our packages and it
broke, so...

Originally reported downstream in Gentoo at https://bugs.gentoo.org/919165 by
Toralf Förster.

```
# x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../src -fno-strict-aliasing
-DCLUSTALO -DCLUSTALO_NOFILE -DDEFAULT_FILTER=90 -fopenmp -O3 -march=native
-fno-semantic-interposition -pipe -Wa,-O2 -Wa,-mtune=znver2
-fcf-protection=none -fdiagnostics-color=always -fdiagnostics-urls=never
-frecord-gcc-switches -ggdb3 -c hhalign.cpp  -fPIC -DPIC -o .libs/hhalign.o
In file included from hhalign.cpp:70:
hhhmm-C.h: In member function ‘void HMM::UseSecStrucDependentGapPenalties()’:
hhhmm-C.h:1748:16: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
 1748 |   iis[0]=iis[L]=0;
  |  ~~^~
hhhmm-C.h:1734:17: note: at offset [-2147483648, -1] into destination object
‘iis’ of size [0, 2147483647]
 1734 |   unsigned char iis[par.maxResLen]; // inside-integer array
  | ^~~
during GIMPLE pass: ch_vect
In file included from hhalign.cpp:75:
hhhitlist-C.h: In member function ‘void HitList::SVD(double**, int, double*,
double**)’:
hhhitlist-C.h:2919:1: internal compiler error: in check_loop_closed_ssa_def, at
tree-ssa-loop-manip.cc:647
 2919 | HitList::SVD(double **A, int n, double w[], double **V)
  | ^~~
0x55fb54b5dd71 check_loop_closed_ssa_def
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231203/gcc-14-20231203/gcc/tree-ssa-loop-manip.cc:647
0x55fb54b5dd71 check_loop_closed_ssa_bb
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231203/gcc-14-20231203/gcc/tree-ssa-loop-manip.cc:661
0x55fb54b5d787 verify_loop_closed_ssa(bool, loop*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231203/gcc-14-20231203/gcc/tree-ssa-loop-manip.cc:697
0x55fb5449dd08 execute_function_todo
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231203/gcc-14-20231203/gcc/passes.cc:2106
0x55fb5449dd08 do_per_function
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231203/gcc-14-20231203/gcc/passes.cc:1687
0x55fb5449dd08 execute_todo
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231203/gcc-14-20231203/gcc/passes.cc:2142
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.
```

I can reproduce with 'g++ -c hhalign.ii -O3 -fno-strict-aliasing'.

[Bug target/101017] ICE: Segmentation fault, convert_memory_address_addr_space_1 with vector_size(32) and target_clone arch=core-avx2/default

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

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

--- Comment #6 from Hongtao Liu  ---
(In reply to Andrew Pinski from comment #4)
> Note the testcase which ICEs is now:
> ```
> typedef int v32qi __attribute__((vector_size(32)));
> __attribute__((target_clones("arch=core-avx2", "default"))) v32qi
> foo_ashift_256() {}
> ```
> 
> Note the `int` there. Otherwise you get an error.

For arch=core-avx2, function returns in reg(cfun->returns_struct), but for
"default" and resolver function, it returns in memory(cfun->returns_struct ==
1)

The mismatch between resolver and dispatched function caused the ICE.

[Bug tree-optimization/111678] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:647

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #3 from Sam James  ---


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

[Bug tree-optimization/109689] [14 Regression] ICE at -O1 with "-ftree-vectorize": in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:645 since r14-301-gf2d6beb7a4ddf1

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

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

--- Comment #13 from Sam James  ---
*** Bug 111678 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/112856] [14 regression] ICE when building clustal-omega in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:647

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

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

Sam James  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
Summary|[14 regression] ICE when|[14 regression] ICE when
   |building clustal-omega  |building clustal-omega in
   ||check_loop_closed_ssa_def,
   ||at
   ||tree-ssa-loop-manip.cc:647

--- Comment #2 from Sam James  ---
Possibly a dupe of PR109689.

[Bug tree-optimization/112856] [14 regression] ICE when building clustal-omega

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

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

--- Comment #1 from Sam James  ---
reduced C version:
```
double *SVD_A_0;
int SVD_i, SVD_j, SVD_k, SVD_n;
double SVD_f;
void SVD() {
  SVD_i = SVD_n - 1;
  for (; SVD_i; SVD_i--) {
for (; SVD_j; SVD_j++) {
  SVD_f = SVD_k = SVD_i;
  for (; SVD_k < SVD_n; SVD_k++)
SVD_A_0[SVD_k] += SVD_f;
}
SVD_j = SVD_i;
for (; SVD_j < SVD_n; SVD_j++)
  ;
  }
}

```
fails with just gcc -O3.

[Bug middle-end/112854] New: [14] RISCV ICE: expand: in store_integral_bit_field, at expmed.cc:1049 on rv32gcv_zvl1024b --param=riscv-autovec-preference=fixed-vlmax

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 112854
   Summary: [14] RISCV ICE: expand: in store_integral_bit_field,
at expmed.cc:1049 on rv32gcv_zvl1024b
--param=riscv-autovec-preference=fixed-vlmax
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Created attachment 56802
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56802=edit
-freport-bug output

Command:
> /scratch/tc-testing/tc-dec-4-trunk/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc
>  -march=rv32gcv_zvl1024b -mabi=ilp32d 
> --param=riscv-autovec-preference=fixed-vlmax -O3 red.c -freport-bug
during RTL pass: expand
red.c: In function 'c':
red.c:2:6: internal compiler error: in store_integral_bit_field, at
expmed.cc:1049
2 | void c(int d) {
  |  ^
0x9b17de store_integral_bit_field
../../../gcc/gcc/expmed.cc:1049
0x9b17de store_bit_field_1
../../../gcc/gcc/expmed.cc:884
0xe4c83d store_bit_field(rtx_def*, poly_int<2u, unsigned long>, poly_int<2u,
unsigned long>, poly_int<2u, unsigned long>, poly_int<2u, unsig
../../../gcc/gcc/expmed.cc:1193
0xe783e8 store_field
../../../gcc/gcc/expr.cc:8231
0xe768ba store_constructor(tree_node*, rtx_def*, int, poly_int<2u, long>, bool)
../../../gcc/gcc/expr.cc:7986
0xe791e8 expand_constructor
../../../gcc/gcc/expr.cc:9329
0xe641f8 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../../gcc/gcc/expr.cc:11605
0xe649a9 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../../gcc/gcc/expr.cc:11220
0xf99ff2 expand_normal(tree_node*)
../../../gcc/gcc/expr.h:319
0xf99ff2 expand_vec_cond_mask_optab_fn
../../../gcc/gcc/internal-fn.cc:3116
0xf99ff2 expand_VCOND_MASK
../../../gcc/gcc/internal-fn.def:235
0xd2cd07 expand_call_stmt
../../../gcc/gcc/cfgexpand.cc:2738
0xd2cd07 expand_gimple_stmt_1
../../../gcc/gcc/cfgexpand.cc:3881
0xd2cd07 expand_gimple_stmt
../../../gcc/gcc/cfgexpand.cc:4045
0xd31ca0 expand_gimple_basic_block
../../../gcc/gcc/cfgexpand.cc:6101
0xd33c36 execute
../../../gcc/gcc/cfgexpand.cc:6836
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
Preprocessed source stored into /scratch/tmp/ccZuP8B4.out file, please attach
this to your bugreport.

Reduced testcase:
short a, b;
void c(int d) {
  for (; a; a--) {
b = 0;
for (; b <= 8; b++)
  if (d)
break;
  }
}

Godbolt:
https://godbolt.org/z/9YGs9jTfv

[Bug target/112755] RISC-V regression testsuite errors with rv32gcv_zvl256b

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

  Attachment #56711|0   |1
is obsolete||

--- Comment #2 from Patrick O'Neill  ---
Created attachment 56797
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56797=edit
rv32gcv_zvl256b testsuite failures 2023-12-04

Tested with hash 0c2ea80a4ffbddc0bc29f5badaf2ae43e59483b2
CI run:
https://github.com/patrick-rivos/gcc-postcommit-ci/actions/runs/7089317318

Comparison with zvl128b (pr112754):

Resolved failures (present on zvl128b but not zvl256b):
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++14  scan-tree-dump optimized
"return 15;"
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++17  scan-tree-dump optimized
"return 15;"
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++20  scan-tree-dump optimized
"return 15;"
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++98  scan-tree-dump optimized
"return 15;"

New failures (present on zvl256b but not zvl128b):
FAIL: gcc.dg/pr30957-1.c execution test
FAIL: gcc.dg/pr30957-1.c scan-rtl-dump loop2_unroll "Expanding Accumulator"
FAIL: gcc.dg/torture/pr109219.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error: in
partial_subreg_p, at rtl.h:3187)
FAIL: gcc.dg/torture/pr109219.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gcc.dg/tree-ssa/ivopts-lt-2.c scan-tree-dump-times ivopts "PHI "
FAIL: gcc.dg/tree-ssa/ssa-sink-16.c (internal compiler error: verify_gimple
failed)
FAIL: gcc.dg/tree-ssa/ssa-sink-16.c (test for excess errors)
FAIL: gcc.target/riscv/rvv/autovec/pr112552.c -O3 -ftree-vectorize (test for
excess errors)


All new failures are also seen on zvl128b: pr112754

[Bug ada/112781] [13/14 regression] ICE in generic instantiation

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Botcazou  ---
Investigating.

[Bug target/112599] RISC-V regression testsuite errors with rv64gcv_zvl1024b

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

  Attachment #56701|0   |1
is obsolete||

--- Comment #7 from Patrick O'Neill  ---
Created attachment 56795
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56795=edit
rv64gcv_zvl1024b testsuite failures 2023-12-03

Tested with hash 806789e6daa39ab0503d91c71b3faeb5d5cdd317
CI run:
https://github.com/patrick-rivos/gcc-postcommit-ci/actions/runs/7077949347

Comparison with zvl128b (pr112583):

Resolved failures (present on zvl128b but not zvl1024b):
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++14  scan-tree-dump optimized
"return 15;"
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++17  scan-tree-dump optimized
"return 15;"
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++20  scan-tree-dump optimized
"return 15;"
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++98  scan-tree-dump optimized
"return 15;"
XPASS: gcc.dg/tree-ssa/pr84512.c scan-tree-dump optimized "return 285;"

New failures (present on zvl1024b but not zvl128b):
FAIL: gfortran.dg/matmul_1.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/matmul_1.f90   -O3 -g  execution test
FAIL: gfortran.dg/proc_ptr_comp_12.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/proc_ptr_comp_12.f90   -O3 -g  execution test
FAIL: gcc.dg/no-strict-overflow-6.c scan-tree-dump optimized "return 0"
FAIL: gcc.dg/pr30957-1.c execution test
FAIL: gcc.dg/pr30957-1.c scan-rtl-dump loop2_unroll "Expanding Accumulator"
FAIL: gcc.dg/pr53265.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/ivopts-lt-2.c scan-tree-dump-times ivopts "PHI  i" 2
FAIL: gcc.dg/torture/pr58955-2.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gcc.dg/tree-prof/time-profiler-3.c scan-ipa-dump-times profile "Read
tp_first_run: 0" 1
FAIL: gcc.dg/tree-prof/time-profiler-3.c scan-ipa-dump-times profile "Read
tp_first_run: 2" 1
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/strided_store_run-2.c (test
for excess errors)
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/strided_store_run-2.c (test
for excess errors)

New failures:
FAIL: gcc.target/riscv/rvv/autovec/pr112552.c -O3 -ftree-vectorize (test for
excess errors)


This new failure is also seen on pr112583 - looks like a simple issue.

[Bug target/112853] RISC-V: RVV: SPEC2017 525.x264 regression

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

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

--- Comment #1 from Vineet Gupta  ---
Currently bisecting.

The issue happens at an indexed load insn:

=> 0x6f656 :vluxei64.v  v2,(a3),v2

The src reg v2 is different in good vs. failing case

bad case
--
info reg v2
 b = {0xc0, 0xcf, 0xb6, 0x0, 0x0, 0x0, 0x0, 0x0, 0x40, 0xc5, 0xb6, 0x0
}}

good case
-
 b = {0xc0, 0xcf, 0xb6, 0x0, 0x0, 0x0, 0x0, 0x0, 0x40, 0xc5, 0xb6, 0x0,
0x0, 0x0, 0x0, 0x0, 0xc0, 0xcf, 0xb6, 0x0, 0x0, 0x0, 0x0, 0x0, 0x40, 0xb0,
0xb6, 0x0, 0x0, 0x0, 0x0, 0x0}}

[Bug tree-optimization/112809] during GIMPLE pass: bitintlower ICE: in limb_access_type, at gimple-lower-bitint.cc:563 at -O1 and above

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #1 from Zdenek Sojka  ---
Created attachment 56791
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56791=edit
a simpler testcase using only two variables

$ x86_64-pc-linux-gnu-gcc -O testcase.c
during GIMPLE pass: bitintlower
testcase.c: In function 'foo':
testcase.c:5:1: internal compiler error: in limb_access_type, at
gimple-lower-bitint.cc:563
5 | foo (void)
  | ^~~
0xd52c07 limb_access_type
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:563
0x25351a7 limb_access_type
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:559
0x25351a7 limb_access
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:578
0x2545989 lower_mergeable_stmt
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:2693
0x254a30d lower_stmt
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:5268
0x254c9a6 gimple_lower_bitint
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:6397
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 c++/70819] constexpr error location wrong

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
   Keywords|needs-bisection |
 Resolution|--- |FIXED

--- Comment #2 from Marek Polacek  ---
Changed in r14-2771

commit 5ebe5bcf8b6b6a0de16737b717e8bd06e4950a14
Author: Nathaniel Shead 
Date:   Sun Jul 23 01:13:43 2023 +1000

c++: Improve location information in constant evaluation

So I guess fixed.

[Bug target/112851] [14 Regression] RISCV ICE: vsetvl pass: in partial_subreg_p, at rtl.h:3187 on rv32gcv_zvl256b

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

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

--- Comment #1 from JuzheZhong  ---
Confirm. I will take a look at it.

[Bug c++/55004] [meta-bug] constexpr issues

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

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

Bug 70819 Summary: constexpr error location wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70819

   What|Removed |Added

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

[Bug target/112707] [14 regression] gcc 14 outputs invalid assembly on ppc: Error: unrecognized opcode: `fctid'

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

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #12 from Peter Bergner  ---
Confirmed.

A simpler test case with minimal rtl insns.  I'll note that you don't always
get an assembler error, since gcc still passes -many to the assembler for non
--enable-checking gcc builds, which causes it to accept the fctid insn.

extern double rint (double);
void
foo (long long *dst, double a)
{
  *dst = rint (a);
}

[Bug target/112853] RISC-V: RVV: SPEC2017 525.x264 regression

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

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

--- Comment #2 from Vineet Gupta  ---
Bisected to

commit 97ddebb6b4f6b132b0a8072b26d030077b418963
Author: Juzhe-Zhong 
Date:   Thu Nov 23 18:55:03 2023 +0800

RISC-V: Refine some codes of riscv-v.cc[NFC]

This patch is NFC patch to refine unreasonable codes I notice.

Tested on zvl128b/zvl256b/zvl512b/zvl1024b no regression.

Committed.

gcc/ChangeLog:

* config/riscv/riscv-v.cc (emit_vlmax_gather_insn): Refine codes.
(emit_vlmax_masked_gather_mu_insn): Ditto.
(modulo_sel_indices): Ditto.
(expand_vec_perm): Ditto.
(shuffle_generic_patterns): Ditto.

[Bug target/112851] New: [14 Regression] RISCV ICE: vsetvl pass: in partial_subreg_p, at rtl.h:3187 on rv32gcv_zvl256b

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 112851
   Summary: [14 Regression] RISCV ICE: vsetvl pass: in
partial_subreg_p, at rtl.h:3187 on rv32gcv_zvl256b
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Created attachment 56800
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56800=edit
-freport-bug output

Seen on rv32gcv_zvl{256|512|1024}b:
pr112755
pr112756
pr112757

FAIL: gcc.dg/torture/pr109219.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error: in
partial_subreg_p, at rtl.h:3187)

Command:
> /scratch/tc-testing/tc-dec-4-trunk/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc
>  -march=rv32gcv_zvl256b -mabi=ilp32d -O3 -funroll-loops -ftracer pr109219.c 
> -freport-bug
during RTL pass: vsetvl
pr109219.c: In function 'g_97':
pr109219.c:21:1: internal compiler error: in partial_subreg_p, at rtl.h:3187
   21 | }
  | ^
0xb3a42b partial_subreg_p(machine_mode, machine_mode)
../../../gcc/gcc/rtl.h:3187
0xb3a42b partial_subreg_p(machine_mode, machine_mode)
../../../gcc/gcc/rtl.h:3181
0xb3a42b
rtl_ssa::function_info::record_use(rtl_ssa::function_info::build_info&,
rtl_ssa::insn_info*, rtx_obj_reference)
../../../gcc/gcc/rtl-ssa/insns.cc:524
0x23ee521
rtl_ssa::function_info::add_insn_to_block(rtl_ssa::function_info::build_info&,
rtx_insn*)
../../../gcc/gcc/rtl-ssa/insns.cc:662
0x2a0876d
rtl_ssa::function_info::add_block_contents(rtl_ssa::function_info::build_info&)
../../../gcc/gcc/rtl-ssa/blocks.cc:948
0x2a08e8a
rtl_ssa::function_info::start_block(rtl_ssa::function_info::build_info&,
rtl_ssa::bb_info*)
../../../gcc/gcc/rtl-ssa/blocks.cc:1064
0x2a08f1c
rtl_ssa::function_info::bb_walker::before_dom_children(basic_block_def*)
../../../gcc/gcc/rtl-ssa/blocks.cc:117
0x225c207 dom_walker::walk(basic_block_def*)
../../../gcc/gcc/domwalk.cc:311
0x2a0a5c9 rtl_ssa::function_info::process_all_blocks()
../../../gcc/gcc/rtl-ssa/blocks.cc:1281
0x23ebb68 rtl_ssa::function_info::function_info(function*)
../../../gcc/gcc/rtl-ssa/functions.cc:50
0x1734d12 pre_vsetvl::pre_vsetvl()
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:2218
0x1733527 pass_vsetvl::lazy_vsetvl()
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:3454
0x173391f pass_vsetvl::execute(function*)
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:3518
0x173391f pass_vsetvl::execute(function*)
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:3501
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
Preprocessed source stored into /scratch/tmp/ccMXNexu.out file, please attach
this to your bugreport.

Testcase:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/testsuite/gcc.dg/torture/pr109219.c;h=2b5c514ad858e583e5f610101303429bcbf06780;hb=HEAD

Godbolt:
https://godbolt.org/z/PMjeGhzEz

[Bug middle-end/112854] [14] RISCV ICE: expand: in store_integral_bit_field, at expmed.cc:1049 on rv32gcv_zvl1024b --param=riscv-autovec-preference=fixed-vlmax

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

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

--- Comment #1 from JuzheZhong  ---
I have noticed in full coverage testing.

It's mask bit field related issue again.

Robin could you take a look at it ?

I think you are the better one than me to take care of it.

Thanks.

[Bug c++/110997] [13/14 Regression] internal compiler error: in cxx_eval_constant_expression, at cp/constexpr.cc:8005

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

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

--- Comment #3 from GCC Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:1f1c432226cf3db399b2a2a627e3c5720b02b1d6

commit r14-6129-g1f1c432226cf3db399b2a2a627e3c5720b02b1d6
Author: Marek Polacek 
Date:   Tue Sep 19 16:31:17 2023 -0400

c++: implement P2564, consteval needs to propagate up [PR107687]

This patch implements P2564, described at , whereby
certain functions are promoted to consteval.  For example:

  consteval int id(int i) { return i; }

  template 
  constexpr int f(T t)
  {
return t + id(t); // id causes f to be promoted to consteval
  }

  void g(int i)
  {
f (3);
  }

now compiles.  Previously the code was ill-formed: we would complain
that 't' in 'f' is not a constant expression.  Since 'f' is now
consteval, it means that the call to id(t) is in an immediate context,
so doesn't have to produce a constant -- this is how we allow consteval
functions composition.  But making 'f' consteval also means that
the call to 'f' in 'g' must yield a constant; failure to do so results
in an error.  I made the effort to have cc1plus explain to us what's
going on.  For example, calling f(i) produces this neat diagnostic:

w.C:11:11: error: call to consteval function 'f(i)' is not a constant
expression
   11 | f (i);
  | ~~^~~
w.C:11:11: error: 'i' is not a constant expression
w.C:6:22: note: 'constexpr int f(T) [with T = int]' was promoted to an
immediate function because its body contains an immediate-escalating expression
'id(t)'
6 | return t + id(t); // id causes f to be promoted to
consteval
  |~~^~~

which hopefully makes it clear what's going on.

Implementing this proposal has been tricky.  One problem was delayed
instantiation: instantiating a function can set off a domino effect
where one call promotes a function to consteval but that then means
that another function should also be promoted, etc.

In v1, I addressed the delayed instantiation problem by instantiating
trees early, so that we can escalate functions right away.  That caused
a number of problems, and in certain cases, like consteval-prop3.C, it
can't work, because we need to wait till EOF to see the definition of
the function anyway.  Overeager instantiation tends to cause diagnostic
problems too.

In v2, I attempted to move the escalation to the gimplifier, at which
point all templates have been instantiated.  That attempt flopped,
however, because once we've gimplified a function, its body is discarded
and as a consequence, you can no longer evaluate a call to that function
which is required for escalating, which needs to decide if a call is
a constant expression or not.

Therefore, we have to perform the escalation before gimplifying, but
after instantiate_pending_templates.  That's not easy because we have
no way to walk all the trees.  In the v2 patch, I use two vectors: one
to store function decls that may become consteval, and another to
remember references to immediate-escalating functions.  Unfortunately
the latter must also stash functions that call immediate-escalating
functions.  Consider:

  int g(int i)
  {
f(i); // f is immediate-escalating
  }

where g itself is not immediate-escalating, but we have to make sure
that if f gets promoted to consteval, we give an error.

A new option, -fno-immediate-escalation, is provided to suppress
escalating functions.

v2 also adds a new flag, DECL_ESCALATION_CHECKED_P, so that we don't
escalate a function multiple times, and so that we can distinguish between
explicitly consteval functions and functions that have been promoted
to consteval.

In v3, I removed one of the new vectors and changed the other one
to a hash set.  This version also contains numerous cleanups.

v4 merges find_escalating_expr_r into cp_fold_immediate_r.  It also
adds a new optimization in cp_fold_function.

v5 greatly simplifies the code.

v6 simplifies the code further and removes an ff_ flag.

v7 removes maybe_promote_function_to_consteval and further simplifies
cp_fold_immediate_r logic.

v8 removes maybe_store_immediate_escalating_fn.

PR c++/107687
PR c++/110997

gcc/c-family/ChangeLog:

* c-cppbuiltin.cc (c_cpp_builtins): Update __cpp_consteval.
* c-opts.cc (c_common_post_options): Pre-C++20, unset
flag_immediate_escalation.
* c.opt (fimmediate-escalation): New option.

gcc/cp/ChangeLog:

* call.cc (in_immediate_context): No longer static.
* constexpr.cc (cxx_eval_call_expression): Adjust assert.
* cp-gimplify.cc (deferred_escalating_exprs): 

[Bug c++/107687] [C++23] P2564 - consteval needs to propagate up

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

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

--- Comment #3 from GCC Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:1f1c432226cf3db399b2a2a627e3c5720b02b1d6

commit r14-6129-g1f1c432226cf3db399b2a2a627e3c5720b02b1d6
Author: Marek Polacek 
Date:   Tue Sep 19 16:31:17 2023 -0400

c++: implement P2564, consteval needs to propagate up [PR107687]

This patch implements P2564, described at , whereby
certain functions are promoted to consteval.  For example:

  consteval int id(int i) { return i; }

  template 
  constexpr int f(T t)
  {
return t + id(t); // id causes f to be promoted to consteval
  }

  void g(int i)
  {
f (3);
  }

now compiles.  Previously the code was ill-formed: we would complain
that 't' in 'f' is not a constant expression.  Since 'f' is now
consteval, it means that the call to id(t) is in an immediate context,
so doesn't have to produce a constant -- this is how we allow consteval
functions composition.  But making 'f' consteval also means that
the call to 'f' in 'g' must yield a constant; failure to do so results
in an error.  I made the effort to have cc1plus explain to us what's
going on.  For example, calling f(i) produces this neat diagnostic:

w.C:11:11: error: call to consteval function 'f(i)' is not a constant
expression
   11 | f (i);
  | ~~^~~
w.C:11:11: error: 'i' is not a constant expression
w.C:6:22: note: 'constexpr int f(T) [with T = int]' was promoted to an
immediate function because its body contains an immediate-escalating expression
'id(t)'
6 | return t + id(t); // id causes f to be promoted to
consteval
  |~~^~~

which hopefully makes it clear what's going on.

Implementing this proposal has been tricky.  One problem was delayed
instantiation: instantiating a function can set off a domino effect
where one call promotes a function to consteval but that then means
that another function should also be promoted, etc.

In v1, I addressed the delayed instantiation problem by instantiating
trees early, so that we can escalate functions right away.  That caused
a number of problems, and in certain cases, like consteval-prop3.C, it
can't work, because we need to wait till EOF to see the definition of
the function anyway.  Overeager instantiation tends to cause diagnostic
problems too.

In v2, I attempted to move the escalation to the gimplifier, at which
point all templates have been instantiated.  That attempt flopped,
however, because once we've gimplified a function, its body is discarded
and as a consequence, you can no longer evaluate a call to that function
which is required for escalating, which needs to decide if a call is
a constant expression or not.

Therefore, we have to perform the escalation before gimplifying, but
after instantiate_pending_templates.  That's not easy because we have
no way to walk all the trees.  In the v2 patch, I use two vectors: one
to store function decls that may become consteval, and another to
remember references to immediate-escalating functions.  Unfortunately
the latter must also stash functions that call immediate-escalating
functions.  Consider:

  int g(int i)
  {
f(i); // f is immediate-escalating
  }

where g itself is not immediate-escalating, but we have to make sure
that if f gets promoted to consteval, we give an error.

A new option, -fno-immediate-escalation, is provided to suppress
escalating functions.

v2 also adds a new flag, DECL_ESCALATION_CHECKED_P, so that we don't
escalate a function multiple times, and so that we can distinguish between
explicitly consteval functions and functions that have been promoted
to consteval.

In v3, I removed one of the new vectors and changed the other one
to a hash set.  This version also contains numerous cleanups.

v4 merges find_escalating_expr_r into cp_fold_immediate_r.  It also
adds a new optimization in cp_fold_function.

v5 greatly simplifies the code.

v6 simplifies the code further and removes an ff_ flag.

v7 removes maybe_promote_function_to_consteval and further simplifies
cp_fold_immediate_r logic.

v8 removes maybe_store_immediate_escalating_fn.

PR c++/107687
PR c++/110997

gcc/c-family/ChangeLog:

* c-cppbuiltin.cc (c_cpp_builtins): Update __cpp_consteval.
* c-opts.cc (c_common_post_options): Pre-C++20, unset
flag_immediate_escalation.
* c.opt (fimmediate-escalation): New option.

gcc/cp/ChangeLog:

* call.cc (in_immediate_context): No longer static.
* constexpr.cc (cxx_eval_call_expression): Adjust assert.
* cp-gimplify.cc (deferred_escalating_exprs): 

[Bug target/112853] RISC-V: RVV: SPEC2017 525.x264 regression

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

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

--- Comment #3 from JuzheZhong  ---
Confirm. I will have a look at it.

[Bug tree-optimization/112843] during GIMPLE pass: bitintlower ICE: SIGSEGV in ranger_cache::range_of_expr (gimple-range-cache.cc:1204) with _BitInt() at -O1

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #9 from Andrew Macleod  ---
Created attachment 56790
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56790=edit
auxially patch to avid the trap

refining a range is fine...  the only issue we are really running into here
that is causing the trap is that the "update" on the original LHS DEF is a new
stmt which hasnt been added to the IL yet, so ranger is trapping when it asks
for the basic block of the def stmt.. It had one before, it expects it to still
have one when it looks at the context of the stmt to update the range.

Now that said, the update issue is primarily within the cache.  if we are
updating and the BB isn't set, we could simply just pick up the global value. 
Patch is attached, and pre-approved if you want to use it.

[Bug target/112813] [14 Regression] RISCV ICE: vsetvl pass: in merge at config/riscv/riscv-vsetvl.cc:1968 on rv32gcv_zvl256b

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

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

--- Comment #4 from Patrick O'Neill  ---
Fixed, thanks!

[Bug tree-optimization/111972] [14 regression] missed vectorzation for bool a = j != 1; j = (long int)a;

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

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

--- Comment #16 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:886f256ce3be4aa85f30af88558f0dfcb8003300

commit r14-6126-g886f256ce3be4aa85f30af88558f0dfcb8003300
Author: Andrew Pinski 
Date:   Sat Nov 11 20:33:28 2023 -0800

MATCH: Fix zero_one_valued_p's convert pattern

While working on PR 111972, I was getting a regression
due to zero_one_valued_p matching a signed 1 bit integer
when it came to convert. This patch fixes that by checking
the outer type too.

Bootstrapped and tested on x86_64-linux-gnu with no regressions.

gcc/ChangeLog:

* match.pd (zero_one_valued_p): For convert
make sure type is not a signed 1-bit integer.

Signed-off-by: Andrew Pinski 

[Bug target/112801] [14] RISC-V vector: failure to mask top bits during type conversion

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

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

--- Comment #6 from Patrick O'Neill  ---
Fixed, thanks!

[Bug ada/112781] [13/14 regression] ICE in generic instantiation

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

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

Eric Botcazou  changed:

   What|Removed |Added

Summary|[13?/14 regression] ICE in  |[13/14 regression] ICE in
   |generic instantiation   |generic instantiation
 CC||ebotcazou at gcc dot gnu.org
   Last reconfirmed||2023-12-04
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Eric Botcazou  ---
At least the program runs quietly when compiled with earlier compilers.

[Bug other/111288] formatting mistake in HTML documentation

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug ada/112821] unexpected Program_Error raised in the parser on mismatched []

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-12-04
 Status|UNCONFIRMED |NEW
 CC||ebotcazou at gcc dot gnu.org
Summary|GNAT issues bug box on  |unexpected Program_Error
   |mismatched []   |raised in the parser on
   ||mismatched []

--- Comment #1 from Eric Botcazou  ---
Missing guard in the parser indeed.

[Bug tree-optimization/112848] [14 regression] ICE compiling gcc.dg/tree-ssa/ssa-sink-16.c after r14-6114-gde0ab339a79535

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||pinskia at gcc dot gnu.org
   Target Milestone|--- |14.0

[Bug target/112816] [11/12/13 Regression] ICE unrecognizable_insn with __builtin_signbit and returning struct with int[4]

[a.elovikov at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Andrei Elovikov  ---
Created attachment 56789
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56789=edit
Another reproducer, now using short instead of int

Once the fix is ready, please verify the "uint16_t" version of it passes as
well. I'm not familiar with GCC internals to understand if it's a single crash
or two different issues. Godbolt link (same as the attached file):
https://godbolt.org/z/cEh1W7PdG .

[Bug tree-optimization/112848] [14 regression] ICE compiling gcc.dg/tree-ssa/ssa-sink-16.c after r14-6114-gde0ab339a79535

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-12-04
 Ever confirmed|0   |1
 CC||law at gcc dot gnu.org

--- Comment #2 from Jeffrey A. Law  ---
Also seeing on microblaze-linux.

[Bug tree-optimization/112843] during GIMPLE pass: bitintlower ICE: SIGSEGV in ranger_cache::range_of_expr (gimple-range-cache.cc:1204) with _BitInt() at -O1

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

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

--- Comment #8 from Jakub Jelinek  ---
Well, refining a range should be ok and I thought one would just flush caches
somewheres, so that next time it can be computed in more detail.
But, some local changes could be just temporary state until more code is
updated and that will be necessarily in some inconsistent state.
Anyway, I'm going to test my patch anyway because after thinking it through I
think such updating is the least worse of those 3 options for the update in
particular.

[Bug middle-end/112824] Stack spills and vector splitting with vector builtins

[elrodc at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Chris Elrod  ---
Hongtao Liu, I do think that one should ideally be able to get optimal codegen
when using 512-bit builtin vectors or vector intrinsics, without needing to set
`-mprefer-vector-width=512` (and, currently, also setting
`-mtune-ctrl=avx512_move_by_pieces`).

For example, if I remove `-mprefer-vector-width=512`, I get

prod(Dual, 2l>&, Dual, 2l> const&,
Dual, 2l> const&):
pushrbp
mov eax, -2
kmovb   k1, eax
mov rbp, rsp
and rsp, -64
sub rsp, 264
vmovdqa ymm4, YMMWORD PTR [rsi+128]
vmovapd zmm8, ZMMWORD PTR [rsi]
vmovapd zmm9, ZMMWORD PTR [rdx]
vmovdqa ymm6, YMMWORD PTR [rsi+64]
vmovdqa YMMWORD PTR [rsp+8], ymm4
vmovdqa ymm4, YMMWORD PTR [rdx+96]
vbroadcastsdzmm0, xmm8
vmovdqa ymm7, YMMWORD PTR [rsi+96]
vbroadcastsdzmm1, xmm9
vmovdqa YMMWORD PTR [rsp-56], ymm6
vmovdqa ymm5, YMMWORD PTR [rdx+128]
vmovdqa ymm6, YMMWORD PTR [rsi+160]
vmovdqa YMMWORD PTR [rsp+168], ymm4
vxorpd  xmm4, xmm4, xmm4
vaddpd  zmm0, zmm0, zmm4
vaddpd  zmm1, zmm1, zmm4
vmovdqa YMMWORD PTR [rsp-24], ymm7
vmovdqa ymm7, YMMWORD PTR [rdx+64]
vmovapd zmm3, ZMMWORD PTR [rsp-56]
vmovdqa YMMWORD PTR [rsp+40], ymm6
vmovdqa ymm6, YMMWORD PTR [rdx+160]
vmovdqa YMMWORD PTR [rsp+200], ymm5
vmulpd  zmm2, zmm0, zmm9
vmovdqa YMMWORD PTR [rsp+136], ymm7
vmulpd  zmm5, zmm1, zmm3
vbroadcastsdzmm3, xmm3
vmovdqa YMMWORD PTR [rsp+232], ymm6
vaddpd  zmm3, zmm3, zmm4
vmovapd zmm7, zmm2
vmovapd zmm2, ZMMWORD PTR [rsp+8]
vfmadd231pd zmm7{k1}, zmm8, zmm1
vmovapd zmm6, zmm5
vmovapd zmm5, ZMMWORD PTR [rsp+136]
vmulpd  zmm1, zmm1, zmm2
vfmadd231pd zmm6{k1}, zmm9, zmm3
vbroadcastsdzmm2, xmm2
vmovapd zmm3, ZMMWORD PTR [rsp+200]
vaddpd  zmm2, zmm2, zmm4
vmovapd ZMMWORD PTR [rdi], zmm7
vfmadd231pd zmm1{k1}, zmm9, zmm2
vmulpd  zmm2, zmm0, zmm5
vbroadcastsdzmm5, xmm5
vmulpd  zmm0, zmm0, zmm3
vbroadcastsdzmm3, xmm3
vaddpd  zmm5, zmm5, zmm4
vaddpd  zmm3, zmm3, zmm4
vfmadd231pd zmm2{k1}, zmm8, zmm5
vfmadd231pd zmm0{k1}, zmm8, zmm3
vaddpd  zmm2, zmm2, zmm6
vaddpd  zmm0, zmm0, zmm1
vmovapd ZMMWORD PTR [rdi+64], zmm2
vmovapd ZMMWORD PTR [rdi+128], zmm0
vzeroupper
leave
ret
prod(Dual, 2l>&, Dual, 2l> const&,
Dual, 2l> const&):
pushrbp
mov rbp, rsp
and rsp, -64
sub rsp, 648
vmovdqa ymm5, YMMWORD PTR [rsi+224]
vmovdqa ymm3, YMMWORD PTR [rsi+352]
vmovapd zmm0, ZMMWORD PTR [rdx+64]
vmovdqa ymm2, YMMWORD PTR [rsi+320]
vmovdqa YMMWORD PTR [rsp+104], ymm5
vmovdqa ymm5, YMMWORD PTR [rdx+224]
vmovdqa ymm7, YMMWORD PTR [rsi+128]
vmovdqa YMMWORD PTR [rsp+232], ymm3
vmovsd  xmm3, QWORD PTR [rsi]
vmovdqa ymm6, YMMWORD PTR [rsi+192]
vmovdqa YMMWORD PTR [rsp+488], ymm5
vmovdqa ymm4, YMMWORD PTR [rdx+192]
vmovapd zmm1, ZMMWORD PTR [rsi+64]
vbroadcastsdzmm5, xmm3
vmovdqa YMMWORD PTR [rsp+200], ymm2
vmovdqa ymm2, YMMWORD PTR [rdx+320]
vmulpd  zmm8, zmm5, zmm0
vmovdqa YMMWORD PTR [rsp+8], ymm7
vmovdqa ymm7, YMMWORD PTR [rsi+256]
vmovdqa YMMWORD PTR [rsp+72], ymm6
vmovdqa ymm6, YMMWORD PTR [rdx+128]
vmovdqa YMMWORD PTR [rsp+584], ymm2
vmovsd  xmm2, QWORD PTR [rdx]
vmovdqa YMMWORD PTR [rsp+136], ymm7
vmovdqa ymm7, YMMWORD PTR [rdx+256]
vmovdqa YMMWORD PTR [rsp+392], ymm6
vmovdqa ymm6, YMMWORD PTR [rdx+352]
vmulsd  xmm10, xmm3, xmm2
vmovdqa YMMWORD PTR [rsp+456], ymm4
vbroadcastsdzmm4, xmm2
vfmadd231pd zmm8, zmm4, zmm1
vmovdqa YMMWORD PTR [rsp+520], ymm7
vmovdqa YMMWORD PTR [rsp+616], ymm6
vmulpd  zmm9, zmm4, ZMMWORD PTR [rsp+72]
vmovsd  xmm6, QWORD PTR [rsp+520]
vmulpd  zmm4, zmm4, ZMMWORD PTR [rsp+200]
vmulpd  zmm11, zmm5, ZMMWORD PTR [rsp+456]
vmovsd  QWORD PTR [rdi], xmm10
vmulpd  zmm5, zmm5, ZMMWORD PTR [rsp+584]
vmovapd ZMMWORD PTR [rdi+64], zmm8
vfmadd231pd zmm9, zmm0, QWORD PTR [rsp+8]{1to8}
vfmadd231pd zmm4, zmm0, QWORD PTR [rsp+136]{1to8}
vmovsd  xmm0, QWORD PTR [rsp+392]
vmulsd  xmm7, xmm3, xmm0
vbroadcastsdzmm0, xmm0
vmulsd  xmm3, xmm3, xmm6
vfmadd132pd zmm0, zmm11, zmm1
vbroadcastsdzmm6, xmm6
vfmadd132pd zmm1, zmm5, zmm6
vfmadd231sd xmm7, xmm2, QWORD PTR [rsp+8]
vfmadd132sd  

[Bug tree-optimization/112843] during GIMPLE pass: bitintlower ICE: SIGSEGV in ranger_cache::range_of_expr (gimple-range-cache.cc:1204) with _BitInt() at -O1

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #7 from Andrew Macleod  ---
(In reply to Jakub Jelinek from comment #6)
> (In reply to Andrew Macleod from comment #5)
> > what do you mean?  when a statement is changed, it may generate a different
> > range than it did before,
> 
> No, that would be a bug.  If some IL changes need to extend existing range,
> then
> reset_flow_sensitive_info needs to be called for the SSA_NAME.

Not from rangers point of view.  You may change 
_1 = _2 + 5
to
_1 = _6 + 5  
and it finds it has a better understanding of the range of _6, and so it can
further refine the range for _1 based on that.So it merely checks to see if
the changes to the statement means it can understand it better.  In particular: 
  const char *lossage = _result ? "constant string" : 0;

  if (__builtin_expect (lossage != ((void *)0) , 0))
{
unsigned __message_length = __builtin_strlen (lossage);
if (! __builtin_constant_p (__message_length))
  dead ();
}

This provides an IL update which happens later in compilation when
builtin_expect gives us a rbetter result which gives us a much better range and
can then fold away the call to dead()


> 
> > so we re-evaluate the statement to see if the
> > result is different.  If it is, then we update it in the cache.
> > 
> > All its doing is re-calculating and updating the cache values.
> > 
> > It looks to me like the problem is the stmt is being added in a way that
> > leaves the IL in an illegal state,
> 
> But unfortunately that is pretty much unavoidable in changes like this.
> So, I have
>   lhs1 = some_stmt;
> and want to change it to
>   lhs2 = some_stmt;
>   lhs1 = (lhs_type) lhs2;
> (where lhs2 has a different type from lhs).
> The options to do that are either what the code does right now, i.e.
> first create lhs1 = (lhs_type) lhs2; stmt, add it after lhs1 = some_stmt;
> (including update_stmt), then gimple_set_lhs on the first stmt to lhs2, then
> update_stmt on the first stmt, but this is temporarily invalid IL, because
> two different stmts in the IL have the same lhs, or as changed in the patch
> gimple_set_lhs on the first stmt to lhs2 (but no update_stmt), create the
> second stmt, add it including update_stmt, then update_stmt on the first
> one; this is also invalid IL, the effects of update_stmt haven't been done
> until the second update_stmt; or gimple_set_lhs and update_stmt on the first
> one (but then lhs1 has no definition and we insert a stmt into the IL
> without the definition, so again temporarily invalid IL).

Im still confused tho.

So what I think you are doing is taking
lhs1 = some_stmt
and rewriting it to a different type, and it looks like looping thru the
operands so that some_stmt is consuming the right types too..  so the type of
some_stmt is changing from lhs1_type to lhs2_type.  adn then we create  a new
stmt for lhs1.

to avoid lying why dont we just create a new stmt  'g' before stmt 
lhs2 = some_stmt
with the operands converted and then when that is done, simply update stmt
lhs1 = (lhs1_type) lhs2

the the IL is never in an invalid state?

Otherwise if we are going to have invalid IL states, we have to turn off any
automatic updating...   you could possible just save all the update/sets until
the end.. that might work.The biggest issue would be that lhs1 was in the
IL so ranger expects the block to be set for its def stmt and it is being added
via a new stmt whic is not in the IL yet when the update happens... its
expects gimple_bb to be set for a DEF that it has seen.


Isn't the "normal" way to do this to leave
lhs1 = some_stmt
and then add
lhs2 = (lhs2_type) lhs1
and  follow immeidate uses and change all the occurences of lhs1 to lhs2?

[Bug tree-optimization/112848] [14 regression] ICE compiling gcc.dg/tree-ssa/ssa-sink-16.c after r14-6114-gde0ab339a79535

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

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

--- Comment #1 from seurer at gcc dot gnu.org ---
Of course it fails with r14-6114 as that is the source.  Doh!  I was looking at
pr112827.

[Bug tree-optimization/112848] New: [14 regression] ICE compiling gcc.dg/tree-ssa/ssa-sink-16.c after r14-6114-gde0ab339a79535

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

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

Bug ID: 112848
   Summary: [14 regression] ICE compiling
gcc.dg/tree-ssa/ssa-sink-16.c after
r14-6114-gde0ab339a79535
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:de0ab339a795352c843f6e9b2dfce222f26588de, r14-6114-gde0ab339a79535
make  -k check-gcc RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/ssa-sink-16.c"
FAIL: gcc.dg/tree-ssa/ssa-sink-16.c (internal compiler error: verify_gimple
failed)
FAIL: gcc.dg/tree-ssa/ssa-sink-16.c (test for excess errors)
# of expected passes1
# of unexpected failures2
# of unresolved testcases   1


commit de0ab339a795352c843f6e9b2dfce222f26588de (HEAD)
Author: Richard Biener 
Date:   Mon Dec 4 10:46:11 2023 +0100

tree-optimization/112827 - corrupt SCEV cache during SCCP


spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-16.c
-fdiagnostics-plain-output -O2 -fno-tree-pre -fno-tree-dominator-opts
-fdump-tree-sink -fdump-tree-optimized -S -o ssa-sink-16.s
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-16.c: In
function 'f':
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-16.c:5:5:
error: gimple_bb (stmt) is set to a wrong basic block
j_5 = __builtin_ffs (30);
during GIMPLE pass: sccp
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-16.c:5:5:
internal compiler error: verify_gimple failed
0x10d6df93 verify_gimple_in_cfg(function*, bool, bool)
/home/seurer/gcc/git/gcc-test/gcc/tree-cfg.cc:5662
0x10b5041f execute_function_todo
/home/seurer/gcc/git/gcc-test/gcc/passes.cc:2088
0x10b513eb do_per_function
/home/seurer/gcc/git/gcc-test/gcc/passes.cc:1687
0x10b5160b execute_todo
/home/seurer/gcc/git/gcc-test/gcc/passes.cc:2142


Note that this is not fixed by
r14-6114-gde0ab339a795352c843f6e9b2dfce222f26588de as it still occurs with
r14-6120.

[Bug tree-optimization/105616] Using regex_replace throws "maybe-uninitialized" warnings with -fsanitize=address

[jg at jguk dot org via Gcc-bugs]

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

Jonny Grant  changed:

   What|Removed |Added

 CC||jg at jguk dot org

--- Comment #5 from Jonny Grant  ---
The godbolt link shows the issue on the trunk.

I see this in 13.2.0 myself.

[Bug c++/112842] Constrained parameter pack with trailing param gives no matching function.

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

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

Patrick Palka  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-12-04
 Ever confirmed|0   |1

--- Comment #2 from Patrick Palka  ---
Confirmed.  Seems similar to PR84796 which also involves partial instantiation
of a template parameter pack of a member template.

[Bug tree-optimization/112843] during GIMPLE pass: bitintlower ICE: SIGSEGV in ranger_cache::range_of_expr (gimple-range-cache.cc:1204) with _BitInt() at -O1

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

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

--- Comment #6 from Jakub Jelinek  ---
(In reply to Andrew Macleod from comment #5)
> what do you mean?  when a statement is changed, it may generate a different
> range than it did before,

No, that would be a bug.  If some IL changes need to extend existing range,
then
reset_flow_sensitive_info needs to be called for the SSA_NAME.

> so we re-evaluate the statement to see if the
> result is different.  If it is, then we update it in the cache.
> 
> All its doing is re-calculating and updating the cache values.
> 
> It looks to me like the problem is the stmt is being added in a way that
> leaves the IL in an illegal state,

But unfortunately that is pretty much unavoidable in changes like this.
So, I have
  lhs1 = some_stmt;
and want to change it to
  lhs2 = some_stmt;
  lhs1 = (lhs_type) lhs2;
(where lhs2 has a different type from lhs).
The options to do that are either what the code does right now, i.e.
first create lhs1 = (lhs_type) lhs2; stmt, add it after lhs1 = some_stmt;
(including update_stmt), then gimple_set_lhs on the first stmt to lhs2, then
update_stmt on the first stmt, but this is temporarily invalid IL, because two
different stmts in the IL have the same lhs, or as changed in the patch
gimple_set_lhs on the first stmt to lhs2 (but no update_stmt), create the
second stmt, add it including update_stmt, then update_stmt on the first one;
this is also invalid IL, the effects of update_stmt haven't been done until the
second update_stmt; or gimple_set_lhs and update_stmt on the first one (but
then lhs1 has no definition and we insert a stmt into the IL without the
definition, so again temporarily invalid IL).

[Bug tree-optimization/112843] during GIMPLE pass: bitintlower ICE: SIGSEGV in ranger_cache::range_of_expr (gimple-range-cache.cc:1204) with _BitInt() at -O1

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #5 from Andrew Macleod  ---
(In reply to Richard Biener from comment #3)
> (In reply to Richard Biener from comment #2)
> > what?!  Ick.  It definitely shouldn't re-fold anything but only scrap caches
> > _at most_.
> 
> So it does
> 
>   // Only update if it already had a value.
>   if (m_cache.get_global_range (r, lhs))
> {
>   // Re-calculate a new value using just cache values.
>   Value_Range tmp (TREE_TYPE (lhs));
>   fold_using_range f;
>   fur_stmt src (s, _cache);
>   f.fold_stmt (tmp, s, src, lhs);
> 
>   // Combine the new value with the old value to check for a change.
>   if (r.intersect (tmp))
> {
>   if (dump_file && (dump_flags & TDF_DETAILS))
> {
>   print_generic_expr (dump_file, lhs, TDF_SLIM);
>   fprintf (dump_file, " : global value re-evaluated to ");
>   r.dump (dump_file);
>   fputc ('\n', dump_file);
> }
>   m_cache.set_global_range (lhs, r);
> 
> WTF?  If a pass invalidates a range it needs to properly do this itself.
> But update_stmt itself _never_ should alter range info.

what do you mean?  when a statement is changed, it may generate a different
range than it did before, so we re-evaluate the statement to see if the result
is different.  If it is, then we update it in the cache.

All its doing is re-calculating and updating the cache values.

It looks to me like the problem is the stmt is being added in a way that leaves
the IL in an illegal state,

tree lhs2 = make_ssa_name (type);
gimple *g = gimple_build_assign (lhs, NOP_EXPR, lhs2);
if (stmt_ends_bb_p (stmt))
  {
edge e = find_fallthru_edge (gsi_bb (gsi)->succs);
gsi_insert_on_edge_immediate (e, g);
  }
else
  gsi_insert_after (, g, GSI_SAME_STMT);
gimple_set_lhs (stmt, lhs2);

(gdb) p print_generic_expr (stderr, lhs, 0)
_1$3 = void
(gdb) p print_generic_expr (stderr, lhs2, 0)
_12$4 = void
(gdb) p print_gimple_stmt (stderr, stmt, 0, 0)
_1 = x_4(D) * 5;
$5 = void
(gdb) p print_gimple_stmt (stderr, g, 0, 0)
_1 = (_BitInt(128)) _12;
$6 = void

So we have 
_1 = x_4(D) * 5;
then we create 
_1 = (_BitInt(128)) _12;
And add it to the IL...  and finally change the original stmt to 
_12 = x_4(D) * 5

how is that right?  _1 is now a different type?  but regardless, we have 2
statements with _1 as a LHS for a brief time.

And rangers real complaint is that we have a range for _1, but its being
updated by a stmt which is not actually in the IL yet during this update.. so
it is finding no basic block info for an SSA name which is thinks its knows
something about already because it WAS in the IL.

It also does not seem correct to me that you can take an existing SSA_NAME and
change its type on the fly while its still being used in the IL?   Once we
create an ssa name, I thought it was immutable from a type point of view untl
deleted and reused?

(gdb) p print_generic_expr (stderr, lhs->typed.type, 0)
_BitInt(128)$7 = void
(gdb) p print_generic_expr (stderr, lhs2->typed.type, 0)
int128_t$8 = void

[Bug c++/112847] [14 Regression] nvptx: 'FAIL: g++.dg/cpp2a/concepts-explicit-inst1.C -std=c++20 scan-assembler _Z1gI1XEvT_', 'scan-assembler _Z1gI1YEvT_'

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Thomas Schwinge  ---
Same as for PR112846, the issue disappears if I revert commit
r14-6064-gc3f281a0c1ca50e4df5049923aa2f5d1c3c39ff6 "c++: mangle function
template constraints".  I don't know yet (a) what that means, and (b) why nvptx
target behaves differently from everything else.

[Bug c++/112846] [14 Regression] nvptx: 'FAIL: g++.dg/abi/anon6.C -std=c++20 scan-assembler _Z5dummyIXtl8wrapper1IdEtlNS1_Ut_Edi9RightNametlNS2_Ut_Edi9RightNameLd405ec00000000000EEEEEEvv'

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

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

Thomas Schwinge  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=112847
 CC||jason at gcc dot gnu.org

--- Comment #1 from Thomas Schwinge  ---
Same as for PR112847, the issue disappears if I revert commit
r14-6064-gc3f281a0c1ca50e4df5049923aa2f5d1c3c39ff6 "c++: mangle function
template constraints".  I don't know yet (a) what that means, and (b) why nvptx
target behaves differently from everything else.

[Bug target/112845] [11/12/13/14 Regression] ICE: in extract_insn, at recog.cc:2804 with -Os -fcf-protection -c since r8-3504

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

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 56788
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56788=edit
gcc14-pr112845.patch

Untested fix.

[Bug target/112845] [11/12/13/14 Regression] ICE: in extract_insn, at recog.cc:2804 with -Os -fcf-protection -c since r8-3504

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |11.5

[Bug target/112845] [11/12/13/14 Regression] ICE: in extract_insn, at recog.cc:2804 with -Os -fcf-protection -c since r8-3504

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Last reconfirmed||2023-12-04
 Status|UNCONFIRMED |ASSIGNED
 CC||jakub at gcc dot gnu.org
Summary|ICE: in extract_insn, at|[11/12/13/14 Regression]
   |recog.cc:2804 with -Os  |ICE: in extract_insn, at
   |-fcf-protection -c  |recog.cc:2804 with -Os
   ||-fcf-protection -c since
   ||r8-3504
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Guess introduced by my r8-3504-g2891beff1aa8e627ba27b35d28d6a8e6198a0625

[Bug c++/112847] New: [14 Regression] nvptx: 'FAIL: g++.dg/cpp2a/concepts-explicit-inst1.C -std=c++20 scan-assembler _Z1gI1XEvT_', 'scan-assembler _Z1gI1YEvT_'

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

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

Bug ID: 112847
   Summary: [14 Regression] nvptx: 'FAIL:
g++.dg/cpp2a/concepts-explicit-inst1.C  -std=c++20
scan-assembler _Z1gI1XEvT_', 'scan-assembler
_Z1gI1YEvT_'
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: vries at gcc dot gnu.org
  Target Milestone: ---
Target: nvptx

For nvptx target, something in Git
r14-5829-g449b6b817ed76173e6475debd02b195ea9dab0a0..r14-6074-gb74981b5cf32ebf4bfffd25e7174b5c80243447a
regresses:

UNSUPPORTED: g++.dg/cpp2a/concepts-explicit-inst1.C  -std=c++98
UNSUPPORTED: g++.dg/cpp2a/concepts-explicit-inst1.C  -std=c++14
UNSUPPORTED: g++.dg/cpp2a/concepts-explicit-inst1.C  -std=c++17
PASS: g++.dg/cpp2a/concepts-explicit-inst1.C  -std=c++20 (test for excess
errors)
[-PASS:-]{+FAIL:+} g++.dg/cpp2a/concepts-explicit-inst1.C  -std=c++20 
scan-assembler _Z1gI1XEvT_
[-PASS:-]{+FAIL:+} g++.dg/cpp2a/concepts-explicit-inst1.C  -std=c++20 
scan-assembler _Z1gI1YEvT_
PASS: g++.dg/cpp2a/concepts-explicit-inst1.C  -std=c++20  scan-assembler
_Z1gIiEvT_

--- concepts-explicit-inst1.s   2023-12-04 12:44:38.047527549 +0100
+++ concepts-explicit-inst1.s   2023-12-04 12:44:20.675703887 +0100
@@ -26,2 +26,2 @@
-// BEGIN GLOBAL FUNCTION DECL: _Z1gI1XEvT_
-.weak .func _Z1gI1XEvT_ (.param.u64 %in_ar0);
+// BEGIN GLOBAL FUNCTION DECL: _Z1gITk1D1XEvT_
+.weak .func _Z1gITk1D1XEvT_ (.param.u64 %in_ar0);
@@ -29,2 +29,2 @@
-// BEGIN GLOBAL FUNCTION DEF: _Z1gI1XEvT_
-.weak .func _Z1gI1XEvT_ (.param.u64 %in_ar0)
+// BEGIN GLOBAL FUNCTION DEF: _Z1gITk1D1XEvT_
+.weak .func _Z1gITk1D1XEvT_ (.param.u64 %in_ar0)
@@ -46,2 +46,2 @@
-// BEGIN GLOBAL FUNCTION DECL: _Z1gI1YEvT_
-.weak .func _Z1gI1YEvT_ (.param.u64 %in_ar0);
+// BEGIN GLOBAL FUNCTION DECL: _Z1gITk1C1YEvT_
+.weak .func _Z1gITk1C1YEvT_ (.param.u64 %in_ar0);
@@ -49,2 +49,2 @@
-// BEGIN GLOBAL FUNCTION DEF: _Z1gI1YEvT_
-.weak .func _Z1gI1YEvT_ (.param.u64 %in_ar0)
+// BEGIN GLOBAL FUNCTION DEF: _Z1gITk1C1YEvT_
+.weak .func _Z1gITk1C1YEvT_ (.param.u64 %in_ar0)

[Bug c++/112846] New: [14 Regression] nvptx: 'FAIL: g++.dg/abi/anon6.C -std=c++20 scan-assembler _Z5dummyIXtl8wrapper1IdEtlNS1_Ut_Edi9RightNametlNS2_Ut_Edi9RightNameLd405ec00000000000EEEEEEvv'

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

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

Bug ID: 112846
   Summary: [14 Regression] nvptx: 'FAIL: g++.dg/abi/anon6.C
-std=c++20  scan-assembler
_Z5dummyIXtl8wrapper1IdEtlNS1_Ut_Edi9RightNametlNS2_Ut
_Edi9RightNameLd405ec000EEvv'
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: vries at gcc dot gnu.org
  Target Milestone: ---
Target: nvptx

For nvptx target, something in Git
r14-5829-g449b6b817ed76173e6475debd02b195ea9dab0a0..r14-6074-gb74981b5cf32ebf4bfffd25e7174b5c80243447a
regresses:

UNSUPPORTED: g++.dg/abi/anon6.C  -std=c++98
UNSUPPORTED: g++.dg/abi/anon6.C  -std=c++14
UNSUPPORTED: g++.dg/abi/anon6.C  -std=c++17
PASS: g++.dg/abi/anon6.C  -std=c++20 (test for excess errors)
[-PASS:-]{+FAIL:+} g++.dg/abi/anon6.C  -std=c++20  scan-assembler
_Z5dummyIXtl8wrapper1IdEtlNS1_Ut_Edi9RightNametlNS2_Ut_Edi9RightNameLd405ec000EEvv

--- anon6.s 2023-12-04 12:22:40.631978250 +0100
+++ anon6.s 2023-12-04 12:22:21.592135699 +0100
@@ -8,2 +8,2 @@
-// BEGIN GLOBAL FUNCTION DECL:
_Z5dummyIXtl8wrapper1IdEtlNS1_Ut_Edi9RightNametlNS2_Ut_Edi9RightNameLd405ec000EEvv
-.weak .func
_Z5dummyIXtl8wrapper1IdEtlNS1_Ut_Edi9RightNametlNS2_Ut_Edi9RightNameLd405ec000EEvv;
+// BEGIN GLOBAL FUNCTION DECL:
_Z5dummyITnDaXtl8wrapper1IdEtlNS1_Ut_Edi9RightNametlNS2_Ut_Edi9RightNameLd405ec000EEvv
+.weak .func
_Z5dummyITnDaXtl8wrapper1IdEtlNS1_Ut_Edi9RightNametlNS2_Ut_Edi9RightNameLd405ec000EEvv;
@@ -11,2 +11,2 @@
-// BEGIN GLOBAL FUNCTION DEF:
_Z5dummyIXtl8wrapper1IdEtlNS1_Ut_Edi9RightNametlNS2_Ut_Edi9RightNameLd405ec000EEvv
-.weak .func
_Z5dummyIXtl8wrapper1IdEtlNS1_Ut_Edi9RightNametlNS2_Ut_Edi9RightNameLd405ec000EEvv
+// BEGIN GLOBAL FUNCTION DEF:
_Z5dummyITnDaXtl8wrapper1IdEtlNS1_Ut_Edi9RightNametlNS2_Ut_Edi9RightNameLd405ec000EEvv
+.weak .func
_Z5dummyITnDaXtl8wrapper1IdEtlNS1_Ut_Edi9RightNametlNS2_Ut_Edi9RightNameLd405ec000EEvv
@@ -26 +26 @@
-   call
_Z5dummyIXtl8wrapper1IdEtlNS1_Ut_Edi9RightNametlNS2_Ut_Edi9RightNameLd405ec000EEvv;
+   call
_Z5dummyITnDaXtl8wrapper1IdEtlNS1_Ut_Edi9RightNametlNS2_Ut_Edi9RightNameLd405ec000EEvv;

[Bug tree-optimization/112785] ICE: in duplicate_insn_chain, at cfgrtl.cc:4386 with -O1 -funroll-all-loops --param=max-unroll-times=100000 --param=max-average-unrolled-insns=1000000 --param=max-unroll

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Fixed.

[Bug tree-optimization/112785] ICE: in duplicate_insn_chain, at cfgrtl.cc:4386 with -O1 -funroll-all-loops --param=max-unroll-times=100000 --param=max-average-unrolled-insns=1000000 --param=max-unroll

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Richard Biener :

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

commit r14-6120-g0c2ea80a4ffbddc0bc29f5badaf2ae43e59483b2
Author: Richard Biener 
Date:   Mon Dec 4 14:50:59 2023 +0100

middle-end/112785 - guard against last_clique overflow

The PR shows that we'll ICE eventually when last_clique wraps.  The
following avoids this by refusing to hand out new cliques after
exhausting them.  We then use zero (no clique) as conservative
fallback.

PR middle-end/112785
* function.h (get_new_clique): New inline function handling
last_clique overflow.
* cfgrtl.cc (duplicate_insn_chain): Use it.
* tree-cfg.cc (gimple_duplicate_bb): Likewise.
* tree-inline.cc (remap_dependence_clique): Likewise.

[Bug tree-optimization/112843] during GIMPLE pass: bitintlower ICE: SIGSEGV in ranger_cache::range_of_expr (gimple-range-cache.cc:1204) with _BitInt() at -O1

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

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

--- Comment #4 from Richard Biener  ---
(In reply to Richard Biener from comment #3)
> (In reply to Richard Biener from comment #2)
> > what?!  Ick.  It definitely shouldn't re-fold anything but only scrap caches
> > _at most_.
> 
> So it does
> 
>   // Only update if it already had a value.
>   if (m_cache.get_global_range (r, lhs))
> {
>   // Re-calculate a new value using just cache values.
>   Value_Range tmp (TREE_TYPE (lhs));
>   fold_using_range f;
>   fur_stmt src (s, _cache);
>   f.fold_stmt (tmp, s, src, lhs);
> 
>   // Combine the new value with the old value to check for a change.
>   if (r.intersect (tmp))
> {
>   if (dump_file && (dump_flags & TDF_DETAILS))
> {
>   print_generic_expr (dump_file, lhs, TDF_SLIM);
>   fprintf (dump_file, " : global value re-evaluated to ");
>   r.dump (dump_file);
>   fputc ('\n', dump_file);
> }
>   m_cache.set_global_range (lhs, r);
> 
> WTF?  If a pass invalidates a range it needs to properly do this itself.
> But update_stmt itself _never_ should alter range info.

At least the testcase that was added with it still passes when I remove
the call to get_range_query (fn)->update_stmt

[Bug tree-optimization/112843] during GIMPLE pass: bitintlower ICE: SIGSEGV in ranger_cache::range_of_expr (gimple-range-cache.cc:1204) with _BitInt() at -O1

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

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

--- Comment #3 from Richard Biener  ---
(In reply to Richard Biener from comment #2)
> what?!  Ick.  It definitely shouldn't re-fold anything but only scrap caches
> _at most_.

So it does

  // Only update if it already had a value.
  if (m_cache.get_global_range (r, lhs))
{
  // Re-calculate a new value using just cache values.
  Value_Range tmp (TREE_TYPE (lhs));
  fold_using_range f;
  fur_stmt src (s, _cache);
  f.fold_stmt (tmp, s, src, lhs);

  // Combine the new value with the old value to check for a change.
  if (r.intersect (tmp))
{
  if (dump_file && (dump_flags & TDF_DETAILS))
{
  print_generic_expr (dump_file, lhs, TDF_SLIM);
  fprintf (dump_file, " : global value re-evaluated to ");
  r.dump (dump_file);
  fputc ('\n', dump_file);
}
  m_cache.set_global_range (lhs, r);

WTF?  If a pass invalidates a range it needs to properly do this itself.
But update_stmt itself _never_ should alter range info.

[Bug tree-optimization/112843] during GIMPLE pass: bitintlower ICE: SIGSEGV in ranger_cache::range_of_expr (gimple-range-cache.cc:1204) with _BitInt() at -O1

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #2 from Richard Biener  ---
what?!  Ick.  It definitely shouldn't re-fold anything but only scrap caches
_at most_.

[Bug tree-optimization/112843] during GIMPLE pass: bitintlower ICE: SIGSEGV in ranger_cache::range_of_expr (gimple-range-cache.cc:1204) with _BitInt() at -O1

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 56787
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56787=edit
gcc14-pr112843.patch

Oops, ranger does some stuff during update_stmt.  Afraid updates of the IL will
be quite hard with that...

[Bug target/112845] New: ICE: in extract_insn, at recog.cc:2804 with -Os -fcf-protection -c

[iamanonymous.cs at gmail dot com via Gcc-bugs]

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

Bug ID: 112845
   Summary: ICE: in extract_insn, at recog.cc:2804 with -Os
-fcf-protection -c
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iamanonymous.cs at gmail dot com
  Target Milestone: ---

***
OS and Platform:
$ uname -a:
Linux ubuntu 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023
x86_64 x86_64 x86_64 GNU/Linux
***
gcc version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/root/gcc_set/202311291030/bin/gcc
COLLECT_LTO_WRAPPER=/root/gcc_set/202311291030/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/root/gcc_set/202311291030
--with-gmp=/root/build_essential --with-mpfr=/root/build_essential
--with-mpc=/root/build_essential --enable-languages=c,c++ --disable-multilib
--with-sanitizer=address,undefined,thread,leak
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231129 (experimental) (GCC) 

git version: 99fa0bfd63d97825c4221dcd3123940f1d0e6291
***
Program:
$ cat mutant.c
#ifdef __x86_64__
#define ENDBR_IMMEDIATE 0xfa1e0ff3
#else
#define ENDBR_IMMEDIATE 0xfb1e0ff3
#endif

int
func (int* p)
{
  return *(p + ENDBR_IMMEDIATE);
}

***
Command Lines:
$ gcc -Os -fcf-protection -c mutant.c
mutant.c: In function ‘func’:
mutant.c:11:1: error: unrecognizable insn:
   11 | }
  | ^
(insn 27 7 28 2 (set (reg:DI 0 ax [101])
(const_int 4196274163 [0xfa1e0ff3])) "mutant.c":10:10 discrim 1 -1
 (nil))
during RTL pass: cprop_hardreg
mutant.c:11:1: internal compiler error: in extract_insn, at recog.cc:2804
0x7e504e _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.cc:108
0x7e506a _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.cc:116
0x7e3572 extract_insn(rtx_insn*)
../../gcc/gcc/recog.cc:2804
0xf7209b extract_constrain_insn(rtx_insn*)
../../gcc/gcc/recog.cc:2703
0xf7b182 copyprop_hardreg_forward_1
../../gcc/gcc/regcprop.cc:836
0xf7c389 execute
../../gcc/gcc/regcprop.cc:1423
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.

Also ICE on trunk, compiler explorer: https://godbolt.org/z/d3x5sbG7W

[Bug target/112431] RISC-V GCC-15 feature: Support register overlap on widen RVV instructions

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

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

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

https://gcc.gnu.org/g:018ba3ac952bed4ae01344c060360f13f7cc084a

commit r14-6118-g018ba3ac952bed4ae01344c060360f13f7cc084a
Author: Juzhe-Zhong 
Date:   Mon Dec 4 21:44:56 2023 +0800

RISC-V: Fix overlap group incorrect overlap on v0

In serious high register pressure case (appended in this patch):

We see vluxei8.v   v0,(s1),v1,v0.t which is not allowed.
Since according to RVV ISA:

+;; The destination vector register group for a masked vector instruction
cannot overlap the source mask register (v0),
+;; unless the destination vector register is being written with a mask
value (e.g., compares) or the scalar result of a reduction.

Such case doesn't have spillings, however, we expect such case should be
spilled and reload data.

The rootcause is I made a mistake in previous patch on matching dest
operand and mask operand constraints:

dest: "=vr"
mask: "vmWc1"

After this patch:

dest: "vd,vr"
mask: "vm,Wc1"

make EEW widening pattern are same as other instruction patterns.

PR target/112431

gcc/ChangeLog:

* config/riscv/vector.md: Fix incorrect overlap in v0.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/pr112431-34.c: New test.

[Bug c/105510] error: initializer element is not constant

[andy.shevchenko at gmail dot com via Gcc-bugs]

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

Andy Shevchenko  changed:

   What|Removed |Added

 CC||andy.shevchenko at gmail dot 
com

--- Comment #5 from Andy Shevchenko  ---
Isn't this a dup of bug #71713?