[Bug target/112986] s390x gcc O2, O3: Incorrect logic operation in < comparison with the same values

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

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

Andreas Krebbel  changed:

   What|Removed |Added

 CC||shinwogud12 at gmail dot com

--- Comment #7 from Andreas Krebbel  ---
*** Bug 112665 has been marked as a duplicate of this bug. ***

[Bug target/112665] I am getting incorrect output values at optimization level 2 in GCC for the s390x architecture.

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

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

Andreas Krebbel  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE
 CC||krebbel at gcc dot gnu.org

--- Comment #2 from Andreas Krebbel  ---
I can confirm this when running the program with qemu but not on real hardware.
The code is also using the chrl instruction so I guess this is another instance
of PR112986

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

[Bug target/112387] RISC-V: failed to SLP INT64 gather load

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

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

JuzheZhong  changed:

   What|Removed |Added

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

--- Comment #4 from JuzheZhong  ---
Fixed

[Bug target/112387] RISC-V: failed to SLP INT64 gather load

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

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

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

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

commit r14-6533-ge9f0af150358d93b4c4c5f65d662748ae87bd3d0
Author: Juzhe-Zhong 
Date:   Thu Dec 14 15:47:52 2023 +0800

RISC-V: Add failed SLP testcase

After recent RVV cost model tweak, I found this PR issue has been fixed.

Add testcase and committed.

PR target/112387

gcc/testsuite/ChangeLog:

* gcc.dg/vect/costmodel/riscv/rvv/pr112387.c: New test.

