[Bug tree-optimization/111970] [14 regression] SLP for non-IFN gathers result in RISC-V test failure on gather since r14-4745-gbeab5b95c58145

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

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

--- Comment #13 from JuzheZhong  ---
Created attachment 56649
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56649=edit
Correct vectorized optimized dump

This is the optimized dump IR that runs correctly.

[Bug tree-optimization/111970] [14 regression] SLP for non-IFN gathers result in RISC-V test failure on gather since r14-4745-gbeab5b95c58145

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

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

--- Comment #12 from JuzheZhong  ---
Created attachment 56648
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56648=edit
Optimized dump which is buggy

This is the buggy vectorized dump IR

[Bug tree-optimization/111970] [14 regression] SLP for non-IFN gathers result in RISC-V test failure on gather since r14-4745-gbeab5b95c58145

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

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

--- Comment #11 from JuzheZhong  ---
Hi, Richard.

I come back to revisit this bug.

I found if I do this:

diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
index 4a09b3c2aca..2fd128672b9 100644
--- a/gcc/tree-vect-slp.cc
+++ b/gcc/tree-vect-slp.cc
@@ -1434,7 +1434,6 @@ vect_build_slp_tree_1 (vec_info *vinfo, unsigned char
*swap,
  && rhs_code != CFN_GATHER_LOAD
  && rhs_code != CFN_MASK_GATHER_LOAD
  && rhs_code != CFN_MASK_LEN_GATHER_LOAD
- && !STMT_VINFO_GATHER_SCATTER_P (stmt_info)
  /* Not grouped loads are handled as externals for BB
 vectorization.  For loop vectorization we can handle
 splats the same we handle single element interleaving.  */


The bug is fixed. But I am not sure whether it is the correct fix.

Reproduce bug compile option on RISC-V:
-O3 --param=riscv-autovec-preference=fixed-vlmax --param riscv-autovec-lmul=m4
-fno-vect-cost-model -ffast-math

[Bug c++/112633] [13/14 Regression] ICE with type aliases and depedent value

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-11-20
 Status|UNCONFIRMED |NEW
   Keywords||needs-bisection

--- Comment #2 from Andrew Pinski  ---
.

[Bug c++/112633] [13/14 Regression] ICE with type aliases and depedent value

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
Version|13.0|13.1.0
Summary|ICE in parser GCC 13+   |[13/14 Regression] ICE with
   |(including 14) around type  |type aliases and depedent
   |aliases |value
   Target Milestone|--- |13.3

--- Comment #1 from Andrew Pinski  ---
Confirmed, note this is not related to variadic templates as this crashes in a
similar way:
```
template  constexpr bool dependent_true = true;

template  struct empty_type { }; // something like enable_if

template  using empty_type_t = typename empty_type::type; 

struct wrapper {
using type = void;
};

template  using all = wrapper;

template 
using constraints = typename all::type;

template >> = nullptr> 
void calculate() { };
```

[Bug c++/112633] New: ICE in parser GCC 13+ (including 14) around type aliases

[hanicka at hanicka dot net via Gcc-bugs]

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

Bug ID: 112633
   Summary: ICE in parser GCC 13+ (including 14) around type
aliases
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hanicka at hanicka dot net
  Target Milestone: ---

Tested on GCC 14.0.0 20231119 (on Compiler-Explorer) and it's giving me ICE,
also on all 13.x versions (not 12.x)

```c++
template  constexpr bool dependent_true = true;

template  struct empty_type { }; // something like enable_if

template  using empty_type_t = typename empty_type::type; 

struct wrapper {
using type = void;
};

template  using all = wrapper;

template 
using constraints = typename all::type;

template >> = nullptr> 
void calculate() { };
```

I don't even need to instantiate `calculate` function.

It gives me this error:

: In substitution of 'template using constraints
= typename all::type [with Conditions = {typename
empty_type >::type}]':
:16:66:   required from here
   16 | template >> =
nullptr>
  |  ^
:14:7: internal compiler error: Segmentation fault
   14 | using constraints = typename all::type;
  |   ^~~
0x26a742e internal_error(char const*, ...)
???:0
0xd276f0 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xd1b8f3 instantiate_template(tree_node*, tree_node*, int)
???:0
0xd285ea tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xd35ed6 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
???:0
0xd6996f finish_template_type(tree_node*, tree_node*, int)
???:0
0xcf6a49 c_parse_file()
???:0
0xe38e79 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Compiler returned: 1

[Bug c++/112594] Non-type template parameter created with converting constructor sometimes has original type

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||rejects-valid

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> 
> I will file another related bug seperately which seems like a regression on
> the trunk.

Filed PR 112632 for that case, basically using `inline constexpr` rather than
`conccept` used to work in GCC 13 but fails on the trunk ...

[Bug c++/112632] [14 Regression] Non-type template parameter created with converting constructor sometimes has original type

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug c++/112632] New: [14 Regression] Non-type template parameter created with converting constructor sometimes has original type

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

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

Bug ID: 112632
   Summary: [14 Regression]  Non-type template parameter created
with converting constructor sometimes has original
type
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: needs-bisection, rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
template
inline constexpr bool C = true;

struct n {
constexpr n(int a) : i(a) {}
int i;
};

template
using get_n_i_type = decltype(N.i);

template
int f() {
using iii = get_n_i_type;
#if 1  // Change to 0 and this compiles
static_assert(C);
#endif
return iii{};
}

template int f<3>();
```

This is rejected on the trunk with:
```
: In instantiation of 'int f() [with int X = 3]':
:22:23:   required from here
   22 | template int f<3>();
  |   ^
:11:37: error: request for member 'i' in '3', which is of non-class
type 'int'
   11 | using get_n_i_type = decltype(N.i);
  |   ~~^
```

But was accepted in GCC 13.  Note the difference between this and PR 112594 is
that C here is declared an `inline constexpr` rather than a concept.

[Bug c++/112594] Non-type template parameter created with converting constructor sometimes has original type

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

This fails in a similar way so it is not related to i being static here:
```

template
concept C = true;

struct n {
constexpr n(int a) : i(a) {}
int i;
};

template
using get_n_i_type = decltype(N.i);

template
int f() {
using iii = get_n_i_type;
#if 1  // Change to 0 and this compiles
static_assert(C);
#endif
return iii{};
}

