[Bug c++/112795] [C++>=14] ICE pragma GCC unroll (n) cxx_eval_constant_expression

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

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

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

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

commit r14-6107-gb6c78feea08c36e5754818c6a3d7536b3f8913dc
Author: Jakub Jelinek 
Date:   Mon Dec 4 08:59:15 2023 +0100

c++: #pragma GCC unroll C++ fixes [PR112795]

foo in the unroll-5.C testcase ICEs because cp_parser_pragma_unroll
during parsing calls maybe_constant_value unconditionally, which is
fine if !processing_template_decl, but can ICE otherwise.

While just calling fold_non_dependent_expr there instead could be enough
to fix the ICE (and I guess the right thing to do for backports if any),
I don't see a reason why we couldn't handle a dependent #pragma GCC unroll
argument as well, the unrolling isn't done in the FE and all the middle-end
cares about is that ANNOTATE_EXPR has a 1..65534 last operand when it is
annot_expr_unroll_kind.

So, the following patch changes all the unsigned short unroll arguments
to tree unroll (and thus avoids the tree -> unsigned short -> tree
conversions), does the type and value checking during parsing only if
the argument isn't dependent and repeats it during instantiation.

2023-12-04  Jakub Jelinek  

PR c++/112795
gcc/cp/
* cp-tree.h (cp_convert_range_for): Change UNROLL type from
unsigned short to tree.
(finish_while_stmt_cond, finish_do_stmt, finish_for_cond):
Likewise.
* parser.cc (cp_parser_statement): Pass NULL_TREE rather than 0 to
cp_parser_iteration_statement UNROLL argument.
(cp_parser_for, cp_parser_c_for): Change UNROLL type from
unsigned short to tree.
(cp_parser_range_for): Likewise.  Set RANGE_FOR_UNROLL to just
UNROLL
rather than build_int_cst from it.
(cp_convert_range_for, cp_parser_iteration_statement): Change
UNROLL
type from unsigned short to tree.
(cp_parser_omp_loop_nest): Pass NULL_TREE rather than 0 to
cp_parser_range_for UNROLL argument.
(cp_parser_pragma_unroll): Return tree rather than unsigned short.
If parsed expression is type dependent, just return it, don't
diagnose
issues with value if it is value dependent.
(cp_parser_pragma): Change UNROLL type from unsigned short to tree.
* semantics.cc (finish_while_stmt_cond): Change UNROLL type from
unsigned short to tree.  Build ANNOTATE_EXPR with UNROLL as its
last
operand rather than build_int_cst from it.
(finish_do_stmt, finish_for_cond): Likewise.
* pt.cc (tsubst_stmt) : Change UNROLL type
from
unsigned short to tree and set it to RECUR on RANGE_FOR_UNROLL (t).
(tsubst_expr) : For annot_expr_unroll_kind
repeat
checks on UNROLL value from cp_parser_pragma_unroll.
gcc/testsuite/
* g++.dg/ext/unroll-5.C: New test.
* g++.dg/ext/unroll-6.C: New test.

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

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

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

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

https://gcc.gnu.org/g:994d6dc64435d6b7c50accca9941ee7decd92a22

commit r14-6108-g994d6dc64435d6b7c50accca9941ee7decd92a22
Author: Jakub Jelinek 
Date:   Mon Dec 4 09:00:18 2023 +0100

i386: Fix up signbit2 expander [PR112816]

The following testcase ICEs, because the signbit2 expander uses an
explicit SUBREG in the pattern around match_operand with register_operand
predicate.  If we are unlucky enough that expansion tries to expand it
with some SUBREG as operands[1], we have two nested SUBREGs in the IL,
which is not valid and causes ICE later.

2023-12-04  Jakub Jelinek  

PR target/112816
* config/i386/sse.md (signbit2): Force operands[1] into a
REG.

* gcc.target/i386/sse2-pr112816.c: New test.

[Bug target/112837] [12/13/14 Regression] ICE: RTL check: expected elt 1 type 'i' or 'n', have 'e' (rtx plus) in ix86_elim_entry_set_got, at config/i386/i386.cc:8612 with -fcompare-elim -fpie -fprofil

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

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

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

https://gcc.gnu.org/g:4586d7d0a92e9b60d0c01043e0ae262b1e06f337

commit r14-6109-g4586d7d0a92e9b60d0c01043e0ae262b1e06f337
Author: Jakub Jelinek 
Date:   Mon Dec 4 09:01:09 2023 +0100

i386: Fix rtl checking ICE in ix86_elim_entry_set_got [PR112837]

The following testcase ICEs with RTL checking, because it sets if
XINT (SET_SRC (set), 1) is UNSPEC_SET_GOT without checking if SET_SRC (set)
is actually an UNSPEC, so any time we see any other insn with PARALLEL
and a SET in it which is not an UNSPEC we ICE during RTL checking or
access there some other union member as if it was an rt_int.
The rest is just small cleanup.

2023-12-04  Jakub Jelinek  

PR target/112837
* config/i386/i386.cc (ix86_elim_entry_set_got): Before checking
for UNSPEC_SET_GOT check that SET_SRC is UNSPEC.  Use SET_SRC and
SET_DEST macros instead of XEXP, rename vec variable to set.

* gcc.dg/pr112837.c: New test.

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

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[11/12/13/14 Regression]|[11/12/13 Regression] ICE
   |ICE unrecognizable_insn |unrecognizable_insn with
   |with __builtin_signbit and  |__builtin_signbit and
   |returning struct with   |returning struct with
   |int[4]  |int[4]

--- Comment #8 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c++/112795] [C++>=14] ICE pragma GCC unroll (n) cxx_eval_constant_expression

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

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

