[Bug c++/114683] [modules] name declared in GMF in inline namespace and exported via using-decl from parent namespace is not visible to importer

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

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

Nathaniel Shead  changed:

   What|Removed |Added

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

[Bug middle-end/115595] New: ICE: in expand_call_tm, at trans-mem.cc:2546 with attribute optimize and noipa

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

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

Bug ID: 115595
   Summary: ICE: in expand_call_tm, at trans-mem.cc:2546 with
attribute optimize and noipa
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iamanonymous.cs at gmail dot com
  Target Milestone: ---

ICE on trunk.
Compiler Explorer: https://godbolt.org/z/bevrv3Gcs

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

***
Program:
$ cat mutant.c
int a;
__attribute__((optimize(1), noipa)) void b() {
  __transaction_atomic {
if (a)
  __transaction_cancel;
  }
}

***
Command Lines:
$ gcc -fsanitize=thread -fgnu-tm mutant.c
during GIMPLE pass: tmmark
mutant.c: In function ‘b’:
mutant.c:2:42: internal compiler error: in expand_call_tm, at trans-mem.cc:2546
2 | __attribute__((optimize(1), noipa)) void b() {
  |  ^
0x1e577fa expand_call_tm
../../gcc/gcc/trans-mem.cc:2546
0x1e57fb1 expand_block_tm
../../gcc/gcc/trans-mem.cc:2651
0x1e5a18c execute_tm_mark
../../gcc/gcc/trans-mem.cc:3129
0x1e5a344 execute
../../gcc/gcc/trans-mem.cc:3176
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/115596] New: Default arguments are erroneously allowed for parameters of a requires expression

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 115596
   Summary: Default arguments are erroneously allowed for
parameters of a requires expression
   Product: gcc
   Version: 14.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

GCC accepts invalid requires expression as follows with default arguments of a
parameter:
```
template
concept C = requires(T t = {}) {
t;
};
```
Both Clang and MSVC reject it.

Online demo: https://gcc.godbolt.org/z/EMncoT8Yv

[Bug middle-end/115597] New: [15 Regression] vectorizer takes 20+ h compiling 510.parest in SPECCPU2017 since g:46bb4ce4d30ab749d40f6f4cef6f1fb7c7813452

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

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

Bug ID: 115597
   Summary: [15 Regression] vectorizer takes 20+ h compiling
510.parest in SPECCPU2017 since
g:46bb4ce4d30ab749d40f6f4cef6f1fb7c7813452
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: compile-time-hog
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64*

Created attachment 58496
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58496&action=edit
slp dump graph

Since:

commit 46bb4ce4d30ab749d40f6f4cef6f1fb7c7813452 (HEAD)
Author: Richard Biener 
Date:   Wed Jun 19 12:57:27 2024 +0200

tree-optimization/114413 - SLP CSE after permute optimization

We currently fail to re-CSE SLP nodes after optimizing permutes
which results in off cost estimates.  For gcc.dg/vect/bb-slp-32.c
this shows in not re-using the SLP node with the load and arithmetic
for both the store and the reduction.  The following implements
CSE by re-bst-mapping nodes as finalization part of vect_optimize_slp.

I've tried to make the CSE part of permute materialization but it
isn't a very good fit there.  I've not bothered to implement something
more complete, also handling external defs or defs without
SLP_TREE_SCALAR_STMTS.

I realize this might result in more BB SLP which in turn might slow
down code given costing for BB SLP is difficult (even that we now
vectorize gcc.dg/vect/bb-slp-32.c on x86_64 might be not a good idea).
This is nevertheless feeding more accurate info to costing which is
good.

PR tree-optimization/114413
* tree-vect-slp.cc (release_scalar_stmts_to_slp_tree_map):
New function, split out from ...
(vect_analyze_slp): ... here.  Call it.
(vect_cse_slp_nodes): New function.
(vect_optimize_slp): Call it.

* gcc.dg/vect/bb-slp-32.c: Expect CSE and vectorization on x86.

Compilation takes an extremely long time in 510.parest_r.

The problem seems to be that vect_cse_slp_nodes visits the same nodes twice.
It looks like the function has no visited set, and the hot loop in parest (when
vectorizable thanks to libmvec) has many TWO_OPERANDS nodes and one of them is
rooted at the top level.

vect_cse_slp_nodes seems to skip VEC_PERM_EXPR but not it's children, as such
it ends up visiting the same subgraphs multiple times. The graph in parest has
so many TWO_OPERAND nodes that essentially compilation never finishes.

I believe this function needs a visited node set.

example call graph:

#334 0x018a1e14 in vect_cse_slp_nodes (bst_map=0x41627a0,
node=@0x4132f40: 0x3df2ec0) at
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-slp.cc:6111
#335 0x018a1e14 in vect_cse_slp_nodes (bst_map=0x41627a0,
node=@0x41321a0: 0x3df2b90) at
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-slp.cc:6111
#336 0x018a1e14 in vect_cse_slp_nodes (bst_map=0x41627a0,
node=@0x4130b00: 0x3df2860) at
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-slp.cc:6111
#337 0x018a1e14 in vect_cse_slp_nodes (bst_map=0x41627a0,
node=@0x41348a0: 0x3df2530) at
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-slp.cc:6111
#338 0x018a1e14 in vect_cse_slp_nodes (bst_map=0x41627a0,
node=@0x3b8b0d0: 0x3df2310) at
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-slp.cc:6111
#339 0x018a1e14 in vect_cse_slp_nodes (bst_map=0x41627a0,
node=@0x41348f0: 0x3dee928) at
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-slp.cc:6111
#340 0x018a1e14 in vect_cse_slp_nodes (bst_map=0x41627a0,
node=@0x4134500: 0x3dee460) at
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-slp.cc:6111
#341 0x018a1e14 in vect_cse_slp_nodes (bst_map=0x41627a0,
node=@0x3c14600: 0x3ded690) at
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-slp.cc:6111
#342 0x018a1e14 in vect_cse_slp_nodes (bst_map=0x41627a0,
node=@0x3ca75f0: 0x3de7910) at
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-slp.cc:6111
#343 0x018a1e14 in vect_cse_slp_nodes (bst_map=0x41627a0,
node=@0x3e28590: 0x3de8768) at
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-slp.cc:6111
#344 0x018a1e14 in vect_cse_slp_nodes (bst_map=0x41627a0,
node=@0x3c2e4b8: 0x3de7778) at
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-slp.cc:6111
#345 0x018a1e14 in vect_cse_slp_nodes (bst_map=0x41627a0,
node=@0x3da5e58: 0x3de7dd8) at
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-slp.cc:6111
#346 0x018a1e14 in vect_cse_slp_nodes (bst_map=0x41627a0,
node=@0x41d0770: 0x3de7f70) at
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-slp.cc:6111
#347 0x018a1f20 in vect_optimize_slp (vin

[Bug middle-end/115597] [15 Regression] vectorizer takes 20+ h compiling 510.parest in SPECCPU2017 since g:46bb4ce4d30ab749d40f6f4cef6f1fb7c7813452

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2024-06-23
   Target Milestone|--- |15.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Mine.

[Bug tree-optimization/115579] [15 regression] wrong code at -Os with "-fno-tree-sra" on x86_64-linux-gnu since r15-1391-g4b75ed33fa5fd6

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

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

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

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

commit r15-1564-g8a1795bddcd34284936af4706f762d89c60fc69c
Author: Richard Biener 
Date:   Sat Jun 22 14:59:09 2024 +0200

tree-optimization/115579 - fix wrong code with store-motion

The recent change to relax store motion for variables that cannot have
store data races broke the optimization to share flag vars for stores
that all happen in the same single BB.  The following fixes this.

PR tree-optimization/115579
* tree-ssa-loop-im.cc (execute_sm): Return the auxiliary data
created.
(hoist_memory_references): Record the flag var that's eventually
created and re-use it when all stores are in the same BB.

* gcc.dg/pr115579.c: New testcase.

[Bug tree-optimization/115579] [15 regression] wrong code at -Os with "-fno-tree-sra" on x86_64-linux-gnu since r15-1391-g4b75ed33fa5fd6

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/115597] [15 Regression] vectorizer takes 20+ h compiling 510.parest in SPECCPU2017 since g:46bb4ce4d30ab749d40f6f4cef6f1fb7c7813452

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

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

--- Comment #2 from Richard Biener  ---
Ah, I feared this would happen - this case seems to be because of a lot of
VEC_PERM nodes(?) which are not handled by the CSE process as well as the
two-operator nodes which lack SLP_TREE_SCALAR_STMTS (we'd need NULL elements
there, something I need to add anyway).

The bst_map deals as "visited" map, but nodes not handled there would need
a "visited" set (but as said above, the plan is to reduce that set to zero).

I'll see to reproduce to confirm.  Usually a two-operator node shouldn't
be too bad since the next non-two-operator one will serve as 'visited' point
but in this graph we have several adjacent two-operator nodes without any
intermediate node handled by the bst-map processing code.  I can't reproduce
with -Ofast -march=znver2 though.

The easiest way to remedy the situation is probably to allow VEC_PERM_EXPR
CSE when the node has SLP_TREE_SCALAR_STMTS as two-operator nodes have.
So I _think_ the following should fix this.  I'm going to test it (on x86-64).

Can you check whether that fixes the issue?

diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
index 9465d94de1a..212d5f97f7d 100644
--- a/gcc/tree-vect-slp.cc
+++ b/gcc/tree-vect-slp.cc
@@ -6085,7 +6085,6 @@ static void
 vect_cse_slp_nodes (scalar_stmts_to_slp_tree_map_t *bst_map, slp_tree& node)
 {
   if (SLP_TREE_DEF_TYPE (node) == vect_internal_def
-  && SLP_TREE_CODE (node) != VEC_PERM_EXPR
   /* Besides some VEC_PERM_EXPR, two-operator nodes also
 lack scalar stmts and thus CSE doesn't work via bst_map.  Ideally
 we'd have sth that works for all internal and external nodes.  */

[Bug middle-end/115597] [15 Regression] vectorizer takes 20+ h compiling 510.parest in SPECCPU2017 since g:46bb4ce4d30ab749d40f6f4cef6f1fb7c7813452

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

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

--- Comment #3 from Tamar Christina  ---
> 
> Can you check whether that fixes the issue?
> 
> diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
> index 9465d94de1a..212d5f97f7d 100644
> --- a/gcc/tree-vect-slp.cc
> +++ b/gcc/tree-vect-slp.cc
> @@ -6085,7 +6085,6 @@ static void
>  vect_cse_slp_nodes (scalar_stmts_to_slp_tree_map_t *bst_map, slp_tree& node)
>  {
>if (SLP_TREE_DEF_TYPE (node) == vect_internal_def
> -  && SLP_TREE_CODE (node) != VEC_PERM_EXPR
>/* Besides some VEC_PERM_EXPR, two-operator nodes also
>  lack scalar stmts and thus CSE doesn't work via bst_map.  Ideally
>  we'd have sth that works for all internal and external nodes.  */

Yeah that seems to do it, can compile SPECFP again.

[Bug target/115591] internal error on global variable-length array

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

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org
Summary|ICE in riscv64-elf cross|internal error on global
   |compiler, handling imported |variable-length array
   |addresses   |
  Build|x86_64-apple-darwin21.6.0   |
 Status|UNCONFIRMED |NEW
  Component|ada |target
   Last reconfirmed||2024-06-23
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
It's a buglet in the RISC-V back-end:

(gdb) bt
#0  internal_error (gmsgid=0x584aa67 "in %s, at %s:%d")
at /home/eric/cvs/gcc/gcc/diagnostic.cc:2255
#1  0x04ad30a2 in fancy_abort (
file=0x4ea1be0 "/home/eric/cvs/gcc/gcc/tree.cc", line=6488, 
function=0x4ea3cc1 "tree_to_uhwi")
at /home/eric/cvs/gcc/gcc/diagnostic.cc:2380
#2  0x02469386 in tree_to_uhwi (t=0x7705aca8)
at /home/eric/cvs/gcc/gcc/tree.cc:6488
#3  0x02555b2e in riscv_valid_lo_sum_p (sym_type=SYMBOL_ABSOLUTE, 
mode=E_BLKmode, x=0x7717bb58)
at /home/eric/cvs/gcc/gcc/config/riscv/riscv.cc:1706

[Bug target/115591] internal error on global variable-length array

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

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

--- Comment #2 from Eric Botcazou  ---
The immediate fix is:

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index c17141d909a..5e34dc92210 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -1702,7 +1702,9 @@ riscv_valid_lo_sum_p (enum riscv_symbol_type sym_type,
machine_mode mode,
   align = (SYMBOL_REF_DECL (x)
   ? DECL_ALIGN (SYMBOL_REF_DECL (x))
   : 1);
-  size = (SYMBOL_REF_DECL (x) && DECL_SIZE (SYMBOL_REF_DECL (x))
+  size = (SYMBOL_REF_DECL (x)
+ && DECL_SIZE (SYMBOL_REF_DECL (x))
+ && tree_fits_uhwi_p (DECL_SIZE (SYMBOL_REF_DECL (x)))
  ? tree_to_uhwi (DECL_SIZE (SYMBOL_REF_DECL (x)))
  : 2*BITS_PER_WORD);
 }

but I cannot really test it.

[Bug middle-end/115597] [15 Regression] vectorizer takes 20+ h compiling 510.parest in SPECCPU2017 since g:46bb4ce4d30ab749d40f6f4cef6f1fb7c7813452

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

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

--- Comment #4 from Tamar Christina  ---
(In reply to Richard Biener from comment #2)
> Ah, I feared this would happen - this case seems to be because of a lot of
> VEC_PERM nodes(?) which are not handled by the CSE process as well as the
> two-operator nodes which lack SLP_TREE_SCALAR_STMTS (we'd need NULL elements
> there, something I need to add anyway).
> 
> The bst_map deals as "visited" map, but nodes not handled there would need
> a "visited" set (but as said above, the plan is to reduce that set to zero).
> 

Ah I see, that makes sense.

> I'll see to reproduce to confirm.  Usually a two-operator node shouldn't
> be too bad since the next non-two-operator one will serve as 'visited' point
> but in this graph we have several adjacent two-operator nodes without any
> intermediate node handled by the bst-map processing code.  I can't reproduce
> with -Ofast -march=znver2 though.
> 

Yeah I forgot to mention I could only reproduce it with LTO and a recent glibc.

Thanks for the fix!

[Bug c++/115598] New: ICE: in build_call_a, at cp/call.cc:370

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

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

Bug ID: 115598
   Summary: ICE: in build_call_a, at cp/call.cc:370
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iamanonymous.cs at gmail dot com
  Target Milestone: ---
Target: x86_64

***
The compiler produces an internal error during build_call_a when compiling the
provided code with the specified options. 
The issue can also be reproduced on Compiler Explorer.

***
OS and Platform:
# uname -a
Linux ubuntu 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023
x86_64 x86_64 x86_64 GNU/Linux
***
# g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/root/gdbtest/gcc/gcc-15/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /root/gdbtest/gcc/obj/../gcc/configure
--prefix=/root/gdbtest/gcc/gcc-15 --enable-languages=c,c++,fortran,go
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240509 (experimental) (GCC) 
***
Program:
# cat 2.ii

namespace std
{
  class exception
  {
virtual ~exception() throw();
  };
}
namespace std __attribute__((__visibility__("default")))
{
  template , typename
_Alloc = allocator<_CharT>>
  class basic_string;
  typedef basic_string string;
}
namespace boost
{
  class exception
  {
  };
}
namespace __cxxabiv1
{
  extern "C" void *__dynamic_cast(const void *__src_ptr, const
__class_type_info *__src_type, const __class_type_info *__dst_type, ptrdiff_t
__src2dst);
  inline std::string diagnostic_information_impl(boost::exception const *be,
std::exception const *se, bool with_what)
  {
if (!be)
  be = dynamic_cast(se);
  }
}

***
Command Lines:
# g++ 2.ii  -Werror -O2 -ftrapv -fstack-protector-strong -o -c 2.o
\2.ii:10:49: error: ‘char_traits’ does not name a type
   10 |   template ,
typename _Alloc = allocator<_CharT>>
  | ^~~
2.ii:10:60: error: expected ‘>’ before ‘<’ token
   10 |   template ,
typename _Alloc = allocator<_CharT>>
  |^
2.ii:12:28: error: template argument 2 is invalid
   12 |   typedef basic_string string;
  |^
2.ii:22:64: error: ‘__class_type_info’ does not name a type
   22 |   extern "C" void *__dynamic_cast(const void *__src_ptr, const
__class_type_info *__src_type, const __class_type_info *__dst_type, ptrdiff_t
__src2dst);
  |   
^
2.ii:22:101: error: ‘__class_type_info’ does not name a type
   22 |   extern "C" void *__dynamic_cast(const void *__src_ptr, const
__class_type_info *__src_type, const __class_type_info *__dst_type, ptrdiff_t
__src2dst);
  |
^
2.ii:22:132: error: ‘ptrdiff_t’ has not been declared
   22 |   extern "C" void *__dynamic_cast(const void *__src_ptr, const
__class_type_info *__src_type, const __class_type_info *__dst_type, ptrdiff_t
__src2dst);
  |
   ^
: error: conflicting declaration of C function ‘void*
__cxxabiv1::__dynamic_cast(const void*, const __class_type_info*, const
__class_type_info*, long int)’
2.ii:22:20: note: previous declaration ‘void* __cxxabiv1::__dynamic_cast(const
void*, const int*, const int*, int)’
   22 |   extern "C" void *__dynamic_cast(const void *__src_ptr, const
__class_type_info *__src_type, const __class_type_info *__dst_type, ptrdiff_t
__src2dst);
  |^~
2.ii: In function ‘std::string __cxxabiv1::diagnostic_information_impl(const
boost::exception*, const std::exception*, bool)’:
2.ii:26:53: internal compiler error: in build_call_a, at cp/call.cc:370
   26 |   be = dynamic_cast(se);
  | ^
0x7958c9 build_call_a(tree_node*, int, tree_node**)
/root/gdbtest/gcc/obj/../gcc/gcc/cp/call.cc:370
0xaa4a20 build_cxx_call(tree_node*, int, tree_node**, int, tree_node*)
/root/gdbtest/gcc/obj/../gcc/gcc/cp/call.cc:11083
0xcf87e6 build_dynamic_cast_1
/root/gdbtest/gcc/obj/../gcc/gcc/cp/rtti.cc:797
0xcf87e6 build_dynamic_cast(unsigned int, tree_node*, tree_node

[Bug c++/115501] [13/14/15 Regression] ICE: in build_call_a with dynamic_cast after invalid definition of __cxxabiv1::__dynamic_cast since r13-3299

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

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

--- Comment #9 from Anonymous  ---
*** Bug 115598 has been marked as a duplicate of this bug. ***

[Bug c++/115598] ICE: in build_call_a, at cp/call.cc:370

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

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

Anonymous  changed:

   What|Removed |Added

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

--- Comment #1 from Anonymous  ---
*** This bug has been marked as a duplicate of bug 115501 ***

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

[Bug c++/115599] New: ICE: qsort checking failed during GIMPLE pass: reassoc (error: qsort comparator non-negative on sorted output: 150142972)

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

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

Bug ID: 115599
   Summary: ICE: qsort checking failed during GIMPLE pass: reassoc
(error: qsort comparator non-negative on sorted
output: 150142972)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iamanonymous.cs at gmail dot com
  Target Milestone: ---
Target: x86_64

***
The compiler produces an internal error during during GIMPLE pass: reassoc
compiling the provided code with the specified options. 
The issue can also be reproduced on Compiler Explorer.

***
OS and Platform:
# uname -a
Linux ubuntu 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023
x86_64 x86_64 x86_64 GNU/Linux
***
# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/root/gdbtest/gcc/gcc-15/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /root/gdbtest/gcc/obj/../gcc/configure
--prefix=/root/gdbtest/gcc/gcc-15 --enable-languages=c,c++,fortran,go
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240509 (experimental) (GCC) 
***
Program: Please refer to the attachment. 

***

Command Lines: g++ f.cpp -O1  -std=c++2a -Wall -Wextra -pedantic
-fsanitize=undefined -c -o f.o
: In function 'void tf_4_foo()':
:213:79: warning: division by zero [-Wdiv-by-zero]
  213 | if 0 ? 0 : ((0 ? 0 : ((0 ? 0 :
(tf_4_var_6))) / 0) / 0) {
  | 
~^~~
:213:84: warning: division by zero [-Wdiv-by-zero]
  213 | if 0 ? 0 : ((0 ? 0 : ((0 ? 0 :
(tf_4_var_6))) / 0) / 0) {
  |
~~~^~~
:215:1798: warning: division by zero [-Wdiv-by-zero]
  215 |   if bool) (((0 ? 0 : ((0 ? 0 : bool) 
..
..
..
..
..
((bool) (tf_4_var_246))) : ((unsigned int) bool) (((*(tf_4_ptr_152)) ?
(tf_4_array_4 [1]) : (tf_4_var_2 ? (((tf_4_var_178) ? ((int) (tf_4_var_72))
: ((int) (tf_4_var_150 : ((int) (((bool) (tf_4_var_34)) && ((bool)
(tf_4_var_94) : ((unsigned int) ((int) (((bool) bool) bool)
(4095U)) ? ((int) (tf_4_var_72)) : (-1 ? bool) (-31)) ? ((int)
(tf_4_var_218)) : ((int) (tf_4_array_2 [2] : ((int) (((bool) (-1)) &&
((bool) (4095U))) || (((bool) bool) (tf_4_var_56)) ? ((unsigned int)
((int) (tf_4_var_148))) : (*(tf_4_ptr_8) || (((bool) (tf_4_var_148)) ||
((bool) (tf_4_array_4 [2])); }
:209:28: error: qsort comparator non-negative on sorted output:
2147418113
  209 |   void tf_4_foo () {
  |^~~~
during GIMPLE pass: reassoc
:209:28: internal compiler error: qsort checking failed
0x26cfeec internal_error(char const*, ...)
???:0
0x2715408 gcc_qsort(void*, unsigned long, unsigned long, int (*)(void const*,
void const*))
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
Compiler returned: 1
***

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

***

[Bug middle-end/115597] [15 Regression] vectorizer takes 20+ h compiling 510.parest in SPECCPU2017 since g:46bb4ce4d30ab749d40f6f4cef6f1fb7c7813452

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

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

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

https://gcc.gnu.org/g:2a345214fc332b6f0821edf394ff8802b768db1d

commit r15-1565-g2a345214fc332b6f0821edf394ff8802b768db1d
Author: Richard Biener 
Date:   Sun Jun 23 11:26:39 2024 +0200

tree-optimization/115597 - allow CSE of two-operator VEC_PERM nodes

The following makes sure to always CSE when there's SLP_TREE_SCALAR_STMTS
as otherwise a chain of two-operator node operations can result in
exponential behavior of the CSE process as likely seen when building
510.parest on aarch64.

PR tree-optimization/115597
* tree-vect-slp.cc (vect_cse_slp_nodes): Allow to CSE
VEC_PERM nodes.

[Bug middle-end/115597] [15 Regression] vectorizer takes 20+ h compiling 510.parest in SPECCPU2017 since g:46bb4ce4d30ab749d40f6f4cef6f1fb7c7813452

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c++/115599] ICE: qsort checking failed during GIMPLE pass: reassoc (error: qsort comparator non-negative on sorted output: 150142972)

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2024-06-23
   Keywords||ice-checking,
   ||missed-optimization
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
It's compare_repeat_factors

(gdb) p (*repeat_factor_vec.m_vec)[0]
$6 = (repeat_factor &) @0x5d6a7b8: {factor = , 
  rank = 2147549184, count = 1, repr = }
(gdb) p (*repeat_factor_vec.m_vec)[4]
$7 = (repeat_factor &) @0x5d6a838: {factor = , 
  rank = 1, count = 1, repr = }

where one obvious issue might be that rank is unsigned (and count is
int64).

I'm testing a fix.

Note this bug only results in less optimal code.

[Bug tree-optimization/115599] ICE: qsort checking failed during GIMPLE pass: reassoc (error: qsort comparator non-negative on sorted output: 150142972)

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-reduction
  Component|c++ |tree-optimization

--- Comment #2 from Richard Biener  ---
Testcase too big for the testsuite.

[Bug tree-optimization/115599] ICE: qsort checking failed during GIMPLE pass: reassoc (error: qsort comparator non-negative on sorted output: 150142972)

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

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

Sam James  changed:

   What|Removed |Added

 Blocks||82407
 CC||sjames at gcc dot gnu.org

--- Comment #3 from Sam James  ---
I'll throw some CPU hours at it.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82407
[Bug 82407] [meta-bug] qsort_chk fallout tracking

[Bug tree-optimization/115599] ICE: qsort checking failed during GIMPLE pass: reassoc (error: qsort comparator non-negative on sorted output: 150142972)

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

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

--- Comment #4 from Sam James  ---
Created attachment 58497
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58497&action=edit
foo.cxx.xz

Attaching original.

[Bug target/115409] avx512 intrinsics trigger -Wshift-overflow

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

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

Sam James  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Target Milestone|--- |15.0

--- Comment #6 from Sam James  ---
Fixed then.

[Bug libstdc++/38732] [4.4 Regression] Openoffice.org segfaults with runtime libs built from GCC trunk

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

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

--- Comment #21 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> 2008-08-23  Sebastian Redl 
> 
> Add (again) exception propagation support as per N2179.  Feature is
> available only when _GLIBCXX_ATOMIC_BUILTINS_4 is defined.
> 
> This is to support C++0x.

For reference this is commit:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=30a333ceeb9141e67663c6151983a12678dcc329

[Bug target/114139] ICE: RTL check: expected code 'const_int', have 'reg' in riscv_macro_fusion_pair_p, at config/riscv/riscv.cc:8438 with -O2 -fpic -mexplicit-relocs -mcpu=sifive-p450

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Jeff Law :

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

commit r15-1566-gfd536b8412d4dae42aa04739c06f99a915be6261
Author: Jeff Law 
Date:   Sun Jun 23 08:26:25 2024 -0600

[committed][RISC-V][PR target/114139] Verify we have a CONST_INT before
extracting INTVAL

Run-of-the-mill checking issue.  We had something like (plus (reg) (reg))
and
tried to extract INTVAL (XEXP (x, 1)) which of course blows up with
checking
on.

Fixed thusly.   Tested on riscv32-elf in my tester.  riscv64-elf is in
flight,
but won't finish for a while due to other tasks in flight.

PR target/114139
gcc/
* config/riscv/riscv.cc (riscv_macro_fusion_pair_p): Verify object
is a CONST_INT before looking at INTVAL.

gcc/testsuite/

* gcc.target/riscv/pr114139.c: New test.

[Bug target/114139] ICE: RTL check: expected code 'const_int', have 'reg' in riscv_macro_fusion_pair_p, at config/riscv/riscv.cc:8438 with -O2 -fpic -mexplicit-relocs -mcpu=sifive-p450

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #2 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug target/115591] internal error on global variable-length array

[simon at pushface dot org via Gcc-bugs]

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

--- Comment #3 from simon at pushface dot org ---
On 23 Jun 2024, at 11:47, ebotcazou at gcc dot gnu.org
 wrote:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115591
> 
> --- Comment #2 from Eric Botcazou  ---
> The immediate fix is:
> 
> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> index c17141d909a..5e34dc92210 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -1702,7 +1702,9 @@ riscv_valid_lo_sum_p (enum riscv_symbol_type sym_type,
> machine_mode mode,
>   align = (SYMBOL_REF_DECL (x)
>   ? DECL_ALIGN (SYMBOL_REF_DECL (x))
>   : 1);
> -  size = (SYMBOL_REF_DECL (x) && DECL_SIZE (SYMBOL_REF_DECL (x))
> +  size = (SYMBOL_REF_DECL (x)
> + && DECL_SIZE (SYMBOL_REF_DECL (x))
> + && tree_fits_uhwi_p (DECL_SIZE (SYMBOL_REF_DECL (x)))
>  ? tree_to_uhwi (DECL_SIZE (SYMBOL_REF_DECL (x)))
>  : 2*BITS_PER_WORD);
> }
> 
> but I cannot really test it.

Can I help with testing? (beyond applying the patch and checking that the error
is fixed)

[Bug rtl-optimization/951] Documentation of compiler passes and sources very out of date

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

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

--- Comment #16 from sandra at gcc dot gnu.org ---
Given that this issue was filed >20 years ago and both the passlist and
documentation have changed drastically since then, I think the
originally-reported bugs are probably irrelevant and it's fine to close this
issue.  If there are still bugs in the internals passlist docs it would be more
helpful to have specific issues for each of them (e.g., missing/incorrect docs
for a particular pass or group of passes).  Or, just propose a patch to improve
the docs.  :-)

[Bug target/109989] RISC-V: Missing sign extension with int to float conversion with 64bit soft floats

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

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

--- Comment #6 from Jeffrey A. Law  ---
floatsisf is going to be called through the libcall interface which has
different paths than normal function calls and I don't think the usual type
promotion rules apply to libcalls.The details escape me, but we've run into
similar kinds of problems with narrow arguments on libcalls for other targets.

This is almost certainly a bad interaction between the risc-v backend and the
libcall code.

[Bug target/113341] Using GCC as the bootstrap compiler breaks LLVM on 32-bit PowerPC

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

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

--- Comment #14 from Segher Boessenkool  ---
(In reply to Andrew Pinski from comment #7)
> This code gives me strict aliasing violation vibes:
> ```
> T **getAddressOfPointer(ExternalASTSource *Source) const {
> // Ensure the integer is in pointer form.
> (void)get(Source);
> return reinterpret_cast(&Ptr);
>   }
> ```

A cast to void like that gives me very strong vibes, too, but of a "does this
person know C at all" kind.

Explicit casts are exceptionally useful, but they should be the exception.
They *should* stand out as something not normal.  Redundant useless silly casts
like this make code less readable, less clear.

Function results like this are implicitly ignored anyway.  Casting it to void
so it cannot be used is just silly, and that is a nice way of saying it.

[Bug target/113341] Using GCC as the bootstrap compiler breaks LLVM on 32-bit PowerPC

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

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

--- Comment #15 from Segher Boessenkool  ---
(In reply to Jessica Clarke from comment #8)
> The clang/ subdirectory should be building itself with -fno-strict-aliasing
> on GCC already

"Should".  I guess you mean "is", as in "we already concluded we have a big fat
bug here"?

I would expect the code to be valid C (or C++).  So that option should never be
needed.  This command line flag means "my code violates many of the principles
of C, but try to compile it anyway, even although I have no clue what I am
doing
there, and you cannot know what I meant either, obviously".

[Bug c++/115596] Default arguments are erroneously allowed for parameters of a requires expression

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-06-23

--- Comment #1 from Andrew Pinski  ---
Confirmed. EDG also rejects it:
"", line 3: error: default argument is not allowed
  concept C = requires(T t = {}) {
   ^

So GCC is definitely the odd one out here.

[Bug c++/115600] New: UndefinedBehaviorSanitizer doesn't seem to like modules

[cjdb.ns at gmail dot com via Gcc-bugs]

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

Bug ID: 115600
   Summary: UndefinedBehaviorSanitizer doesn't seem to like
modules
   Product: gcc
   Version: 14.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cjdb.ns at gmail dot com
  Target Milestone: ---

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

## GCC info

```
$ gcc --version
gcc (GCC) 14.1.1 20240522
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
```

## System type

```
$ lsb_release -a
LSB Version:n/a
Distributor ID: Arch
Description:Arch Linux
Release:rolling
Codename:   n/a
```

## How GCC was configured/built

Arch default

## Command line

Original invocation

```
/usr/bin/g++   -fdiagnostics-color=always -fstack-protector-strong
-fvisibility=hidden -Werror -pedantic -Wall -Wattributes -Wcast-align
-Wconversion -Wdouble-promotion -Wextra -Wformat=2 -Wnon-virtual-dtor
-Wnull-dereference -Wodr -Wold-style-cast -Woverloaded-virtual -Wshadow
-Wsign-conversion -Wsign-promo -Wunused -Wno-ignored-attributes
-Wno-cxx-attribute-extension -Wno-gnu-include-next -Wno-private-header
-Wno-unused-command-line-argument -D_GLIBCXX_ASSERTIONS
-fsanitize=address,undefined -g -std=gnu++23 -MD -MT
source/module_interface/CMakeFiles/greeter_module.dir/greeter_module.cpp.o -MF
source/module_interface/CMakeFiles/greeter_module.dir/greeter_module.cpp.o.d
-fmodules-ts
-fmodule-mapper=source/module_interface/CMakeFiles/greeter_module.dir/greeter_module.cpp.o.modmap
-MD -fdeps-format=p1689r5 -x c++ -o
source/module_interface/CMakeFiles/greeter_module.dir/greeter_module.cpp.o -c
~/projects/project-template-3/build/test/default-options/Output/gnu-toolchain.test.tmp/gnu_toolchain/source/module_interface/greeter_module.cpp
```

With some experimenting, I was able to minimise it to this. Note that the
culprit is `-fsanitize=undefined`: it'll work fine without that (and with
`-fsanitize=address`).

```
/usr/bin/g++ -fsanitize=undefined -std=gnu++23 -fmodules-ts
-fmodule-mapper=source/module_interface/CMakeFiles/greeter_module.dir/greeter_module.cpp.o.modmap
-MD -fdeps-format=p1689r5 -x c++ ~/projects/pr
oject-template-3/build/test/default-options/Output/gnu-toolchain.test.tmp/gnu_toolchain/source/module_interface/greeter_module.cpp
```

## Diagnostic

```
internal compiler error: in tree_node, at cp/module.cc:9428
4 | export module greeter;
  |^~
0x217b27a internal_error(char const*, ...)
???:0
0x703e87 fancy_abort(char const*, int, char const*)
???:0
0x8237da depset::hash::find_dependencies(module_state*)
???:0
0x829996 module_state::write_begin(elf_out*, cpp_reader*, module_state_config&,
unsigned int&)
???:0
0x839c57 finish_module_processing(cpp_reader*)
???:0
0x7ccdfd c_parse_final_cleanups()
???:0
0x9c4fb2 c_common_parse_file()
???:0
```

[Bug c++/99511] default arguments are allowed for parameters of a requires expression

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||fchelnokov at gmail dot com

--- Comment #2 from Patrick Palka  ---
*** Bug 115596 has been marked as a duplicate of this bug. ***

[Bug c++/115596] Default arguments are erroneously allowed for parameters of a requires expression

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Patrick Palka  ---
dup

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

[Bug c++/67491] [meta-bug] concepts issues

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

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

Bug 115596 Summary: Default arguments are erroneously allowed for parameters of 
a requires expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115596

   What|Removed |Added

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

[Bug c++/110137] implement clang -fassume-sane-operator-new

[user202729 at protonmail dot com via Gcc-bugs]

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

--- Comment #16 from user202729  ---
Hi,

I tried to implement patches that fix the two issues mentioned. Comments would
be appreciated.

1. The operator new flag with many of the mentioned issues fixed:
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654145.html

   Although I'm not entirely sure what to do with the link-time optimization
part.

2. The optimization to move the definition to right before the use:
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654700.html .

   As explained, I'm not sure if implementing it in the RTL phase;
nevertheless, reviews and suggestions to improve the code, or explain how to
implement it in GIMPLE phase would be appreciated.

--

Regarding the example code in the previous comment, it appears that the current
analyzer is smart enough to do the optimization when the call to operator new
is replaced by a pure function (curiously enough, it does not need to assume
the returned value does not alias because both the values are 0). So, yes it
should be possible (although I haven't test it with the proposed patch).

[Bug c++/115600] UndefinedBehaviorSanitizer doesn't seem to like modules

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-06-23
 Ever confirmed|0   |1

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

[Bug c++/115600] UndefinedBehaviorSanitizer doesn't seem to like modules

[cjdb.ns at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Christopher Di Bella  ---
I forgot that `gcc -v` can provide config options.

```
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/14.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=ada,c,c++,d,fortran,go,lto,m2,objc,obj-c++,rust
--enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/issues
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.1.1 20240522 (GCC)
```

[Bug c++/115601] New: ICE when compiling a function marked noipa/noinline called in a contract predicate

[ville.voutilainen at gmail dot com via Gcc-bugs]

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

Bug ID: 115601
   Summary: ICE when compiling a function marked noipa/noinline
called in a contract predicate
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ville.voutilainen at gmail dot com
  Target Milestone: ---

[Bug c++/115601] ICE when compiling a function marked noipa/noinline called in a contract predicate

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug c++/115601] ICE when compiling a function marked noipa/noinline called in a contract predicate

[ville.voutilainen at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Ville Voutilainen  ---
Created attachment 58499
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58499&action=edit
Preprocessed source

[Bug debug/108917] ICE when specifying optimization level and debuging for C++ contracts code

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||ville.voutilainen at gmail dot 
com

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

[Bug c++/98735] ICE with -std=c++20 -fmodules-ts -fsanitize=undefined

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||cjdb.ns at gmail dot com

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

[Bug c++/115600] UndefinedBehaviorSanitizer doesn't seem to like modules

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Dup.

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

[Bug c++/103524] [meta-bug] modules issue

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

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

Bug 115600 Summary: UndefinedBehaviorSanitizer doesn't seem to like modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115600

   What|Removed |Added

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

[Bug target/115485] CASEServer.cpp:203:1: internal compiler error: in require_pic_register, at config/arm/arm.c:7855

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

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

--- Comment #13 from Andrew Pinski  ---
Can reproduce on the trunk too:
```
[apinski@xeond2 gcc]$ ./cc1plus CASEServer.ii -quiet  -fPIE -msingle-pic-base
-mpic-register=r9 -fomit-frame-pointer -mno-pic-data-is-text-relative -mthumb
-mlong-calls -mcpu=cortex-m33+nodsp -mfpu=fpv5-sp-d16 -mfloat-abi=hard -mcmse
-Os -g -fno-use-cxa-atexit -fno-builtin-printf -fno-builtin-sprintf
-fno-builtin-snprintf -fno-common -ffunction-sections -fdata-sections
-fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables
CASEServer.cpp: In member function ‘virtual CHIP_ERROR
chip::CASEServer::_ZThn4_N4chip10CASEServer28OnUnsolicitedMessageReceivedERKNS_13PayloadHeaderERPNS_9Messaging16ExchangeDelegateE(const
chip::PayloadHeader&, chip::Messaging::ExchangeDelegate*&)’:
CASEServer.cpp:203:1: internal compiler error: in require_pic_register, at
config/arm/arm.cc:8103
  203 | } // namespace chip
  | ^
0x1ef29a4 require_pic_register
../../gcc/config/arm/arm.cc:8103
0x1ef304f legitimize_pic_address(rtx_def*, machine_mode, rtx_def*, rtx_def*,
bool)
../../gcc/config/arm/arm.cc:8232
0x289d5ba gen_movsi(rtx_def*, rtx_def*)
../../gcc/config/arm/arm.md:6532
0x12ced5e rtx_insn* insn_gen_fn::operator()(rtx_def*,
rtx_def*) const
../../gcc/recog.h:441
0x1490ab7 emit_move_insn_1(rtx_def*, rtx_def*)
../../gcc/expr.cc:4556
0x149155e emit_move_insn(rtx_def*, rtx_def*)
../../gcc/expr.cc:4726
0x1f30a44 arm32_output_mi_thunk
../../gcc/config/arm/arm.cc:29405
0x1f30bf1 arm_output_mi_thunk
../../gcc/config/arm/arm.cc:29443
0x1347dd8 expand_thunk(cgraph_node*, bool, bool)
../../gcc/symtab-thunks.cc:388
0x1363ddb cgraph_node::assemble_thunks_and_aliases()
../../gcc/cgraphunit.cc:1767
0x1363ec4 cgraph_node::assemble_thunks_and_aliases()
../../gcc/cgraphunit.cc:1789
0x1364518 cgraph_node::expand()
../../gcc/cgraphunit.cc:1918
0x1364922 expand_all_functions
../../gcc/cgraphunit.cc:2028
0x1365573 symbol_table::compile()
../../gcc/cgraphunit.cc:2404
0x13659fd symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.cc:2589
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.

```

Reducing ...

[Bug tree-optimization/88814] transform snprintf into memccpy

[crrodriguez at opensuse dot org via Gcc-bugs]

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

--- Comment #4 from Cristian Rodríguez  ---
Any hope to revive this now that memccpy is on the C23 standard?

[Bug target/114846] powerpc: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return

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

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

--- Comment #12 from Segher Boessenkool  ---
The backports have not been done yet.

It would be good if the blockage / barrier would get some comment btw, saying
what exactly it is intended to do!  It is very much cargo-cult the way it is.

[Bug c++/96853] Explicit template instantiation & thread_local interaction

[nsoft.sagaonline at gmail dot com via Gcc-bugs]

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

NIKEA-SOFT  changed:

   What|Removed |Added

 CC||nsoft.sagaonline at gmail dot 
com

--- Comment #1 from NIKEA-SOFT  ---
I confirm the presence of this problem since version GCC 5.3.
I came across it just recently when I was working with my library.
The situation is as follows: starting from version 5.3, TLS init is not called
in template global variables marked as thread_local.
Here is the MRE, pay attention to lines 31 and 33, we see the absence of the
TLS Init call since version 5.3 of GCC.
https://godbolt.org/z/a5orhhTjT

Need a vacation? Let me write for you to save you time

[Sheila Olson via Gcc-bugs]

Hello!


I believe that now is a fantastic moment to publish an article on how to
boost confidence so that individuals can accomplish their goals and live
their best lives.


Does this strike you as a suitable topic for your website? If that’s the
case, I can get started on the article right away. Just let me know if
you’re interested in seeing a draft that I can put together quickly for you
to review.


Have a wonderful day!

Sheila Olson

*https://fitsheila.com/* 



P.S. I appreciate your time, and by the way, if you prefer not to hear from
me going forward, just reply and let me know. If you’re interested,
however, let me know of any writing specifications that you may have. And
if you don’t like the suggested topic, do reach out to me with a topic that
works better for your website.

[Bug debug/108917] ICE when specifying optimization level and debuging for C++ contracts code

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

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

--- Comment #4 from Iain Sandoe  ---
I think the problem here is related to the setting of DECL_ABSTRACT_ORIGIN on
the contract checking functions.

"
   DECL_ABSTRACT_ORIGIN, if non-NULL, points to the original (abstract)
..._DECL node of which this decl is an (inlined or template expanded)
instance.

"

but that is not what these synthesised functions are; rather they are entirely
new functions that implement a series of tests and possibly diagnostic output. 
In fact, they don't necessarily even have the same signature as the original. 
They certainly do not have the same block layout as the original.

It's not clear that we need these functions to be identified as the same
function as the original (if that is really a requirement - e.g. to make the
function name the same in these helpers - then we could do a similar process to
the one used for coroutine helpers).

[Bug c++/115434] Post contracts are ignored on functions with no return statement.

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Ever confirmed|0   |1
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-June/65
   ||4848.html
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-06-23
   Assignee|unassigned at gcc dot gnu.org  |iains at gcc dot gnu.org

[Bug c++/110871] coroutine precondition should be evaluated before the initial suspend

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-06-23
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-June/65
   ||4848.html
 CC||iains at gcc dot gnu.org

[Bug c++/110872] coroutine postcondition is not evaluated

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

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

Iain Sandoe  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-June/65
   ||4848.html
   Last reconfirmed||2024-06-23
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Assignee|unassigned at gcc dot gnu.org  |iains at gcc dot gnu.org
 CC||iains at gcc dot gnu.org

[Bug libstdc++/98678] 30_threads/future/members/poll.cc execution test FAILs

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

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

--- Comment #12 from John David Anglin  ---
Created attachment 58500
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58500&action=edit
Hack to fix failure of poll.cc on hppa-unknown-linux-gnu

The number of iterations is specific to my current kernel configuration.  The
code to determine the number of iterations returned inconsistent results.

Current kernel config is 1000 Hz (to reduce test time) and stable clock.

Here is a typical run:
dave@atlas:~/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/testsuite$ ./poll.exe
wait_for(0s): 92ns for 19500 calls, avg 51.2816ns per call
wait_until(system_clock minimum): 369ns for 19500 calls, avg 205.127ns per
call
wait_until(steady_clock minimum): 461ns for 19500 calls, avg 256.408ns per
call
wait_until(system_clock epoch): 19499847791ns for 19500 calls, avg 92ns per
call
wait_until(steady_clock epoch: 19498848587ns for 19500 calls, avg 41ns per
call
wait_for when ready: 92ns for 19500 calls, avg 51.2816ns per call
missed 9 ticks

For some reason, I never see missed ticks in "wait_for(0s)".  But we almost
always miss ticks in "wait_for when ready" (usually 7 to 9).  I turned off
ntp but this didn't make any significant difference.  CLOCK_MONOTONIC behaves
similarly to CLOCK_REALTIME with regard to missing ticks..

dave@atlas:~/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/testsuite$ ./ntime
CLOCK_REALTIME - "Systemwide realtime clock.":
precision: 100ns
value: -112725112.1719177549
CLOCK_MONOTONIC - "Represents monotonic time. Cannot be set.":
precision: 100ns
value: -112725112.68986

Didn't need to adjust VERIFY conditions.

Test times get much longer at 250 and 100 HZ since clock tick depends on HZ.

[Bug tree-optimization/115602] New: [15 Regression] ICE on liblapack-3.12.0: in vect_schedule_slp_node, at tree-vect-slp.cc:9643

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

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

Bug ID: 115602
   Summary: [15 Regression]  ICE on liblapack-3.12.0: in
vect_schedule_slp_node, at tree-vect-slp.cc:9643
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

Possibly recent regression observed on liblapack-3.12.0 on
r15-1566-gfd536b8412d4da.

Reduced down to the following:

* $ cat ztpmv.f.f
  SUBROUTINE ZTPMV_64(AP,X)
  COMPLEX*16 AP(*),X(*)
  COMPLEX*16 TEMP
  LOGICAL NOCONJ
  LOGICAL LSAME_64
  IF (LSAME_64(UPLO,'U') .AND.LSAME_64(UPLO,'L')) THEN
  ELSE IF (LSAME_64(TRANS,'N') .AND.LSAME_64(DIAG,'N')) THEN
  IF (LSAME_64(UPLO,'U')) THEN
  IF (INCXINCXINCX.EQ.1) THEN
  TEMP = X(JX)
  IF (NOCONJ) THEN
  TEMP = TEMP*AP(KK)
  ELSE
  TEMP = TEMP*DCONJG0
  DO 130 K = 1,J
  TEMP = TEMP + AP(K)*X(IX)
  130 CONTINUE
  END IF
  X(JX) = TEMP
  END IF
  END IF
  END IF
  END

Crashing:

$ gfortran -O2 -frecursive -fdefault-integer-8 -c ztpmv.f.f -o bug.o -Wall
during GIMPLE pass: slp
ztpmv.f.f:1:25:

1 |   SUBROUTINE ZTPMV_64(AP,X)
  | ^
internal compiler error: in vect_schedule_slp_node, at tree-vect-slp.cc:9643
0x1f2a3be diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char
const*, __va_list_tag (*) [1], diagnostic_t)
???:0
0x1f2aa98 internal_error(char const*, ...)
???:0
0x767124 fancy_abort(char const*, int, char const*)
???:0
0x74b0c3 vect_schedule_slp_node(vec_info*, _slp_tree*, _slp_instance*) [clone
.part.0] [clone .cold]
???:0
0x10d34f2 vect_schedule_scc(vec_info*, _slp_tree*, _slp_instance*,
hash_map<_slp_tree*, slp_scc_info,
simple_hashmap_traits, slp_scc_info> >&, int&,
vec<_slp_tree*, va_heap, vl_ptr>&)
???:0
0x10d2989 vect_schedule_scc(vec_info*, _slp_tree*, _slp_instance*,
hash_map<_slp_tree*, slp_scc_info,
simple_hashmap_traits, slp_scc_info> >&, int&,
vec<_slp_tree*, va_heap, vl_ptr>&)
???:0
0x10d2989 vect_schedule_scc(vec_info*, _slp_tree*, _slp_instance*,
hash_map<_slp_tree*, slp_scc_info,
simple_hashmap_traits, slp_scc_info> >&, int&,
vec<_slp_tree*, va_heap, vl_ptr>&)
???:0
0x10d2989 vect_schedule_scc(vec_info*, _slp_tree*, _slp_instance*,
hash_map<_slp_tree*, slp_scc_info,
simple_hashmap_traits, slp_scc_info> >&, int&,
vec<_slp_tree*, va_heap, vl_ptr>&)
???:0
0x10d2989 vect_schedule_scc(vec_info*, _slp_tree*, _slp_instance*,
hash_map<_slp_tree*, slp_scc_info,
simple_hashmap_traits, slp_scc_info> >&, int&,
vec<_slp_tree*, va_heap, vl_ptr>&)
???:0
0x10d2989 vect_schedule_scc(vec_info*, _slp_tree*, _slp_instance*,
hash_map<_slp_tree*, slp_scc_info,
simple_hashmap_traits, slp_scc_info> >&, int&,
vec<_slp_tree*, va_heap, vl_ptr>&)
???:0
0x10d39f0 vect_schedule_slp(vec_info*, vec<_slp_instance*, va_heap, vl_ptr>
const&)
???:0
0x10d61ca vect_slp_bbs(vec const&, loop*)
???:0
0x10d7675 vect_slp_function(function*)
???:0
0x10deef5 (anonymous namespace)::pass_slp_vectorize::execute(function*)
???:0

$ gfortran -v
Using built-in specs.
COLLECT_GCC=/<>/gfortran-15.0.0/bin/gfortran
COLLECT_LTO_WRAPPER=/<>/gfortran-15.0.0/libexec/gcc/x86_64-unknown-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../source/configure --prefix=/<>/gfortran-15.0.0
--with-gmp-include=/<>/gmp-6.3.0-dev/include
--with-gmp-lib=/<>/gmp-6.3.0/lib
--with-mpfr-include=/<>/mpfr-4.2.1-dev/include
--with-mpfr-lib=/<>/mpfr-4.2.1/lib --with-mpc=/<>/libmpc-1.3.1
--with-native-system-header-dir=/<>/glibc-2.39-52-dev/include
--with-build-sysroot=/
--with-gxx-include-dir=/<>/gfortran-15.0.0/include/c++/15.0.0/
--program-prefix= --enable-lto --disable-libstdcxx-pch
--without-included-gettext --with-system-zlib --enable-checking=release
--enable-static --enable-languages=fortran --disable-multilib --enable-plugin
--disable-libcc1 --with-isl=/<>/isl-0.20 --build=x86_64-unknown-linux-gnu
--host=x86_64-unknown-linux-gnu --target=x86_64-unknown-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0  (experimental) (GCC)

[Bug tree-optimization/115602] [15 Regression] ICE on liblapack-3.12.0: in vect_schedule_slp_node, at tree-vect-slp.cc:9643

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

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

--- Comment #1 from Sergei Trofimovich  ---
Created attachment 58501
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58501&action=edit
ztpmv.f.f

Also attaching unreduced 'ztpmv.f.f' in case cvise mangled it too much.

[Bug tree-optimization/115602] [15 Regression] ICE on liblapack-3.12.0: in vect_schedule_slp_node, at tree-vect-slp.cc:9643

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |15.0

[Bug tree-optimization/115602] [15 Regression] ICE on liblapack-3.12.0: in vect_schedule_slp_node, at tree-vect-slp.cc:9643

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-unknown-linux-gnu

--- Comment #2 from Andrew Pinski  ---
It worked at 00848ba8d1602c2e3ff9fb1cb40f232b4c2b2452 . So maybe the fix for PR
115597  .

[Bug ipa/102061] .constprop gets exposed in warning message

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

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

Sam James  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-06-23
 Status|UNCONFIRMED |NEW

[Bug tree-optimization/115602] [15 Regression] ICE on liblapack-3.12.0: in vect_schedule_slp_node, at tree-vect-slp.cc:9643 since r15-1565-g2a345214fc332b

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

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

--- Comment #3 from Sergei Trofimovich  ---
bisect landed at r15-1565-g2a345214fc332b

commit 2a345214fc332b6f0821edf394ff8802b768db1d (HEAD)
Author: Richard Biener 
Date:   Sun Jun 23 11:26:39 2024 +0200

tree-optimization/115597 - allow CSE of two-operator VEC_PERM nodes

[Bug target/115485] [11/12/13/14/15 Regression] CASEServer.cpp:203:1: internal compiler error: in require_pic_register, at config/arm/arm.c:7855

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||6.4.0
 Status|UNCONFIRMED |NEW
Summary|CASEServer.cpp:203:1:   |[11/12/13/14/15 Regression]
   |internal compiler error: in |CASEServer.cpp:203:1:
   |require_pic_register, at|internal compiler error: in
   |config/arm/arm.c:7855   |require_pic_register, at
   ||config/arm/arm.c:7855
   Last reconfirmed||2024-06-23
  Known to fail||7.1.0, 9.5.0
 Ever confirmed|0   |1
   Target Milestone|--- |11.5

--- Comment #14 from Andrew Pinski  ---
Reduced testcase:
```
struct c1 {
  virtual void func1() = 0;
};
struct  c2 {
  virtual ~c2() {}
};
struct c3 : c2, c1 {
  void func1() override;
  void func3();
};
void c3::func1() {
  func3();
}
```

Options needed to get the ICE:
```
-fPIE -mno-pic-data-is-text-relative  -mlong-calls  -ffunction-sections
```

The ICE started in GCC 7.x.

[Bug target/115485] [11/12/13/14/15 Regression] CASEServer.cpp:203:1: internal compiler error: in require_pic_register, at config/arm/arm.c:7855

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

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

--- Comment #15 from Andrew Pinski  ---
Most likely r7-1945-gb88bd5e0ca1208 introduced/exposed the ICE. It changes the
behavior of -mno-pic-data-is-text-relative but adding -msingle-pic-base didn't
ICE in GCC 6.

[Bug target/114846] powerpc: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return

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

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

--- Comment #13 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Kewen Lin :

https://gcc.gnu.org/g:2b5e8f918ef0027d2af8e53c4e114e1d133fc609

commit r14-10342-g2b5e8f918ef0027d2af8e53c4e114e1d133fc609
Author: Kewen Lin 
Date:   Tue May 28 21:13:40 2024 -0500

rs6000: Don't clobber return value when eh_return called [PR114846]

As the associated test case in PR114846 shows, currently
with eh_return involved some register restoring for EH
RETURN DATA in epilogue can clobber the one which holding
the return value.  Referring to the existing handlings in
some other targets, this patch makes eh_return expander
call one new define_insn_and_split eh_return_internal which
directly calls rs6000_emit_epilogue with epilogue_type
EPILOGUE_TYPE_EH_RETURN instead of the previous treating
normal return with crtl->calls_eh_return specially.

PR target/114846

gcc/ChangeLog:

* config/rs6000/rs6000-logue.cc (rs6000_emit_epilogue): As
EPILOGUE_TYPE_EH_RETURN would be passed as epilogue_type directly
now, adjust the relevant handlings on it.
* config/rs6000/rs6000.md (eh_return expander): Append by calling
gen_eh_return_internal and emit_barrier.
(eh_return_internal): New define_insn_and_split, call function
rs6000_emit_epilogue with epilogue type EPILOGUE_TYPE_EH_RETURN.

gcc/testsuite/ChangeLog:

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

(cherry picked from commit e5fc5d42d25c86ae48178db04ce64d340a834614)

[Bug target/114846] powerpc: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return

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

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

--- Comment #14 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Kewen Lin :

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

commit r13-8866-gdd54ed4ae417935300a3c4bb356d37c2ae7f731e
Author: Kewen Lin 
Date:   Tue May 28 21:13:40 2024 -0500

rs6000: Don't clobber return value when eh_return called [PR114846]

As the associated test case in PR114846 shows, currently
with eh_return involved some register restoring for EH
RETURN DATA in epilogue can clobber the one which holding
the return value.  Referring to the existing handlings in
some other targets, this patch makes eh_return expander
call one new define_insn_and_split eh_return_internal which
directly calls rs6000_emit_epilogue with epilogue_type
EPILOGUE_TYPE_EH_RETURN instead of the previous treating
normal return with crtl->calls_eh_return specially.

PR target/114846

gcc/ChangeLog:

* config/rs6000/rs6000-logue.cc (rs6000_emit_epilogue): As
EPILOGUE_TYPE_EH_RETURN would be passed as epilogue_type directly
now, adjust the relevant handlings on it.
* config/rs6000/rs6000.md (eh_return expander): Append by calling
gen_eh_return_internal and emit_barrier.
(eh_return_internal): New define_insn_and_split, call function
rs6000_emit_epilogue with epilogue type EPILOGUE_TYPE_EH_RETURN.

gcc/testsuite/ChangeLog:

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

(cherry picked from commit e5fc5d42d25c86ae48178db04ce64d340a834614)

[Bug target/114846] powerpc: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return

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

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

--- Comment #15 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Kewen Lin :

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

commit r12-10579-g0fd6ae9b20913ab84d596448e14411eedbd324f9
Author: Kewen Lin 
Date:   Tue May 28 21:13:40 2024 -0500

rs6000: Don't clobber return value when eh_return called [PR114846]

As the associated test case in PR114846 shows, currently
with eh_return involved some register restoring for EH
RETURN DATA in epilogue can clobber the one which holding
the return value.  Referring to the existing handlings in
some other targets, this patch makes eh_return expander
call one new define_insn_and_split eh_return_internal which
directly calls rs6000_emit_epilogue with epilogue_type
EPILOGUE_TYPE_EH_RETURN instead of the previous treating
normal return with crtl->calls_eh_return specially.

PR target/114846

gcc/ChangeLog:

* config/rs6000/rs6000-logue.cc (rs6000_emit_epilogue): As
EPILOGUE_TYPE_EH_RETURN would be passed as epilogue_type directly
now, adjust the relevant handlings on it.
* config/rs6000/rs6000.md (eh_return expander): Append by calling
gen_eh_return_internal and emit_barrier.
(eh_return_internal): New define_insn_and_split, call function
rs6000_emit_epilogue with epilogue type EPILOGUE_TYPE_EH_RETURN.

gcc/testsuite/ChangeLog:

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

(cherry picked from commit e5fc5d42d25c86ae48178db04ce64d340a834614)

[Bug target/114846] powerpc: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return

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

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

--- Comment #16 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Kewen Lin :

https://gcc.gnu.org/g:549701628b64a7c4ac9bb5f9623e83a8dc1d828c

commit r11-11535-g549701628b64a7c4ac9bb5f9623e83a8dc1d828c
Author: Kewen Lin 
Date:   Tue May 28 21:13:40 2024 -0500

rs6000: Don't clobber return value when eh_return called [PR114846]

As the associated test case in PR114846 shows, currently
with eh_return involved some register restoring for EH
RETURN DATA in epilogue can clobber the one which holding
the return value.  Referring to the existing handlings in
some other targets, this patch makes eh_return expander
call one new define_insn_and_split eh_return_internal which
directly calls rs6000_emit_epilogue with epilogue_type
EPILOGUE_TYPE_EH_RETURN instead of the previous treating
normal return with crtl->calls_eh_return specially.

PR target/114846

gcc/ChangeLog:

* config/rs6000/rs6000-logue.c (rs6000_emit_epilogue): As
EPILOGUE_TYPE_EH_RETURN would be passed as epilogue_type directly
now, adjust the relevant handlings on it.
* config/rs6000/rs6000.md (eh_return expander): Append by calling
gen_eh_return_internal and emit_barrier.
(eh_return_internal): New define_insn_and_split, call function
rs6000_emit_epilogue with epilogue type EPILOGUE_TYPE_EH_RETURN.

gcc/testsuite/ChangeLog:

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

(cherry picked from commit e5fc5d42d25c86ae48178db04ce64d340a834614)

[Bug c++/115603] New: [concepts] differing declaration and definition do not give error

[ispavlick at gmail dot com via Gcc-bugs]

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

Bug ID: 115603
   Summary: [concepts] differing declaration and definition do not
give error
   Product: gcc
   Version: 14.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ispavlick at gmail dot com
  Target Milestone: ---

#include 
#include 
#include 


template 
requires std::is_pointer_v
using stored_not_null = T;

template 
class Table;

template 
class Data_with_refresh
{
Table *m_table;
public:
// Declaration does not match with defenition. 
// stored_not_null> violates constraint,
// defeition - does not
Data_with_refresh(stored_not_null> *table);
void fn();
};

template 
using enter_cb = std::function d)>;

template 
class Table
{
enter_cb m_entercb;
public:
Table(enter_cb entercb) {
m_entercb = std::move(entercb);
m_entercb(this);
}
void refresh() {std::cout << "tick" << std::endl;}
};

// Defenition is different, and does not violates contstraint
template 
Data_with_refresh::Data_with_refresh(
stored_not_null *> table)
: m_table(table) {}

template 
void Data_with_refresh::fn()
{
m_table->refresh();
}

int main()
{
Table<3> tt([](Data_with_refresh<3> dd) {
dd.fn();
});
}

gcc compiles this without errors and warnings, clang gives compile time error

[Bug target/115406] [15 Regression] wrong code with vector compare at -O0 with -mavx512f since r15-920-gb6c6d5abf0d31c

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

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

--- Comment #7 from Hongtao Liu  ---

> 
> BTW, when assign -1 to vector(1) , should the upper bit be
> cleared? Look like only 1 element boolean vector is cleared, but not
> vector(2) .
> If the upper bits are not cleared, both 2 cases are equal.

diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
index 710d697c021..0f045f851d1 100644
--- a/gcc/fold-const.cc
+++ b/gcc/fold-const.cc
@@ -8077,7 +8077,7 @@ native_encode_vector_part (const_tree expr, unsigned char
*ptr, int len,
 {
   tree itype = TREE_TYPE (TREE_TYPE (expr));
   if (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (expr))
-  && TYPE_PRECISION (itype) <= BITS_PER_UNIT)
+  && TYPE_PRECISION (itype) < BITS_PER_UNIT)
 {
   /* This is the only case in which elements can be smaller than a byte.
 Element 0 is always in the lsb of the containing byte.  */


Can fix this.

It looks like it supposed to handle for itype *less than* but not *less equal*
BITS_PER_UNIT?

[Bug target/114846] powerpc: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return

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

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

--- Comment #17 from Kewen Lin  ---

(In reply to Peter Bergner from comment #11)
> Have we done the backports so we can just mark this bug a FIXED?  ...or do
> we still need to push the backports?

(In reply to Segher Boessenkool from comment #12)
> The backports have not been done yet.
> 

Yeah, I just backported it to all active release branches, previously when I
wanted to backport them, I noticed release 12.4 is ongoing, so I held it for a
while.

> It would be good if the blockage / barrier would get some comment btw, saying
> what exactly it is intended to do!  It is very much cargo-cult the way it is.

Good idea, sorry that didn't specify it originally, the reason why adding the
barrier is that: bb verifier requires returnjump_p should be followed by a
barrier:

  if (JUMP_P (x)
  && returnjump_p (x) && ! condjump_p (x)
  && ! ((y = next_nonnote_nondebug_insn (x))
&& BARRIER_P (y)))
fatal_insn ("return not followed by barrier", x); 

, otherwise we will encounter an ICE. Adding blockage follows the existing
practice when calling rs6000_emit_epilogue to respect option -mno-sched-epilog
(put one scheduling boundary on the emitted insns from rs6000_emit_epilogue).

[Bug target/114846] powerpc: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return

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

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

Kewen Lin  changed:

   What|Removed |Added

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

--- Comment #18 from Kewen Lin  ---
Should be fixed on trunk and all active release branches.

[Bug c++/115604] New: Absurd "flows off the end of the function" diagnostic with requires expression containing lambda

[hstong at ca dot ibm.com via Gcc-bugs]

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

Bug ID: 115604
   Summary: Absurd "flows off the end of the function" diagnostic
with requires expression containing lambda
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hstong at ca dot ibm.com
  Target Milestone: ---

Clearly the following function returns true. When calling it in a constant
expression, GCC thinks it does not have a return statement at all.

### SOURCE ():
constexpr bool f() {
  return requires {
[] {};
  };
}

static_assert(f());

### COMPILER INVOCATION:
g++ -fsyntax-only -std=c++23 -xc++ -

### COMPILER OUTPUT:
:7:16: error: non-constant condition for static assertion
:7:16:   in 'constexpr' expansion of 'f()'
:7:16: error: 'constexpr' call flows off the end of the function

### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240623 (experimental) (GCC)

[Bug c++/115604] Absurd "flows off the end of the function" diagnostic with requires expression containing only lambda(s) without being inside a template

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-06-24
 Status|UNCONFIRMED |NEW
  Known to fail||10.1.0, 11.1.0, 12.1.0,
   ||13.1.0, 14.1.0, 15.0
 Ever confirmed|0   |1
Summary|Absurd "flows off the end   |Absurd "flows off the end
   |of the function" diagnostic |of the function" diagnostic
   |with requires expression|with requires expression
   |containing only lambda(s)   |containing only lambda(s)
   ||without being inside a
   ||template

--- Comment #1 from Andrew Pinski  ---
Confirmed. Not a regression.

Interesting once we change f into a template:
```
template
constexpr bool g() {
  return requires {
[] {};
  };
}
int t = g<1>();
static_assert(g<1>());
```
It works.

Note also GCC 9 (and before), requires was not supported outside of a template:
`a requires expression cannot appear outside a template`. Maybe this is related
to that ...

[Bug target/113325] unnecessary byte swap for memory clear

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by HaoChen Gui :

https://gcc.gnu.org/g:6274f10318d05311f31147c895f76a01aec37830

commit r15-1576-g6274f10318d05311f31147c895f76a01aec37830
Author: Haochen Gui 
Date:   Mon Jun 24 13:16:12 2024 +0800

rs6000: Eliminate unnecessary byte swaps for duplicated constant vector
store

gcc/
PR target/113325
* config/rs6000/vsx.md (vsx_stxvd2x4_le_const_): New.

gcc/testsuite/
PR target/113325
* gcc.target/powerpc/pr113325.c: New.

[Bug c++/115605] New: structured binding break if a variable named tuple_size is visibile at the decomposition site

[marco.rubini08 at gmail dot com via Gcc-bugs]

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

Bug ID: 115605
   Summary: structured binding break if a variable named
tuple_size is visibile at the decomposition site
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marco.rubini08 at gmail dot com
  Target Milestone: ---

Example:


```
// a.cpp
#include 

int foo() {
int const tuple_size = 5;
std::array array {1, 2, 3};
auto [a, b, c] = array;
return c;
}

```

g++ std=c++20 a.cpp

```
a.cpp: In function ‘int foo()’:
a.cpp:6:10: error: 3 names provided for structured binding
6 | auto [a, b, c] = array;
  |  ^
a.cpp:6:10: note: while ‘std::array’ decomposes into 1 element
```

[Bug c++/115605] structured binding break if a variable named tuple_size is visibile at the decomposition site

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||rejects-valid
   Last reconfirmed||2024-06-24

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

Note tuple_element has the same issue.



The code seems like what I would have expected it to do:
  tree inst = lookup_template_class (tuple_size_identifier, args,
 /*in_decl*/NULL_TREE,
 /*context*/std_node,
 tf_none);


  tree inst = lookup_template_class (tuple_element_identifier, args,
 /*in_decl*/NULL_TREE,
 /*context*/std_node,
 tf_warning_or_error);


You might end up with the same issue with coroutine_handle too.

  tree handle_type
= lookup_template_class (coro_handle_identifier, targ,
 /* in_decl=*/NULL_TREE,
 /* context=*/std_node,
 tf_warning_or_error);

Though that might happen outside a function context.

[Bug c++/115605] structured binding break if a variable named tuple_size is visibile at the decomposition site

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

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

--- Comment #2 from Andrew Pinski  ---
Oh I think I see how it should be fixed.

The way std::initializer_list is handled is correct:
static tree
listify (tree arg)
{
  tree std_init_list = lookup_qualified_name (std_node, init_list_identifier);
...  

return lookup_template_class (std_init_list, argvec, NULL_TREE,
NULL_TREE, tf_warning_or_error);

That is:
```
#include 
void f()
{
int initializer_list;
std::vector tt = {0, 1, 2,3};
}
```
Works just fine.

If nobody gets to this soon, I might go and try to fix the use of
lookup_template_class  for those 3 cases to use lookup_qualified_name first.

[Bug middle-end/115606] New: return slot opt prevents tail calls

[andi-gcc at firstfloor dot org via Gcc-bugs]

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

Bug ID: 115606
   Summary: return slot opt prevents tail calls
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andi-gcc at firstfloor dot org
  Target Milestone: ---

For the following test case 

class Foo {
public:
  int a, b;
  Foo(int a, int b) : a(a), b(b) {}
};

Foo __attribute__((noinline,noclone,noipa))
callee (int i)
{
  return Foo(i, i+1);
}

Foo __attribute__((noinline,noclone,noipa))
caller (int i)
{
  return callee (i + 1);
}

x86 can sibling call the callee call, but ARM can't.

The difference seems to be that ARM ends up with 

   = callee (_1); [return slot optimization]

while x86_64 just has

  D.2926 = callee (_1);

and then in tree-tailcall this test fails with return slot optimization:

  tree result_decl = DECL_RESULT (cfun->decl);
  if (result_decl
  && may_be_aliased (result_decl)
  && ref_maybe_used_by_stmt_p (call, result_decl, false))

resulting in no sibling call.

This causes a test suite failure in the musttail patchkit, but only on ARM.

Of course the test could be disabled on ARM but I wonder if there is a missing
optimization bug here. With more musttail usage it might be a bigger problem if
not even simple structures are supported.

I'm not sure:
- why return slot opt at the gimple level is target specific?
- can tree tailcall handle this case?

[Bug c/109618] [12/13/14/15 Regression] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in generic_simplify_CONVERT_EXPR, at generic-match.cc since r12-3278-g823685221de986

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com

--- Comment #5 from Roger Sayle  ---
A patch for this was posted at
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650205.html back in April,
but the review got side tracked into a discussion on poisoning of conflicting
declarations.  My opinion is that this is a necessary evil if the front-end
wishes to continue compilation after encountering an error (that should
otherwise be fatal).  I'd prefer that front-ends not call the
middle-end with generic containing deeply embedded error_mark_nodes, but as
they (currently) do, we should avoid ICEing.

[Bug middle-end/115606] return slot opt prevents tail calls

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

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

--- Comment #1 from Andrew Pinski  ---
Note CALL_EXPR_RETURN_SLOT_OPT is set in the C++ front-end:
  else if (style == arg)
{
  /* Just mark it addressable here, and leave the rest to
 expand_call{,_inline}.  */
  cxx_mark_addressable (slot);
  CALL_EXPR_RETURN_SLOT_OPT (call_expr) = true;
  call_expr = cp_build_init_expr (slot, call_expr);
}

Which comes from:
  enum style_t { ctor, arg, pcc } style;

  if (AGGR_INIT_VIA_CTOR_P (aggr_init_expr))
style = ctor;
#ifdef PCC_STATIC_STRUCT_RETURN
  else if (1)
style = pcc;
#endif
  else
{
  gcc_assert (TREE_ADDRESSABLE (type));
  style = arg;
}

>- why return slot opt at the gimple level is target specific?

It is not from gimple level, it is from the front-end which comes from target
specific.

[Bug tree-optimization/115344] Missing loop counter reversal

[andi-gcc at firstfloor dot org via Gcc-bugs]

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

Andi Kleen  changed:

   What|Removed |Added

 CC||andi-gcc at firstfloor dot org

--- Comment #2 from Andi Kleen  ---

If you go back long enough the RTL loop optimizer used to support that. It
broke at some point, even before that one was removed.

>so the doloop candidate isn't added?

x86 doesn't have hardware do loops, it's only for some obscure targets like
some DSPs.

[Bug middle-end/115606] return slot opt prevents tail calls

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||arm-*-*

--- Comment #2 from Andrew Pinski  ---
Note clang/LLVM does not do a tail call for this either on arm.

[Bug middle-end/115606] return slot opt prevents tail calls

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Note with a modified testcase for C:
```
typedef struct Foo {
  int a, b;
}Foo;

Foo
callee (int i);

Foo 
caller (int i)
{
  return callee (i + 1);
}
```

We get:
   = callee (_1); [return slot optimization] [tail call]


And then the tail call fails.

Note clang/LLVM also fails to do the tail call here
And with musttail gives an internal compiler error:
```
fatal error: error in backend: failed to perform tail call elimination on a
call site marked musttail
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and
include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.  Program arguments: /opt/compiler-explorer/clang-trunk/bin/clang++
-gdwarf-4 -g -o /app/output.s -S -target arm-linux-gnueabi
--gcc-toolchain=/opt/compiler-explorer/arm/gcc-12.2.0/arm-unknown-linux-gnueabi
--sysroot=/opt/compiler-explorer/arm/gcc-12.2.0/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sysroot
-fcolor-diagnostics -fno-crash-diagnostics -O2 -g0 
1.   parser at end of file
2.  Code generation
3.  Running pass 'Function Pass Manager' on module ''.
4.  Running pass 'ARM Instruction Selection' on function '@_Z6calleri'
 #0 0x037a21e8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x37a21e8)
 #1 0x037a0334 llvm::sys::CleanupOnSignal(unsigned long)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x37a0334)
 #2 0x036e8e33 llvm::CrashRecoveryContext::HandleExit(int)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x36e8e33)
 #3 0x03797a5e llvm::sys::Process::Exit(int, bool)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x3797a5e)
 #4 0x00c72976
(/opt/compiler-explorer/clang-trunk/bin/clang+++0xc72976)
 #5 0x036f3433 llvm::report_fatal_error(llvm::Twine const&, bool)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x36f3433)
 #6 0x036f3598
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x36f3598)
 #7 0x0169cac6
llvm::ARMTargetLowering::LowerCall(llvm::TargetLowering::CallLoweringInfo&,
llvm::SmallVectorImpl&) const
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x169cac6)
 #8 0x04876419
llvm::TargetLowering::LowerCallTo(llvm::TargetLowering::CallLoweringInfo&)
const (/opt/compiler-explorer/clang-trunk/bin/clang+++0x4876419)
 #9 0x0487824d
llvm::SelectionDAGBuilder::lowerInvokable(llvm::TargetLowering::CallLoweringInfo&,
llvm::BasicBlock const*)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x487824d)
#10 0x04898c44 llvm::SelectionDAGBuilder::LowerCallTo(llvm::CallBase
const&, llvm::SDValue, bool, bool, llvm::BasicBlock const*,
llvm::TargetLowering::PtrAuthInfo const*)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x4898c44)
#11 0x048af288 llvm::SelectionDAGBuilder::visitCall(llvm::CallInst
const&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x48af288)
#12 0x048c3d77 llvm::SelectionDAGBuilder::visit(llvm::Instruction
const&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x48c3d77)
#13 0x0493c673
llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator_w_bits, false, true>,
llvm::ilist_iterator_w_bits, false, true>, bool&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x493c673)
#14 0x0493dd44
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x493dd44)
#15 0x0493fbb4
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x493fbb4)
#16 0x0162cfe4 (anonymous
namespace)::ARMDAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&)
ARMISelDAGToDAG.cpp:0:0
#17 0x0492f6e1
llvm::SelectionDAGISelLegacy::runOnMachineFunction(llvm::MachineFunction&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x492f6e1)
#18 0x02bfdbdb
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (.part.0)
MachineFunctionPass.cpp:0:0
#19 0x031426f2 llvm::FPPassManager::runOnFunction(llvm::Function&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x31426f2)
#20 0x03142871 llvm::FPPassManager::runOnModule(llvm::Module&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x3142871)
#21 0x03144520 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x3144520)
#22 0x03a3338e clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::HeaderSearchOptions const&, clang::CodeGenOptions const&,
clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef,
llvm::Module*, clang::BackendAction,
llvm::Int

[Bug tree-optimization/115344] Missing loop counter reversal

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andi Kleen from comment #2)
> x86 doesn't have hardware do loops, it's only for some obscure targets like
> some DSPs.

Actually doloop was added to support rs6000(powerpc)'s loop counter register
...
So it is not just for obscure DSPs targets.

[Bug middle-end/115606] return slot opt prevents tail calls

[andi-gcc at firstfloor dot org via Gcc-bugs]

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

Andi Kleen  changed:

   What|Removed |Added

 Target|arm-*-* |
 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #4 from Andi Kleen  ---
Yes I know it's from the frontend, the question is why that is target specific.

The only dependency I see is on PCC_STRUCT_RETURN, but neither x86 nor arm seem
to  set that define.

Anyways I guess it doesn't really matter why the frontend does that, but it
still breaks sibcalls.

[Bug c++/115606] C++ front-end marks the return slot as addressable early on which prevents tail call being marked

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||arm-*-*
   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-06-24
  Component|middle-end  |c++
 Ever confirmed|0   |1
Summary|return slot opt prevents|C++ front-end marks the
   |tail calls  |return slot as addressable
   ||early on which prevents
   ||tail call being marked
   Severity|normal  |enhancement

--- Comment #5 from Andrew Pinski  ---
Though.
It looks like that part is not just the arm backend.

So there are 2 issues here.

Let us record this for the C++ front-end issue rather than the middle-end not
tailing calling afterwards.

[Bug tree-optimization/115602] [15 Regression] ICE on liblapack-3.12.0: in vect_schedule_slp_node, at tree-vect-slp.cc:9643 since r15-1565-g2a345214fc332b

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

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

--- Comment #4 from Sergei Trofimovich  ---
If C example is easier to debug graphviz-10.0.1 exhibits the same ICE.
Minimized example:

// $ cat gvevent.c.c
typedef struct {
  double x, y;
} pointf;
struct {
  pointf focus;
  double zoom;
  pointf devscale;
  char button;
  pointf oldpointer;
} gvevent_motion_job;
char gvevent_motion_job_4;
double gvevent_motion_pointer_1, gvevent_motion_pointer_0;
void gvevent_motion() {
  double dx = (gvevent_motion_pointer_0 - gvevent_motion_job.oldpointer.x) /
  gvevent_motion_job.devscale.x,
 dy = (gvevent_motion_pointer_1 - gvevent_motion_job.oldpointer.y) /
  gvevent_motion_job.devscale.y;
  if (dx && dy < .0001)
return;
  switch (gvevent_motion_job_4)
  case 2: {
gvevent_motion_job.focus.x -= dy / gvevent_motion_job.zoom;
gvevent_motion_job.focus.y += dx / gvevent_motion_job.zoom;
  }
}

Crashing:

$ gcc -O2 -c gvevent.c.c -o bug.o
during GIMPLE pass: slp
gvevent.c.c: In function 'gvevent_motion':
gvevent.c.c:13:6: internal compiler error: in vect_schedule_slp_node, at
tree-vect-slp.cc:9643
   13 | void gvevent_motion() {
  |  ^~

[Bug tree-optimization/115602] [15 Regression] ICE on liblapack-3.12.0: in vect_schedule_slp_node, at tree-vect-slp.cc:9643 since r15-1565-g2a345214fc332b

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

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

--- Comment #5 from Sergei Trofimovich  ---
Created attachment 58502
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58502&action=edit
gvevent.c.c

Attaching unreduced gvevent.c.c in case cvise mangled it too much.

[Bug middle-end/115607] New: missed tail call with large structure size

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

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

Bug ID: 115607
   Summary: missed tail call with large structure size
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-linux-gnu arm-linux-gnu powerpc{,64}-linux-gnu

Take:
```
typedef struct Foo {
  int a, b, c, d, e, f, g, h;
}Foo;

Foo
callee (int i);

Foo 
caller (int i)
{
  return callee (i + 1);
}
```

This can be tail called but currently we don't.
The issue is tail calls for functions where the structure return is passed via
pointer via register is not tail called.

[Bug target/115608] New: ICE in extract_insn, at recog.cc:2812 when building with -mv8plus

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

Bug ID: 115608
   Summary: ICE in extract_insn, at recog.cc:2812 when building
with -mv8plus
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glaubitz at physik dot fu-berlin.de
CC: ebotcazou at gcc dot gnu.org, jrtc27 at jrtc27 dot com,
matorola at gmail dot com, sjames at gcc dot gnu.org
  Target Milestone: ---
Target: sparc-linux-gnu

Support for the V8+ API seems to be broken in GCC as even trying to build a
simple program with "-mv8plus" fails:

(sid_sparc64-dchroot)glaubitz@stadler:~$ cat hello.c
#include 

int main () {
  printf("Hello World!");
  return 0;
}
(sid_sparc64-dchroot)glaubitz@stadler:~$ gcc-14 -mv8plus hello.c -o hello
hello.c: In function 'main':
hello.c:6:1: error: unrecognizable insn:
6 | }
  | ^
(insn 6 5 7 2 (set (reg:DI 115)
(lo_sum:DI (reg:DI 115)
(unspec:DI [
(symbol_ref/f:SI ("*.LC0") [flags 0x2] )
] UNSPEC_MOVE_PIC))) "hello.c":4:3 -1
 (nil))
during RTL pass: vregs
hello.c:6:1: internal compiler error: in extract_insn, at recog.cc:2812
0x4d60a7 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../src/gcc/rtl-error.cc:108
0x4d60d7 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../src/gcc/rtl-error.cc:116
0xb3b21b extract_insn(rtx_insn*)
../../src/gcc/recog.cc:2812
0x9e29eb instantiate_virtual_regs_in_insn
../../src/gcc/function.cc:1612
0x9e29eb instantiate_virtual_regs
../../src/gcc/function.cc:1995
0x9e29eb execute
../../src/gcc/function.cc:2042
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.
(sid_sparc64-dchroot)glaubitz@stadler:~$

[Bug target/115608] ICE in extract_insn, at recog.cc:2812 when building with -mv8plus

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

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

--- Comment #1 from Andrew Pinski  ---
Note -fPIE is needed to get the ICE in this case.

[Bug target/115608] ICE in extract_insn, at recog.cc:2812 when building with -mv8plus

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|sparc-linux-gnu |sparc64-linux-gnu

--- Comment #2 from Andrew Pinski  ---
  /* V8PLUS requires V9 and makes no sense in 64-bit mode.  */
  if (!TARGET_V9 || TARGET_ARCH64)
target_flags &= ~MASK_V8PLUS;


Basically for sparc64, -mv8plus should have been a no-op ...

[Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code since r15-1238-g1fe55a1794863b

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #28 from Jürgen Reuter  ---
Richard, unfortunately the fix (it seems it was committed to gcc git master on
last Friday) did not fix our problem yet. The original test case still
segfaults:
Backtrace for this error:
#0  0x7f36f52a3a6c in ???
#1  0x7f36f52a2b45 in ???
#2  0x7f36f4fe204f in ???
#3  0x7f36f5c9b323 in curr_
at ../../../contrib/tauola/formf.f:501
#4  0x7f36f5cabc16 in dam4pi_
at ../../../contrib/tauola/tauola.f:4106
#5  0x7f36f5cacdb6 in dph4pi_
at ../../../contrib/tauola/tauola.f:4067
#6  0x7f36f5cb1330 in dadnew_
at ../../../contrib/tauola/tauola.f:3667
#7  0x7f36f5cb167c in dexnew_
at ../../../contrib/tauola/tauola.f:3592
#8  0x7f36f5cb7a4d in dexay_
at ../../../contrib/tauola/tauola.f:525
#9  0x7f36f5cb9e3a in initdk_
at ../../../contrib/tauola/tauola_photos_ini.f:452
#10  0x7f36f5aeebbc in __tauola_interface_MOD_wo_tauola_init_call
at ../../../src/tauola/tauola_interface_sub.f90:903