template int f<3>();
```


I will file another related bug seperately which seems like a regression on the
trunk.

[Bug c++/112557] ICE with coroutines in build_special_member_call, at cp/call.cc:11093

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

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

--- Comment #1 from Tobias Schlüter  ---
With today's trunk on x86-64 I can reproduce this, giving the following:

$ ../gcc.git/build/gcc/cc1plus t.cc --std=c++20 -fpermissive
-fext-numeric-literals 2>&1
[ ... stripping away thousands of warnings ... ]
/home/lpresearch/LPResearch/lpopenvr_lpviz/00_3rdparty/00_tracking_systems/DTrackSDK_v2.8.0/include/DTrackParse.hpp:
In static member function ‘static
boost::asio::awaitable >
LP::DTrac>
/home/lpresearch/LPResearch/lpopenvr_lpviz/00_3rdparty/00_tracking_systems/DTrackSDK_v2.8.0/include/DTrackParse.hpp:263:5:
internal compiler error: tree check: expected record_type or union_type or
qual_union_type, have array_type in bu>
0x938c90 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.cc:8952
0x73fd02 tree_check3(tree_node*, char const*, int, char const*, tree_code,
tree_code, tree_code)
../../gcc/tree.h:3642
0x73fd02 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
../../gcc/cp/call.cc:11071
0xaa0eac maybe_promote_temps
../../gcc/cp/coroutines.cc:3142
0xaa0eac await_statement_walker
../../gcc/cp/coroutines.cc:3753
0x162f7dc walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_>
../../gcc/tree.cc:11418
0xaa0668 await_statement_walker
../../gcc/cp/coroutines.cc:3424
0x162f7dc walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_>
../../gcc/tree.cc:11418
0x162f934 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_>
../../gcc/tree.cc:11652
0xaa0668 await_statement_walker
../../gcc/cp/coroutines.cc:3424
0x162f7dc walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_>
../../gcc/tree.cc:11418
0x162f934 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_>
../../gcc/tree.cc:11652
0xaa0668 await_statement_walker
../../gcc/cp/coroutines.cc:3424
0x162f7dc walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_>
../../gcc/tree.cc:11418
0x162f934 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_>
../../gcc/tree.cc:11652
0xaa0668 await_statement_walker
../../gcc/cp/coroutines.cc:3424
0x162f7dc walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_>
../../gcc/tree.cc:11418
0x162f934 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_>
../../gcc/tree.cc:11652
0xaa0668 await_statement_walker
../../gcc/cp/coroutines.cc:3424
0x162f7dc walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_>
../../gcc/tree.cc:11418
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.

The error location is this:
#2  build_special_member_call (instance=0x7fffe891d090, name=0x776f5200,
args=0x0, binfo=0x7fffe88e4540, flags=1, complain=3) at
../../gcc/cp/call.cc:11071
11071 binfo = TYPE_BINFO (binfo);
(gdb) l
11066   {
11067 /* Resolve the name.  */
11068 if (!complete_type_or_maybe_complain (binfo, NULL_TREE,
complain))
11069   return error_mark_node;
11070
11071 binfo = TYPE_BINFO (binfo);
11072   }
11073
11074 gcc_assert (binfo != NULL_TREE);
11075
(gdb)

[Bug c++/112631] New: gcc rejects block-scope declaration of function in a module unit even if the function is attached to the global module fragment

[michael.kenzel at gmail dot com via Gcc-bugs]

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

Bug ID: 112631
   Summary: gcc rejects block-scope declaration of function in a
module unit even if the function is attached to the
global module fragment
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michael.kenzel at gmail dot com
  Target Milestone: ---

repro: https://godbolt.org/z/h5f798eEY

export module bla;

extern "C++" inline void fun()
{
void oops();  // error: block-scope extern declaration 'void
oops()' not permitted in module purview
}

fun is not attached to a named module due to being declared with a linkage
specification (https://eel.is/c++draft/module.unit#7.2). thus,
[dcl.meaning.general]/3.5 (https://eel.is/c++draft/dcl.meaning.general#3.5)
should not apply.

[Bug tree-optimization/112325] Missed vectorization of reduction after unrolling

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

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

commit r14-5603-g2b59e2b4dff42118fe3a505f07b9a6aa4cf53bdf
Author: liuhongt 
Date:   Thu Nov 16 18:38:39 2023 +0800

Support reduc_{plus,xor,and,ior}_scal_m for vector integer mode.

BB vectorizer relies on the backend support of
.REDUC_{PLUS,IOR,XOR,AND} to vectorize reduction.

gcc/ChangeLog:

PR target/112325
* config/i386/sse.md (reduc__scal_): New expander.
(REDUC_ANY_LOGIC_MODE): New iterator.
(REDUC_PLUS_MODE): Extend to VxHI/SI/DImode.
(REDUC_SSE_PLUS_MODE): Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr112325-1.c: New test.
* gcc.target/i386/pr112325-2.c: New test.

[Bug target/112537] Is there a way to disable cpymem pass for rvv

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

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

--- Comment #14 from CVS Commits  ---
The master branch has been updated by Li Xu :

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

commit r14-5602-ge6269bb69c0734a5af716bfbded3621de6ca351d
Author: xuli 
Date:   Fri Nov 17 04:48:47 2023 +

RISC-V: Implement -mmemcpy-strategy= options[PR112537]

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

-mmemcpy-strategy=[auto|libcall|scalar|vector]

auto: Current status, use scalar or vector instructions.
libcall: Always use a library call.
scalar: Only use scalar instructions.
vector: Only use vector instructions.

PR target/112537

gcc/ChangeLog:

* config/riscv/riscv-opts.h (enum riscv_stringop_strategy_enum):
Strategy enum.
* config/riscv/riscv-string.cc (riscv_expand_block_move): Disabled
based on options.
(expand_block_move): Ditto.
* config/riscv/riscv.opt: Add -mmemcpy-strategy=.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/cpymem-strategy-1.c: New test.
* gcc.target/riscv/rvv/base/cpymem-strategy-2.c: New test.
* gcc.target/riscv/rvv/base/cpymem-strategy-3.c: New test.
* gcc.target/riscv/rvv/base/cpymem-strategy-4.c: New test.
* gcc.target/riscv/rvv/base/cpymem-strategy-5.c: New test.
* gcc.target/riscv/rvv/base/cpymem-strategy.h: New test.

[Bug libstdc++/112630] New: [14 Regression] 19_diagnostics/stacktrace/output.cc execution test

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

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

Bug ID: 112630
   Summary: [14 Regression] 19_diagnostics/stacktrace/output.cc
execution test
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hp at gcc dot gnu.org
CC: redi at gcc dot gnu.org
  Target Milestone: ---
Target: cris-elf, m68k-linux-gnu, arm

>From r14-5536-g23725aa53bd264, this test started failing for cris-elf and some
other targets.

The test changed from "dg-compile" to "dg-run" so for once there's a simple
cause for the regression, and N.B. I notably disregard the underlying problem
that the test actually fails when running; a problem that doesn't seem trivial.

Incidentally, for cris-elf as well as (at least) m68k-linux-gnu, the
neighboring stacktrace execution tests fail (excerpt for cris-elf at
r14-5540-ga671095c208c):

Running /x/gcc/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ...
FAIL: 19_diagnostics/stacktrace/current.cc  -std=gnu++23 execution test
FAIL: 19_diagnostics/stacktrace/current.cc  -std=gnu++26 execution test
FAIL: 19_diagnostics/stacktrace/entry.cc  -std=gnu++23 execution test
FAIL: 19_diagnostics/stacktrace/entry.cc  -std=gnu++26 execution test
FAIL: 19_diagnostics/stacktrace/output.cc  -std=gnu++23 execution test
FAIL: 19_diagnostics/stacktrace/output.cc  -std=gnu++26 execution test
FAIL: 19_diagnostics/stacktrace/stacktrace.cc  -std=gnu++23 execution test
FAIL: 19_diagnostics/stacktrace/stacktrace.cc  -std=gnu++26 execution test
FAIL: 23_containers/vector/debug/mutex_association.cc  -std=gnu++17 execution
test
FAIL: 27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc  -std=gnu++17
execution test
[...]

To wit, of those, these are the introduced regressions:
FAIL: 19_diagnostics/stacktrace/output.cc  -std=gnu++23 execution test
FAIL: 19_diagnostics/stacktrace/output.cc  -std=gnu++26 execution test

For the other targets, compare results for m68k-linux:
https://gcc.gnu.org/pipermail/gcc-testresults/2023-November/801238.html
...to its earlier results:
https://gcc.gnu.org/pipermail/gcc-testresults/2023-November/800388.html

The "arm" CI bot picked it up too:
https://gcc.gnu.org/pipermail/gcc-regression/2023-November/078553.html

I'm not sure which component fits best here.  It seems there's an exposed bug
with libstdc++ or libbacktrace or both.  Or, it could just be that the change
from dg-compile to dg-run is a testsuite typo; that it shouldn't dg-run.

[Bug c/83324] [feature request] Pragma or special syntax for guaranteed tail calls

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

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

--- Comment #10 from Andrew Pinski  ---
(In reply to David Edelsohn from comment #9)
> Brandt Bucher: A JIT compiler for CPython
> https://www.youtube.com/watch?v=HxSHIpEQRjs
> https://github.com/brandtbucher/cpython/tree/justin

But must tail is there for the gcc jit interface already. Maybe it is not
exposed to c/c++ attribute but it is there already. So maybe this is just not
noticing that point.

[Bug c/83324] [feature request] Pragma or special syntax for guaranteed tail calls

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

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

--- Comment #9 from David Edelsohn  ---
Brandt Bucher: A JIT compiler for CPython
https://www.youtube.com/watch?v=HxSHIpEQRjs
https://github.com/brandtbucher/cpython/tree/justin

[Bug target/112578] LoongArch: Wrong code -with -mlsx -fno-fp-int-builtin-inexact

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

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

Xi Ruoyao  changed:

   What|Removed |Added

URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma
   |il/gcc-patches/2023-Novembe |il/gcc-patches/2023-Novembe
   |r/637097.html   |r/637316.html
   See Also|https://github.com/loongson |
   |-community/discussions/issu |
   |es/7|

--- Comment #4 from Xi Ruoyao  ---
(In reply to Xi Ruoyao from comment #3)
> https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637097.html
> 
> This fixes most of -ml[a]sx -fno-fp-int-builtin-inexact issues on LoongArch,
> except PR107723.

Updated: https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637316.html

[Bug libstdc++/112591] variant allows for creating multiple empty objects at same address

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-11-19
 Ever confirmed|0   |1

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

[Bug middle-end/112614] Compile-time float-to-_Decimal64 fails for -NAN

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-11-19
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed, not a regression.

[Bug c++/99187] [modules] ICE exporting thread_local static local variable

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Nathan Sidwell :

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

commit r14-5598-geaeaad3fcac4d7a30b5a256410cb59fa1a3fa9dd
Author: Nathaniel Shead 
Date:   Fri Nov 17 08:39:53 2023 +1100

c++: Set DECL_CONTEXT for __cxa_thread_atexit [PR99187]

Modules streaming requires DECL_CONTEXT to be set on declarations that
are streamed. This ensures that __cxa_thread_atexit is given translation
unit context much like is already done with many other support
functions.

PR c++/99187

gcc/cp/ChangeLog:

* cp-tree.h (enum cp_tree_index): Add CPTI_THREAD_ATEXIT.
(thread_atexit_node): New.
* decl.cc (get_thread_atexit_node): Cache in thread_atexit_node.

gcc/testsuite/ChangeLog:

* g++.dg/modules/pr99187.C: New test.

Signed-off-by: Nathaniel Shead 
Signed-off-by: Nathan Sidwell 

[Bug middle-end/112600] Failed to optimize saturating addition using __builtin_add_overflow

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-11-19
 Ever confirmed|0   |1

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

[Bug tree-optimization/112629] Missed-optimization: constant << (b + signed_constant)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot 
gnu.org
  Component|middle-end  |tree-optimization
   Severity|normal  |enhancement

[Bug middle-end/112629] Missed-optimization: constant << (b + signed_constant)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

--- Comment #6 from Andrew Pinski  ---
Actually I am not going to implement this one any time soon.  Maybe someone
else will.

[Bug c++/112595] ICE on invalid code: Literal class NTTP aggregate initialized with self-referential pointer

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-11-19
   Keywords||error-recovery,
   ||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
  Known to fail||10.5.0, 11.3.0, 12.2.0,
   ||9.5.0

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

[Bug sanitizer/112563] [14 regression] libsanitizer doesn't assemble with Solaris/sparc as

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

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

--- Comment #1 from Jakub Jelinek  ---
So, what is the Solaris/sparc native as syntax for something similar?
Strangely, non-weak aliases in config/sparc/sysv4.h use the x = y syntax
rather than .set x, y that is used on most targets.
Would using
extern "C" void *memcpy (void *, const void *, decltype (sizeof 0)) __asm
("__sanitizer_internal_memcpy");
extern "C" void *memmove (void *, const void *, decltype (sizeof 0)) __asm
("__sanitizer_internal_memmove");
extern "C" void *memset (void *, int, decltype (sizeof 0)) __asm
("__sanitizer_internal_memset");
extern "C" void *__builtin_memcpy (void *, const void *, decltype (sizeof 0))
__asm ("__sanitizer_internal_memcpy");
extern "C" void *__builtin_memmove (void *, const void *, decltype (sizeof 0))
__asm ("__sanitizer_internal_memmove");
extern "C" void *__builtin_memset (void *, int, decltype (sizeof 0)) __asm
("__sanitizer_internal_memset");
instead work there?
At least on x86_64-linux, I get the same effects when using e.g.
void
foo (void *r, void *s, void *t, void *u)
{
  memcpy (r, s, 512);
  __builtin_memcpy (t, u, 512);
}
with -O2 -mstringop-strategy=libcall

[Bug middle-end/112629] Missed-optimization: constant << (b + signed_constant)

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to gooncreeper from comment #3)
> This optimization could also be performed for unsigned integers if we know
> they won't overflow in the optimization.

Note it is not overflow, is wrap anyways.

[Bug middle-end/112629] Missed-optimization: constant << (b + signed_constant)

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

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

--- Comment #4 from Andrew Pinski  ---
Note we could do it even for unsigned if we know that (a+4) will not wrap.

That is:
```
#include 