--- Comment #7 from Jakub Jelinek  ---
Fixed for GCC 14+, backports if any will be more limited.

[Bug target/112837] [12/13 Regression] ICE: RTL check: expected elt 1 type 'i' or 'n', have 'e' (rtx plus) in ix86_elim_entry_set_got, at config/i386/i386.cc:8612 with -fcompare-elim -fpie -fprofile

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[12/13/14 Regression] ICE:  |[12/13 Regression] ICE: RTL
   |RTL check: expected elt 1   |check: expected elt 1 type
   |type 'i' or 'n', have 'e'   |'i' or 'n', have 'e' (rtx
   |(rtx plus) in   |plus) in
   |ix86_elim_entry_set_got, at |ix86_elim_entry_set_got, at
   |config/i386/i386.cc:8612|config/i386/i386.cc:8612
   |with -fcompare-elim -fpie   |with -fcompare-elim -fpie
   |-fprofile   |-fprofile

--- Comment #4 from Jakub Jelinek  ---
Fixed for GCC 14+ so far.

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

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

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

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

https://gcc.gnu.org/g:462ccc3b9d5625cdc6104322a417bcd1ff1a8ff4

commit r14-6110-g462ccc3b9d5625cdc6104322a417bcd1ff1a8ff4
Author: Pan Li 
Date:   Mon Dec 4 16:06:14 2023 +0800

RISC-V: Add test case for bug PR112813

The bugzilla 112813 has been fixed recently, add below test
case for the bug.

PR target/112813

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/vsetvl/pr112813-1.c: New test.

Signed-off-by: Pan Li 

[Bug tree-optimization/112818] [14 regression] ICE when building accel-ppp (error: conversion of register to a different size in ‘view_convert_expr’, verify_gimple failed) since r14-5068-g88aca917eb70

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

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

Sam James  changed:

   What|Removed |Added

 CC||pan2.li at intel dot com
Summary|[14 regression] ICE when|[14 regression] ICE when
   |building accel-ppp (error:  |building accel-ppp (error:
   |conversion of register to a |conversion of register to a
   |different size in   |different size in
   |‘view_convert_expr’,|‘view_convert_expr’,
   |verify_gimple failed)   |verify_gimple failed) since
   ||r14-5068-g88aca917eb705b

--- Comment #6 from Sam James  ---
$ git bisect visualize --oneline
88aca917eb70 VECT: Refine the type size restriction of call vectorizer
1a0af6e5a99c RISC-V: Allow dest operand and accumulator operand overlap of
widen reduction instruction[PR112327]
c73d2d49f9be Daily bump.
4968e4844a3c (HEAD) Minor formatting fix for newly-added file from previous
commit
2b9778c8d9d3 Add files to discourage submissions of PRs to the GitHub mirror.
80b1a371008c PR target/110551: Tweak mulx register allocation using peephole2.

so yeah, let's call it r14-5068-g88aca917eb705b.

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

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
@defmac POINTERS_EXTEND_UNSIGNED
A C expression that determines how pointers should be extended from
@code{ptr_mode} to either @code{Pmode} or @code{word_mode}.  It is
greater than zero if pointers should be zero-extended, zero if they  
should be sign-extended, and negative if some other sort of conversion
is needed.  In the last case, the extension is done by the target's
@code{ptr_extend} instruction.

You need not define this macro if the @code{ptr_mode}, @code{Pmode}
and @code{word_mode} are all the same width.
@end defmac


so you _need_ to define POINTERS_EXTEND_UNSIGNED given that obviously
the modes are not the same.  The other possibility is that the caller
passes in the wrong modes for the address-space in question or it uses
the wrong function - the function is for converting of ptr_mode <-> Pmode
of the _same_ address-space, but guessing from the source we are converting
from different address-spaces.