[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 #11 from Jeevitha  ---
Regarding the test case provided by Matthias Klose:

Within the AllocMemory() routine, the compiler aimed to eliminate the entire if
block but faced difficulties in removing references to the variable 'sMemPool'.

The corresponding source code is as follows:

if (sMemPool) {
__trans_tmp_2 = operator new(AllocMemory_size);
return __trans_tmp_2;
}
void *ptr = operator new(AllocMemory_size);
return ptr;

The subsequent details are pertaining to the body of if statement [BB5], which
includes a 'mov' [insn 35] for "AllocMemory_size" and a 'call' [insn 36] for
"operator new." Furthermore, regarding the code after the if body [BB6], there
was another 'mov' [insn 43] and 'call' [insn 44], similar to those in BB5.

Before SCHED1:
--

BB5:
insn 35   set r3, r124
insn 36   call [`operator new`] -> Uses r3,r2
...
insn 78   jump L47

L41:
BB6:
insn 43   set r3, r124
insn 44   call [`operator new`] -> Uses r3,r2
...

L47:
BB7:
insn 49 set r5, 0
insn 50 set r4, 1

During the 'sched1' pass, a reordering occurred that moved insn 35 before insn
31 from BB5 to BB4. BB4 contains the check for the 'sMempool' variable [insn
33]: if it's zero, there's a branch to label 41, leading to BB6; otherwise, it
continues with BB5.

After SCHED1:
-

BB3:
insn 80 set r145, high(unspec[r2]) 
insn 81 set r139, r145+low(unspec[r2])'

BB4:
insn 72  set r3, r139
insn 23  set r124, [r138]
insn 26  call [`__tls_get_addr`] -> Uses r3,r2
insn 75  set r142, r3
insn 28  set r132, unspec[r142, symbol_ref: `_ZL8sMemPool`]
insn 29  set r130, unspec[r132, symbol_ref: `_ZL8sMemPool`]
insn 35  set r3, r124
insn 31  set r133, [r130]
insn 32  set r134, cmp(r133, 0)
insn 33  set pc, { (r134 == 0) ? L41 : pc } 

BB5:
insn 36   call [`operator new`] -> Uses r3,r2
...
insn 78   jump L47

L41:
BB6 
insn 43   set r3, r124
insn 44   call [`operator new`] -> Uses r3,r2
...

L47:
BB7:
insn 49 set r5, 0
insn 50 set r4, 1

In the 'Jump2' pass, the compiler successfully removed the if body (bb5)
consisting of insn 36 and insn 78. However, it couldn't remove insn 35, which
was moved to bb4. Additionally, it changed insn 43 to be in bb6 and moved the
remaining instructions from insn 44 to bb10. As insn 43 and insn 35 are similar
instructions, insn 43 was chosen for deletion in the later pass.

After JUMP2:
---

BB3:

insn 80 set r28[orig:r145], high(unspec[r2]) 
insn 81 set r28[orig:r139], r28[orig:r145]+low(unspec[r2])'


BB4:


insn 32  set cr0[orig:r134], cmp(r9[orig:r133], 0)
insn 33  set pc, { (cr0[orig:r134] == 0) ? L41 : pc }

BB5:
insn 134 set pc, L133

L41:
BB6:
insn 43 set r3, r30[orig:r124]

L133:
BB10:
insn 44 call [`operator new`] -> Uses r3,r2
insn 49 set r5,0
insn 50 set r4, 1


In cprop_hardreg pass, insn 43 in BB6 is removed

After cprop_hardreg:


BB3:

insn 80 set r28, high(unspec[r2]) 
insn 81 set r139, r28+low(unspec[r2])'


BB4:
insn 72  set r3, r28[orig:r139]
insn 23  set r30[orig:r124], r27[orig:r138]
insn 26  call [`__tls_get_addr`] -> Uses r3,r2
insn 28  set r9[orig:r132], unspec[r3[orig:r142],symbol_ref: `_ZL8sMemPool']
insn 29  set r9[orig:r130], unspec[r9[orig:r132],symbol_ref: `_ZL8sMemPool']
insn 35  set r3, r30[orig:r124]
insn 31  set r9[orig:r133], [r9][orig:r130]
insn 32  set cr0[orig:r134], cmp(r9[orig:r133], 0)
insn 33  set pc, { (cr0[orig:r134] == 0) ? L41 : pc }

BB5:
insn 134 set pc, L133

L41:
BB6:

L133:
BB10:
insn 44 call [`operator new`] -> Uses r3,r2
insn 49 set r5,0
insn 50 set r4, 1



Following the removal of insn 43 in the 'cprop_hardreg' pass, both insn 134 and
33 became unnecessary due to jumping to the same location, which was removed in
the basic block reordering pass.

After BBRO:
---

BB3:
...
insn 80 set r28, high(unspec[r2]) 
insn 81 set r28, r28+low(unspec[r2])'
...

BB4:
insn 72  set r3, r28
insn 23  set r30, r27
insn 26  call [`__tls_get_addr`] -> Uses r3,r2
insn 28  set r9, unspec[r3,`_ZL8sMemPool']
insn 29  set r9, unspec[r9,`_ZL8sMemPool']
insn 35  set r3, r30
insn 31  set r9, [r9]
insn 32  set cr0, cmp(r9, 0)

insn 44 call [`operator new`] -> Uses r3,r2
insn 49 set r5,0
insn 50 set r4, 1
...


Upon the removal of these jumps, instructions 32, 31, 29, and 28 in bb4 became
dead, since r9, r3 were used for those jumps. During 'sched2 DCE,' those
instructions in BB4 were removed, rendering r3 unused (which was populated in
insn 26). However, its not deleted in this pass:

After SCHED2:

BB3:
...
insn 80 set r28, high(unspec[r2]) 
insn 81 set r28, r28+low(unspec[r2])'
...

BB4:
insn 23  set r30, r27
insn 72  set r3, r28
insn 26  call [`__tls_get_addr`] -> Uses r3,r2
insn 35  set r3, r30
insn 44 call [`operator new`] -> Uses r3,r2
insn 49 set r5,0
insn 50 set r4, 1
...
...


The flag 'df_in_progress' is avoiding the call deletion in 'sched2 DCE'. If the
insn 26 is removed, insn 72 can be removed. Consequently, below ins

[Bug tree-optimization/110640] [13 Regression] Wrong code at -O2/3 on x86_64-linux-gnu since GCC-13 since r12-1653-gcb448ade74d

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

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

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

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

commit r14-6532-g9e20779a7d8e14e77df6efaeadc6bf3a001336ef
Author: Richard Biener 
Date:   Thu Dec 14 08:40:00 2023 +0100

tree-optimization/110640 - testcase for fixed bug

PR tree-optimization/110640
* gcc.dg/torture/pr110640.c: New testcase.

[Bug tree-optimization/110640] [13 Regression] Wrong code at -O2/3 on x86_64-linux-gnu since GCC-13 since r12-1653-gcb448ade74d

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||13.2.1
 Resolution|--- |FIXED

--- Comment #8 from Richard Biener  ---
Verified fixed on the branch (patch was backported).

[Bug target/112986] s390x gcc O2, O3: Incorrect logic operation in < comparison with the same values

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

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

Andreas Krebbel  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from Andreas Krebbel  ---
No problem. Thanks for testing s390x!
I've requested the qemu fix to be included into Ubuntu 22.04. Closing the BZ
now.

[Bug tree-optimization/110640] [13 Regression] Wrong code at -O2/3 on x86_64-linux-gnu since GCC-13 since r12-1653-gcb448ade74d

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||14.0
Summary|[13/14 Regression] Wrong|[13 Regression] Wrong code
   |code at -O2/3 on|at -O2/3 on
   |x86_64-linux-gnu since  |x86_64-linux-gnu since
   |GCC-13 since|GCC-13 since
   |r12-1653-gcb448ade74d   |r12-1653-gcb448ade74d
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Depends on||111445
 Status|NEW |ASSIGNED

--- Comment #7 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #6)
> This doesn't reproduce on the trunk since
> r14-4790-g9692309ed6b625f0fb358c0e230404b5603f69a6 anymore.  Was that a fix
> for this or just made it latent?

It does look similar enough:

[local count: 118111600]:
   k_11 = k_38 + 1;
-  _13 = (unsigned char) j_12(D);
-  _14 = _13 + 1;
-  _15 = (int) _14;
+  _13 = _26;
+  _14 = _28;
+  _15 = _29;
   _16 = (int) k_11;
-  _17 = _15 + _16;
+  _17 = _29 + 1;

I'll add this testcase as well.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111445
[Bug 111445] [12 Regression] Wrong code at -Os on x86_64-linux-gnu since
r12-1077-g57bf3751511

[Bug c++/112968] Valgrind error on libstdc++-v3/testsuite/18_support/comparisons/object/93479.cc

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed.

[Bug target/112904] [14 Regression] ICE in extract_insn, at recog.cc:2791 with -mxop since r14-4964-g7eed861e8ca3f5

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

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

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

https://gcc.gnu.org/g:585dc19ef051959d688e6ea89b41998600480ecb

commit r14-6530-g585dc19ef051959d688e6ea89b41998600480ecb
Author: Jakub Jelinek 
Date:   Thu Dec 14 08:01:04 2023 +0100

testsuite: Fix up pr112904.C test [PR112904]

On Fri, Dec 08, 2023 at 03:12:00PM +0800, liuhongt wrote:
>   * g++.target/i386/pr112904.C: New test.

The new test FAILs on i686-linux and even on x86_64-linux I think
it doesn't actually test what was reported, unless one performs testing
with -march= for some XOP enabled CPU or -mxop.

The following patch fixes that, tested on x86_64-linux with
make check-g++
RUNTESTFLAGS='--target_board=unix\{-m32,-m32/-mno-sse/-mno-mmx,-m64\}
i386.exp=pr112904.C'

2023-12-14  Jakub Jelinek  

PR target/112904
* g++.target/i386/pr112904.C: Add dg-do compile, dg-options -mxop
and for ia32 also dg-additional-options -mmmx.

[Bug c++/112968] Valgrind error on libstdc++-v3/testsuite/18_support/comparisons/object/93479.cc

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

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

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

https://gcc.gnu.org/g:7ff33c609a64319583223d6d39a89e971f993ecf

commit r14-6529-g7ff33c609a64319583223d6d39a89e971f993ecf
Author: Jakub Jelinek 
Date:   Thu Dec 14 07:57:34 2023 +0100

c++: Fix tinst_level::to_list [PR112968]

With valgrind checking, there are various errors reported on some C++26
libstdc++ tests, like:
==2009913== Conditional jump or move depends on uninitialised value(s)
==2009913==at 0x914C59: gt_ggc_mx_lang_tree_node(void*)
(gt-cp-tree.h:107)
==2009913==by 0x8AB7A5: gt_ggc_mx_tinst_level(void*) (gt-cp-pt.h:32)
==2009913==by 0xB89B25: ggc_mark_root_tab(ggc_root_tab const*)
(ggc-common.cc:75)
==2009913==by 0xB89DF4: ggc_mark_roots() (ggc-common.cc:104)
==2009913==by 0x9D6311: ggc_collect(ggc_collect) (ggc-page.cc:2227)
==2009913==by 0xDB70F6: execute_one_pass(opt_pass*) (passes.cc:2738)
==2009913==by 0xDB721F: execute_pass_list_1(opt_pass*) (passes.cc:2755)
==2009913==by 0xDB7258: execute_pass_list(function*, opt_pass*)
(passes.cc:2766)
==2009913==by 0xA55525: cgraph_node::analyze() (cgraphunit.cc:695)
==2009913==by 0xA57CC7: analyze_functions(bool) (cgraphunit.cc:1248)
==2009913==by 0xA5890D: symbol_table::finalize_compilation_unit()
(cgraphunit.cc:2555)
==2009913==by 0xEB02A1: compile_file() (toplev.cc:473)

I think the problem is in the tinst_level::to_list optimization from 2018.
That function returns a TREE_LIST with TREE_PURPOSE/TREE_VALUE filled in.
Either it freshly allocates using build_tree_list (NULL, NULL); + stores
TREE_PURPOSE/TREE_VALUE, that case is fine (the whole tree_list object
is zeros, except for TREE_CODE set to TREE_LIST and TREE_PURPOSE/TREE_VALUE
modified later; the above also means in particular TREE_TYPE of it is NULL
and TREE_CHAIN is NULL and both are accessible/initialized even in valgrind
annotations.
Or it grabs a TREE_LIST node from a freelist.
If defined(ENABLE_GC_CHECKING), the object is still all zeros except
for TREE_CODE/TREE_PURPOSE/TREE_VALUE like in the fresh allocation case
(but unlike the build_tree_list case in the valgrind annotations
TREE_TYPE and TREE_CHAIN are marked as uninitialized).
If !defined(ENABLE_GC_CHECKING), I believe the actual memory content
is that everything but TREE_CODE/TREE_PURPOSE/TREE_VALUE/TREE_CHAIN is
zeros and TREE_CHAIN is something random (whatever next entry is in the
freelist, nothing overwrote it) and from valgrind POV again,
TREE_TYPE and TREE_CHAIN are marked as uninitialized.

When using the other freelist instantiations (pending_template and
tinst_level) I believe everything is correct, from valgrind POV it marks
the whole pending_template or tinst_level as uninitialized, but the
caller initializes it all).

One way to fix this would be let tinst_level::to_list not store just
  TREE_PURPOSE (ret) = tldcl;
  TREE_VALUE (ret) = targs;
but also
  TREE_TYPE (ret) = NULL_TREE;
  TREE_CHAIN (ret) = NULL_TREE;
Though, that seems like wasted effort in the build_tree_list case to me.

So, the following patch instead does that TREE_CHAIN = NULL_TREE store only
in the case where it isn't already done (and likewise for TREE_TYPE just to
be sure) and marks both TREE_CHAIN and TREE_TYPE as initialized (the latter
is at that spot, the former is because we never really touch TREE_TYPE of a
TREE_LIST anywhere and so the NULL gets stored into the freelist and
restored from there (except for ENABLE_GC_CHECKING where it is poisoned
and then cleared again).

2023-12-14  Jakub Jelinek  

PR c++/112968
* pt.cc (freelist::reinit): Make whole obj->common
defined for valgrind annotations rather than just obj->base,
and do it even for ENABLE_GC_CHECKING.  If not ENABLE_GC_CHECKING,
clear TREE_CHAIN (obj) and TREE_TYPE (obj).

[Bug c/111153] RISC-V: Incorrect Vector cost model for reduction

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

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

JuzheZhong  changed:

   What|Removed |Added

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

--- Comment #7 from JuzheZhong  ---
Fixed.

[Bug c/111153] RISC-V: Incorrect Vector cost model for reduction

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

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

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

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

commit r14-6528-g5e0f67b84a615ba186ab234a9bc43df0df5a50b6
Author: Juzhe-Zhong 
Date:   Thu Dec 14 11:23:43 2023 +0800

RISC-V: Add RVV builtin vectorization cost model

This patch fixes PR11153:

ble a1,zero,.L8
addiw   a5,a1,-1
li  a4,4
addisp,sp,-16
mv  a2,a0
sext.w  a3,a1
bleua5,a4,.L9
srliw   a4,a3,2
sllia4,a4,4
mv  a5,a0
add a4,a4,a0
vsetivlizero,4,e32,m1,ta,ma
vmv.v.i v1,0
vse32.v v1,0(sp)
.L4:
vle32.v v1,0(a5) ---> This loop always processes 4 elements which
is ok for VLEN = 128bits, but waste a huge amount of computation units when
VLEN > 128bits
vle32.v v2,0(sp)
addia5,a5,16
vadd.vv v1,v2,v1
vse32.v v1,0(sp)
bne a4,a5,.L4
ld  a5,0(sp)
lw  a4,0(sp)
andia1,a1,-4
sraia5,a5,32
addwa5,a4,a5
lw  a4,8(sp)
addwa5,a5,a4
ld  a4,8(sp)
sraia4,a4,32
addwa0,a5,a4
beq a3,a1,.L15
.L3:
subwa3,a3,a1
sllia5,a1,32
sllia3,a3,32
srlia3,a3,32
srlia5,a5,30
add a2,a2,a5
vsetvli a5,a3,e8,mf4,tu,mu
vsetvli a4,zero,e32,m1,ta,ma
sub a1,a3,a5
vmv.v.i v1,0
vsetvli zero,a3,e32,m1,tu,ma
vle32.v v2,0(a2)
vmv.v.v v1,v2
bne a3,a5,.L21
.L7:
vsetvli a4,zero,e32,m1,ta,ma
vmv.s.x v2,zero
vredsum.vs  v1,v1,v2
vmv.x.s a5,v1
addwa0,a0,a5
.L15:
addisp,sp,16
jr  ra
.L21:
sllia5,a5,2
add a2,a2,a5
vsetvli zero,a1,e32,m1,tu,ma
vle32.v v2,0(a2)
vadd.vv v1,v1,v2
j   .L7
.L8:
li  a0,0
ret
.L9:
li  a1,0
li  a0,0
j   .L3

The rootcause of this is we missed RVV builtin vectorization cost model.

After this patch:

ble a1,zero,.L4
vsetvli a5,zero,e32,m1,ta,ma
vmv.v.i v1,0
.L3:
vsetvli a5,a1,e32,m1,tu,ma
vle32.v v2,0(a0)
sllia4,a5,2
sub a1,a1,a5
add a0,a0,a4
vadd.vv v1,v2,v1
bne a1,zero,.L3
li  a5,0
vsetivlizero,1,e32,m1,ta,ma
vmv.s.x v2,a5
vsetvli a5,zero,e32,m1,ta,ma
vredsum.vs  v1,v1,v2
vmv.x.s a0,v1
ret
.L4:
li  a0,0
ret

PR target/53

gcc/ChangeLog:

* config/riscv/riscv-protos.h (struct common_vector_cost): New
struct.
(struct scalable_vector_cost): Ditto.
(struct cpu_vector_cost): Ditto.
* config/riscv/riscv-vector-costs.cc (costs::add_stmt_cost): Add
RVV
builtin vectorization cost
* config/riscv/riscv.cc (struct riscv_tune_param): Ditto.
(get_common_costs): New function.
(riscv_builtin_vectorization_cost): Ditto.
(TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST): New targethook.

gcc/testsuite/ChangeLog:

* gcc.dg/vect/costmodel/riscv/rvv/pr53.c: New test.

[Bug target/112986] s390x gcc O2, O3: Incorrect logic operation in < comparison with the same values

[22s302h0659 at sonline20 dot sen.go.kr via Gcc-bugs]

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

--- Comment #5 from 김대영 <22s302h0659 at sonline20 dot sen.go.kr> ---
Thank you for your response. Naturally, I anticipated that the issue might be
with the s390x architecture cross-compiler. However, unexpectedly, I was
unaware that qemu was generating incorrect instructions during the binary
execution process

[Bug target/113016] New: -mtls-dialect=gnu2 conflicts with -mfdpic but ICEs rather than gives an error

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

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

Bug ID: 113016
   Summary: -mtls-dialect=gnu2 conflicts with  -mfdpic but ICEs
rather than gives an error
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: arm-linux-gnueabi

Just a simple testcase like:
```
__thread int t;
int f(void)
{
  return t;
}
```

Compiling with `-mfdpic -mtls-dialect=gnu2 -fPIC -g0` gives an ICE:
```

during RTL pass: expand
: In function 'f':
:5:10: internal compiler error: in legitimize_tls_address, at
config/arm/arm.cc:9358
5 |   return t;
  |  ^
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
```

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

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 113015
   Summary: ICE: verify_ssa failed: definition in block 12 does
not dominate use in block 13 at -O with _BitInt()
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O testcase.c 
testcase.c: In function 'foo':
testcase.c:5:1: error: definition in block 12 does not dominate use in block 13
5 | foo(void)
  | ^~~
for SSA_NAME: _11 in statement:
_10 = PHI <0(2), _11(13)>
PHI argument
_11
for PHI node
_10 = PHI <0(2), _11(13)>
during GIMPLE pass: bitintlower
testcase.c:5:1: internal compiler error: verify_ssa failed
0x1768b9f verify_ssa(bool, bool)
/repo/gcc-trunk/gcc/tree-ssa.cc:1203
0x13bcfd5 execute_function_todo
/repo/gcc-trunk/gcc/passes.cc:2095
0x13bd43e execute_todo
/repo/gcc-trunk/gcc/passes.cc:2142
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

$ 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-6527-20231213172439-gacfd33620af-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-6527-20231213172439-gacfd33620af-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231214 (experimental) (GCC)

[Bug target/113014] RISC-V: Redundant zeroing instructions in reduction due to r14-3998-g6223ea766daf7c

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

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

--- Comment #1 from JuzheZhong  ---
Richard S has a late combine PASS which is going to be merged in GCC-14.

Since we generate this following RTL int split1:

(insn 48 24 49 5 (set (reg:SI 149)
(const_int 0 [0])) -1
 (nil))

(insn 49 48 50 5 (set (reg:RVVM1SI 148)
(if_then_else:RVVM1SI (unspec:RVVMF32BI [
(const_vector:RVVMF32BI [
(const_int 1 [0x1])
repeat [
(const_int 0 [0])
]
])
(const_int 1 [0x1])
(const_int 2 [0x2]) repeated x2
(const_int 0 [0])
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)
(vec_duplicate:RVVM1SI (reg:SI 149))
(unspec:RVVM1SI [
(reg:SI 0 zero)
] UNSPEC_VUNDEF))) -1
 (nil))

I suspect late-combine PASS can combine it into:

(insn 49 48 50 5 (set (reg:RVVM1SI 148)
(if_then_else:RVVM1SI (unspec:RVVMF32BI [
(const_vector:RVVMF32BI [
(const_int 1 [0x1])
repeat [
(const_int 0 [0])
]
])
(const_int 1 [0x1])
(const_int 2 [0x2]) repeated x2
(const_int 0 [0])
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)
(CONST_VECTOR: 0)
(unspec:RVVM1SI [
(reg:SI 0 zero)
] UNSPEC_VUNDEF))) -1
 (nil))

that is: combine

(set(reg0) (0)) and (vec_duplicate:reg0) 

into:

(CONST_VECTOR:0)

after split1 by late-combine PASS.

I am not sure.

Hi,Robin. Could you confirm it for me ?

[Bug tree-optimization/113013] [12/13/14 regression] ICE in fold_convert_loc with -fsanitize=undefined

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

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

--- Comment #3 from Andrew Pinski  ---
The use of __alloc_size__ here is definitely not well defined but GCC should
NOT crash.

[Bug tree-optimization/113013] [12/13/14 regression] ICE in fold_convert_loc with -fsanitize=undefined

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.4

--- Comment #2 from Andrew Pinski  ---
Most likely r12-6479-g404c787e2bfe8cae666b075ed903990ea452220e or
r12-6482-g06bc1b0c539e3a60692d7432d15e701c38610f80 .

[Bug c/113014] New: RISC-V: Redundant zeroing instructions in reduction

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

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

Bug ID: 113014
   Summary: RISC-V: Redundant zeroing instructions in reduction
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juzhe.zhong at rivai dot ai
  Target Milestone: ---

#define DEF_REDUC_PLUS(TYPE)  
\
  TYPE __attribute__ ((noinline, noclone))
\
  reduc_plus_##TYPE (TYPE *__restrict a, int n)   
\
  {   
\
TYPE r = 0;   
\
for (int i = 0; i < n; ++i)   
\
  r += a[i];  
\
return r; 
\
  }

#define TEST_PLUS(T) T (int) T (float)

TEST_PLUS (DEF_REDUC_PLUS)

-fno-vect-cost-model:

li  a5,0 ---> redundant instruction
vsetivlizero,1,e32,m1,ta,ma
vmv.s.x v2,a5

It should be vmv.s.x v2,zero instead.

I realize this is because this commit:
https://hub.fgit.cf/gcc-mirror/gcc/commit/6223ea766daf7c9155106b9784302442e2ff98d3

we change define_expand into define_insn_and_split, since split1 is after
combine pass.

we missed optimization of (vec_duplicate:const0_rtx) into (const_vector:0).

[Bug tree-optimization/113013] [12/13/14 regression] ICE in fold_convert_loc with -fsanitize=undefined

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-12-14

--- Comment #1 from Andrew Pinski  ---
Reduced slightly more:
```
struct _xPoint {
  short x;
} xPoint;
void *reallocarray() __attribute__((__alloc_size__(1)));
struct _xPoint * miZeroLine_pspanInit;
void miZeroLine_list_len(void) {
  miZeroLine_pspanInit = reallocarray(xPoint);
  miZeroLine_pspanInit->x = 0;
}
``

[Bug sanitizer/113012] [13/14 regression] ICE when building xorg-server with -fsanitize=undefined

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Maybe r13-222-g28896b38fabce818e59266b0063a46b3bc1b700f .

[Bug tree-optimization/113013] New: [12/13/14 regression] ICE in fold_convert_loc with -fsanitize=undefined

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

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

Bug ID: 113013
   Summary: [12/13/14 regression] ICE in fold_convert_loc with
-fsanitize=undefined
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

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

Hit this when reducing PR113012.

```
$ gcc -c /tmp/foo.c -O2 -fsanitize=undefined
during GIMPLE pass: objsz
/tmp/foo.c: In function ‘miZeroLine_list_len’:
/tmp/foo.c:9:6: internal compiler error: in fold_convert_loc, at
fold-const.cc:2602
9 | void miZeroLine_list_len() {
  |  ^~~
0x55eb4274eca3 fold_convert_loc(unsigned int, tree_node*, tree_node*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231210/gcc-14-20231210/gcc/fold-const.cc:2602
0x55eb446f7d13 alloc_object_size
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231210/gcc-14-20231210/gcc/tree-object-size.cc:811
0x55eb446f7d13 call_object_size
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231210/gcc-14-20231210/gcc/tree-object-size.cc:1339
0x55eb446f7d13 collect_object_sizes_for
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231210/gcc-14-20231210/gcc/tree-object-size.cc:1779
0x55eb4418920f compute_builtin_object_size(tree_node*, int, tree_node**)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231210/gcc-14-20231210/gcc/tree-object-size.cc:1194
0x55eb43fab777 fold_builtin_object_size
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231210/gcc-14-20231210/gcc/builtins.cc:11556
0x55eb43fab777 fold_builtin_2
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231210/gcc-14-20231210/gcc/builtins.cc:10575
0x55eb43fab777 fold_builtin_n(unsigned int, tree_node*, tree_node*,
tree_node**, int, bool) [clone .isra.0]
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231210/gcc-14-20231210/gcc/builtins.cc:10687
0x55eb440cd22d dynamic_object_sizes_execute_one
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231210/gcc-14-20231210/gcc/tree-object-size.cc:2078
0x55eb440cd22d object_sizes_execute
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231210/gcc-14-20231210/gcc/tree-object-size.cc:2140
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
```

[Bug tree-optimization/113012] [13/14 regression] ICE when building xorg-server with -fsanitize=undefined

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

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

--- Comment #3 from Andrew Pinski  ---
Note once we remove the -1, GCC does not ICE. I am 99% sure it is undefined to
go one before the begining of the array, only one past the end of the array is
well defined.

Note I am not shocked that xorg has undefined code in it too.

[Bug tree-optimization/113012] [13/14 regression] ICE when building xorg-server with -fsanitize=undefined

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> Note I am not 100% sure the above code is well defined due to subtracting
> one from the allocated array.

and yes this represents exactly what the code does.

[Bug tree-optimization/113012] [13/14 regression] ICE when building xorg-server with -fsanitize=undefined

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Reduced testcase:
```
typedef __SIZE_TYPE__ size_t;
extern void *reallocarray(void *__ptr, size_t __nmemb, size_t __size)
__attribute__((__alloc_size__(2, 3)));
void miZeroLine(int npt, int Nspans, int list_len, int ady) {
  int *pwidthInit, *widths;
  pwidthInit = reallocarray(0, (list_len), (sizeof(int)));
  widths = pwidthInit - 1;
  while (--npt > 0)
  {
if (ady + 1 > Nspans)
  widths = pwidthInit - 1;
++*widths;
++widths;
  }
}

```

Note I am not 100% sure the above code is well defined due to subtracting one
from the allocated array.

[Bug target/112871] [14 Regression] RISCV ICE: in extract_insn, at recog.cc:2804 (unrecognizable insn) with -01 rv32gc_zicond

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

 CC||jeffreyalaw at gmail dot com

--- Comment #2 from Patrick O'Neill  ---
Bisected to r14-3041-g18c453f0e63

[Bug target/113001] [14 Regression] RISCV Zicond ICE: in extract_insn, at recog.cc:2812 with -O2 rv64gcv_zicond

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #1 from Patrick O'Neill  ---
Bisected to r14-3041-g18c453f0e63

[Bug tree-optimization/113012] [14 regression] ICE when building xorg-server with -fsanitize=undefined

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |14.0
  Component|middle-end  |tree-optimization

[Bug middle-end/113012] New: [14 regression] ICE when building xorg-server with -fsanitize=undefined

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

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

Bug ID: 113012
   Summary: [14 regression] ICE when building xorg-server with
-fsanitize=undefined
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 56875
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56875&action=edit
mizerline.c.i

Hit this when building xorg-server. Only hit it by chance when poking at
something else...

```
$ gcc -c mizerline.c.i -fsanitize=undefined -O2
gimplification failed:
0 
constant 0>
during GIMPLE pass: objsz
In function ‘miZeroLine’:
cc1: internal compiler error: gimplification failed
0x55aa6617eb5b gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231210/gcc-14-20231210/gcc/gimplify.cc:17753
0x55aa678d24bf gimplify_modify_expr
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231210/gcc-14-20231210/gcc/gimplify.cc:6418
0x55aa678c383c gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231210/gcc-14-20231210/gcc/gimplify.cc:16719
0x55aa67b39946 force_gimple_operand_1(tree_node*, gimple**, bool
(*)(tree_node*), tree_node*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231210/gcc-14-20231210/gcc/gimplify-me.cc:78
0x55aa67acd61a gimplify_size_expressions
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231210/gcc-14-20231210/gcc/tree-object-size.cc:1088
0x55aa67acd61a compute_builtin_object_size(tree_node*, int, tree_node**)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231210/gcc-14-20231210/gcc/tree-object-size.cc:1199
0x55aa678ef777 fold_builtin_object_size
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231210/gcc-14-20231210/gcc/builtins.cc:11556
0x55aa678ef777 fold_builtin_2
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231210/gcc-14-20231210/gcc/builtins.cc:10575
0x55aa678ef777 fold_builtin_n(unsigned int, tree_node*, tree_node*,
tree_node**, int, bool) [clone .isra.0]
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231210/gcc-14-20231210/gcc/builtins.cc:10687
0x55aa67a1122d dynamic_object_sizes_execute_one
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231210/gcc-14-20231210/gcc/tree-object-size.cc:2078
0x55aa67a1122d object_sizes_execute
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231210/gcc-14-20231210/gcc/tree-object-size.cc:2140
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.
```

```
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/14/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231210/work/gcc-14-20231210/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/14
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/14/python
--enable-languages=c,c++,fortran,rust --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=yes,extra,rtl
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened
14.0.0_pre20231210 p10' --with-gcc-major-version-only --enable-libstdcxx-time
--enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-multilib
--with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all
--enable-libgomp --disable-libssp --disable-libada --enable-cet
--disable-systemtap --enable-valgrind-annotations --disable-vtable-verify
--disable-libvtv --with-zstd --with-isl --disable-isl-version-check
--enable-default-pie --enable-host-pie --enable-host-bind-now
--enable-default-ssp --with-build-config='bootstrap-O3 bootstrap-lto
bootstrap-cet'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231210 (experimental) (Gentoo Hardened 14.0.0_pre20231210
p10)
```

[Bug libstdc++/112997] _Unwind_Exception conflicts with void*. failed to build with clang

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #7 from cqwrteur  ---
(In reply to Andrew Pinski from comment #5)
> (In reply to cqwrteur from comment #4)
> > (In reply to Andrew Pinski from comment #1)
> > > Why are you building libstdc++ sources with clang? I doubt that is 
> > > supported.
> > 
> > GCC does not support WebAssembly backend
> 
> Then libstdc++ has not been ported . Or you implement add a WebAssembly
> backend to GCC.

i do not know whether binutils has implemented wasm. Or i would like to
implement a wasm backend to GCC tbh.

[Bug c/113011] main declared with enumerated type is not accepted

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

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

--- Comment #4 from Andrew Pinski  ---
C23 working draft can be found at
https://open-std.org/JTC1/SC22/WG14/www/docs/n3096.pdf .

[Bug c/113011] main declared with enumerated type is not accepted

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
C23 working draft has the same wording there too:
The function called at program startup is named main.The implementation
declares no prototype for this function. It shallbe defined with a return type
of int

Nowhere it says compatiable with int. just the return type of int.

[Bug c/113011] main declared with enumerated type is not accepted

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

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

--- Comment #2 from Andrew Pinski  ---
>From C99 draft: 5.1.2.2.1 Program startup
The function called at program startup is named main.The implementation
declares no prototype for this function. It shall be defined with a return type
ofintand with no parameters
...
or with two parameters (referred to here asargcandargv, though anynames may be
used, as theyare local to the function in which theyare declared):

[Bug c/113011] main declared with enumerated type is not accepted

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

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

--- Comment #1 from Andrew Pinski  ---
clang even errors out:
:6:1: error: 'main' must return 'int'
6 | enum E main(){}
  | ^~
  | int

[Bug c/113011] New: main declared with enumerated type is not accepted

[luigighiron at gmail dot com via Gcc-bugs]

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

Bug ID: 113011
   Summary: main declared with enumerated type is not accepted
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: luigighiron at gmail dot com
  Target Milestone: ---

The following code is rejected in GCC with pedantic mode enabled:

enum E{e=-1};
_Static_assert(
_Generic((enum E)e,int:1,default:0),
"incorrect enumeration type"
);
enum E main(){}

If the static assertion succeeds, then the type enum E is compatible with int.
Given that enum E is compatible with int, it should be a valid return type of
main:

> If the return type of the main function is a type compatible with int,
> a return from the initial call to the main function is equivalent to
> calling the exit function with the value returned by the main function
> as its argument; reaching the } that terminates the main function returns
> a value of 0. If the return type is not compatible with int, the termination
> status returned to the host environment is unspecified.
Section 5.1.2.2.3 "Program termination" Paragraph 1 ISO/IEC 9899:2018

Additionally, here is the paragraph explaining that an enumerated type is
compatible with its underlying type:

> Each enumerated type shall be compatible with char, a signed integer type,
> or an unsigned integer type. The choice of type is implementation-defined,
> but shall be capable of representing the values of all the members of the
> enumeration.
Section 6.7.2.2 "Enumeration specifiers" Paragraph 4 ISO/IEC 9899:2018

Outside of pedantic mode, GCC accepts the code but returns a non-zero value
when the closing brace is reached which isn't correct either.

[Bug target/113009] [14] RISC-V: gcc.c-torture/unsorted/dump-noaddr.c flakey tests

[ewlu at rivosinc dot com via Gcc-bugs]

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

--- Comment #4 from Edwin Lu  ---
(In reply to JuzheZhong from comment #3)
> (In reply to Edwin Lu from comment #2)
> > Re-bisected to r14-6197-g2e7abd09621
> > 
> > Full steps to reproduce:
> > mkdir dump1
> > ./build-gcc-linux-stage2/gcc/xgcc -B./build-gcc-linux-stage2/gcc/  
> > -march=rv64gcv -mabi=lp64d -mcmodel=medlow   -fdiagnostics-plain-output  -w 
> > -O3 -g   -dumpbase dump1/dump-noaddr.c -DMASK=1 -x c --param
> > ggc-min-heapsize=1 -fdump-ipa-all -fdump-rtl-all -fdump-tree-all
> > -fdump-noaddr -gno-record-gcc-switches -c   -o
> > ./build-gcc-linux-stage2/gcc/testsuite/gcc/dump-noaddr.o
> > ../gcc/gcc/testsuite/gcc.c-torture/unsorted/dump-noaddr.c
> > mv dump1 dump1-comp
> > mkdir dump1
> > for i in {1..100}; do 
> >   ./build-gcc-linux-stage2/gcc/xgcc -B./build-gcc-linux-stage2/gcc/  
> > -march=rv64gcv -mabi=lp64d -mcmodel=medlow   -fdiagnostics-plain-output  -w 
> > -O3 -g   -dumpbase dump1/dump-noaddr.c -DMASK=1 -x c --param
> > ggc-min-heapsize=1 -fdump-ipa-all -fdump-rtl-all -fdump-tree-all
> > -fdump-noaddr -gno-record-gcc-switches -c   -o
> > ./build-gcc-linux-stage2/gcc/testsuite/gcc/dump-noaddr.o
> > ../gcc/gcc/testsuite/gcc.c-torture/unsorted/dump-noaddr.c && diff -d
> > dump1/dump-noaddr.c.*r.avlprop ./dump1-comp/dump-noaddr.c.*r.avlprop; 
> > done
> > 
> > may take around 2-3 min for the diff output to start appearing depending on
> > whether the expected output is saved into dump-comp or not
> 
> Thanks for reporting it.  I will take a look at it.
> That commit is to fix ICE and execution issues (real bugs).
> 
> We are busy with fixing real bugs (ICE and execution FAILs) on full coverage
> testing.
> Dump FAILs are bogus FAILs, it's low priority for now.

While it is a dump failure, there is some non-determinism in the compilation.
Running the same executable on the same piece of code should not try compiling
it differently every time.

[Bug libstdc++/113007] `std::variant` converting constructor and `operator=` compile while the C++ Standard says they must not

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
#include 

int main()
{
  int i = 42;
  std::monostate x_0[] = { i };
  bool x_1[] = { i };
  long long x_2[] = { i };
  double x_3[] = { i };
}

var.cc: In function ‘int main()’:
var.cc:6:30: error: initializer for ‘std::monostate’ must be brace-enclosed
6 |   std::monostate x_0[] = { i };
  |  ^
var.cc:7:18: warning: narrowing conversion of ‘i’ from ‘int’ to ‘bool’
[-Wnarrowing]
7 |   bool x_1[] = { i };
  |  ^
var.cc:9:20: warning: narrowing conversion of ‘i’ from ‘int’ to ‘double’
[-Wnarrowing]
9 |   double x_3[] = { i };
  |^

Narrowing conversions are hard errors in SFINAE contexts, even though they're
just a warning in other contexts.

Only x_2 is well-formed, and so the overload set is just F(int64_t).

[Bug libstdc++/113007] `std::variant` converting constructor and `operator=` compile while the C++ Standard says they must not

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

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Pavel Novikov from comment #0)
> e.g. for `std::variant` the overload
> set would be
> 
> void F(std::monostate) {}
> void F(bool) {}
> void F(int64_t) {}
> void F(double) {}

No, because it says:

"build an imaginary function FUN(Ti) for each alternative type Ti for which Ti
x[] = {std​::​forward(t)}; is well-formed for some invented variable x."

That array initializer would be ill-formed for all except int64_t.
std::monostate just can't be initialized from an int, and for double and bool
it's a narrowing conversion (because of the braces).

I think libstdc++ is correct.

[Bug target/113009] [14] RISC-V: gcc.c-torture/unsorted/dump-noaddr.c flakey tests

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

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

--- Comment #3 from JuzheZhong  ---
(In reply to Edwin Lu from comment #2)
> Re-bisected to r14-6197-g2e7abd09621
> 
> Full steps to reproduce:
> mkdir dump1
> ./build-gcc-linux-stage2/gcc/xgcc -B./build-gcc-linux-stage2/gcc/  
> -march=rv64gcv -mabi=lp64d -mcmodel=medlow   -fdiagnostics-plain-output  -w 
> -O3 -g   -dumpbase dump1/dump-noaddr.c -DMASK=1 -x c --param
> ggc-min-heapsize=1 -fdump-ipa-all -fdump-rtl-all -fdump-tree-all
> -fdump-noaddr -gno-record-gcc-switches -c   -o
> ./build-gcc-linux-stage2/gcc/testsuite/gcc/dump-noaddr.o
> ../gcc/gcc/testsuite/gcc.c-torture/unsorted/dump-noaddr.c
> mv dump1 dump1-comp
> mkdir dump1
> for i in {1..100}; do 
>   ./build-gcc-linux-stage2/gcc/xgcc -B./build-gcc-linux-stage2/gcc/  
> -march=rv64gcv -mabi=lp64d -mcmodel=medlow   -fdiagnostics-plain-output  -w 
> -O3 -g   -dumpbase dump1/dump-noaddr.c -DMASK=1 -x c --param
> ggc-min-heapsize=1 -fdump-ipa-all -fdump-rtl-all -fdump-tree-all
> -fdump-noaddr -gno-record-gcc-switches -c   -o
> ./build-gcc-linux-stage2/gcc/testsuite/gcc/dump-noaddr.o
> ../gcc/gcc/testsuite/gcc.c-torture/unsorted/dump-noaddr.c && diff -d
> dump1/dump-noaddr.c.*r.avlprop ./dump1-comp/dump-noaddr.c.*r.avlprop; 
> done
> 
> may take around 2-3 min for the diff output to start appearing depending on
> whether the expected output is saved into dump-comp or not

Thanks for reporting it.  I will take a look at it.
That commit is to fix ICE and execution issues (real bugs).

We are busy with fixing real bugs (ICE and execution FAILs) on full coverage
testing.
Dump FAILs are bogus FAILs, it's low priority for now.

[Bug libstdc++/112997] _Unwind_Exception conflicts with void*. failed to build with clang

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

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

--- Comment #6 from Jonathan Wakely  ---
I think we can just change the declaration in unwind-cxx.h

[Bug target/113009] [14] RISC-V: gcc.c-torture/unsorted/dump-noaddr.c flakey tests

[ewlu at rivosinc dot com via Gcc-bugs]

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

Edwin Lu  changed:

   What|Removed |Added

 CC||juzhe.zhong at rivai dot ai

--- Comment #2 from Edwin Lu  ---
Re-bisected to r14-6197-g2e7abd09621

Full steps to reproduce:
mkdir dump1
./build-gcc-linux-stage2/gcc/xgcc -B./build-gcc-linux-stage2/gcc/  
-march=rv64gcv -mabi=lp64d -mcmodel=medlow   -fdiagnostics-plain-output  -w 
-O3 -g   -dumpbase dump1/dump-noaddr.c -DMASK=1 -x c --param ggc-min-heapsize=1
-fdump-ipa-all -fdump-rtl-all -fdump-tree-all -fdump-noaddr
-gno-record-gcc-switches -c   -o
./build-gcc-linux-stage2/gcc/testsuite/gcc/dump-noaddr.o
../gcc/gcc/testsuite/gcc.c-torture/unsorted/dump-noaddr.c
mv dump1 dump1-comp
mkdir dump1
for i in {1..100}; do 
  ./build-gcc-linux-stage2/gcc/xgcc -B./build-gcc-linux-stage2/gcc/  
-march=rv64gcv -mabi=lp64d -mcmodel=medlow   -fdiagnostics-plain-output  -w 
-O3 -g   -dumpbase dump1/dump-noaddr.c -DMASK=1 -x c --param ggc-min-heapsize=1
-fdump-ipa-all -fdump-rtl-all -fdump-tree-all -fdump-noaddr
-gno-record-gcc-switches -c   -o
./build-gcc-linux-stage2/gcc/testsuite/gcc/dump-noaddr.o
../gcc/gcc/testsuite/gcc.c-torture/unsorted/dump-noaddr.c && diff -d
dump1/dump-noaddr.c.*r.avlprop ./dump1-comp/dump-noaddr.c.*r.avlprop; 
done

may take around 2-3 min for the diff output to start appearing depending on
whether the expected output is saved into dump-comp or not

[Bug tree-optimization/112468] [14 Regression] Missed phi-opt after recent change (phi-opt-24.c)

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

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

--- Comment #11 from Hans-Peter Nilsson  ---
(In reply to Tamar Christina from comment #10)
> Hi,
> 
> It's not forgotten. I've agreed on a fix with the maintainers that should
> solve a bunch of other (older) issues with copysign as well.
> 
> Since it's a bug fix it's on my list after my stage3 changes.  But I expect
> to be able to send the patch next week.
> 
> Sorry for the delay.

Fair enough, thanks for the update!

[Bug libstdc++/112997] _Unwind_Exception conflicts with void*. failed to build with clang

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #5 from Andrew Pinski  ---
(In reply to cqwrteur from comment #4)
> (In reply to Andrew Pinski from comment #1)
> > Why are you building libstdc++ sources with clang? I doubt that is 
> > supported.
> 
> GCC does not support WebAssembly backend

Then libstdc++ has not been ported . Or you implement add a WebAssembly backend
to GCC.

[Bug middle-end/80283] [11/12/13/14 Regression] bad SIMD register allocation

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

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

--- Comment #38 from Andrew Pinski  ---
For aarch64, the test from comment #11 is so much worse on the trunk than in
GCC 13.2.0.

[Bug libstdc++/112997] _Unwind_Exception conflicts with void*. failed to build with clang

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #4 from cqwrteur  ---
(In reply to Andrew Pinski from comment #1)
> Why are you building libstdc++ sources with clang? I doubt that is supported.

GCC does not support WebAssembly backend

[Bug rtl-optimization/112758] [13/14 Regression] Inconsistent Bitwise AND Operation Result between int and long long int

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||gkm at rivosinc dot com

--- Comment #13 from Andrew Pinski  ---
*** Bug 113010 has been marked as a duplicate of this bug. ***

[Bug target/113010] [RISCV] sign-extension lost in comparison with constant embedded in comma-op expression

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 112758.  See the discussion there ...

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

[Bug target/113009] [14] RISC-V: gcc.c-torture/unsorted/dump-noaddr.c flakey tests

[ewlu at rivosinc dot com via Gcc-bugs]

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

--- Comment #1 from Edwin Lu  ---
Found issue with bisection script. Currently re-bisecting

[Bug target/113010] New: [RISCV] sign-extension lost in comparison with constant embedded in comma-op expression

[gkm at rivosinc dot com via Gcc-bugs]

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

Bug ID: 113010
   Summary: [RISCV] sign-extension lost in comparison with
constant embedded in comma-op expression
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gkm at rivosinc dot com
  Target Milestone: ---

Implicit conversion rules in C for comparing (unsigned long) with (int) require
that (int) first widen to (long) extending sign, then convert to (unsigned
long). 

I debugged this far enough to see that expand_compound_operation () in
combine.cc converts (SIGN_EXTEND:DI (mem/c:SI ... )) into paradoxical
(SUBREG:DI (mem/c:SI ... )), and thus loses the sign extension.

It only happens when the constant comparand is within a comma operator.


Test case:
--
int minus_1 = -1;

int main ()
{
  return ((0, 0xul) < minus_1) ? 0 : 1;
}
--
Godbolt:
https://godbolt.org/z/xPMPzG1n1

The -march=rv64gc case begins to fail with gcc-13
The -march=rv64gc_zbs case begins to fail with gcc-12

[Bug target/113009] New: [14] RISC-V: gcc.c-torture/unsorted/dump-noaddr.c flakey tests

[ewlu at rivosinc dot com via Gcc-bugs]

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

Bug ID: 113009
   Summary: [14] RISC-V: gcc.c-torture/unsorted/dump-noaddr.c
flakey tests
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ewlu at rivosinc dot com
  Target Milestone: ---

The following tests are flakey on newlib/linux for 32-bit and 64-bit vector
targets

FAIL: gcc.c-torture/unsorted/dump-noaddr.c.*r.avlprop,  -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions 
comparison
FAIL: gcc.c-torture/unsorted/dump-noaddr.c.*r.avlprop,  -O3 -g  comparison
FAIL: gcc.c-torture/unsorted/dump-noaddr.c.*r.reload,  -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  comparison
FAIL: gcc.c-torture/unsorted/dump-noaddr.c.*r.reload,  -O3 -g  comparison

With logs along the lines of 

line #8
< rescanning insn with uid = 213.
> rescanning insn with uid = 215.
line #9
< verify found no changes in insn with uid = 213.
> verify found no changes in insn with uid = 215.
line #10
< rescanning insn with uid = 215.
> rescanning insn with uid = 213.
line #11
< verify found no changes in insn with uid = 215.
> verify found no changes in insn with uid = 213.
FAIL: gcc.c-torture/unsorted/dump-noaddr.c.*r.avlprop,  -O3 -g  comparison

line #694
< changing reg in insn 215
> changing reg in insn 213
line #695
< changing reg in insn 213
> changing reg in insn 215
FAIL: gcc.c-torture/unsorted/dump-noaddr.c.*r.reload,  -O3 -g  comparison

Flakey tests bisected to r14-5744-gae098dfeeef though this is a rough estimate.
I only compiled and diffed the output 20 times for each hash during the
bisection so I might have just gotten lucky (or unlucky) when searching for the
"good" hash.

Command used:
./build-gcc-linux-stage2/gcc/xgcc -B./build-gcc-linux-stage2/gcc/  
-march=rv64gcv -mabi=lp64d -mcmodel=medlow   -fdiagnostics-plain-output  -w 
-O3 -g   -dumpbase dump1/dump-noaddr.c -DMASK=1 -x c --param ggc-min-heapsize=1
-fdump-ipa-all -fdump-rtl-all -fdump-tree-all -fdump-noaddr
-gno-record-gcc-switches -c   -o
./build-gcc-linux-stage2/gcc/testsuite/gcc/dump-noaddr.o
../gcc/gcc/testsuite/gcc.c-torture/unsorted/dump-noaddr.c && diff -d
dump1/dump-noaddr.c.*r.avlprop
../../baseline/build-flakey/dump1/dump-noaddr.c.302r.avlprop

All recorded instances can be found here:
https://github.com/patrick-rivos/gcc-postcommit-ci/issues?q=FAIL%3A+gcc.c-torture%2Funsorted%2Fdump-noaddr.c.*r.avlprop%2C+-O3+-g+comparison+

[Bug c++/113008] New: Trivially default constructible requires default member initializer before the end of its enclosing class

[barry.revzin at gmail dot com via Gcc-bugs]

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

Bug ID: 113008
   Summary: Trivially default constructible requires default
member initializer before the end of its enclosing
class
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

This is related to bugs PR96645 and PR88165.

Consider this:

#include 

template 
struct Array {
T elems[N];
};

struct A {
struct B {
int i = 0;
};

static constexpr bool v1 = std::is_trivially_default_constructible_v;
static constexpr bool v2 =
std::is_trivially_default_constructible_v>;
};



Declaring v1 works (and it correctly evaluates to false).

Declaring v2 fails to compile entirely:

opt/compiler-explorer/gcc-trunk-20231213/include/c++/14.0.0/type_traits:3284:7:
  required from 'constexpr const bool
std::is_trivially_default_constructible_v >'
 3284 | = __is_trivially_constructible(_Tp);
  |   ^
:14:37:   required from here
   14 | static constexpr bool v2 =
std::is_trivially_default_constructible_v>;
  |
^~
/opt/compiler-explorer/gcc-trunk-20231213/include/c++/14.0.0/type_traits:3284:7:
error: default member initializer for 'A::B::i' required before the end of its
enclosing class
 3284 | = __is_trivially_constructible(_Tp);
  |   ^
:10:15: note: defined here
   10 | int i = 0;
  |   ^~~~

If we know that B isn't trivially default constructible (A::v1 is initialized
to false), then can't we likewise also know that Array isn't trivially
default constructible?

[Bug libstdc++/113007] `std::variant` converting constructor and `operator=` compile while the C++ Standard says they must not

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

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 56874
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56874&action=edit
Full testcase

Please next time attach the full testcase (or place it inline) instead of just
linking to godbolt.

[Bug libstdc++/113007] New: `std::variant` converting constructor and `operator=` compile while the C++ Standard says they must not

[paul.skeptic at yandex dot ru via Gcc-bugs]

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

Bug ID: 113007
   Summary: `std::variant` converting constructor and `operator=`
compile while the C++ Standard says they must not
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: paul.skeptic at yandex dot ru
  Target Milestone: ---

According to [variant.ctor] (https://eel.is/c++draft/variant.ctor, also see
https://en.cppreference.com/w/cpp/utility/variant/variant) converting
constructor

template
constexpr variant(T&& t) noexcept(/*...*/);

determines the alternative to construct as if by selecting an overload for
`F(std​::​forward(​t))` from an overload set `F(T_j)` where `T_j` are types
of the alternatives,
e.g. for `std::variant` the overload set
would be

void F(std::monostate) {}
void F(bool) {}
void F(int64_t) {}
void F(double) {}


In violation of the standard this code compiles with GCC and libstdc++
(https://godbolt.org/z/fd8xa1bqM):

std::variant v = 42;

while overload resolution of `F()` fails:

F(42); // error: ambiguous confused_john_travolta.gif

Compiler output:

: In function 'int main()':
:14:4: error: call of overloaded 'F(int)' is ambiguous
   14 |   F(42);
  |   ~^~~~
:6:6: note: candidate: 'void F(bool)'
6 | void F(bool) {}
  |  ^
:7:6: note: candidate: 'void F(int64_t)'
7 | void F(int64_t) {}
  |  ^
:8:6: note: candidate: 'void F(double)'
8 | void F(double) {}
  |  ^


Also the same applies to converting assignment operator

template
constexpr variant& operator=(T&& t) noexcept(/*...*/);

see [variant.assign] (https://eel.is/c++draft/variant.assign, also
https://en.cppreference.com/w/cpp/utility/variant/operator%3D).

Among libc++, libstdc++ and MSVC standard libraries only MSVC standard library
gets it according to the standard so you can look at it for reference.

See corresponding bug for libc++:
https://github.com/llvm/llvm-project/issues/75323

[Bug c++/101603] [meta-bug] pointer to member functions issues

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

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

Bug 93740 Summary: Template base classes parametrized by pointer-to-member are 
amibiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93740

   What|Removed |Added

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

[Bug c++/93740] Template base classes parametrized by pointer-to-member are amibiguous

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

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||ppalka at gcc dot gnu.org
 Status|NEW |RESOLVED
   Target Milestone|--- |14.0

--- Comment #7 from Patrick Palka  ---
Fixed for GCC 14.

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

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

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

Bug 93740 Summary: Template base classes parametrized by pointer-to-member are 
amibiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93740

   What|Removed |Added

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

[Bug c++/99186] std::tuple compilation error when elements are specializations of template class declared with template < auto E > syntax with E being a enumerator of a enum

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:35ba3add7d0a9fc6ce955ba8ad82b0413e86ad7d

commit r14-6520-g35ba3add7d0a9fc6ce955ba8ad82b0413e86ad7d
Author: Patrick Palka 
Date:   Wed Dec 13 15:55:14 2023 -0500

c++: unifying constants vs their type [PR99186, PR104867]

When unifying constants we need to treat constants of different types
but same value as different in light of auto template parameters since
otherwise e.g. A<1> will unify with A<1u> (where A's template-head is
template).  This patch fixes this in a minimal way; it seems we
could get away with just using template_args_equal here, as we do in the
default case, or even just cp_tree_equal since the CONVERT_EXPR_P loop
seems to be dead code, but that's a simplification we could consider
during next stage 1.

PR c++/99186
PR c++/104867

gcc/cp/ChangeLog:

* pt.cc (unify) : Compare types as well.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/nontype-auto23.C: New test.
* g++.dg/cpp1z/nontype-auto24.C: New test.

[Bug c++/104867] Base class matching ignores type of `auto` template parameter

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:35ba3add7d0a9fc6ce955ba8ad82b0413e86ad7d

commit r14-6520-g35ba3add7d0a9fc6ce955ba8ad82b0413e86ad7d
Author: Patrick Palka 
Date:   Wed Dec 13 15:55:14 2023 -0500

c++: unifying constants vs their type [PR99186, PR104867]

When unifying constants we need to treat constants of different types
but same value as different in light of auto template parameters since
otherwise e.g. A<1> will unify with A<1u> (where A's template-head is
template).  This patch fixes this in a minimal way; it seems we
could get away with just using template_args_equal here, as we do in the
default case, or even just cp_tree_equal since the CONVERT_EXPR_P loop
seems to be dead code, but that's a simplification we could consider
during next stage 1.

PR c++/99186
PR c++/104867

gcc/cp/ChangeLog:

* pt.cc (unify) : Compare types as well.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/nontype-auto23.C: New test.
* g++.dg/cpp1z/nontype-auto24.C: New test.

[Bug c++/93740] Template base classes parametrized by pointer-to-member are amibiguous

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r14-6519-gc822ad86984e752734b9c371f9cfef9330334ec4
Author: Patrick Palka 
Date:   Wed Dec 13 15:55:01 2023 -0500

c++: unifying FUNCTION_DECLs [PR93740]

unify currently always returns success when unifying two FUNCTION_DECLs
(due to the is_overloaded_fn deferment within the default case), which
means for the below testcase we incorrectly unify &A::foo and &A::bar
leading to deduction failure for the index_of calls due to a bogus base
class ambiguity.

This patch makes unify handle FUNCTION_DECL naturally like other decls.

PR c++/93740

gcc/cp/ChangeLog:

* pt.cc (unify) : Handle it like FIELD_DECL
and TEMPLATE_DECL.

gcc/testsuite/ChangeLog:

* g++.dg/template/ptrmem34.C: New test.

[Bug middle-end/113006] New: OpenMP 5 - lvalue parsing support for map/to/from clause

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

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

Bug ID: 113006
   Summary: OpenMP 5 - lvalue parsing support for map/to/from
clause
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jules at gcc dot gnu.org
  Target Milestone: ---

The following test:

  libgomp/testsuite/libgomp.c++/baseptrs-4.C

partly depends on the following in-review patches:

  https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629365.html
  https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629364.html

Tobias points out there is currently an unresolved OpenMP issue, 2618 ("Clarify
behavior of mapping lvalues on target construct"), which talks about whether
code like the following:

   map(*p = 10)
   map(x = 20)
   map(x ? y[0] : p[1])
   map(f(y))

is valid or not. He writes that the sentiment was to require that a 'map'
clause list item must have a base pointer or a base variable.

As far as I know, none of these "problematic" cases are permitted by the above
patches, but it might be worth following the OpenMP issue to make sure that
nothing diverges.

[Bug libfortran/113005] New: 'libgomp.fortran/rwlock_1.f90', 'libgomp.fortran/rwlock_3.f90' execution test timeouts

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

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

Bug ID: 113005
   Summary: 'libgomp.fortran/rwlock_1.f90',
'libgomp.fortran/rwlock_3.f90' execution test timeouts
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: hjl at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64le-linux-gnu

On several of our "big iron" powerpc64le-linux-gnu systems, I'm seeing the new
test cases 'libgomp.fortran/rwlock_1.f90', 'libgomp.fortran/rwlock_3.f90' run
into execution test timeouts (300 s).  Those were added in commit
r14-6425-gb806c88fab3f9c6833563f9a44b608dd5dd14de9 "libgfortran: Replace mutex
with rwlock".

PASS: libgomp.fortran/rwlock_1.f90   -O0  (test for excess errors)
WARNING: program timed out.
FAIL: libgomp.fortran/rwlock_1.f90   -O0  execution test
PASS: libgomp.fortran/rwlock_1.f90   -O1  (test for excess errors)
WARNING: program timed out.
FAIL: libgomp.fortran/rwlock_1.f90   -O1  execution test
PASS: libgomp.fortran/rwlock_1.f90   -O2  (test for excess errors)
WARNING: program timed out.
FAIL: libgomp.fortran/rwlock_1.f90   -O2  execution test
PASS: libgomp.fortran/rwlock_1.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
WARNING: program timed out.
FAIL: libgomp.fortran/rwlock_1.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
PASS: libgomp.fortran/rwlock_1.f90   -O3 -g  (test for excess errors)
WARNING: program timed out.
FAIL: libgomp.fortran/rwlock_1.f90   -O3 -g  execution test
PASS: libgomp.fortran/rwlock_1.f90   -Os  (test for excess errors)
WARNING: program timed out.
FAIL: libgomp.fortran/rwlock_1.f90   -Os  execution test
PASS: libgomp.fortran/rwlock_2.f90   -O0  (test for excess errors)
PASS: libgomp.fortran/rwlock_2.f90   -O0  execution test
PASS: libgomp.fortran/rwlock_2.f90   -O1  (test for excess errors)
PASS: libgomp.fortran/rwlock_2.f90   -O1  execution test
PASS: libgomp.fortran/rwlock_2.f90   -O2  (test for excess errors)
PASS: libgomp.fortran/rwlock_2.f90   -O2  execution test
PASS: libgomp.fortran/rwlock_2.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
PASS: libgomp.fortran/rwlock_2.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
PASS: libgomp.fortran/rwlock_2.f90   -O3 -g  (test for excess errors)
PASS: libgomp.fortran/rwlock_2.f90   -O3 -g  execution test
PASS: libgomp.fortran/rwlock_2.f90   -Os  (test for excess errors)
PASS: libgomp.fortran/rwlock_2.f90   -Os  execution test
PASS: libgomp.fortran/rwlock_3.f90   -O0  (test for excess errors)
WARNING: program timed out.
FAIL: libgomp.fortran/rwlock_3.f90   -O0  execution test
PASS: libgomp.fortran/rwlock_3.f90   -O1  (test for excess errors)
WARNING: program timed out.
FAIL: libgomp.fortran/rwlock_3.f90   -O1  execution test
PASS: libgomp.fortran/rwlock_3.f90   -O2  (test for excess errors)
WARNING: program timed out.
FAIL: libgomp.fortran/rwlock_3.f90   -O2  execution test
PASS: libgomp.fortran/rwlock_3.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
WARNING: program timed out.
FAIL: libgomp.fortran/rwlock_3.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
PASS: libgomp.fortran/rwlock_3.f90   -O3 -g  (test for excess errors)
WARNING: program timed out.
FAIL: libgomp.fortran/rwlock_3.f90   -O3 -g  execution test
PASS: libgomp.fortran/rwlock_3.f90   -Os  (test for excess errors)
WARNING: program timed out.
FAIL: libgomp.fortran/rwlock_3.f90   -Os  execution test

All-PASS on all x86_64-pc-linux-gnu systems that I've tested.

[Bug middle-end/113004] New: OpenMP 5 - structs are not mapped element-wise by default

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

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

Bug ID: 113004
   Summary: OpenMP 5 - structs are not mapped element-wise by
default
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jules at gcc dot gnu.org
  Target Milestone: ---

According to e.g. OpenMP 5.2, "5.8.2 Mapper Identifiers and mapper Modifiers":

"A structure type T has a predefined default mapper that is defined as if by a
declare mapper directive that specifies v in a map clause with the alloc
map-type and each structure element of v in a map clause with the tofrom
map-type."

At present, a variable of struct type will be mapped as as a single block (the
pre-OpenMP 5.0 legacy behaviour).

This works fine most of the time, but for example fails in the case where one
of the struct's members is a reference, demonstrated in the test case:

  libgomp/testsuite/libgomp.c++/target-49.C

Once "declare mapper" support is committed, cases where a struct with an
implicit default mapper should invoke a struct with a *non*-default mapper,
will also probably be mishandled.

[Bug preprocessor/112956] Valgrind errors on pr88974.c

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Fixed.

[Bug preprocessor/112956] Valgrind errors on pr88974.c

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

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

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

https://gcc.gnu.org/g:819bc4f6700847068883eb862dfaed11f30db80b

commit r14-6513-g819bc4f6700847068883eb862dfaed11f30db80b
Author: Jakub Jelinek 
Date:   Wed Dec 13 21:13:22 2023 +0100

libcpp: Fix valgrind errors on pr88974.c [PR112956]

On the c-c++-common/cpp/pr88974.c testcase I'm seeing
==600549== Conditional jump or move depends on uninitialised value(s)
==600549==at 0x1DD3A05: cpp_get_token_1(cpp_reader*, unsigned int*)
(macro.cc:3050)
==600549==by 0x1DBFC7F: _cpp_parse_expr (expr.cc:1392)
==600549==by 0x1DB9471: do_if(cpp_reader*) (directives.cc:2087)
==600549==by 0x1DBB4D8: _cpp_handle_directive (directives.cc:572)
==600549==by 0x1DCD488: _cpp_lex_token (lex.cc:3682)
==600549==by 0x1DD3A97: cpp_get_token_1(cpp_reader*, unsigned int*)
(macro.cc:2936)
==600549==by 0x7F7EE4: scan_translation_unit (c-ppoutput.cc:350)
==600549==by 0x7F7EE4: preprocess_file(cpp_reader*) (c-ppoutput.cc:106)
==600549==by 0x7F6235: c_common_init() (c-opts.cc:1280)
==600549==by 0x704C8B: lang_dependent_init (toplev.cc:1837)
==600549==by 0x704C8B: do_compile (toplev.cc:2135)
==600549==by 0x704C8B: toplev::main(int, char**) (toplev.cc:2306)
==600549==by 0x7064BA: main (main.cc:39)
error.  The problem is that _cpp_lex_direct can leave result->src_loc
uninitialized in some cases and later on we use that location_t.

_cpp_lex_direct essentially does:
  cppchar_t c;
...
  cpp_token *result = pfile->cur_token++;

 fresh_line:
  result->flags = 0;
...
  if (buffer->need_line)
{
  if (pfile->state.in_deferred_pragma)
{
  result->type = CPP_PRAGMA_EOL;
  ... // keeps result->src_loc uninitialized;
  return result;
}
  if (!_cpp_get_fresh_line (pfile))
{
  result->type = CPP_EOF;
  if (!pfile->state.in_directive && !pfile->state.parsing_args)
{
  result->src_loc = pfile->line_table->highest_line;
  ...
}
  ... // otherwise result->src_loc is sometimes uninitialized here
  return result;
}
  ...
}
...
  result->src_loc = pfile->line_table->highest_line;
...
  c = *buffer->cur++;
  switch (c)
{
...
case '\n':
...
  buffer->need_line = true;
  if (pfile->state.in_deferred_pragma)
{
  result->type = CPP_PRAGMA_EOL;
...
  return result;
}
  goto fresh_line;
...
}
...
So, if _cpp_lex_direct is called without buffer->need_line initially set,
result->src_loc is always initialized (and actually hundreds of tests rely
on that exact value it has), even when c == '\n' and we set that flag later
on and goto fresh_line.  For CPP_PRAGMA_EOL case we have in that case
separate handling and don't goto.
But if _cpp_lex_direct is called with buffer->need_line initially set and
either decide to return a CPP_PRAGMA_EOL token or if getting a new line
fails
for some reason and we return an CPP_ERROR token and we are in directive
or parsing args state, it is kept uninitialized and can be whatever the
allocation left it there as.

The following patch attempts to keep the status quo, use value that was
returned previously if it was initialized (i.e. we went through the
goto fresh_line; statement in c == '\n' handling) and only initialize
result->src_loc if it was uninitialized before.

2023-12-13  Jakub Jelinek  

PR preprocessor/112956
* lex.cc (_cpp_lex_direct): Initialize c to 0.
For CPP_PRAGMA_EOL tokens and if c == 0 also for CPP_EOF
set result->src_loc to highest locus.

[Bug debug/96997] [10/11 Regression] step over in gdb always stops in basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())

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

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

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

https://gcc.gnu.org/g:063564ecbfc618cd019f86216a0224e144effae1

commit r14-6511-g063564ecbfc618cd019f86216a0224e144effae1
Author: Jason Merrill 
Date:   Wed Dec 13 14:15:44 2023 -0500

c++: TARGET_EXPR location in default arg [PR96997]

My r14-6505-g52b4b7d7f5c7c0 change to copy the location in
build_aggr_init_expr reopened PR96997; let's fix it properly this time, by
clearing the location like we do for other trees.

PR c++/96997

gcc/cp/ChangeLog:

* tree.cc (bot_manip): Check data.clear_location for TARGET_EXPR.

gcc/testsuite/ChangeLog:

* g++.dg/debug/cleanup2.C: New test.

[Bug rtl-optimization/113003] ICE: in expand_mult, at expmed.cc:3603 at -O with __builtin_mul_overflow_p() and _BitInt()

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

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #2 from Zdenek Sojka  ---
(In reply to Andrew Pinski from comment #1)
> Confirmed.
> 
> Slightly more reduced:
> ```
> _BitInt (2049) b2049;
> unsigned _BitInt (6384) b16384;
> 
> void
> foo (signed char t)
> {
>   b2049 = b16384 * t;
> }
> 
> ```

Thank you for the further reduction.
In the original testcase, foo() and bar() trigger different ICE ( :2126 and
:2134 )

[Bug rtl-optimization/113003] New: ICE: in expand_mult, at expmed.cc:3603 at -O with __builtin_mul_overflow_p() and _BitInt()

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 113003
   Summary: ICE: in expand_mult, at expmed.cc:3603 at -O with
__builtin_mul_overflow_p() and _BitInt()
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O testcase.c 
during RTL pass: expand
testcase.c: In function 'foo':
testcase.c:6:7: internal compiler error: in expand_mult, at expmed.cc:3603
6 |   b = __builtin_mul_overflow_p(a, (_BitInt(383))3545869000730815518 <<
64 << 4, 0);
  |   ^~~~
0x7573f8 expand_mult(machine_mode, rtx_def*, rtx_def*, rtx_def*, int, bool)
/repo/gcc-trunk/gcc/expmed.cc:3603
0x11e7a3c expand_arith_overflow
/repo/gcc-trunk/gcc/internal-fn.cc:2722
0xf74a6f expand_call_stmt
/repo/gcc-trunk/gcc/cfgexpand.cc:2744
0xf74a6f expand_gimple_stmt_1
/repo/gcc-trunk/gcc/cfgexpand.cc:3900
0xf74a6f expand_gimple_stmt
/repo/gcc-trunk/gcc/cfgexpand.cc:4064
0xf7b04e expand_gimple_basic_block
/repo/gcc-trunk/gcc/cfgexpand.cc:6120
0xf7cd27 execute
/repo/gcc-trunk/gcc/cfgexpand.cc:6855
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.

This is with g373a85a82650d9938adb02a14686049cbcbe6892 ;
g348874f0baac0f22c98ab11abbfa65fd172f6bdd breaks the build for me (as can be
also seen on gcc-regression)

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

[mjires at suse dot cz via Gcc-bugs]

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

Bug ID: 113002
   Summary: ICE in commit_one_edge_insertion, at cfgrtl.cc:2095
with new -finline-stringops
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mjires at suse dot cz
CC: aoliva at gcc dot gnu.org
  Target Milestone: ---

Compiling reduced testcase gcc.dg/pr76783.c results in ICE with new
-finline-stringops since its addition r14-5946-g1ff6d9f7428b06.
Happens with riscv64-linux-gnu-gcc and ppc64le-linux-gnu-gcc.


$ cat pr76783.c
typedef __int128 v64u128 __attribute__((vector_size(64)));
int c;
v64u128 u;
void foo() {
  if (c)
u = (v64u128){0};
  else
u = (v64u128){1};
}


$ riscv64-linux-gnu-gcc pr76783.c -finline-stringops -Os
during RTL pass: expand
pr76783.c: In function ‘foo’:
pr76783.c:9:1: internal compiler error: in commit_one_edge_insertion, at
cfgrtl.cc:2095
9 | }
  | ^
0x1286438 commit_one_edge_insertion(edge_def*)
/home/mjires/git/GCC/master/gcc/cfgrtl.cc:2095
0x12864bf commit_edge_insertions()
/home/mjires/git/GCC/master/gcc/cfgrtl.cc:2127
0x126337c execute
/home/mjires/git/GCC/master/gcc/cfgexpand.cc:6926
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.


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

[Bug target/113001] New: [14 Regression] RISCV Zicond ICE: in extract_insn, at recog.cc:2812 with -O2 rv64gcv_zicond

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 113001
   Summary: [14 Regression] RISCV Zicond ICE: in extract_insn, at
recog.cc:2812 with -O2 rv64gcv_zicond
   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 56872
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56872&action=edit
-freport-bug output

> /scratch/tc-testing/tc-dec-13-trunk/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc
>  -march=rv64gc_zicond -mabi=lp64d -O2 red.c -freport-bug
red.c: In function 'g':
red.c:11:1: error: unrecognizable insn:
   11 | }
  | ^
(insn 14 13 15 4 (set (reg:DI 145)
(if_then_else:DI (ne:DI (reg:DI 138 [ _7 ])
(const_int 0 [0]))
(reg:DI 138 [ _7 ])
(reg:DI 146))) -1
 (nil))
during RTL pass: vregs
red.c:11:1: internal compiler error: in extract_insn, at recog.cc:2812
0xa2a515 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../../gcc/gcc/rtl-error.cc:108
0xa2a537 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../../gcc/gcc/rtl-error.cc:116
0xa28e0b extract_insn(rtx_insn*)
../../../gcc/gcc/recog.cc:2812
0xedee3e instantiate_virtual_regs_in_insn
../../../gcc/gcc/function.cc:1611
0xedee3e instantiate_virtual_regs
../../../gcc/gcc/function.cc:1994
0xedee3e execute
../../../gcc/gcc/function.cc:2041
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/ccw1t5xI.out file, please attach
this to your bugreport.

Testcase:
long a, b;
int c, d;
void e(long *f) {
  (b = *f) && --b;
  for (; c;)
;
}
void g() {
  for (; d; d--)
e(&a);
}

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

-freport bug output is attached.

pr112871 looks related but is on rv32gc_zicond.

[Bug fortran/112873] F2023 degree trig functions

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #17 from Steve Kargl  ---
On Wed, Dec 13, 2023 at 05:36:55PM +, jvdelisle at gcc dot gnu.org wrote:
> 
> Do we need any other test cases?
> 

I think that we need not added any testcases.  The degree
trig function have been available for awhile now.  The 
patch simply changes the visibility to be F2023 instead
of a DEC Fortran extension.

[Bug target/112986] s390x gcc O2, O3: Incorrect logic operation in < comparison with the same values

[iii at linux dot ibm.com via Gcc-bugs]

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

--- Comment #4 from Ilya Leoshkevich  ---
Hi,

Nina fixed this in v8.0.0
(https://gitlab.com/qemu-project/qemu/-/commit/54fce97cfcaf5463ee5f325bc1f1d4adc2772f38).
The fix was backported to v7.2.2
(https://gitlab.com/qemu-project/qemu/-/commit/17b032c6598ea756889f25e8d3e4cd9f2036669b),
but not to v6.

[Bug tree-optimization/112994] [12/13/14 Regression] Missed optimization for redundancy computation elimination because pattern is broken

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Patch to add the other simplification.

[Bug target/112996] Improperly evaluated value of the s390x conditional expression

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

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

Andreas Krebbel  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||iii at linux dot ibm.com
 Resolution|--- |DUPLICATE

--- Comment #2 from Andreas Krebbel  ---
Same as with PR112986. Confirmed with qemu. Runs fine on real hardware.

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

[Bug target/112986] s390x gcc O2, O3: Incorrect logic operation in < comparison with the same values

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

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

--- Comment #3 from Andreas Krebbel  ---
*** Bug 112996 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/112994] [12/13/14 Regression] Missed optimization for redundancy computation elimination because pattern is broken

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #56868|0   |1
is obsolete||

--- Comment #6 from Jakub Jelinek  ---
Created attachment 56870
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56870&action=edit
gcc14-pr112994-1.patch

Small tweaks to the above patch.

[Bug debug/113000] New: Generate BTF always in early-finish regardless of CO-RE

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

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

Bug ID: 113000
   Summary: Generate BTF always in early-finish regardless of
CO-RE
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jemarch at gcc dot gnu.org
  Target Milestone: ---

The BPF CO-RE support requires storing information relevant to the BTF debug
info in the .BTF.ext section.  In particular:

 * The CO-RE relocation strings contain references to BTF types, by type ID.
 * The CO-RE information includes strings that are stored in the BTF string
section.

Because of the above, we are generating BTF (call to ctf_debug_finish) in
dwarf2out's early_finish if no -mco-re is specified, but the call is done in
dwarf2out's finish instead if -mco-re is specified.  This implies that there
are differences in the output (also in CTF) because for example entries for
inlined functions are no longer present at 'finish' time but they are at
'early_finish' time.

We should change GCC so it always calls ctf_debug_finish in early_finish,
regardless of whether CO-RE relocs are being generated or not.

[Bug target/112986] s390x gcc O2, O3: Incorrect logic operation in < comparison with the same values

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

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

Andreas Krebbel  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-12-13
 CC||iii at linux dot ibm.com

--- Comment #2 from Andreas Krebbel  ---
I can confirm the failure when running the binaries with qemu.

However, the binaries run as expected on real hardware. So it might rather be a
qemu issue.

@Ilya:Ubuntu 22.04 is using qemu 6.2.0. Is this perhaps something you have
fixed already?

[Bug c/112488] [14 Regression] ICE in make_ssa_name_fn with VLA inside type and inlining since r14-1142

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #12 from uecker at gcc dot gnu.org ---
Fixed on trunk.

[Bug modula2/112921] module shortreal is missing

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #4 from Gaius Mulley  ---
Closing now that the patch has been applied.

[Bug fortran/112873] F2023 degree trig functions

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

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

--- Comment #16 from Jerry DeLisle  ---
(In reply to Steve Kargl from comment #15)
--- snip ---
> 
> Jerry, are you starting with the patch submitted by Harald that
> fixes the doc issue.  It seems 'gmake pdf', which is what I use
> to check doc changes, works while 'gmake info' fails.  I assume
> that this is how Harald found the issue.
> 
> Thanks for taking up the commit.

Yes, I will start with Harald's patch and will plan to test make pdf and make
info.

Do we need any other test cases?

[Bug modula2/112921] module shortreal is missing

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Gaius Mulley :

https://gcc.gnu.org/g:33a3f85ee4b5bc562a84c6896294278e0a5ab160

commit r14-6509-g33a3f85ee4b5bc562a84c6896294278e0a5ab160
Author: Gaius Mulley 
Date:   Wed Dec 13 17:35:02 2023 +

PR modula2/112921 missing modules shortreal shortstr shortconv
convstringshort

For completeness here are three SHORTREAL modules which match their
LONGREAL and REAL counterparts.  The datatype SHORTREAL is a GNU
extension and these modules were missing.

gcc/m2/ChangeLog:

PR modula2/112921
* gm2-libs-iso/ConvStringShort.def: New file.
* gm2-libs-iso/ConvStringShort.mod: New file.
* gm2-libs-iso/ShortConv.def: New file.
* gm2-libs-iso/ShortConv.mod: New file.
* gm2-libs-iso/ShortMath.def: New file.
* gm2-libs-iso/ShortMath.mod: New file.
* gm2-libs-iso/ShortStr.def: New file.
* gm2-libs-iso/ShortStr.mod: New file.

libgm2/ChangeLog:

PR modula2/112921
* libm2iso/Makefile.am (M2DEFS): Add ConvStringShort.def,
ShortConv.def, ShortMath.def and ShortStr.def.
(M2MODS): Add ConvStringShort.mod,
ShortConv.mod, ShortMath.mod and ShortStr.mod.
* libm2iso/Makefile.in: Regenerate.

gcc/testsuite/ChangeLog:

PR modula2/112921
* gm2/iso/run/pass/shorttest.mod: New test.

Signed-off-by: Gaius Mulley 

[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5

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

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

--- Comment #9 from Arsen Arsenović  ---
removing EXTRA_HOST_FLAGS from the gettext targets fixed the build on my
cfarm112.

overall, I'm not sure overriding what subconfigures discover and adjust CC and
CFLAGS with is a good idea.  it seems sensible to allow subpackages to have
that disabled (or to require packages to enable that functionality, but that
change would be more intrusive)

[Bug modula2/112921] module shortreal is missing

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

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

--- Comment #2 from Gaius Mulley  ---
Created attachment 56869
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56869&action=edit
Proposed fix containing missing shortreal modules

For completeness here are three SHORTREAL modules which match their
LONGREAL and REAL counterparts.  The datatype SHORTREAL is a GNU
extension and these modules were missing.

[Bug tree-optimization/110640] [13/14 Regression] Wrong code at -O2/3 on x86_64-linux-gnu since GCC-13

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
This doesn't reproduce on the trunk since
r14-4790-g9692309ed6b625f0fb358c0e230404b5603f69a6 anymore.  Was that a fix for
this or just made it latent?

[Bug middle-end/111260] [14 Regression] arm/aarch64: ice in maybe_legitimize_operand with ?: and constants and different types since r14-2667-gceae1400cf24f329393e96dd9720

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-Decembe
   ||r/640520.html
   Keywords||patch

--- Comment #11 from Andrew Pinski  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640520.html

[Bug c++/108243] [11/12 Regression] Missed optimization for static const std::string_view(const char*)

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

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

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

https://gcc.gnu.org/g:958940eb3511e341e57606f5a2f5399bc89533cb

commit r14-6506-g958940eb3511e341e57606f5a2f5399bc89533cb
Author: Jason Merrill 
Date:   Tue Dec 12 22:53:10 2023 -0500

c++: constant direct-initialization [PR108243]

When testing the proposed patch for PR71093 I noticed that it changed the
diagnostic for consteval-prop6.C.  I then noticed that the diagnostic
wasn't
very helpful either way; it was complaining about modification of the 'x'
variable, but it's not a problem to initialize a local variable with a
consteval constructor as long as the value is actually constant, we want to
know why the value isn't constant.  And then it turned out that this also
fixed a missed-optimization bug in the testsuite.

PR c++/108243

gcc/cp/ChangeLog:

* constexpr.cc (cxx_eval_outermost_constant_expr): Turn
a constructor CALL_EXPR into a TARGET_EXPR.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/consteval-prop6.C: Adjust diagnostic.
* g++.dg/opt/is_constant_evaluated3.C: Remove xfails.

[Bug c++/71093] use of pseudo-destructor accepted in constant expression

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

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

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

https://gcc.gnu.org/g:90bc2d09b5bfcc913f79543c3b65202e7246e162

commit r14-6508-g90bc2d09b5bfcc913f79543c3b65202e7246e162
Author: Nathaniel Shead 
Date:   Fri Nov 3 12:18:29 2023 +1100

c++: End lifetime of objects in constexpr after destructor call [PR71093]

This patch adds checks for using objects after they've been manually
destroyed via explicit destructor call. Currently this is only
implemented for 'top-level' objects; FIELD_DECLs and individual elements
of arrays will need a lot more work to track correctly and are left for
a future patch.

The other limitation is that destruction of parameter objects is checked
too 'early', happening at the end of the function call rather than the
end of the owning full-expression as they should be for consistency;
see cpp2a/constexpr-lifetime2.C. This is because I wasn't able to find a
good way to link the constructed parameter declarations with the
variable declarations that are actually destroyed later on to propagate
their lifetime status, so I'm leaving this for a later patch.

PR c++/71093

gcc/cp/ChangeLog:

* constexpr.cc (constexpr_global_ctx::get_value_ptr): Don't
return NULL_TREE for objects we're initializing.
(constexpr_global_ctx::destroy_value): Rename from remove_value.
Only mark real variables as outside lifetime.
(constexpr_global_ctx::clear_value): New function.
(destroy_value_checked): New function.
(cxx_eval_call_expression): Defer complaining about non-constant
arg0 for operator delete. Use remove_value_safe.
(cxx_fold_indirect_ref_1): Handle conversion to 'as base' type.
(outside_lifetime_error): Include name of object we're
accessing.
(cxx_eval_store_expression): Handle clobbers. Improve error
messages.
(cxx_eval_constant_expression): Use remove_value_safe. Clear
bind variables before entering body.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/constexpr-lifetime1.C: Improve error message.
* g++.dg/cpp1y/constexpr-lifetime2.C: Likewise.
* g++.dg/cpp1y/constexpr-lifetime3.C: Likewise.
* g++.dg/cpp1y/constexpr-lifetime4.C: Likewise.
* g++.dg/cpp2a/bitfield2.C: Likewise.
* g++.dg/cpp2a/constexpr-new3.C: Likewise. New check.
* g++.dg/cpp1y/constexpr-lifetime7.C: New test.
* g++.dg/cpp2a/constexpr-lifetime1.C: New test.
* g++.dg/cpp2a/constexpr-lifetime2.C: New test.

Signed-off-by: Nathaniel Shead 

[Bug target/112929] [14] RISC-V vector: Variable clobbered at runtime

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

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

--- Comment #23 from Patrick O'Neill  ---
Confirmed to be fixed on tip-of-tree. Thank you!

[Bug target/112988] [14] RISC-V vector: Variadic function call causes runtime failure

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

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

--- Comment #3 from Patrick O'Neill  ---
Confirmed to be fixed - thank you!

[Bug tree-optimization/112994] [12/13/14 Regression] Missed optimization for redundancy computation elimination because pattern is broken

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

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 56868
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56868&action=edit
gcc14-pr112994-1.patch

Untested patch which adds the first above mentioned pattern.

[Bug tree-optimization/112468] [14 Regression] Missed phi-opt after recent change (phi-opt-24.c)

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

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

--- Comment #10 from Tamar Christina  ---
Hi,

It's not forgotten. I've agreed on a fix with the maintainers that should solve
a bunch of other (older) issues with copysign as well.

Since it's a bug fix it's on my list after my stage3 changes.  But I expect to
be able to send the patch next week.

Sorry for the delay.

[Bug tree-optimization/112468] [14 Regression] Missed phi-opt after recent change (phi-opt-24.c)

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

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

--- Comment #9 from Hans-Peter Nilsson  ---
(In reply to Tamar Christina from comment #7)
> testing patch

A month later: any update on that?
I didn't see a patch posted, so perhaps there was more work to it.
Please leave a note if you're no longer working on it and/or not expecting
progress within, say, another month.

[Bug tree-optimization/112994] [12/13/14 Regression] Missed optimization for redundancy computation elimination because pattern is broken

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

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

--- Comment #4 from Jakub Jelinek  ---
So, don't we want next to the /* Simplify (t * 2) / 2) -> t.  */ pattern (dunno
why it uses there in the comment 2 when it is actually generic (a * b) / a ->
b, doesn't rely on constants) also one (a * b) / c -> a * (b / c) for
INTEGER_CST b and c where wi::multiple_of_p (wi::to_widest (b), wi::to_widest
(c), SIGNED) and b / c folds into a constant?
int f1 (int x) { return (x * 4) / 2;  }
int f2 (int x) { return (x * 56) / 8;  }
int f3 (int x) { return (x * 56) / -8;  }
int f4 (int x) { int y = x * 4; return y / 2;  }
int f5 (int x) { int y = x * 56; return y / 8;  }
int f6 (int x) { int y = x * 56; return y / -8;  }
In the above f1, f2 and f3 are folded in fold_binary_loc
  strict_overflow_p = false;
  if (TREE_CODE (arg1) == INTEGER_CST
  && (tem = extract_muldiv (op0, arg1, code, NULL_TREE,
&strict_overflow_p)) != 0)
{
  if (strict_overflow_p)
fold_overflow_warning (("assuming signed overflow does not occur "
"when simplifying division"),
   WARN_STRICT_OVERFLOW_MISC);
  return fold_convert_loc (loc, type, tem);
}
but not at GIMPLE.  Or do we want to somehow reimplement even bigger part of
extract_muldiv_1 in match.pd?  It can handle even (x * 16 + y * 32) / 8
-> x * 2 + y * 4 etc.
And then there is the case from this PR,
int f7 (int x) { return (x * 4) / (x * 2); }
int f8 (int x) { return (x * 56) / (x * 8); }
int f9 (int x) { return (x * 56) / (x * -8); }
int f10 (int x) { int y = x * 4; return y / (x * 2); }
int f11 (int x) { int y = x * 56; return y / (x * 8); }
int f12 (int x) { int y = x * 56; return y / (x * -8); }
which isn't optimized in GENERIC nor in GIMPLE.

[Bug c++/112318] Deprecated move ctor does not trigger -Wdeprecated-declarations when creating a std::optional

[herring at lanl dot gov via Gcc-bugs]

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

S. Davis Herring  changed:

   What|Removed |Added

 CC||herring at lanl dot gov

--- Comment #4 from S. Davis Herring  ---
The issue is really broader than just "declaration or use is not in -isystem";
since it's standard practice to use -isystem for third-party headers (to avoid
"personal" warnings like -Wparentheses taking effect in code not written to
them), this still fails to issue a warning if `foo` comes from such a header. 
(But the warning works when foo's author checks for it in their own unit
tests...)

It's a very hard problem in general.  A colleague pointed me at Perl's carp,
which attempts to identify whose "fault" a diagnostic is
.  The package rule there could even
be applied to C++20 modules, or perhaps to top-level namespaces in a pinch. 
Beyond that, it might be worthwhile to presume that any warning triggered by a
type- or value-dependent expression should be associated (for -Wsystem-headers
purposes) with the point of instantiation, although I'm sure there would be
some false positives from that.  (There needs to be a better-than-#pragma way
to suppress individual deprecation warnings for such cases.)

[Bug tree-optimization/112994] [12/13/14 Regression] Missed optimization for redundancy computation elimination because pattern is broken

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Started with r12-476-gd846f225c25c5885250c303c8d118caa08c447ab

[Bug tree-optimization/112822] [14 regression] ICE: invalid RHS for gimple memory store after r14-5831-gaae723d360ca26

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

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

--- Comment #13 from GCC Commits  ---
The master branch has been updated by Peter Bergner :

https://gcc.gnu.org/g:373a85a82650d9938adb02a14686049cbcbe6892

commit r14-6498-g373a85a82650d9938adb02a14686049cbcbe6892
Author: Peter Bergner 
Date:   Wed Dec 13 08:13:34 2023 -0600

testsuite: Add dg-do compile target c++17 directive for testcase [PR112822]

Add dg-do compile target directive that limits the test case to being built
on c++17 compiles or greater.

2023-12-13  Peter Bergner  

gcc/testsuite/
PR tree-optimization/112822
* g++.dg/pr112822.C: Add dg-do compile target c++17 directive.

[Bug target/112929] [14] RISC-V vector: Variable clobbered at runtime

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

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

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

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

commit r14-6497-gd702387b1b765f85e19961a0b2a29df14df89bfd
Author: Pan Li 
Date:   Wed Dec 13 21:46:14 2023 +0800

RISC-V: Refine test cases for both PR112929 and PR112988

Refine the test cases for:

* Name convention.
* Add run case.

These test cases used to cause out-of-bounds writes to the stack
and therefore showed unreliable behavior.  Depending on the
execution environment they can either pass or fail.  As of now,
with the latest QEMU version, they will pass even without the
underlying issue fixed.  As the test case is known to have
caused the problem before we keep it as a run test case for
future reference.

PR target/112929
PR target/112988

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/vsetvl/pr112929.c: Moved to...
* gcc.target/riscv/rvv/vsetvl/pr112929-1.c: ...here.
* gcc.target/riscv/rvv/vsetvl/pr112988.c: Moved to...
* gcc.target/riscv/rvv/vsetvl/pr112988-1.c: ...here.
* gcc.target/riscv/rvv/vsetvl/pr112929-2.c: New test.
* gcc.target/riscv/rvv/vsetvl/pr112988-2.c: New test.

Signed-off-by: Pan Li