int optimized_shift(unsigned shift) {
   if ((shift < 0) | (shift > (unsigned)INT_MAX)) __builtin_unreachable();
return 1 << (shift + 4);
}
```

LLVM is able to handle both cases.

[Bug middle-end/112629] Missed-optimization: constant << (b + signed_constant)

[goon.pri.low at gmail dot com via Gcc-bugs]

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

--- Comment #3 from gooncreeper  ---
This optimization could also be performed for unsigned integers if we know they
won't overflow in the optimization.

[Bug middle-end/112629] Missed-optimization: constant << (b + signed_constant)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-11-19
 Resolution|INVALID |---
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|RESOLVED|ASSIGNED

--- Comment #2 from Andrew Pinski  ---
Now if we know shift is known to be non-negative we should be able to this
optimization.

e.g.
```
int add_shift(signed shift) {
if (shift < 0)  __builtin_unreachable();
return 1 << (shift + 4);
}
int add_shift_1(signed shift) {
shift &= 0xff;
return 1 << (shift + 4);
}
```

Mine.

[Bug middle-end/112629] Missed-optimization: constant << (b + signed_constant)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
if shift was -4, then `16 << shift` would be undefined but `1 << (shift + 4)`
would be still defined.

[Bug middle-end/112629] New: Missed-optimization: constant << (b + signed_constant)

[goon.pri.low at gmail dot com via Gcc-bugs]

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

Bug ID: 112629
   Summary: Missed-optimization: constant << (b + signed_constant)
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: goon.pri.low at gmail dot com
  Target Milestone: ---

The following C code:

```
int add_shift(signed shift) {
return 1 << (shift + 4);
}

add_shift:
lea ecx, [rdi+4]
mov eax, 1
sal eax, cl
ret
```

Could be optimized to:

```
int optimized_shift(signed shift) {
return 16 << shift;
}

optimized_shift:
mov ecx, edi
mov eax, 16
sal eax, cl
ret
```

We always know we are shifting by at least 4, since the added value is a signed
integer and overflow is undefined. Also note that this optimization works the
same for right shifts.

[Bug c/112571] [13/14 Regression] ICE with nested redefinition of enum

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||12.3.0
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |13.3
 Ever confirmed|0   |1
Summary|ICE with nested |[13/14 Regression] ICE with
   |redefinition of enum|nested redefinition of enum
   Last reconfirmed||2023-11-19
  Known to fail||13.1.0

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

>but not on 13.2 with -std=c2x
Yes it does just hidden from the user really:
:3: confused by earlier errors, bailing out

is an ICE after an error with --enable-checking=release (which is the default
for release branches).

Anyways 12.x didn't ICE for the one in comment #1.

[Bug c++/112619] [14 regression] ICE when building libcrafter (tree check: expected statement_list, have modify_expr in tsi_start, at tree-iterator.h:57) since r14-5086-gae07265381d934

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-11-19
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
Confirmed, -std=c++98 is enough to reproduce the ICE.

Slightly more reduced:
```
struct st1 {
  st1();
  ~st1();
};
st1 MatchFilter(char n, char b)  {
  if (n || b) {
st1 ret_string;
return ret_string;
  }
  return st1();
}
```

[Bug c++/112619] [14 regression] ICE when building libcrafter (tree check: expected statement_list, have modify_expr in tsi_start, at tree-iterator.h:57) since r14-5086-gae07265381d934

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 CC||pinskia at gcc dot gnu.org

[Bug tree-optimization/112618] [13/14 Regression] internal compiler error: in expand_MASK_CALL, at internal-fn.cc:4529

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-11-19
Summary|internal compiler error: in |[13/14 Regression] internal
   |expand_MASK_CALL, at|compiler error: in
   |internal-fn.cc:4529 |expand_MASK_CALL, at
   ||internal-fn.cc:4529
 Status|UNCONFIRMED |NEW
  Known to work||12.1.0
   Target Milestone|--- |13.3

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

[Bug ipa/112616] [11/12/13/14 Regression] wrong code at -O{s, 2, 3} on x86_64-linux-gnu

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

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

--- Comment #2 from Andrew Pinski  ---
This is like PR 108007 but unlike that one, -fno-tree-dce is not used.

[Bug ipa/112616] [11/12/13/14 Regression] wrong code at -O{s, 2, 3} on x86_64-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-11-19
 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
  Component|tree-optimization   |ipa

--- Comment #1 from Andrew Pinski  ---
  # q_11 = PHI <0B(2), removed_return.14_14(D)(4), removed_return.14_14(D)(3)>
  _12 = *q_11;


WTF

[Bug tree-optimization/112616] [11/12/13/14 Regression] wrong code at -O{s,2,3} on x86_64-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
Summary|wrong code at -O{s,2,3} on  |[11/12/13/14 Regression]
   |x86_64-linux-gnu|wrong code at -O{s,2,3} on
   ||x86_64-linux-gnu
   Target Milestone|--- |11.5

[Bug c++/112620] Changes to the referenced object in exception handler are lost after rethrow

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Fedor Chelnokov from comment #0) 
> prints some not-null value in Clang and MSVC, which is correct according to
> https://eel.is/c++draft/except.handle#15

Clang had a hack added to workaround the Itanium C++ ABI deficiency but that
itself broke std::rethrow_exception .
Anyways this is recorded in PR 99858 (and the linked LLVM github issue).

[Bug c++/99858] Wrong throw-expression behaviour with reference to pointer

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||fchelnokov at gmail dot com

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

[Bug c++/112620] Changes to the referenced object in exception handler are lost after rethrow

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 99858.

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

[Bug tree-optimization/112628] `~a < -a` can be optimized to `a != 0` for unsigned types

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

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

--- Comment #2 from Andrew Pinski  ---
For signed, it is just true.

That is:
```
int f(int a)
{
  return (~a) < -a;
}
int f0(int a)
{
  return (a) > ~(-a);
}
```
Are the same.

In fact we can optimize even more:
```
int feq(int a)
{
  return (~a) == -a;
}
```
is always false for both signed and unsigned types.

So we just do `~a CMP -a` -> `(a - 1) CMP a` for all types.

Which is what we do for: `/* Fold ~X op ~Y as Y op X.  */`

So it is just
```
/* Fold ~X op -Y as (~(-Y)) op X. or `(Y-1) op X`  */
(for cmp (simple_comparison)
 (simplify
  (cmp:c (bit_not @0) (negative @1))
  (cmp (plus @1 { build_minus_one_cst (TREE_TYPE (@0)); }) @0)))