[Bug tree-optimization/112831] [14 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in type_has_mode_precision_p, at tree.h:6767

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Dup of that other bug I guess.

[Bug other/112836] gcc fails when job control is used

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Can you post it to gcc-patc...@gcc.gnu.org please?

[Bug target/112837] [12/13 Regression] ICE: RTL check: expected elt 1 type 'i' or 'n', have 'e' (rtx plus) in ix86_elim_entry_set_got, at config/i386/i386.cc:8612 with -fcompare-elim -fpie -fprofile

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.4
   Priority|P3  |P2

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

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Note we end up trying to expand a memcpy between different address spaces
and that does

  addr = expand_expr (orig_exp, NULL_RTX, ptr_mode, EXPAND_NORMAL);
  mem = gen_rtx_MEM (BLKmode, memory_address (BLKmode, addr)); 

which assumes the default address-space.  The get_memory_rtx () function
also doesn't correctly preserve the address-space for the MEM_EXPR.

The following fixes the ICE and tries to correct the MEM_EXPR.  But I wonder
if the actual code generation is sane?  It also appears we'd eventually
emit a call to memcpy as we call emit_block_move_hints with BLOCK_OP_NORMAL
which sets may_use_call to 1.

So, can you check whether we generate correct code with the following patch?
Otherwise we should keep it ICEing (wrong-code is IMHO worse).

diff --git a/gcc/builtins.cc b/gcc/builtins.cc
index 4fc58a0bda9..244863699be 100644
--- a/gcc/builtins.cc
+++ b/gcc/builtins.cc
@@ -1353,7 +1353,8 @@ get_memory_rtx (tree exp, tree len)
 exp = TREE_OPERAND (exp, 0);

   addr = expand_expr (orig_exp, NULL_RTX, ptr_mode, EXPAND_NORMAL);
-  mem = gen_rtx_MEM (BLKmode, memory_address (BLKmode, addr));
+  addr_space_t as = TYPE_ADDR_SPACE (TREE_TYPE (TREE_TYPE (exp)));
+  mem = gen_rtx_MEM (BLKmode, memory_address_addr_space (BLKmode, addr, as));

   /* Get an expression we can use to find the attributes to assign to MEM.
  First remove any nops.  */
@@ -1363,8 +1364,11 @@ get_memory_rtx (tree exp, tree len)

   /* Build a MEM_REF representing the whole accessed area as a byte blob,
  (as builtin stringops may alias with anything).  */
+  tree ctype = char_type_node;
+  if (as != ADDR_SPACE_GENERIC)
+ctype = build_qualified_type (ctype, ENCODE_QUAL_ADDR_SPACE (as));
   exp = fold_build2 (MEM_REF,
-build_array_type (char_type_node,
+build_array_type (ctype,
   build_range_type (sizetype,
 size_one_node, len)),
 exp, build_int_cst (ptr_type_node, 0));
@@ -1381,7 +1385,7 @@ get_memory_rtx (tree exp, tree len)
   unsigned int align = get_pointer_alignment (TREE_OPERAND (exp, 0));
   exp = build_fold_addr_expr (base);
   exp = fold_build2 (MEM_REF,
-build_array_type (char_type_node,
+build_array_type (ctype,
   build_range_type (sizetype,
 size_zero_node,
 NULL)),

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

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

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

--- Comment #6 from Richard Biener  ---
Ah, that function does later

  else if (may_use_call && !might_overlap
   && ADDR_SPACE_GENERIC_P (MEM_ADDR_SPACE (x))
   && ADDR_SPACE_GENERIC_P (MEM_ADDR_SPACE (y)))
{

so only emits memcpy for generic address-space.

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

[jehelset at gmail dot com via Gcc-bugs]

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

Bug ID: 112842
   Summary: Constrained parameter pack with trailing param gives
no matching function.
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jehelset at gmail dot com
  Target Milestone: ---

Created attachment 56785
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56785&action=edit
Minimal reproducer, compile with --std=c++20

Program below doesn't compile:

template
concept U = true;

template
struct V{
  static constexpr void f(U auto ...,int){

  }
};

int main(){
  V::f(0,1); //no matching function for call to ‘V::f(int, int)’
  //template argument deduction/substitution failed:
  //candidate expects 1 argument, 2 provided
}

If there's no trailing parameter it works ok. clang-trunk seemed to handle it
fine. gcc-trunk also failed this.

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

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

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

--- Comment #7 from Richard Biener  ---
The following avoids gimplifying to a memcpy, but we are not prepared for
WITH_SIZE_EXPR in GIMPLE assigns (guess we think we can handle all with
memcpy).  Removing the verification makes the testcase "work" as well.

diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index 02f85e7109b..a1d5ee28cbe 100644
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@ -6331,7 +6331,8 @@ gimplify_modify_expr (tree *expr_p, gimple_seq *pre_p,
gim
ple_seq *post_p,
   && TYPE_SIZE_UNIT (TREE_TYPE (*from_p))
   && !poly_int_tree_p (TYPE_SIZE_UNIT (TREE_TYPE (*from_p)))
   && TREE_CODE (*from_p) == CONSTRUCTOR
-  && CONSTRUCTOR_NELTS (*from_p) == 0)
+  && CONSTRUCTOR_NELTS (*from_p) == 0
+  && ADDR_SPACE_GENERIC_P (TYPE_ADDR_SPACE (TREE_TYPE (*to_p
 {
   maybe_with_size_expr (from_p);
   gcc_assert (TREE_CODE (*from_p) == WITH_SIZE_EXPR);
@@ -6464,10 +6465,12 @@ gimplify_modify_expr (tree *expr_p, gimple_seq *pre_p,
gimple_seq *post_p,
   tree from = TREE_OPERAND (*from_p, 0);
   tree size = TREE_OPERAND (*from_p, 1);

-  if (TREE_CODE (from) == CONSTRUCTOR)
+  if (!ADDR_SPACE_GENERIC_P (TYPE_ADDR_SPACE (TREE_TYPE (*to_p)))
+ || !ADDR_SPACE_GENERIC_P (TYPE_ADDR_SPACE (TREE_TYPE (from
+   ;
+  else if (TREE_CODE (from) == CONSTRUCTOR)
return gimplify_modify_expr_to_memset (expr_p, size, want_value,
pre_p);
-
-  if (is_gimple_addressable (from))
+  else if (is_gimple_addressable (from))
{
  *from_p = from;
  return gimplify_modify_expr_to_memcpy (expr_p, size, want_value,

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

[jehelset at gmail dot com via Gcc-bugs]

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

--- Comment #1 from John Eivind Helset  ---
hopefully not a duplicate, couldn't find any matching ones,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69623 was the closest i could
find.

[Bug target/110606] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu

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

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

--- Comment #6 from Jeevitha  ---
The ICE is happenning on the following insn at final_scan,

(insn 80 146 111 (set (reg:DI 28 28 [145])
(high:DI (unspec:DI [
(reg:DI 2 2)
] UNSPEC_TLSLD))) "test.ii":28:7 737 {*tls_ld_high64}
 (expr_list:REG_EQUIV (high:DI (unspec:DI [
(reg:DI 2 2)
] UNSPEC_TLSLD))
(nil)))

It was unable to parse the operand "%&" in the following instruction for above
RTL.
  "addis %0,%1,%&@got@tlsld@ha"

For the operand "%&" tries to retrive some local-dynamic symbol in that
function but it return null. This happened because that function lost its
symbol(it was dead insn and removed from split3). Unfortunately the reference
are not removed, those instruction are unused but not eliminated which results
in error.

[Bug tree-optimization/112831] [14 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in type_has_mode_precision_p, at tree.h:6767

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #5 from Richard Biener  ---
dup

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

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

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||shaohua.li at inf dot ethz.ch

--- Comment #4 from Richard Biener  ---
*** Bug 112831 has been marked as a duplicate of this bug. ***

[Bug debug/112768] btf: fix asm comment output for BTF_KIND_FUNC* kinds

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Indu Bhagat :

https://gcc.gnu.org/g:9b6e2cb7e61ebb7006a89fa75869ec1a3e0a6e33

commit r14-6111-g9b6e2cb7e61ebb7006a89fa75869ec1a3e0a6e33
Author: Indu Bhagat 
Date:   Mon Dec 4 01:57:25 2023 -0800

BTF: fix PR debug/112768

PR debug/112768 - btf: fix asm comment output for BTF_KIND_FUNC* kinds

The patch adds a small function to abstract out the detail and return
the name of the type.  The patch also fixes the issue of BTF_KIND_FUNC
appearing in the comments with a 'null' string.

For btf-function-6.c testcase, after the patch:

.long   0   # TYPE 2 BTF_KIND_FUNC_PROTO ''
.long   0xd02   # btt_info: kind=13, kflag=0, vlen=2
.long   0x1 # btt_type: (BTF_KIND_INT 'int')
.long   0   # farg_name
.long   0x1 # farg_type: (BTF_KIND_INT 'int')
.long   0   # farg_name
.long   0x1 # farg_type: (BTF_KIND_INT 'int')
.long   0   # TYPE 3 BTF_KIND_FUNC_PROTO ''
.long   0xd01   # btt_info: kind=13, kflag=0, vlen=1
.long   0x1 # btt_type: (BTF_KIND_INT 'int')
.long   0x68# farg_name
.long   0x1 # farg_type: (BTF_KIND_INT 'int')
.long   0x5 # TYPE 4 BTF_KIND_FUNC 'extfunc'
.long   0xc02   # btt_info: kind=12, kflag=0, linkage=2
.long   0x2 # btt_type: (BTF_KIND_FUNC_PROTO '')
.long   0xd # TYPE 5 BTF_KIND_FUNC 'foo'
.long   0xc01   # btt_info: kind=12, kflag=0, linkage=1
.long   0x3 # btt_type: (BTF_KIND_FUNC_PROTO '')

gcc/ChangeLog:

PR debug/112768
* btfout.cc (get_btf_type_name): New definition.
(btf_collect_datasec): Update dtd_name to the original type name
string.
(btf_asm_type_ref): Use the new get_btf_type_name function
instead.
(btf_asm_type): Likewise.
(btf_asm_func_type): Likewise.

gcc/testsuite/ChangeLog:

PR debug/112768
* gcc.dg/debug/btf/btf-function-6.c: Empty string expected with
BTF_KIND_FUNC_PROTO.

[Bug debug/112656] btf: function prototypes generated with name

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Indu Bhagat :

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

commit r14-6112-gb6abc5dbfa5342347828b9feb4d9060071ff819c
Author: Indu Bhagat 
Date:   Mon Dec 4 01:57:34 2023 -0800

BTF: fix PR debug/112656

PR debug/112656 - btf: function prototypes generated with name

With this patch, all BTF_KIND_FUNC_PROTO will appear anonymous in the
generated BTF section.

As noted in the discussion in the bugzilla, the number of
BTF_KIND_FUNC_PROTO types output varies across targets (BPF with -mco-re
vs non-BPF targets).  Hence the check in the test case merely checks
that all BTF_KIND_FUNC_PROTO appear anonymous.

gcc/ChangeLog:

PR debug/112656
* btfout.cc (btf_asm_type): Fixup ctti_name for all
BTF types of kind BTF_KIND_FUNC_PROTO.

gcc/testsuite/ChangeLog:

PR debug/112656
* gcc.dg/debug/btf/btf-function-7.c: New test.

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

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
On GIMPLE there's nothing wrong I think.  There's some inconsistency in
representing a splat where when we have a scalar source we use a CONSTRUCTOR
but when we have a (multi-use) vector we use a VEC_PERM to splat its
first element (but I guess that's actually good in the end).

[Bug ada/112461] [14 regression] premature finalization with nested return inside extended one

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Botcazou  ---
https://gcc.gnu.org/g:f6bbf84ec759f203251c6c5a0dec8344f17cc614

commit r14-5909-gf6bbf84ec759f203251c6c5a0dec8344f17cc614
Author: Eric Botcazou 
Date:   Wed Nov 8 23:29:01 2023 +0100

ada: Fix premature finalization for nested return within extended one

The return object is incorrectly finalized when the nested return is taken,
because the special flag attached to the return object is not updated.

gcc/ada/
* exp_ch6.adb (Build_Flag_For_Function): New function made up of
the
code building the special flag for return object present...
(Expand_N_Extended_Return_Statement): ...in there.  Replace the
code
with a call to Build_Flag_For_Function.  Add assertion for the
flag.
(Expand_Non_Function_Return): For a nested return, if the return
object needs finalization actions, update the special flag.

[Bug target/65146] alignment of _Atomic structure member is not correct

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

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

Eric Gallager  changed:

   What|Removed |Added

URL|https://gitlab.com/x86-psAB |
   |Is/i386-ABI/-/issues/1  |
   See Also||https://gitlab.com/x86-psAB
   ||Is/i386-ABI/-/issues/1
 CC||egallager at gcc dot gnu.org

--- Comment #26 from Eric Gallager  ---
(In reply to H.J. Lu from comment #23)
> I created:
> 
> https://gitlab.com/x86-psABIs/i386-ABI/-/issues/1

Let's move that to the "See Also" field, now that that's possible.

[Bug target/99741] dllexport attribute is not compatible with c99 inline

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

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

Eric Gallager  changed:

   What|Removed |Added

   See Also|https://gcc.gnu.org/bugzill |https://gcc.gnu.org/bugzill
   |a/show_bug.cgi?id=90161 |a/show_bug.cgi?id=99901

--- Comment #2 from Eric Gallager  ---
(In reply to Andrew Aladjev from comment #0)
> PS this issue is indirectly related to
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90161

That has been closed as a dup of bug 99901, which has since been closed as
fixed.

[Bug target/96895] ABI of returning V1DF differs between GCC and clang

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

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

Eric Gallager  changed:

   What|Removed |Added

URL|https://gitlab.com/x86-psAB |
   |Is/x86-64-ABI/-/issues/1|
 CC||egallager at gcc dot gnu.org
   See Also||https://gitlab.com/x86-psAB
   ||Is/x86-64-ABI/-/issues/1

--- Comment #8 from Eric Gallager  ---
(In reply to H.J. Lu from comment #3)
> I opened:
> 
> https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/1

I'm moving this to the "See Also" field, now that that's possible.

[Bug other/111288] formatting mistake in HTML documentation

[bruno at clisp dot org via Gcc-bugs]

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

Bruno Haible  changed:

   What|Removed |Added

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

--- Comment #6 from Bruno Haible  ---
A fix that includes my patch has been applied by Jakub Jelinek on 2023-12-01:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=ff99671ac3ea583a9d65c8c3cd3ff4aad1d68592

This bug report is therefore FIXED.

[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 #10 from Robin Dapp  ---
I didn't yet look at all those closer because they are more dump failures than
real execution failures.

The ones I checked are

expected
"^foobar$" but got:
"foobar"

so I considered this rather an environment problem than a real problem (like
qemu stripping the output or so).  But who knows.  Going to have a closer look
this week.  On my machine those pass at least.

[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 #11 from GCC Commits  ---
The trunk branch has been updated by Lehua Ding :

https://gcc.gnu.org/g:7804b4e24cd16283067225d4c2c4a4483a2b31bc

commit r14-6113-g7804b4e24cd16283067225d4c2c4a4483a2b31bc
Author: Juzhe-Zhong 
Date:   Mon Dec 4 16:51:06 2023 +0800

RISC-V: Remove earlyclobber from widen reduction

Since the destination of reduction is not a vector register group, there
is no need to apply overlap constraint.

Also confirm Clang:

The mir in LLVM has early clobber:
early-clobber %49:vrm2 = PseudoVWADD_VX_M1 $noreg(tied-def 0), killed
%17:vr, %48:gpr, %0:gprnox0, 3, 0; example.c:59:24

The mir in LLVM doesn't have early clobber:
%48:vr = PseudoVWREDSUM_VS_M2_E8 $noreg(tied-def 0), %17:vrm2, killed
%33:vr, %0:gprnox0, 3, 1; example.c:60:26

And also confirm both:

vwredsum.vs v24, v8, v24 and vwredsum.vs v8, v8, v24 all legal on
LLVM.

Align with LLVM and honor RISC-V V spec, remove earlyclobber.

Before this patch:

vwredsum.vs v8,v24,v8
vwredsum.vs v7,v22,v7
vwredsum.vs v6,v20,v6
vwredsum.vs v5,v18,v5
vwredsum.vs v4,v16,v4
vwredsum.vs v3,v14,v3
vwredsum.vs v2,v12,v2
vwredsum.vs v1,v10,v1
vmv1r.v v9,v8
vwredsum.vs v9,v24,v9
vmv1r.v v24,v7
vwredsum.vs v24,v22,v24
vmv1r.v v22,v6
vwredsum.vs v22,v20,v22
vmv1r.v v20,v5
vwredsum.vs v20,v18,v20
vmv1r.v v18,v4
vwredsum.vs v18,v16,v18
vmv1r.v v16,v3
vwredsum.vs v16,v14,v16
vmv1r.v v14,v2
vwredsum.vs v14,v12,v14
vmv1r.v v12,v1
vwredsum.vs v12,v10,v12

After this patch:

vfwredusum.vs   v17,v12,v17
vfwredusum.vs   v18,v10,v18
vfwredusum.vs   v15,v26,v15
vfwredusum.vs   v16,v24,v16
vfwredusum.vs   v12,v12,v17
vfwredusum.vs   v10,v10,v18
vfwredusum.vs   v13,v6,v20
vfwredusum.vs   v11,v8,v19
vfwredusum.vs   v6,v6,v13
vfwredusum.vs   v8,v8,v11
vfwredusum.vs   v7,v4,v21
vfwredusum.vs   v9,v2,v22
vfwredusum.vs   v14,v26,v15
vfwredusum.vs   v1,v24,v16
vfwredusum.vs   v4,v4,v7
vfwredusum.vs   v2,v2,v9

Same behavior as LLVM, and honor RISC-V V spec.

PR target/112431

gcc/ChangeLog:

* config/riscv/vector.md: Remove earlyclobber from widen reduction.

gcc/testsuite/ChangeLog:

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

[Bug middle-end/112572] [14 regression] LLVM miscompiled since r14-5355-g3cd3a09b3f91a1

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

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

--- Comment #32 from Sam James  ---
(In reply to Sam James from comment #30)
> afaik the best we have so far is
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112613#c0

we also know that pipewire fails a test (test-filter) when built for -m32, but
I haven't reduced it. it's way smaller than llvm though and C.

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

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

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

--- Comment #12 from JuzheZhong  ---
Except vv/wv variant widen instructions.
All other widen EEW overlap have been done.

It seems that current register filter can not help us simulate accurate
highest-number overlap for vwadd.vv/vwadd.wv instructions.

[Bug c++/112838] Compiler is unable to show the exact error location when calling copy ctor for a non-copyable object

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #4 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #1)
> Confirmed, I thought I had saw an issue filed that is very smilar to this.

See PR 80858 (and PR 58589) and PR 106176 and PR 90413 and others.

I created PR 109551 for the underlying front-end issue.

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

[Bug c++/109551] Show location where implicit instantiation first required

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||eng.ahmad.nour at gmail dot com

--- Comment #2 from Jonathan Wakely  ---
*** Bug 112838 has been marked as a duplicate of this bug. ***

[Bug c++/112838] Compiler is unable to show the exact error location when calling copy ctor for a non-copyable object

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

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Ahmad Nour from comment #2)
> I tried with clang-12 -Wall -Wextra main.cpp, but I didn't get that
> hint/note. Am I missing something?

You should get that note with clang-12 (and newer versions)
https://godbolt.org/z/KM65MKrPa

[Bug libstdc++/112832] [std::format] Broken non-SFINAE-friendly `set_debug_format()` for `const char *` formatter

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Egor from comment #0)
> GCC doesn't seem to implement `{:?}` debug format for strings yet.

Correct, see PR 109162

> Yet for some reason `std::formatter` has a
> `set_debug_format()` function, which causes a hard error when used (isn't
> SFINAE-friendly).

The error has nothing to do with it being SFINAE-friendly or not.

> `set_debug_format()` should be SFINAE-friendly, to allow the user to call it
> conditionally when available.

No, it should just not exist yet.

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

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 112843
   Summary: during GIMPLE pass: bitintlower ICE: SIGSEGV in
ranger_cache::range_of_expr
(gimple-range-cache.cc:1204) with _BitInt() at -O1
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O testcase.c -wrapper valgrind,-q
==18057== Invalid read of size 8
==18057==at 0x25641C8: ranger_cache::range_of_expr(vrange&, tree_node*,
gimple*) (gimple-range-cache.cc:1204)
==18057==by 0x256FDB9: fold_using_range::range_of_range_op(vrange&,
gimple_range_op_handler&, fur_source&) (gimple-range-fold.cc:671)
==18057==by 0x25719D2: fold_using_range::fold_stmt(vrange&, gimple*,
fur_source&, tree_node*) (gimple-range-fold.cc:602)
==18057==by 0x25575CD: gimple_ranger::update_stmt(gimple*)
(gimple-range.cc:564)
==18057==by 0x16A90C4: update_stmt_operands(function*, gimple*)
(tree-ssa-operands.cc:1150)
==18057==by 0x113AE26: update_stmt_if_modified (gimple-ssa.h:187)
==18057==by 0x113AE26: update_stmt_if_modified (gimple-ssa.h:184)
==18057==by 0x113AE26: update_modified_stmt (gimple-iterator.cc:44)
==18057==by 0x113AE26: gsi_insert_after(gimple_stmt_iterator*, gimple*,
gsi_iterator_update) (gimple-iterator.cc:544)
==18057==by 0x254E274: gimple_lower_bitint() (gimple-lower-bitint.cc:6348)
==18057==by 0x13A3C1A: execute_one_pass(opt_pass*) (passes.cc:2641)
==18057==by 0x13A44FF: execute_pass_list_1(opt_pass*) (passes.cc:2750)
==18057==by 0x13A4511: execute_pass_list_1(opt_pass*) (passes.cc:2751)
==18057==by 0x13A4538: execute_pass_list(function*, opt_pass*)
(passes.cc:2761)
==18057==by 0xFB1595: expand (cgraphunit.cc:1841)
==18057==by 0xFB1595: cgraph_node::expand() (cgraphunit.cc:1794)
==18057==  Address 0x10 is not stack'd, malloc'd or (recently) free'd
==18057== 
during GIMPLE pass: bitintlower
testcase.c: In function 'foo':
testcase.c:2:1: internal compiler error: Segmentation fault
2 | foo (_BitInt (128) x, _BitInt (256) y)
  | ^~~
0x14e51ff crash_signal
/repo/gcc-trunk/gcc/toplev.cc:316
0x25641c8 ranger_cache::range_of_expr(vrange&, tree_node*, gimple*)
/repo/gcc-trunk/gcc/gimple-range-cache.cc:1204
0x256fdb9 fold_using_range::range_of_range_op(vrange&,
gimple_range_op_handler&, fur_source&)
/repo/gcc-trunk/gcc/gimple-range-fold.cc:671
0x25719d2 fold_using_range::fold_stmt(vrange&, gimple*, fur_source&,
tree_node*)
/repo/gcc-trunk/gcc/gimple-range-fold.cc:602
0x25575cd gimple_ranger::update_stmt(gimple*)
/repo/gcc-trunk/gcc/gimple-range.cc:564
0x16a90c4 update_stmt_operands(function*, gimple*)
/repo/gcc-trunk/gcc/tree-ssa-operands.cc:1150
0x113ae26 update_stmt_if_modified(gimple*)
/repo/gcc-trunk/gcc/gimple-ssa.h:187
0x113ae26 update_stmt_if_modified(gimple*)
/repo/gcc-trunk/gcc/gimple-ssa.h:184
0x113ae26 update_modified_stmt
/repo/gcc-trunk/gcc/gimple-iterator.cc:44
0x113ae26 gsi_insert_after(gimple_stmt_iterator*, gimple*, gsi_iterator_update)
/repo/gcc-trunk/gcc/gimple-iterator.cc:544
0x254e274 gimple_lower_bitint
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:6348
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

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

[Bug tree-optimization/112818] [14 regression] ICE when building accel-ppp (error: conversion of register to a different size in ‘view_convert_expr’, verify_gimple failed) since r14-5068-g88aca917eb70

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

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

--- Comment #7 from Richard Biener  ---
So the issue is we're having

  _8 = __builtin_bswap16 (type_6(D));

with short _8 and int type_6 due to C argument promotion applied because
of promote_prototypes.

Since the arg is an external_def we could have done better and actually
demoted it but vectorizable_call decided on a vector type already.

[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 #5 from GCC Commits  ---
The master branch has been updated by Richard Biener :

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

commit r14-6114-gde0ab339a795352c843f6e9b2dfce222f26588de
Author: Richard Biener 
Date:   Mon Dec 4 10:46:11 2023 +0100

tree-optimization/112827 - corrupt SCEV cache during SCCP

The following avoids corrupting the SCEV cache by my last change
to propagate constant final values immediately.  The easiest fix
is to keep a dead initialization around.

PR tree-optimization/112827
* tree-scalar-evolution.cc (final_value_replacement_loop):
Do not release SSA name but keep a dead initialization around.

* gcc.dg/torture/pr112827-1.c: New testcase.
* gcc.dg/torture/pr112827-2.c: Likewise.

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

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

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

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

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

--- Comment #8 from Richard Biener  ---
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?

[Bug middle-end/79649] Memset pattern in named address space crashes compiler or generates wrong code

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #14 from Richard Biener  ---
The testcase in comment#2 no longer ICEs and comment#12 is also no longer true.

[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

  Component|target  |c
   Last reconfirmed||2023-12-04
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
It still ICEs.  The IL from the frontend looks wrong.  We have

  p = &s->y;

but we should have a ADDR_SPACE_CONVERT_EXPR here, but we have

 >
side-effects
arg:0 
unsigned HI
...

and its DECL_INITIAL is

 
HI
size 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76b45dc8 domain 
pointer_to_this >
unsigned HI size  unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76b45e70>
readonly
arg:0 
unsigned HI size  unit-size

align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76b45d20>
readonly
arg:0 
readonly
arg:0 
readonly arg:0 
t.c:6:26 start: t.c:6:26 finish: t.c:6:27> arg:1 
t.c:6:26 start: t.c:6:25 finish: t.c:6:28>
t.c:6:24 start: t.c:6:24 finish: t.c:6:28>
t.c:6:24 start: t.c:6:24 finish: t.c:6:28>

and the issue is that while the RECORD_TYPE has the correct address-space
qualification the array-type does not (the array-type component does).

That's the fault of the C frontend c_build_qualified_type which
special-cases ARRAY_TYPE and doesn't behave like build_array_type_1 would.

I have a fix.

[Bug c/112844] New: Branches under -Os (unlike -O{1,2,3}) do not respect __builtin_expect hints

[pskocik at gmail dot com via Gcc-bugs]

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

Bug ID: 112844
   Summary: Branches under -Os (unlike -O{1,2,3}) do not respect
__builtin_expect hints
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pskocik at gmail dot com
  Target Milestone: ---

A simple example that demonstrates this is:

int test(void);
void yes(void);
void expect_yes(void){ if (__builtin_expect(test(),1)) yes(); else {} }
void expect_no(void){ if (__builtin_expect(test(),0)) yes(); else {} }

For an optimized x86-64 output, one should expect:
   -a fall-through to a yes() tailcall for the expect_yes() case, preceded by a
conditional jump to code doing a plain return
   -a fall-through to a plain return for the expect_no() case, preceded by a
conditional jump to a yes() tailcall (or even more preferably: a
conditional-taicall to yes() with the needed stack adjustment done once before
the test instead of being duplicated in each branch after the test)

Indeed, that's how gcc lays it out for -O{1,2,3}
(https://godbolt.org/z/rG3P3d6f7) as does clang at -O{1,2,3,s}
(https://godbolt.org/z/EcKbrn1b7) and icc at -O{1,2,3,s}
(https://godbolt.org/z/Err73eGsb).

But gcc at -Os seems to have a very strong preference to falling through to
call yes() even in 

void expect_no(void){ if (__builtin_expect(test(),0)) yes(); else {} }

and even in

void expect_no2(void){ if (__builtin_expect(!test(),1)){} else yes(); }

essentially completely disregarding any user attempts at controlling the branch
layout of the output.

[Bug c/112844] Branches under -Os (unlike -O{1,2,3}) do not respect __builtin_expect hints

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
With -Os you ask the code to be small.  So, while internally the hint is still
present in edge probabilities, -Os is considered more important and certain
code changes based on the probabilities aren't done if they are known or
expected to result in larger code.

[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 #11 from Robin Dapp  ---
Verified they work locally but also fail on a different server.  Also fail
without vector and at -O0.  Maybe it's different tcl versions or the shell
doing wonky stuff?

[Bug middle-end/89270] [11/12/13/14 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|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1
 CC||jsm28 at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-12-04

--- Comment #12 from Richard Biener  ---
Confirmed.  We have a NOP_EXPR from the 24bit pointer __memx address-space
to long int (32bit).  That's an extension and we don't know how to do that
since POINTERS_EXTEND_UNSIGNED is not defined for AVR.  Note that
for GIMPLE verification the exception would be

#if defined(POINTERS_EXTEND_UNSIGNED)
|| (TYPE_MODE (rhs1_type) == ptr_mode
&& (TYPE_PRECISION (lhs_type)
  == BITS_PER_WORD /* word_mode */
|| (TYPE_PRECISION (lhs_type)
  == GET_MODE_PRECISION (Pmode
#endif

but that's currently written without address-spaces in mind (because
POINTERS_EXTEND_UNSIGNED is defined without address-spaces in mind).

I think the "bug" is that the C frontend emits

  extern const  unsigned char __data_load_end;
  __uint24 top = (__uint24) (long int) &__data_load_end;

so it inserts the widening to 'long int' here.  And that's the fault of
convert.cc:convert_to_integer_1 which does

  /* Convert to an unsigned integer of the correct width first, and from
 there widen/truncate to the required type.  Some targets support the
 coexistence of multiple valid pointer sizes, so fetch the one we need
 from the type.  */
  if (!dofold)
return build1 (CONVERT_EXPR, type, expr);
  expr = fold_build1 (CONVERT_EXPR,
  lang_hooks.types.type_for_size
(TYPE_PRECISION (intype), 0),
  expr);
  return fold_convert (type, expr);

using type_for_mode would have yielded the __int24 type here.

The code is more or less present since the original version of convert.c

I'd argue the most correct way to deal with this is to _remove_ the
intermediate conversion done by convert.c since it only papers over
possible user errors?  The C standard says the only supported conversion
is to/from [u]intptr_t, that's probably what the above tried to do.
But then it looks like it doesn't achieve its intent.

Now, c_common_type_for_size doesn't handle registered_builtin_types
like c_common_type_for_mode does, so extending that to cover these
fixes the issue as well.

[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 #12 from Robin Dapp  ---
Ok, on my server the difference is that I didn't add vext_spec=v1.0 to the qemu
options.  This caused the qemu diagnostic which would of course not match the
expected output.

[Bug tree-optimization/112818] [14 regression] ICE when building accel-ppp (error: conversion of register to a different size in ‘view_convert_expr’, verify_gimple failed) since r14-5068-g88aca917eb70

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

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

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

https://gcc.gnu.org/g:80d67d8f682a6050a3bf4dcfa18a83f321986f2a

commit r14-6116-g80d67d8f682a6050a3bf4dcfa18a83f321986f2a
Author: Richard Biener 
Date:   Mon Dec 4 12:50:36 2023 +0100

tree-optimization/112818 - re-instantiate vector type size check for bswap

For __builtin_bswap vectorization we still require an equal vector
type size.  Re-instantiate that check.

PR tree-optimization/112818
* tree-vect-stmts.cc (vectorizable_bswap): Check input and
output vector types have the same size.

* gcc.dg/vect/pr112818.c: New testcase.

[Bug tree-optimization/112818] [14 regression] ICE when building accel-ppp (error: conversion of register to a different size in ‘view_convert_expr’, verify_gimple failed) since r14-5068-g88aca917eb70

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[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 #13 from GCC Commits  ---
The master branch has been updated by Pan Li :

https://gcc.gnu.org/g:27fde325d64447a3a0d5d550c5976e5f3fb6dc16

commit r14-6117-g27fde325d64447a3a0d5d550c5976e5f3fb6dc16
Author: Juzhe-Zhong 
Date:   Mon Dec 4 21:32:06 2023 +0800

RISC-V: Support highest-number regno overlap for widen ternary

Consider this example:

#include "riscv_vector.h"
void
foo6 (void *in, void *out)
{
  vfloat64m8_t accum = __riscv_vle64_v_f64m8 (in, 4);
  vfloat64m4_t high_eew64 = __riscv_vget_v_f64m8_f64m4 (accum, 1);
  vint64m4_t high_eew64_i = __riscv_vreinterpret_v_f64m4_i64m4
(high_eew64);
  vint32m4_t high_eew32_i = __riscv_vreinterpret_v_i64m4_i32m4
(high_eew64_i);
  vfloat32m4_t high_eew32 = __riscv_vreinterpret_v_i32m4_f32m4
(high_eew32_i);
  vfloat64m8_t result = __riscv_vfwnmsac_vf_f64m8 (accum, 64, high_eew32,
4);
  __riscv_vse64_v_f64m8 (out, result, 4);
}

Before this patch:

foo6:   # @foo6
vsetivlizero, 4, e32, m4, ta, ma
vle64.v v8, (a0)
lui a0, 272384
fmv.w.x fa5, a0
vmv8r.v v16, v8
vfwnmsac.vf v16, fa5, v12
vse64.v v16, (a1)
ret

After this patch:

foo6:
.LFB5:
.cfi_startproc
lui a5,%hi(.LC0)
flw fa5,%lo(.LC0)(a5)
vsetivlizero,4,e32,m4,ta,ma
vle64.v v8,0(a0)
vfwnmsac.vf v8,fa5,v12
vse64.v v8,0(a1)
ret

PR target/112431

gcc/ChangeLog:

* config/riscv/vector.md: Add highest-number overlap support.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/pr112431-37.c: New test.
* gcc.target/riscv/rvv/base/pr112431-38.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?

[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 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 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&action=edit
gcc14-pr112843.patch

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

[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

[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, &m_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

--- 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, &m_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/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/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 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 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 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 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

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

Untested fix.

[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 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 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, &m_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 (&gsi, 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 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 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/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 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/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/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 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

[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 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 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&action=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

[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 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 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/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 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 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/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/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&action=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 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): New

[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 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): New

[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 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&action=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 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 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 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&action=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 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&action=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}}