```

[Bug target/89316] ICE with -mforce-indirect-call and -fsplit-stack

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

  Attachment #56637|0   |1
is obsolete||

--- Comment #13 from Uroš Bizjak  ---
Created attachment 56647
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56647=edit
Proposed patch v2

New version, also fixes "-fsplit-stack -fpic -mforce-indirect-call" on 32-bit
targets.

[Bug target/110184] [x86] Missed optimisation: atomic operations should use PF, ZF and SF

[securesneakers at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Ivan Bodrov  ---
Created attachment 56646
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56646=edit
Fails to apply optimization for __atomic_fetch_and ZF-flag with separate
literals

[Bug target/110184] [x86] Missed optimisation: atomic operations should use PF, ZF and SF

[securesneakers at gmail dot com via Gcc-bugs]

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

Ivan Bodrov  changed:

   What|Removed |Added

 CC||securesneakers at gmail dot com

--- Comment #2 from Ivan Bodrov  ---
This seem to have been implemented, at least for __atomic_fetch_and, but the
optimization is very fragile and fails when "lock and" value and mask used
during checking come from separate literals:

$ cat fragile-fetch-and.c
void slowpath(unsigned long *p);
void func_bad(unsigned long *p)
{
if (__atomic_fetch_and(p, ~1UL, __ATOMIC_RELAXED) & ~1UL)
slowpath(p);
}
void func_good(unsigned long *p)
{
unsigned long mask = ~1UL;
if (__atomic_fetch_and(p, mask, __ATOMIC_RELAXED) & mask)
slowpath(p);
}

Compiling this we can see that even though functions are the same, the first
one wasn't optimized:

$ gcc --version
gcc (GCC) 13.2.1 20230801
Copyright (C) 2023 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.

$ uname -s -m
Linux x86_64
$ gcc -O2 -c fragile-fetch-and.c 
$ objdump -d fragile-fetch-and.o

fragile-fetch-and.o: file format elf64-x86-64


Disassembly of section .text:

 :
   0:   48 8b 07mov(%rdi),%rax
   3:   48 89 c1mov%rax,%rcx
   6:   48 89 c2mov%rax,%rdx
   9:   48 83 e1 fe and$0xfffe,%rcx
   d:   f0 48 0f b1 0f  lock cmpxchg %rcx,(%rdi)
  12:   75 ef   jne3 
  14:   48 83 fa 01 cmp$0x1,%rdx
  18:   77 06   ja 20 
  1a:   c3  ret
  1b:   0f 1f 44 00 00  nopl   0x0(%rax,%rax,1)
  20:   e9 00 00 00 00  jmp25 
  25:   66 66 2e 0f 1f 84 00data16 cs nopw 0x0(%rax,%rax,1)
  2c:   00 00 00 00 

0030 :
  30:   f0 48 83 27 fe  lock andq $0xfffe,(%rdi)
  35:   75 09   jne40 
  37:   c3  ret
  38:   0f 1f 84 00 00 00 00nopl   0x0(%rax,%rax,1)
  3f:   00 
  40:   e9 00 00 00 00  jmp45 

[Bug tree-optimization/112628] `~a < -a` can be optimized to `a != 0` for unsigned types

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-11-19
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org

--- Comment #1 from Andrew Pinski  ---
Note also we should be optimize this at the gimple level too:
```
unsigned f1(unsigned a, unsigned *c)
{
  return __builtin_add_overflow(a,-a,c);
}
```

into:
```
unsigned f1(unsigned a, unsigned *c)
{
  *c = 0;
  return a != 0;
}
```

Or the gimple level format:
```
  _1 = -a_4(D);
  _5 = .ADD_OVERFLOW (_1, a_4(D));
  _2 = REALPART_EXPR <_5>;
  *c_7(D) = _2;
  _3 = IMAGPART_EXPR <_5>;
```
Into:
```
_tmp = a != 0;
_5 = COMPLEX_EXPR<0, _tmp>;
...
```

Mine.

[Bug tree-optimization/112628] New: `~a < -a` can be optimized to `a != 0` for unsigned types

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

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

Bug ID: 112628
   Summary: `~a < -a` can be optimized to `a != 0` for unsigned
types
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization, TREE
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
unsigned fu(unsigned a)
{
  return (~a) < -a;
}
```

This can be optimized to just `a != 0` like it is on the RTL level due to
optizing to ADD_OVERFLOW which started in GCC 11.

[Bug target/112617] [14 regression] ICE when building systemd on HPPA (internal compiler error: in find_reloads, at reload.cc:3839)

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

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

John David Anglin  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-11-19
 Status|UNCONFIRMED |NEW

[Bug tree-optimization/112627] New: `(a + c) - b == c` is not optimized to `a == b`

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

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

Bug ID: 112627
   Summary: `(a + c) - b == c` is not optimized to `a == b`
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
int f(int a, int b, int c)
{
  return (a + c) - b == c;
}
int f1(int a, int b, int c)
{
  return (a + 1) - b == 1;
}
```

GCC can optimize f1 but not f. Note f1 is only optimized at the RTL level even.

[Bug c/83324] [feature request] Pragma or special syntax for guaranteed tail calls

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

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

--- Comment #8 from Sam James  ---
(In reply to David Edelsohn from comment #4)
> The lack of this feature is motivating CPython to rely on LLVM for its JIT
> in future releases.

Do you have something I can read up on for this part? It's the first I've heard
it.

[Bug c/83324] [feature request] Pragma or special syntax for guaranteed tail calls

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://github.com/llvm/llv
   ||m-project/issues/72555

--- Comment #7 from Andrew Pinski  ---
https://github.com/llvm/llvm-project/issues/72555

Hmmm

[Bug tree-optimization/112324] phiopt fail to recog if (b < 0) max = MAX(-b, max); else max = MAX (b, max) into max = MAX (ABS(b), max)

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Sam James from comment #6)
> Someone filed a bug for LLVM for x <= abs(x) being always true
> (https://github.com/llvm/llvm-project/issues/72653) and it looks like we're
> missing that too. Not sure if that's a dupe though.

Filed as PR 112626.

[Bug tree-optimization/112626] `ABS(a) CMP a` can be optimized

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-11-19
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

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

[Bug tree-optimization/112626] New: `ABS(a) CMP a` can be optimized

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

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

Bug ID: 112626
   Summary: `ABS(a) CMP a` can be optimized
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

This assumes, non-wrapping types, non-signed zero types
`abs(a) >= a` -> true
`abs(a) <  a` -> false
`abs(a) <= a` -> `a >= 0`
`abs(a) == a` -> `a >= 0`
`abs(a) != a` -> `a < 0`
`abs(a) >  a` -> `a < 0`


For wrapping types (non-signed zero types) or `((type)absu)`:
`abs(a) >= a` -> `a != TYPE_MIN`
`abs(a) <  a` -> `a == TYPE_MIN`
`abs(a) != a` -> `a <  0 & a != TYPE_MIN`
`abs(a) >  a` -> `a <  0 & a != TYPE_MIN`
`abs(a) == a` -> `a >= 0 | a == TYPE_MIN`
`abs(a) <= a` -> `a >= 0 | a == TYPE_MIN`

[Bug middle-end/112619] [14 regression] ICE when building libcrafter (tree check: expected statement_list, have modify_expr in tsi_start, at tree-iterator.h:57)

[kocelfc at tutanota dot com via Gcc-bugs]

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

Kostadin Shishmanov  changed:

   What|Removed |Added

 CC||jason at redhat dot com

--- Comment #2 from Kostadin Shishmanov  ---
Bisected to r14-5086-gae07265381d934

[Bug fortran/112625] New: Segmentation fault in getter function of unlimited polymorphic object in nested container / wrapper object

[michail.stamatakis at chem dot ox.ac.uk via Gcc-bugs]

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

Bug ID: 112625
   Summary: Segmentation fault in getter function of unlimited
polymorphic object in nested container / wrapper
object
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michail.stamatakis at chem dot ox.ac.uk
  Target Milestone: ---

Created attachment 56645
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56645=edit
Code demonstrating the seg-fault

The attached code demonstrates the problem. I have seen segmentation faults in
GNU Fortran 13.1.0 and 13.2.0, but not in 12.3.0 or earlier versions. The
output of the attached code for the latter two versions is shown below. Note
how the getter function in tvalcont_mod seems to be executed twice in GNU
Fortran 13.2.0, which also does not seem correct.

$ ~/dev/gcc/12.3.0/bin/gfortran -Wall -Wextra -fsanitize=undefined test.f90
$ ./a.out 
 tvalcont_mod::Getting value
 tvalcont_mod::Got value! T
 element type is val
   3.
 tvalcontcont_mod::Getting value
 tvalcont_mod::Getting value
 tvalcont_mod::Got value! T
 tvalcontcont_mod::Got value! T
 element type is val
   3.
$ ~/dev/gcc/13.2.0/bin/gfortran -Wall -Wextra -fsanitize=undefined test.f90
$ ./a.out 
 tvalcont_mod::Getting value
 tvalcont_mod::Got value! T
 element type is val
   3.
 tvalcontcont_mod::Getting value
 tvalcont_mod::Getting value
 tvalcont_mod::Got value! T
 tvalcont_mod::Getting value
 tvalcont_mod::Got value! T

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7f47caffd960 in ???
#1  0x7f47caffcac5 in ???
#2  0x7f47ca6b851f in ???
at ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
#3  0x7f47ca73aaa2 in ???
at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:513
#4  0x402443 in ???
#5  0x4044c9 in ???
#6  0x404a98 in ???
#7  0x404cfd in ???
#8  0x7f47ca69fd8f in __libc_start_call_main
at ../sysdeps/nptl/libc_start_call_main.h:58
#9  0x7f47ca69fe3f in __libc_start_main_impl
at ../csu/libc-start.c:392
#10  0x401184 in ???
#11  0x in ???
Segmentation fault (core dumped)
$

[Bug c++/112624] New: Internal compiler error when compiling a module

[amaikinono at gmail dot com via Gcc-bugs]

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

Bug ID: 112624
   Summary: Internal compiler error when compiling a module
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amaikinono at gmail dot com
  Target Milestone: ---

Created attachment 56644
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56644=edit
Preprocessed file.

Sorry for the vague title as I am still new to C++ and don't have better
understanding of the bug.

Here are the source files:

```
// mod.cxx
module;
#include 
export module mod;

export class Example
{
public:
  const std::string& display() const;
};
```

```
// mod_impl.cpp
#include 
#include 

const std::string& display()
{
  return std::format("hi {}", 1);
}
```

Compile it:

```
$ g++ -std=c++20 -fmodules-ts -c mod.cxx
[kino@kino-pc /yard/new-box/works/code-snippets/2023-professional-cpp/gcc-bug]
$ g++ -std=c++20 -fmodules-ts -c mod.o mod_impl.cpp
mod_impl.cpp: In function ‘const std::string& display()’:
mod_impl.cpp:6:21: warning: returning reference to temporary
[]8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wreturn-local-addr-Wreturn-local-addr]8;;]
6 |   return std::format("hi {}", 1);
  |  ~~~^~~~
In file included from /usr/include/c++/13.2.1/bits/locale_classes.h:869,
 from /usr/include/c++/13.2.1/locale:41,
 from /usr/include/c++/13.2.1/format:42,
of module /usr/include/c++/13.2.1/format, imported at mod_impl.cpp:1:
/usr/include/c++/13.2.1/bits/locale_classes.tcc: In instantiation of ‘const
_Facet& std::use_face
(const locale&) [with _Facet = ctype]’:
/usr/include/c++/13.2.1/format:2135:45:   required from ‘typename
std::basic_format_context<_Out, _CharT>::iterator std::formatter::format(const void*, std::basic_format_context<_Out, _CharT>&) const
[with _Out = std::__format::_Sink_iter; _CharT = wchar_t; typename
std::basic_format_context<_Out, _CharT>::iterator =
std::basic_format_context,
wchar_t>::iterator]’
/usr/include/c++/13.2.1/format:3581:41:   required from
‘std::__format::_Formatting_scanner,
wchar_t>::_M_format_arg(std::size_t):: [with auto:31 = const
void*]’
/usr/include/c++/13.2.1/format:3084:44:   required from ‘decltype(auto)
std::basic_format_arg<_Context>::_M_visit(_Visitor&&, std::__format::_Arg_t)
[with _Visitor =
std::__format::_Formatting_scanner,
wchar_t>::_M_format_arg(std::size_t)::; _Context =
std::basic_format_context, wchar_t>]’
/usr/include/c++/13.2.1/format:3111:28:   required from ‘decltype(auto)
std::visit_format_arg(_Visitor&&, basic_format_arg<_Context>) [with _Visitor =
__format::_Formatting_scanner<__format::_Sink_iter,
wchar_t>::_M_format_arg(std::size_t)::; _Context =
basic_format_context<__format::_Sink_iter, wchar_t>]’
/usr/include/c++/13.2.1/format:3570:23:   required from ‘constexpr void
std::__format::_Formatting_scanner<_Out, _CharT>::_M_format_arg(std::size_t)
[with _Out = std::__format::_Sink_iter; _CharT = wchar_t; std::size_t
= long unsigned int]’
/usr/include/c++/13.2.1/format:3565:7:   required from here
/usr/include/c++/13.2.1/bits/locale_classes.tcc:200:60: internal compiler
error: in tsubst_copy, at cp/pt.cc:17292
  200 |   if (const _Facet* __f = std::__try_use_facet<_Facet>(__loc))
  |^
0x1ad33c8 internal_error(char const*, ...)
???:0
0x6b7b63 fancy_abort(char const*, int, char const*)
???:0
0x85da9c tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*)
???:0
0x85df90 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*)
???:0
0x85e183 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*)
???:0
0x85663d instantiate_decl(tree_node*, bool, bool)
???:0
0x87ad63 instantiate_pending_templates(int)
???:0
0x7714d6 c_parse_final_cleanups()
???:0
0x9444b4 c_common_parse_file()
???: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.
```

Outputs of `gcc -v`:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.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,objc,obj-c++ --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--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 

[Bug tree-optimization/112324] phiopt fail to recog if (b < 0) max = MAX(-b, max); else max = MAX (b, max) into max = MAX (ABS(b), max)

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Sam James from comment #6)
> Someone filed a bug for LLVM for x <= abs(x) being always true
> (https://github.com/llvm/llvm-project/issues/72653) and it looks like we're
> missing that too. Not sure if that's a dupe though.

Yes and there is no dup filed so far. Let me file about them.

[Bug target/112623] New: [14 Regression] ICE: in emit_move_insn, at expr.cc:4249 with -O -mavx512vl -mavx512fp16 on vector conversion

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 112623
   Summary: [14 Regression] ICE: in emit_move_insn, at
expr.cc:4249 with -O -mavx512vl -mavx512fp16 on vector
conversion
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -mavx512vl -mavx512fp16 testcase.c 
during RTL pass: expand
testcase.c: In function 'foo':
testcase.c:7:10: internal compiler error: in emit_move_insn, at expr.cc:4249
7 |   return __builtin_convertvector (f, BF);
  |  ^~~
0x7583d8 emit_move_insn(rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/expr.cc:4249
0xf591f9 expand_value_return
/repo/gcc-trunk/gcc/cfgexpand.cc:3739
0xf63364 expand_return
/repo/gcc-trunk/gcc/cfgexpand.cc:3811
0xf63364 expand_gimple_stmt_1
/repo/gcc-trunk/gcc/cfgexpand.cc:3918
0xf63364 expand_gimple_stmt
/repo/gcc-trunk/gcc/cfgexpand.cc:4044
0xf694ae expand_gimple_basic_block
/repo/gcc-trunk/gcc/cfgexpand.cc:6100
0xf6b187 execute
/repo/gcc-trunk/gcc/cfgexpand.cc:6835
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

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

[Bug c/112622] [14 Regression] ICE: tree check: expected none of vector_type, have vector_type in convert_to_real_1, at convert.cc:295 with invalid cast

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug c/112622] New: [14 Regression] ICE: tree check: expected none of vector_type, have vector_type in convert_to_real_1, at convert.cc:295 with invalid cast

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 112622
   Summary: [14 Regression] ICE: tree check: expected none of
vector_type, have vector_type in convert_to_real_1, at
convert.cc:295 with invalid cast
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc testcase.c 
testcase.c:3:1: internal compiler error: tree check: expected none of
vector_type, have vector_type in convert_to_real_1, at convert.cc:295
3 | V v = (float)-v;
  | ^
0x8825f8 tree_not_check_failed(tree_node const*, char const*, int, char const*,
...)
/repo/gcc-trunk/gcc/tree.cc:8989
0x72f82a tree_not_check(tree_node*, char const*, int, char const*, tree_code)
/repo/gcc-trunk/gcc/tree.h:3611
0x72f82a convert_to_real_1
/repo/gcc-trunk/gcc/convert.cc:295
0xe2a8fc c_convert
/repo/gcc-trunk/gcc/c/c-convert.cc:175
0xe13c8b build_c_cast(unsigned int, tree_node*, tree_node*)
/repo/gcc-trunk/gcc/c/c-typeck.cc:6098
0xe14c82 c_cast_expr(unsigned int, c_type_name*, tree_node*)
/repo/gcc-trunk/gcc/c/c-typeck.cc:6172
0xe3d624 c_parser_cast_expression
/repo/gcc-trunk/gcc/c/c-parser.cc:9677
0xe3d7af c_parser_binary_expression
/repo/gcc-trunk/gcc/c/c-parser.cc:9454
0xe3ec1b c_parser_conditional_expression
/repo/gcc-trunk/gcc/c/c-parser.cc:9152
0xe3f3e4 c_parser_expr_no_commas
/repo/gcc-trunk/gcc/c/c-parser.cc:9066
0xe4636c c_parser_initializer
/repo/gcc-trunk/gcc/c/c-parser.cc:6099
0xe4636c c_parser_initializer
/repo/gcc-trunk/gcc/c/c-parser.cc:6091
0xe5f0cb c_parser_declaration_or_fndef
/repo/gcc-trunk/gcc/c/c-parser.cc:2727
0xe69a6b c_parser_external_declaration
/repo/gcc-trunk/gcc/c/c-parser.cc:2046
0xe6a453 c_parser_translation_unit
/repo/gcc-trunk/gcc/c/c-parser.cc:1900
0xe6a453 c_parse_file()
/repo/gcc-trunk/gcc/c/c-parser.cc:26392
0xedc5c1 c_common_parse_file()
/repo/gcc-trunk/gcc/c-family/c-opts.cc:1295
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

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

[Bug tree-optimization/112324] phiopt fail to recog if (b < 0) max = MAX(-b, max); else max = MAX (b, max) into max = MAX (ABS(b), max)

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #6 from Sam James  ---
Someone filed a bug for LLVM for x <= abs(x) being always true
(https://github.com/llvm/llvm-project/issues/72653) and it looks like we're
missing that too. Not sure if that's a dupe though.

[Bug c++/112621] New: g++ error: "references internal linkage entity" when compiling a module interface

[amaikinono at gmail dot com via Gcc-bugs]

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

Bug ID: 112621
   Summary: g++ error: "references internal linkage entity" when
compiling a module interface
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amaikinono at gmail dot com
  Target Milestone: ---

Created attachment 56641
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56641=edit
Preprocessed files.

Here's a minimal example:

```
// class.cxx
export module mod;

const int default_val { 0 };

export class Example
{
  // This line causes the problem.
  int value { default_val };
};
```

Compile it:

```
$ g++ -c -std=c++20 -fmodules-ts class.cxx
class.cxx:5:14: error: ‘class Example’ references internal linkage entity
‘const int default_val’
5 | export class Example
  |  ^~~
class.cxx:1:8: error: failed to write compiled module: Bad file data
1 | export module mod;
  |^~
class.cxx:1:8: note: compiled module file is ‘gcm.cache/mod.gcm’
```

If we don't use `default_val` in the class:

```
export module mod;

const int default_val { 0 };

export class Example
{
  int value { 0 };
};
```

or if the file is not a module interface:

```
const int default_val { 0 };

class Example
{
  int value { default_val };
};
```

Then it compiles.

I've also reported this at
.

Outputs of `gcc -v`:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.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,objc,obj-c++ --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--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 13.2.1 20230801 (GCC)

[Bug c++/112620] New: Changes to the referenced object in exception handler are lost after rethrow

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 112620
   Summary: Changes to the referenced object in exception handler
are lost after rethrow
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

This program

#include 

int main() {
int i;
try {
try {
throw (int*)0;
} catch (int*& p) {
p = 
throw;
}
}
catch (int*& p) {
printf("%p", (void*)p);
}
}

prints some not-null value in Clang and MSVC, which is correct according to
https://eel.is/c++draft/except.handle#15

> When the handler declares a reference to an object, any changes to the 
> referenced object are changes to the exception object and will have effect 
> should that object be rethrown.

But GCC prints (nil) here. Online demo: https://godbolt.org/z/n6s6bc17s

[Bug libstdc++/110287] _M_check_len is expensive

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

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

--- Comment #9 from Jan Hubicka  ---
This is _M_realloc insert at release_ssa time:

eleased 63 names, 165.79%, removed 63 holes
void std::vector::_M_realloc_insert (struct vector *
const this, struct iterator __position, const struct pair_t & __args#0)
{ 
  struct pair_t * const __position;
  struct pair_t * __new_finish;
  struct pair_t * __old_finish;
  struct pair_t * __old_start;
  long unsigned int _1; 
  struct pair_t * _2;
  struct pair_t * _3;
  long int _4;
  long unsigned int _5;
  struct pair_t * _6;
  const size_type _10;
  long int _13;
  struct pair_t * iftmp.5_15;
  struct pair_t * _17; 
  struct _Vector_impl * _18;
  long unsigned int _22;
  long int _23;
  long unsigned int _24;
  long unsigned int _25;
  struct pair_t * _26;
  long unsigned int _36;

   [local count: 1073741824]:
  __position_27 = MEM[(struct __normal_iterator *)&__position];
  _10 = std::vector::_M_check_len (this_8(D), 1,
"vector::_M_realloc_insert");
  __old_start_11 = this_8(D)->D.25975._M_impl.D.25282._M_start;
  __old_finish_12 = this_8(D)->D.25975._M_impl.D.25282._M_finish;
  _13 = __position_27 - __old_start_11;
  if (_10 != 0)
goto ; [54.67%]
  else
goto ; [45.33%]

   [local count: 587014656]:
  _18 = [(struct _Vector_base *)this_8(D)]._M_impl;
  _17 = std::__new_allocator::allocate (_18, _10, 0B);

   [local count: 1073741824]:
  # iftmp.5_15 = PHI <0B(2), _17(3)>
  _1 = (long unsigned int) _13;
  _2 = iftmp.5_15 + _1;
  *_2 = *__args#0_14(D);
  if (_13 > 0)
goto ; [41.48%]
  else
goto ; [58.52%]

   [local count: 445388112]:
  __builtin_memmove (iftmp.5_15, __old_start_11, _1);

   [local count: 1073741824]:
  _36 = _1 + 8;
  __new_finish_16 = iftmp.5_15 + _36;
  _23 = __old_finish_12 - __position_27;
  if (_23 > 0)
goto ; [41.48%]
  else
goto ; [58.52%]

   [local count: 445388112]:
  _24 = (long unsigned int) _23;
  __builtin_memcpy (__new_finish_16, __position_27, _24);

   [local count: 1073741824]:
  _25 = (long unsigned int) _23;
  _26 = __new_finish_16 + _25;
  _3 = this_8(D)->D.25975._M_impl.D.25282._M_end_of_storage;
  _4 = _3 - __old_start_11;
  if (__old_start_11 != 0B)
goto ; [53.47%]
  else
goto ; [46.53%]

   [local count: 574129752]:
  _22 = (long unsigned int) _4;
  operator delete (__old_start_11, _22);

   [local count: 1073741824]:
  this_8(D)->D.25975._M_impl.D.25282._M_start = iftmp.5_15;
  this_8(D)->D.25975._M_impl.D.25282._M_finish = _26;
  _5 = _10 * 8;
  _6 = iftmp.5_15 + _5;
  this_8(D)->D.25975._M_impl.D.25282._M_end_of_storage = _6;
  return;

}

First it is not clear to me why we need memmove at all?

So first issue is:
   [local count: 1073741824]:
  __position_27 = MEM[(struct __normal_iterator *)&__position];
  _10 = std::vector::_M_check_len (this_8(D), 1,
"vector::_M_realloc_insert");
  __old_start_11 = this_8(D)->D.25975._M_impl.D.25282._M_start;
  __old_finish_12 = this_8(D)->D.25975._M_impl.D.25282._M_finish;
  _13 = __position_27 - __old_start_11;
  if (_10 != 0)
goto ; [54.67%]
  else
goto ; [45.33%]

Without inlining _M_check_len early we can not work out return value range,
since we need to know that paramter 2 is 1 and not 0.
Adding __builtin_unreachable check after helps to reduce

if (_10 != 0)

but I need to do something about inliner accounting the conditional to function
body size.

   [local count: 1073741824]:
  # iftmp.5_15 = PHI <0B(2), _17(3)>
  _1 = (long unsigned int) _13;
  _2 = iftmp.5_15 + _1;
  *_2 = *__args#0_14(D);
  if (_13 > 0)
goto ; [41.48%]
  else
goto ; [58.52%]

   [local count: 445388112]:
  __builtin_memmove (iftmp.5_15, __old_start_11, _1);

Is this code about inserting value to the middle?  Since push_back always
initializes iterator to point to the end, this seems quite sily to do.
Can't we do somehting like _M_realloc_append?

[Bug middle-end/109849] suboptimal code for vector walking loop

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

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

--- Comment #21 from Jan Hubicka  ---
Patch
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637265.html
gets us closer to inlining _M_realloc_insert at -O3 (3 insns away)

Patch
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636935.html
reduces the expense when _M_realloc_insert is not inlined at -O2 (where I think
we should not inline it, unlike for clang)

[Bug libstdc++/110287] _M_check_len is expensive

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

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

--- Comment #8 from Jan Hubicka  ---
With return value range propagation
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637265.html
reduces --param max-inline-insns-auto needed for _M_realloc_insert to be
inlined on my testcase from 39 to 35.

This is done by eliminating two unnecesary trow calls by propagating fact that
check_len does not return incredibly large values.

Default inline limit at -O3 is 30, so we are not that far and I think we really
ought to solve this for next release since push_back is such a common case.

Is it known that check_len can not return 0 in this situation? Adding 
if (ret <= 0)
  __builtin_unreachable
saves another 2 instructions because _M_realloc_insert otherwise contain a code
path for case that vector gets increased to 0 elements.

[Bug middle-end/112619] [14 regression] ICE when building libcrafter (tree check: expected statement_list, have modify_expr in tsi_start, at tree-iterator.h:57)

[kocelfc at tutanota dot com via Gcc-bugs]

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

Kostadin Shishmanov  changed:

   What|Removed |Added

 CC||kocelfc at tutanota dot com

--- Comment #1 from Kostadin Shishmanov  ---
reduction:


struct basic_string {
  basic_string(const char *);
  ~basic_string();
};
char InformationRequest, AddressMaskRequest;
struct ICMP {
  basic_string MatchFilter() const;
};
basic_string ICMP::MatchFilter() const {
  if (InformationRequest || AddressMaskRequest) {
basic_string ret_string = "";
return ret_string;
  }
  return "";
}

[Bug middle-end/112619] New: [14 regression] ICE when building libcrafter (tree check: expected statement_list, have modify_expr in tsi_start, at tree-iterator.h:57)

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

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

Bug ID: 112619
   Summary: [14 regression] ICE when building libcrafter (tree
check: expected statement_list, have modify_expr in
tsi_start, at tree-iterator.h:57)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 56640
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56640=edit
ICMPCraft.ii

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

```
libtool: compile:  x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I.
-I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -ansi -pedantic -Wall -O2
-march=native -pipe -fcf-protection=none -fdiagnostics-color=always
-fdiagnostics-urls=never -frecord-gcc-switches -ggdb3 -c
crafter/Protocols/ICMPCraft.cpp  -fPIC -DPIC -o
crafter/Protocols/.libs/ICMPCraft.o
In file included from crafter/Protocols/ICMP.h:30,
 from crafter/Protocols/ICMPCraft.cpp:34:
crafter/Protocols/../Layer.h:246:32: warning: 'virtual Crafter::Layer&
Crafter::Layer::operator=(const Crafter::Layer&)' was hidden
[-Woverloaded-virtual=]
  246 | virtual Layer& operator=(const Layer& right);
  |^~~~
In file included from crafter/Protocols/ICMP.h:31:
crafter/Protocols/ICMPLayer.h:15:15: note:   by 'Crafter::ICMPLayer&
Crafter::ICMPLayer::operator=(const Crafter::ICMPLayer&)'
   15 | class ICMPLayer: public Layer {
  |   ^
crafter/Protocols/../Layer.h:246:32: warning: 'virtual Crafter::Layer&
Crafter::Layer::operator=(const Crafter::Layer&)' was hidden
[-Woverloaded-virtual=]
  246 | virtual Layer& operator=(const Layer& right);
  |^~~~
crafter/Protocols/ICMP.h:35:11: note:   by 'Crafter::ICMP&
Crafter::ICMP::operator=(const Crafter::ICMP&)'
   35 | class ICMP: public ICMPLayer {
  |   ^~~~
crafter/Protocols/ICMPCraft.cpp: In member function 'virtual std::string
Crafter::ICMP::MatchFilter() const':
crafter/Protocols/ICMPCraft.cpp:196:9: internal compiler error: tree check:
expected statement_list, have modify_expr in tsi_start, at tree-iterator.h:57
  196 | if ( type == EchoRequest || type == TimeStampRequest ||
  | ^~
0x55b58f7d2432 tree_check_failed(tree_node const*, char const*, int, char
const*, ...)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree.cc:8952
0x55b58e6c2423 tree_check(tree_node*, char const*, int, char const*, tree_code)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree.h:3602
0x55b58e6c2423 tsi_start(tree_node*)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-iterator.h:57
0x55b58ea0a100 try_catch_may_fallthru
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree.cc:12576
0x55b58ea0a100 block_may_fallthru(tree_node const*)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree.cc:12649
0x55b59092bac0 block_may_fallthru(tree_node const*)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree.cc:12659
0x55b59092b20a shortcut_cond_expr
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/gimplify.cc:4412
0x55b59090c794 gimplify_cond_expr
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/gimplify.cc:4691
0x55b5900af22a gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/gimplify.cc:16672
0x55b5900ad2f0 gimplify_stmt(tree_node**, gimple**)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/gimplify.cc:7472
0x55b5908f2131 gimplify_bind_expr
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/gimplify.cc:1614
0x55b5900af3aa gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/gimplify.cc:16916
0x55b5900af2b9 gimplify_stmt(tree_node**, gimple**)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/gimplify.cc:7472
0x55b5900af2b9 gimplify_statement_list
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/gimplify.cc:
0x55b5900af2b9 gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/gimplify.cc:17160
0x55b5900ad2f0 gimplify_stmt(tree_node**, gimple**)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/gimplify.cc:7472
0x55b5900aec7a gimplify_and_add(tree_node*, gimple**)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/gimplify.cc:493
0x55b5900aec7a 

[Bug tree-optimization/112618] New: internal compiler error: in expand_MASK_CALL, at internal-fn.cc:4529

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

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

Bug ID: 112618
   Summary: internal compiler error: in expand_MASK_CALL, at
internal-fn.cc:4529
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

jh@ryzen4:~/gcc/build4/stage1-gcc> cat b.c
/* PR tree-optimization/106433 */

int m, *p;

__attribute__ ((simd)) int
bar (int x)
{
  if (x)
{
  if (m < 1)
for (m = 0; m < 1; ++m)
  ++x;
  p = 
  for (;;)
++m;
}
  return 0;
}

__attribute__ ((simd)) int
foo (int x)
{
 bar (x);
 return 0;
}
jh@ryzen4:~/gcc/build4/stage1-gcc> ./xgcc -B ./ -O2 b.c -fno-tree-vrp
during RTL pass: expand
b.c: In function ‘foo.simdclone.3’:
b.c:23:2: internal compiler error: in expand_MASK_CALL, at internal-fn.cc:5013
   23 |  bar (x);
  |  ^~~
0x12db307 expand_MASK_CALL(internal_fn, gcall*)
../../gcc/internal-fn.cc:5013
0x12daa47 expand_internal_call(internal_fn, gcall*)
../../gcc/internal-fn.cc:4920
0x12daa72 expand_internal_call(gcall*)
../../gcc/internal-fn.cc:4928
0xf7637e expand_call_stmt
../../gcc/cfgexpand.cc:2737
0xf7a5a8 expand_gimple_stmt_1
../../gcc/cfgexpand.cc:3880
0xf7ac2c expand_gimple_stmt
../../gcc/cfgexpand.cc:4044
0xf82d6f expand_gimple_basic_block
../../gcc/cfgexpand.cc:6100
0xf85322 execute
../../gcc/cfgexpand.cc:6835
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 target/112617] [14 regression] ICE when building systemd on HPPA (internal compiler error: in find_reloads, at reload.cc:3839)

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

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

--- Comment #3 from Sam James  ---
Created attachment 56639
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56639=edit
reduced.i

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

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

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

--- Comment #27 from Sam James  ---
(In reply to Andrew Pinski from comment #18)
> This fixes the issue for me:
> ```
> diff --git a/gcc/compare-elim.cc b/gcc/compare-elim.cc
> [...]

This solves both pipewire (unreported, was working on reducing it; found it
needed -fstack-protector-strong and I think PIE) and LLVM failures. Thank you
Andrew & thanks Sergei for looking at it too.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112613#c3 is an interesting
comment wrt checking. Is that feasible?

It would be nice if this was catchable with --enable-checking=rtl or
--enable-checking=df (I don't test with this regularly, but it would've been
helpful after seeing the bisect result), especially given there's some clear
(possible) misuse.

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

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

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #26 from Eric Botcazou  ---
> Eric B. mentioned back in 2011, neither REG_DEAD nor REG_UNUSED needs to be
> kept up to date:
> https://gcc.gnu.org/pipermail/gcc-patches/2011-October/326733.html
> Also see PR 48773 where he mentioned the same.
> He mentioned the same thing again in 2018 even:
> https://gcc.gnu.org/pipermail/gcc-patches/2018-October/508057.html

REG_DEAD and REG_UNUSED notes are recomputed by DF so they do not need to be
maintained explicitly (although you may do it of course).  REG_EQUAL and
REG_EQUIV notes are not recomputed by DF so they need to maintained explicitly.

[Bug target/112617] [14 regression] ICE when building systemd on HPPA (internal compiler error: in find_reloads, at reload.cc:3839)

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

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

--- Comment #2 from Sam James  ---
Reducing now. I won't bisect it proactively unless someone asks, given I assume
it's r14-5538-gd2934eb6ae92471484469d8ddd039eb34ef400b1.

[Bug target/112617] [14 regression] ICE when building systemd on HPPA (internal compiler error: in find_reloads, at reload.cc:3839)

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

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

--- Comment #1 from Sam James  ---
'gcc -c btrfs-util.c.i -O1 -fno-omit-frame-pointer' is enough for me to hit it.

[Bug target/112617] New: [14 regression] ICE when building systemd on HPPA (internal compiler error: in find_reloads, at reload.cc:3839)

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

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

Bug ID: 112617
   Summary: [14 regression] ICE when building systemd on HPPA
(internal compiler error: in find_reloads, at
reload.cc:3839)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: danglin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 56638
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56638=edit
btrfs-util.c.i

```
FAILED: src/shared/libsystemd-shared-254.a.p/btrfs-util.c.o
hppa2.0-unknown-linux-gnu-gcc -Isrc/shared/libsystemd-shared-254.a.p
-Isrc/shared -I../systemd-stable-254.6/src/shared -Isrc/basic
-I../systemd-stable-254.6/src/basic -Isrc/fundamental
-I../systemd-stable-254.6/src/fundamental -Isrc/systemd
-I../systemd-stable-254.6/src/systemd -I. -I../systemd-stable-254.6
-I../systemd-stable-254.6/src/libsystemd/sd-bus
-I../systemd-stable-254.6/src/libsystemd/sd-device
-I../systemd-stable-254.6/src/libsystemd/sd-event
-I../systemd-stable-254.6/src/libsystemd/sd-hwdb
-I../systemd-stable-254.6/src/libsystemd/sd-id128
-I../systemd-stable-254.6/src/libsystemd/sd-journal
-I../systemd-stable-254.6/src/libsystemd/sd-netlink
-I../systemd-stable-254.6/src/libsystemd/sd-network
-I../systemd-stable-254.6/src/libsystemd/sd-resolve -I/usr/include/blkid
-I/usr/include/libmount -I/usr/include/security -fdiagnostics-color=always
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -std=gnu11
-Wno-missing-field-initializers -Wno-unused-parameter -Warray-bounds
-Warray-bounds=2 -Wdate-time -Wendif-labels -Werror=format=2
-Werror=format-signedness -Werror=implicit-function-declaration
-Werror=implicit-int -Werror=incompatible-pointer-types -Werror=int-conversion
-Werror=missing-declarations -Werror=missing-prototy
pes -Werror=overflow -Werror=override-init -Werror=return-type
-Werror=shift-count-overflow -Werror=shift-overflow=2
-Werror=strict-flex-arrays -Werror=undef -Wfloat-equal -Wimplicit-fallthrough=5
-Winit-self -Wlogical-op -Wmissing-include-dirs -Wmissing-noreturn
-Wnested-externs -Wold-style-definition -Wpointer-arith -Wredundant-decls
-Wshadow -Wstrict-aliasing=2 -Wstrict-prototypes -Wsuggest-attribute=noreturn
-Wunused-function -Wwrite-strings -Wzero-length-bounds
-fdiagnostics-show-option -fno-common -fstack-protector
-fstack-protector-strong -fstrict-flex-arrays --param=ssp-buffer-size=4
-Wno-maybe-uninitialized -Wno-unused-result -Werror=shadow -O2 -pipe -march=2.0
-fdiagnostics-color=always -frecord-gcc-switches -fPIC -fno-strict-aliasing
-fstrict-flex-arrays=1 -fvisibility=hidden -ffunction-sections -fdata-sections
-fno-omit-frame-pointer -include config.h -pthread -fvisibility=default -MD -MQ
src/shared/libsystemd-shared-254.a.p/btrfs-util.c.o -MF
src/shared/libsystemd-shared-254.a.p/btrfs-util.c.o.d -o
src/shared/libsystemd-shared-254.a.p/btrfs-util.c.o -c
../systemd-stable-254.6/src/shared/btrfs-util.c
../systemd-stable-254.6/src/shared/btrfs-util.c: In function
‘subvol_snapshot_children’:
../systemd-stable-254.6/src/shared/btrfs-util.c:1526:1: error: unable to
generate reloads for:
 1526 | }
  | ^
(jump_insn 593 1256 594 59 (parallel [
(set (pc)
(if_then_else (ge (reg:SI 28 %r28 [649])
(const_int 0 [0]))
(label_ref 601)
(pc)))
(set (reg/v:SI 148 [ old_child_fd ])
(reg:SI 28 %r28 [649]))
]) "../systemd-stable-254.6/src/shared/btrfs-util.c":1460:28 234
{*pa.md:9555}
 (expr_list:REG_DEAD (reg:SI 28 %r28 [649])
(int_list:REG_BR_PROB 1052266988 (nil)))
 -> 601)
during RTL pass: reload
../systemd-stable-254.6/src/shared/btrfs-util.c:1526:1: internal compiler
error: in find_reloads, at reload.cc:3839
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
```

```
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/hppa2.0-unknown-linux-gnu/14/lto-wrapper
Target: hppa2.0-unknown-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-14.0.0./work/gcc-14.0.0./configure
--host=hppa2.0-unknown-linux-gnu --build=hppa2.0-unknown-linux-gnu
--prefix=/usr --bindir=/usr/hppa2.0-unknown-linux-gnu/gcc-bin/14
--includedir=/usr/lib/gcc/hppa2.0-unknown-linux-gnu/14/include
--datadir=/usr/share/gcc-data/hppa2.0-unknown-linux-gnu/14
--mandir=/usr/share/gcc-data/hppa2.0-unknown-linux-gnu/14/man
--infodir=/usr/share/gcc-data/hppa2.0-unknown-linux-gnu/14/info
--with-gxx-include-dir=/usr/lib/gcc/hppa2.0-unknown-linux-gnu/14/include/g++-v14
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/hppa2.0-unknown-linux-gnu/14/python
--enable-languages=c,c++,fortran --enable-obsolete 

[Bug rtl-optimization/111554] [12/13/14 regression] Timeout with with "-O3 -fno-dse -fno-inline -fno-store-merging -fno-toplevel-reorder -fno-tree-dce -fno-tree-dse" since r12-2097-g9f34b780b0461e

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

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

Maxim Kuvyrkov  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #10 from Maxim Kuvyrkov  ---
This is, mostly, a dup of PR96388.
With the problem in PR96388 fixed, I'm seeing strange -ftime-report reporting
that [wrongly?] attributes a lot of time to alias analysis.