[Bug tree-optimization/109639] [14 regression] Internal compiler error: tree check: expected integer_cst, have addr_expr in to_wide, at tree.h:6283 since r14-249-g3c9372dfee0bb8

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

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

Sam James  changed:

   What|Removed |Added

Summary|[14 regression] Internal|[14 regression] Internal
   |compiler error: tree check: |compiler error: tree check:
   |expected integer_cst, have  |expected integer_cst, have
   |addr_expr in to_wide, at|addr_expr in to_wide, at
   |tree.h:6283 |tree.h:6283 since
   ||r14-249-g3c9372dfee0bb8
   Keywords|needs-bisection,|
   |needs-reduction |
 CC||aldyh at gcc dot gnu.org

--- Comment #7 from Sam James  ---
3c9372dfee0bb893b99dd28658c98d397cda5b49 is the first bad commit
commit 3c9372dfee0bb893b99dd28658c98d397cda5b49
Author: Aldy Hernandez 
Date:   Mon Nov 21 00:54:21 2022 +0100

Remove deprecated range_fold_{unary,binary}_expr uses from ipa-*.

gcc/ChangeLog:

* ipa-cp.cc (ipa_vr_operation_and_type_effects): Convert to ranger
API.
(ipa_value_range_from_jfunc): Same.
(propagate_vr_across_jump_function): Same.
* ipa-fnsummary.cc (evaluate_conditions_for_known_args): Same.
* ipa-prop.cc (ipa_compute_jump_functions_for_edge): Same.
* vr-values.cc (bounds_of_var_in_loop): Same.

 gcc/ipa-cp.cc| 28 ++--
 gcc/ipa-fnsummary.cc | 45 +
 gcc/ipa-prop.cc  |  5 ++---
 gcc/vr-values.cc |  6 --
 4 files changed, 57 insertions(+), 27 deletions(-)
bisect found first bad commit

i.e. r14-249-g3c9372dfee0bb8

[Bug tree-optimization/109639] [14 regression] Internal compiler error: tree check: expected integer_cst, have addr_expr in to_wide, at tree.h:6283

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

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

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

[Bug tree-optimization/109639] [14 regression] Internal compiler error: tree check: expected integer_cst, have addr_expr in to_wide, at tree.h:6283

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

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

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

[Bug tree-optimization/109639] [14 regression] Internal compiler error: tree check: expected integer_cst, have addr_expr in to_wide, at tree.h:6283

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection,
   ||needs-reduction
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-04-27
 Ever confirmed|0   |1

[Bug tree-optimization/109639] [14 regression] Internal compiler error: tree check: expected integer_cst, have addr_expr in to_wide, at tree.h:6283

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

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

--- Comment #4 from Andrew Pinski  ---
Created attachment 54931
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54931=edit
One version of the reduced testcase

I am not a fan of this reduced testcase so I am trying again.

[Bug tree-optimization/109639] [14 regression] Internal compiler error: tree check: expected integer_cst, have addr_expr in to_wide, at tree.h:6283

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug tree-optimization/109639] [14 regression] Internal compiler error: tree check: expected integer_cst, have addr_expr in to_wide, at tree.h:6283

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Host|aarch64-unknown-linux-gnu   |
   Keywords||ice-on-valid-code

--- Comment #3 from Andrew Pinski  ---
Can reproduce on the trunk on x86_64, reducing.

[Bug tree-optimization/109639] [14 regression] Internal compiler error: tree check: expected integer_cst, have addr_expr in to_wide, at tree.h:6283

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

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

--- Comment #2 from Sam James  ---
(In reply to Sam James from comment #1)
> (In reply to Sam James from comment #0)
> > gcc (Gentoo 14.0.0. p, commit 7546d8be5a8ae93e81535644c2578807db276ab6)
> > 14.0.0 20230426 (experimental)
> 
> This commit is wrong (recorded incorrectly). I'm changing something in our
> packaging to record the upstream commit correctly vs the commit after any
> patches.
> 
> Anyway, reducing.

It's actually built at b4c69e6b663753f41259e2e19ad03cfc11457534
(r14-267-gb4c69e6b663753).

[Bug tree-optimization/25290] PHI-OPT could be rewritten so that is uses match

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #54821|0   |1
is obsolete||

--- Comment #30 from Andrew Pinski  ---
Created attachment 54930
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54930=edit
New set of patches

Note this is a new set, It does not do the C++ify as I had done before. It is
missing some of the factor_out_* patches from the previous set; I am
re-implementing that (the last patch in the series is the start of that).

[Bug c/109412] [13/14 Regression] ICE in fold_convert_loc, at fold-const.cc:2627 since r13-2205-g14cfa01755a66a

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org
Summary|[13/14 Regression] ICE in   |[13/14 Regression] ICE in
   |fold_convert_loc, at|fold_convert_loc, at
   |fold-const.cc:2627  |fold-const.cc:2627 since
   ||r13-2205-g14cfa01755a66a

--- Comment #5 from Sam James  ---
When trying to reduce another bug, I accidentally reduced to something invalid
which seems to hti this bug:
```
int bfd_elf_final_link() = {}
```

w/
```
$ gcc -O2 /tmp/foo.c -c
/tmp/foo.c:1:1: error: function ‘bfd_elf_final_link’ is initialized like a
variable
1 | int bfd_elf_final_link() = {}
  | ^~~
/tmp/foo.c:1:1: internal compiler error: in fold_convert_loc, at
fold-const.cc:2627
0x62ce64 fold_convert_loc(unsigned int, tree_node*, tree_node*)
   
/usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/fold-const.cc:2627
0x6e5753 pop_init_level(unsigned int, int, obstack*, unsigned int)
   
/usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/c/c-typeck.cc:9382
0x1f0d141 c_parser_braced_init
   
/usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/c/c-parser.cc:5775
0x1ef2857 c_parser_initializer
   
/usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/c/c-parser.cc:5675
0x1edc23a c_parser_declaration_or_fndef
   
/usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/c/c-parser.cc:2564
0x1edb817 c_parser_external_declaration
   
/usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/c/c-parser.cc:1925
0x1ed7028 c_parser_translation_unit
   
/usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/c/c-parser.cc:1779
0x1ed7028 c_parse_file()
   
/usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/c/c-parser.cc:24632
0x1ecf431 c_common_parse_file()
   
/usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/c-family/c-opts.cc:1248
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++/61445] [4.10 Regression][C++11] ice in instantiate_decl at cp/pt.c:19770

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

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

--- Comment #5 from CVS Commits  ---
The trunk branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:95d4c0d2e6318aef88ba0bc607dfc1ec6b7a612f

commit r14-283-g95d4c0d2e6318aef88ba0bc607dfc1ec6b7a612f
Author: Jason Merrill 
Date:   Thu Mar 16 16:55:39 2023 -0400

c++: restore instantiate_decl assert

For PR61445 I removed this assert, but PR108242 demonstrated why it's still
useful; to avoid regressing the former testcase I check pattern_defined
in the assert.

This reverts r212524.

PR c++/61445

gcc/cp/ChangeLog:

* pt.cc (instantiate_decl): Assert !defer_ok for local
class members.

[Bug fortran/109641] New: Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones.

[adelson.oliveira at gmail dot com via Gcc-bugs]

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

Bug ID: 109641
   Summary: Gfortran fails to overload intrinsic operator (*) if
operands are complex. It works with real ones.
   Product: gcc
   Version: og10 (devel/omp/gcc-10)
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adelson.oliveira at gmail dot com
  Target Milestone: ---

Created attachment 54929
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54929=edit
A small FORTRAN code to reproduce the bug

I'm uploading a small fortran code to show the problem. The code has a module
that overloads intrinsic operator (*) for a vector matrix multiplication. The
bug is triggered when the matrix (and the result) is complex.
The compilation with

$ gfortran -o teste -O teste.f90

will fail with a error message reporting inconsistent rank declaration.
As indicated in the snippet, simply changing  from COMPLEX to REAL in the
declaration of the matrix (and the result) everything goes fine.

As an additional information, if one changes from the intrinsic (*) to
something like (.MULT.) in the module then there is no error at all.

Please look for the comments in the MODULE TESTEOP and in the PROGRAM TESTE to
better test  the bug.

Thanks for any help

[Bug target/109610] [14 regression] gcc.target/powerpc/dform-3.c fails after r14-172-g0368d169492017

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Hongtao.liu  ---
(In reply to rsand...@gcc.gnu.org from comment #6)
> Please don't do the peephole thing!  This seems like a
> target-independent problem.
> 
> The costs for r117 look odd.  Why is the cost of GENERAL_REGS so high
> when the use (before the introduction of insn 13) explicitly requires
> GENERAL_REGS?
> 
> Given those costs, the behaviour after the patch looks correct
> (on the basis of the information its working with, I mean,
> even though it's not the desired effect).

(define_insn "vsx_mov_64bit"
  [(set (match_operand:VSX_M 0 "nonimmediate_operand"
   "=ZwO,  wa,wa,r, we,?wQ,
?,   ??r,   ??Y,   , wa,v,
wa,wa,
?wa,   v, , wZ,v")

(match_operand:VSX_M 1 "input_operand" 
   "wa,ZwO,   wa,we,r, r,
wQ,Y, r, r, wE,jwM,
eQ,eP,
?jwM,  W, ,  v, wZ"))]

  "TARGET_POWERPC64 && VECTOR_MEM_VSX_P (mode)
   && (register_operand (operands[0], mode) 
   || register_operand (operands[1], mode))"
{
  return rs6000_output_move_128bit (operands);
}

Because the backend pattern explicitly disparage the alternative (, r),
(??r, Y) which moves from GENERAL_REGS/MEM to GENERAL_REGS. And in cost
calculation, RA will add extra 2 for each '?', that's why cost of GENERAL_REGS
is so high. If manually remove ?? from ??r, then the cost for GENERAL_REGS will
become 0, then RA can allocate r117 as GENERAL_REGS, the extra move can be
eliminated by pass_reload.  

--cost after removing ?? from ??r--
a2(r117,l0) costs: BASE_REGS:0,0 GENERAL_REGS:0,0 FLOAT_REGS:0,0
ALTIVEC_REGS:0,0 VSX_REGS:0,0 GEN_OR_FLOAT_REGS:12000,12000
GEN_OR_VSX_REGS:12000,12000 MEM:0,0
---end---

So it looks like an target dependent issue, the backend dislike allocating
GENERAL_REGS for V2DFmode move, but inline asm explicitly want it to be in
GENERAL_REGS.

[Bug tree-optimization/109639] [14 regression] Internal compiler error: tree check: expected integer_cst, have addr_expr in to_wide, at tree.h:6283

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

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

--- Comment #1 from Sam James  ---
(In reply to Sam James from comment #0)
> gcc (Gentoo 14.0.0. p, commit 7546d8be5a8ae93e81535644c2578807db276ab6)
> 14.0.0 20230426 (experimental)

This commit is wrong (recorded incorrectly). I'm changing something in our
packaging to record the upstream commit correctly vs the commit after any
patches.

Anyway, reducing.

[Bug c++/109640] Spurious Wdangling-reference for argument to temporary lambda cast to rvalue reference

[ed at catmur dot uk via Gcc-bugs]

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

--- Comment #2 from Ed Catmur  ---
Ah, so this is Bug 108165? That's a shame, we use (temporary) lambdas
extensively so I think we'd have to disable the warning entirely.

[Bug c++/109640] Spurious Wdangling-reference for argument to temporary lambda cast to rvalue reference

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #1 from Andrew Pinski  ---
Reduced testcase:
```
struct f{};
int &(const f&, int ) { return static_cast(r); }
void b() {
  int a;
  int&& i = ffa(f{}, a);
  i = 1;
}
```

Should see f{} is an empty struct which is exactly the same as the lambda here.

[Bug c++/109640] New: Spurious Wdangling-reference for argument to temporary lambda cast to rvalue reference

[ed at catmur dot uk via Gcc-bugs]

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

Bug ID: 109640
   Summary: Spurious Wdangling-reference for argument to temporary
lambda cast to rvalue reference
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ed at catmur dot uk
  Target Milestone: ---

bool b() {
int a;
int&& i = [](int& r) -> int&& { return static_cast(r); }(a);
auto const l = [](int& r) -> int&& { return static_cast(r); };
int&& j = l(a);
return  == 
}

: In function 'bool b()':
:3:11: warning: possibly dangling reference to a temporary
[-Wdangling-reference]
3 | int&& i = [](int& r) -> int&& { return static_cast(r); }(a);
  |   ^
:3:68: note: the temporary was destroyed at the end of the full
expression 'b()::().b()::(a)'
3 | int&& i = [](int& r) -> int&& { return static_cast(r); }(a);
  |   ~^~~

The heuristic appears to be confused by the lambda itself being a temporary,
even though it is captureless.

[Bug tree-optimization/109639] New: [14 regression] Internal compiler error: tree check: expected integer_cst, have addr_expr in to_wide, at tree.h:6283

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

, int, char const*, int, char
const*)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree.h:3728
0x83cf9b tree_int_cst_elt_check(tree_node const*, int, char const*, int, char
const*)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree.h:6285
[...]
```

```
gcc (Gentoo 14.0.0. p, commit 7546d8be5a8ae93e81535644c2578807db276ab6)
14.0.0 20230426 (experimental)
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.
```

[Bug target/109636] [14 Regression] ICE: in paradoxical_subreg_p, at rtl.h:3205 with -O -mcpu=a64fx

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

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

--- Comment #3 from Andrew Pinski  ---
Oh simplify_gen_subreg should not be used I think. Rather gen_lowpart should be
used instead. Especially when it comes to big endian.

[Bug target/109636] [14 Regression] ICE: in paradoxical_subreg_p, at rtl.h:3205 with -O -mcpu=a64fx

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #1)
> Are you sure this is not a regression also in GCC 13.1.0.
> The most obvious revision which caused this is r13-6620-gf23dc726875c26f2c3 .

I'd expect it's g:c69db3ef7f7d82a50f46038aa5457b7c8cc2d643 but haven't looked
deeper yet

[Bug libstdc++/106376] [LWG3545] The implementation of std::pointer_traits seems wrong

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|SUSPENDED   |RESOLVED

--- Comment #3 from Jonathan Wakely  ---
Closing ,as libstdc++ matches the C++23 working paper.

[Bug c++/109241] [13 Regression] ICE Segmentation fault for statement expression with a local type inside inside a generic lambda inside a generic lambda since r13-6722-gb323f52ccf966800

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

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

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

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

commit r14-278-gd60cbbfaa9a3ad3bd1f613be95add939c16fc9a1
Author: Jason Merrill 
Date:   Wed Mar 22 16:11:47 2023 -0400

c++: local class in nested generic lambda [PR109241]

The earlier fix for PR109241 avoided the crash by handling a type with no
TREE_BINFO.  But we want to move toward doing the partial substitution of
classes in generic lambdas, so let's take a step in that direction.

PR c++/109241

gcc/cp/ChangeLog:

* pt.cc (instantiate_class_template): Do partially instantiate.
(tsubst_expr): Do call complete_type for partial instantiations.

[Bug c++/69836] compilation error with constexpr in template types with redeclared methods

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

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

--- Comment #6 from CVS Commits  ---
The trunk branch has been updated by Jason Merrill :

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

commit r14-277-g1e27e7e0985e055b3d4ec92e93976b709fdbe425
Author: Jason Merrill 
Date:   Wed Feb 1 17:00:48 2023 -0500

c++: unique friend shenanigans [PR69836]

Normally we re-instantiate a function declaration when we start to
instantiate the body in case of multiple declarations.  In this wacky
testcase, this causes a problem because the type of the w_counter parameter
depends on its declaration not being in scope yet, so the name lookup only
finds the previous declaration.  This isn't a problem for member functions,
since they aren't subject to argument-dependent lookup.  So let's just skip
the regeneration for hidden friends.

PR c++/69836

gcc/cp/ChangeLog:

* pt.cc (regenerate_decl_from_template): Skip unique friends.

gcc/testsuite/ChangeLog:

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

[Bug tree-optimization/109638] unsigned > 1 ? 0 : n is not optimized to n == 1

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

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

--- Comment #1 from Andrew Pinski  ---
This should do it, I think:

(simplify
 (cond (lt @1 integer_onep@2) integer_zerop @1)
 (if (TYPE_UNSIGNED (type))
  (convert (eq @1 @2

[Bug tree-optimization/109638] New: unsigned > 1 ? 0 : n is not optimized to n == 1

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

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

Bug ID: 109638
   Summary: unsigned > 1 ? 0 : n is not optimized to n == 1
   Product: gcc
   Version: 13.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:
```
unsigned test_cst (unsigned n)
{
  if (n > 1)
n = 0;
  return n;
}
unsigned test_cst1 (unsigned n)
{
  return (n == 1);
}
```
For gimple at least the second one is smaller. I suspect for x86 the second
version is also faster because it uses sete rather than cmov.
But these 2 functions should produce the same code.

I found this on accident while looking at gcc.dg/tree-ssa/builtin-snprintf-2.c 
testcase.

This can only be done for 1 too.

[Bug c++/109625] [14 regression] 'error: use of built-in trait ‘__type_pack_element’ in function signature; use library traits instead' when building folly

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

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

Sam James  changed:

   What|Removed |Added

 Resolution|--- |MOVED
 Status|UNCONFIRMED |RESOLVED
   See Also||https://github.com/facebook
   ||/folly/issues/1991

--- Comment #6 from Sam James  ---
Thanks folks. Moving to https://github.com/facebook/folly/issues/1991.

[Bug tree-optimization/108697] constructing a path-range-query is expensive

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Andrew Macleod :

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

commit r14-275-g0a38f677463ff8a4fb61b049263aa596ef6471a7
Author: Andrew MacLeod 
Date:   Tue Mar 28 11:35:26 2023 -0400

Create a lazy ssa_cache.

Sparsely used ssa caches can benefit from using a bitmap to
determine if a name already has an entry.  Utilize it in the path query
and remove its private bitmap for tracking the same info.
Also use it in the "assume" query class.

PR tree-optimization/108697
* gimple-range-cache.cc (ssa_global_cache::clear_range): Do
not clear the vector on an out of range query.
(ssa_cache::dump): Use dump_range_query instead of get_range.
(ssa_cache::dump_range_query): New.
(ssa_lazy_cache::dump_range_query): New.
(ssa_lazy_cache::set_range): New.
* gimple-range-cache.h (ssa_cache::dump_range_query): New.
(class ssa_lazy_cache): New.
(ssa_lazy_cache::ssa_lazy_cache): New.
(ssa_lazy_cache::~ssa_lazy_cache): New.
(ssa_lazy_cache::get_range): New.
(ssa_lazy_cache::clear_range): New.
(ssa_lazy_cache::clear): New.
(ssa_lazy_cache::dump): New.
* gimple-range-path.cc (path_range_query::path_range_query): Do
not allocate a ssa_cache object nor has_cache bitmap.
(path_range_query::~path_range_query): Do not free objects.
(path_range_query::clear_cache): Remove.
(path_range_query::get_cache): Adjust.
(path_range_query::set_cache): Remove.
(path_range_query::dump): Don't call through a pointer.
(path_range_query::internal_range_of_expr): Set cache directly.
(path_range_query::reset_path): Clear cache directly.
(path_range_query::ssa_range_in_phi): Fold with globals only.
(path_range_query::compute_ranges_in_phis): Simply set range.
(path_range_query::compute_ranges_in_block): Call cache directly.
* gimple-range-path.h (class path_range_query): Replace bitmap
and cache pointer with lazy cache object.
* gimple-range.h (class assume_query): Use ssa_lazy_cache.

[Bug tree-optimization/109417] [13 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault since r13-6945

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Andrew Macleod :

https://gcc.gnu.org/g:40c7f943e882e8c5eccf45fc28146559f446764d

commit r14-271-g40c7f943e882e8c5eccf45fc28146559f446764d
Author: Andrew MacLeod 
Date:   Tue Apr 25 15:33:52 2023 -0400

Don't save ssa-name pointer in dependency cache.

If the direct dependence fields point directly to an ssa-name,
its possible that an optimization frees an ssa-name, and the value
pointed to may now be in the free list.   Simply maintain the ssa
version number instead.

PR tree-optimization/109417
* gimple-range-gori.cc (range_def_chain::register_dependency):
Save the ssa version number, not the pointer.
(gori_compute::may_recompute_p): No need to check if a dependency
is in the free list.
* gimple-range-gori.h (class range_def_chain): Change ssa1 and ssa2
fields to be unsigned int instead of trees.
(ange_def_chain::depend1): Adjust.
(ange_def_chain::depend2): Adjust.
* gimple-range.h: Include "ssa.h" to inline ssa_name().

[Bug tree-optimization/109637] unnecessary range check in complete switch on bitfield

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #5 from Andrew Macleod  ---
Perhaps switch conv just needs to look at it...

[Bug target/109636] [14 Regression] ICE: in paradoxical_subreg_p, at rtl.h:3205 with -O -mcpu=a64fx

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work|13.0|
   Host|x86_64-pc-linux-gnu |
   Target Milestone|--- |14.0

--- Comment #1 from Andrew Pinski  ---
Are you sure this is not a regression also in GCC 13.1.0.
The most obvious revision which caused this is r13-6620-gf23dc726875c26f2c3 .

[Bug tree-optimization/109637] unnecessary range check in complete switch on bitfield

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Macleod from comment #3)
> we know the range of _2 is [0, 3].. wonder why we don't know that about
> _1...  having a look

I assume the range of _1 is [-INF, +INF] (aka [0, 3] aka varrying) really as _1
has a type of unnamed-unsigned:2 so it would cover the whole range of the type.

[Bug tree-optimization/109637] unnecessary range check in complete switch on bitfield

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #3 from Andrew Macleod  ---
Just to add:

040.evrp:
_2  : [irange] int [0, 3] NONZERO 0x3
_3  : [irange] int [0, 3] NONZERO 0x3

   :
  _1 = s_5(D)->x;
  _2 = (int) _1;
  switch (_1)  [INV], case 1:  [INV], case 2:  [INV],
case 3:  [INV]>


we know the range of _2 is [0, 3].. wonder why we don't know that about _1... 
having a look

[Bug tree-optimization/109637] unnecessary range check in complete switch on bitfield

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #2 from Andrew Macleod  ---
I think the bigger questions is why did switch conv change:

  1 = s_5(D)->x;
  switch (_1)  [INV], case 1:  [INV], case 2:  [INV],
case 3:  [INV]>

   :
:
  goto ; [INV]

   :
:
  goto ; [INV]

   :
:

   :
  # _3 = PHI <0(2), 1(3), 2(4), 3(5)>
:
  return _3;


to 


   :
  _1 = s_5(D)->x;
  _6 = (unsigned char) _1;
  _2 = _6 + 255;
  if (_2 <= 2)
goto ; [INV]
  else
goto ; [INV]

   :
:
  _10 = 0;
  goto ; [100.00%]

   :
:
  _8 = (unsigned int) _1;
  _9 = (int) _1;
  _7 = _9;

   :
  # _3 = PHI <_10(3), _7(4)>
:
:
  return _3;


Why are we adding -1 to [0,3] ?  Thats the root of this issue I think?  seems
strange

[Bug tree-optimization/109637] unnecessary range check in complete switch on bitfield

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-04-26
  Component|middle-end  |tree-optimization
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
  # RANGE [irange] unsigned char [0, 3] NONZERO 0x3
  _6 = (unsigned charD.30) _1;
  # RANGE [irange] unsigned char [0, 2][+INF, +INF]
  _2 = _6 + 255;

  if (_2 <= 2)

VRP Should have changed _2 <= 2 to just _2 != 255 which then gets folded into
_6 != 0 which then will get folded into _1 != 0

and then phiopt could also have sunk the cast:
  if (_2 <= 2)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870913]:
:
  _9 = (int) _1;

   [local count: 1073741824]:
  # _3 = PHI <0(2), _9(3)>

Which then would get simplified into just:
_3 = (int)_1;

So there are a few things that needed to be done here ...

[Bug middle-end/109637] unnecessary range check in complete switch on bitfield

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|normal  |enhancement

[Bug middle-end/109637] New: unnecessary range check in complete switch on bitfield

[mattiase at acm dot org via Gcc-bugs]

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

Bug ID: 109637
   Summary: unnecessary range check in complete switch on bitfield
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mattiase at acm dot org
  Target Milestone: ---

This fully populated switch still produces some kind of useless range check:

struct S { unsigned x : 2; };
int f (struct S *s) {
switch(s->x) {
case 0: return 0;
case 1: return 1;
case 2: return 2;
case 3: return 3;
}
}

->
movzbl  (%rdi), %eax
andl$3, %eax
leal-1(%rax), %edx
movzbl  %al, %eax
cmpb$3, %dl
movl$0, %edx
cmovnb  %edx, %eax
ret

GCC apparently understands that the switch is complete at some level since
anything after the switch is recognised as dead code, so the range check is a
bit puzzling.

The code is fine if we explicitly mask the switch value as in `switch(s->x &
3)`:

movzbl  (%rdi), %eax
andl$3, %eax
ret

[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||bremende55 at gmail dot com

--- Comment #26 from Xi Ruoyao  ---
*** Bug 109633 has been marked as a duplicate of this bug. ***

[Bug c++/109633] segfault using cout after set with simple prog from cppreference.com

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE
 CC||xry111 at gcc dot gnu.org

--- Comment #5 from Xi Ruoyao  ---


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

[Bug target/109636] New: [14 Regression] ICE: in paradoxical_subreg_p, at rtl.h:3205 with -O -mcpu=a64fx

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 109636
   Summary: [14 Regression] ICE: in paradoxical_subreg_p, at
rtl.h:3205 with -O -mcpu=a64fx
   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: aarch64-unknown-linux-gnu

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

Compiler output:
$ aarch64-unknown-linux-gnu-gcc -O -mcpu=a64fx testcase.c 
during RTL pass: expand
testcase.c: In function 'foo':
testcase.c:9:3: internal compiler error: in paradoxical_subreg_p, at rtl.h:3205
9 |   bar (__builtin_shuffle (v, __builtin_shufflevector ((V){}, w, 4, 5) /
v));
  |  
^
0x7e83b3 paradoxical_subreg_p(machine_mode, machine_mode)
/repo/gcc-trunk/gcc/rtl.h:3205
0x7f1871 paradoxical_subreg_p(machine_mode, machine_mode)
/repo/gcc-trunk/gcc/simplify-rtx.cc:7459
0x7f1871 simplify_context::simplify_subreg(machine_mode, rtx_def*,
machine_mode, poly_int<2u, unsigned long>)
/repo/gcc-trunk/gcc/simplify-rtx.cc:7533
0x1193a21 simplify_context::simplify_gen_subreg(machine_mode, rtx_def*,
machine_mode, poly_int<2u, unsigned long>)
/repo/gcc-trunk/gcc/simplify-rtx.cc:7748
0x1af64c4 simplify_gen_subreg(machine_mode, rtx_def*, machine_mode,
poly_int<2u, unsigned long>)
/repo/gcc-trunk/gcc/rtl.h:3542
0x1af64c4 gen_udivv2di3(rtx_def*, rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/config/aarch64/aarch64-simd.md:2910
0x104e9da expand_binop_directly
/repo/gcc-trunk/gcc/optabs.cc:1442
0x104c481 expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*,
int, optab_methods)
/repo/gcc-trunk/gcc/optabs.cc:1529
0x104f063 sign_expand_binop(machine_mode, optab_tag, optab_tag, rtx_def*,
rtx_def*, rtx_def*, int, optab_methods)
/repo/gcc-trunk/gcc/optabs.cc:2317
0xd92811 expand_divmod(int, tree_code, machine_mode, rtx_def*, rtx_def*,
rtx_def*, int, optab_methods)
/repo/gcc-trunk/gcc/expmed.cc:5268
0xd9f3e9 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/repo/gcc-trunk/gcc/expr.cc:9863
0xda6218 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/repo/gcc-trunk/gcc/expr.cc:10800
0xda0317 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/repo/gcc-trunk/gcc/expr.cc:8999
0xda0317 expand_normal(tree_node*)
/repo/gcc-trunk/gcc/expr.h:316
0xda0317 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/repo/gcc-trunk/gcc/expr.cc:10453
0xda6218 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/repo/gcc-trunk/gcc/expr.cc:10800
0xc4d218 expand_normal(tree_node*)
/repo/gcc-trunk/gcc/expr.h:316
0xc4d218 precompute_register_parameters
/repo/gcc-trunk/gcc/calls.cc:988
0xc53ca0 expand_call(tree_node*, rtx_def*, int)
/repo/gcc-trunk/gcc/calls.cc:3416
0xda4c51 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/repo/gcc-trunk/gcc/expr.cc:11867
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.

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

[Bug c++/109633] segfault using cout after set with simple prog from cppreference.com

[bremende55 at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Jo  ---
good idea, thank you

[Bug c++/109633] segfault using cout after set with simple prog from cppreference.com

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

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

--- Comment #3 from Andrew Pinski  ---
Since I see this as going to be a FAQ soon, I submitted a patch to add a note
to the begining of changes page for GCC 13:
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616806.html

[Bug target/104338] RISC-V: Subword atomics result in library calls

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

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

--- Comment #15 from CVS Commits  ---
The master branch has been updated by Patrick O'Neill :

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

commit r14-269-gf797260adaf52bee0ec0e16190bbefbe1bfc3692
Author: Patrick O'Neill 
Date:   Tue Apr 18 14:33:13 2023 -0700

RISCV: Inline subword atomic ops

RISC-V has no support for subword atomic operations; code currently
generates libatomic library calls.

This patch changes the default behavior to inline subword atomic calls
(using the same logic as the existing library call).
Behavior can be specified using the -minline-atomics and
-mno-inline-atomics command line flags.

gcc/libgcc/config/riscv/atomic.c has the same logic implemented in asm.
This will need to stay for backwards compatibility and the
-mno-inline-atomics flag.

2023-04-18 Patrick O'Neill 

gcc/ChangeLog:
PR target/104338
* config/riscv/riscv-protos.h: Add helper function stubs.
* config/riscv/riscv.cc: Add helper functions for subword masking.
* config/riscv/riscv.opt: Add command-line flag.
* config/riscv/sync.md: Add masking logic and inline asm for
fetch_and_op,
fetch_and_nand, CAS, and exchange ops.
* doc/invoke.texi: Add blurb regarding command-line flag.

libgcc/ChangeLog:
PR target/104338
* config/riscv/atomic.c: Add reference to duplicate logic.

gcc/testsuite/ChangeLog:
PR target/104338
* gcc.target/riscv/inline-atomics-1.c: New test.
* gcc.target/riscv/inline-atomics-2.c: New test.
* gcc.target/riscv/inline-atomics-3.c: New test.
* gcc.target/riscv/inline-atomics-4.c: New test.
* gcc.target/riscv/inline-atomics-5.c: New test.
* gcc.target/riscv/inline-atomics-6.c: New test.
* gcc.target/riscv/inline-atomics-7.c: New test.
* gcc.target/riscv/inline-atomics-8.c: New test.

Signed-off-by: Patrick O'Neill 
Signed-off-by: Palmer Dabbelt 

[Bug ipa/107769] [12 Regression] -flto with -Os/-O2/-O3 emitted code with gcc 12.x segfaults via mutated global in .rodata since r12-2887-ga6da2cddcf0e959d

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

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #11 from Martin Jambor  ---
Fixed.

[Bug ipa/109318] [12 Regression] csmith: -fipa-cp seems to cause trouble since r12-2523-g13586172d0b70c

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

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #14 from Martin Jambor  ---
Fixed.

[Bug ipa/107769] [12 Regression] -flto with -Os/-O2/-O3 emitted code with gcc 12.x segfaults via mutated global in .rodata since r12-2887-ga6da2cddcf0e959d

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

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Martin Jambor
:

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

commit r12-9476-gbea3885200c549419567ad3a43ac71642619ad1a
Author: Martin Jambor 
Date:   Wed Apr 26 18:38:39 2023 +0200

ipa: Fix double reference-count decrements for the same edge (PR 107769, PR
109318)

It turns out that since addition of the code that can identify globals
which are only read from, the code that keeps track of the references
can decrement their count for the same calls, once during IPA-CP and
then again during inlining.  Fixed by adding a special flag to the
pass-through variant and simply wiping out the reference to the
refdesc structure from the constant ones.

Moreover, during debugging of the issue I have discovered that the
code removing references could remove a reference associated with the
same statement but of a wrong type.  In all cases it wanted to remove
an IPA_REF_ADDR reference so removing a lesser one instead should do
no harm in practice, but we should try to be consistent and so this
patch extends symtab_node::find_reference so that it searches for a
reference of a given type only.

gcc/ChangeLog:

2023-04-14  Martin Jambor  

PR ipa/107769
PR ipa/109318
* cgraph.h (symtab_node::find_reference): Add parameter use_type.
* ipa-prop.h (ipa_pass_through_data): New flag refdesc_decremented.
(ipa_zap_jf_refdesc): New function.
(ipa_get_jf_pass_through_refdesc_decremented): Likewise.
(ipa_set_jf_pass_through_refdesc_decremented): Likewise.
* ipa-cp.cc (ipcp_discover_new_direct_edges): Provide a value for
the new parameter of find_reference.
(adjust_references_in_caller): Likewise. Make sure the constant
jump
function is not used to decrement a refdec counter again.  Only
decrement refdesc counters when the pass_through jump function
allows
it.  Added a detailed dump when decrementing refdesc counters.
* ipa-prop.cc (ipa_print_node_jump_functions_for_edge): Dump new
flag.
(ipa_set_jf_simple_pass_through): Initialize the new flag.
(ipa_set_jf_unary_pass_through): Likewise.
(ipa_set_jf_arith_pass_through): Likewise.
(remove_described_reference): Provide a value for the new parameter
of
find_reference.
(update_jump_functions_after_inlining): Zap refdesc of new jfunc if
the previous pass_through had a flag mandating that we do so.
(propagate_controlled_uses): Likewise.  Only decrement refdesc
counters when the pass_through jump function allows it.
(ipa_edge_args_sum_t::duplicate): Provide a value for the new
parameter of find_reference.
(ipa_write_jump_function): Assert the new flag does not have to be
streamed.
* symtab.cc (symtab_node::find_reference): Add parameter use_type,
use
it in searching.

gcc/testsuite/ChangeLog:

2023-04-06  Martin Jambor  

PR ipa/107769
PR ipa/109318
* gcc.dg/ipa/pr109318.c: New test.
* gcc.dg/lto/pr107769_0.c: Likewise.

(cherry picked from commit 8e08c7886eed5824bebd0e011526ec302d622844)

[Bug ipa/109318] [12 Regression] csmith: -fipa-cp seems to cause trouble since r12-2523-g13586172d0b70c

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

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Martin Jambor
:

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

commit r12-9476-gbea3885200c549419567ad3a43ac71642619ad1a
Author: Martin Jambor 
Date:   Wed Apr 26 18:38:39 2023 +0200

ipa: Fix double reference-count decrements for the same edge (PR 107769, PR
109318)

It turns out that since addition of the code that can identify globals
which are only read from, the code that keeps track of the references
can decrement their count for the same calls, once during IPA-CP and
then again during inlining.  Fixed by adding a special flag to the
pass-through variant and simply wiping out the reference to the
refdesc structure from the constant ones.

Moreover, during debugging of the issue I have discovered that the
code removing references could remove a reference associated with the
same statement but of a wrong type.  In all cases it wanted to remove
an IPA_REF_ADDR reference so removing a lesser one instead should do
no harm in practice, but we should try to be consistent and so this
patch extends symtab_node::find_reference so that it searches for a
reference of a given type only.

gcc/ChangeLog:

2023-04-14  Martin Jambor  

PR ipa/107769
PR ipa/109318
* cgraph.h (symtab_node::find_reference): Add parameter use_type.
* ipa-prop.h (ipa_pass_through_data): New flag refdesc_decremented.
(ipa_zap_jf_refdesc): New function.
(ipa_get_jf_pass_through_refdesc_decremented): Likewise.
(ipa_set_jf_pass_through_refdesc_decremented): Likewise.
* ipa-cp.cc (ipcp_discover_new_direct_edges): Provide a value for
the new parameter of find_reference.
(adjust_references_in_caller): Likewise. Make sure the constant
jump
function is not used to decrement a refdec counter again.  Only
decrement refdesc counters when the pass_through jump function
allows
it.  Added a detailed dump when decrementing refdesc counters.
* ipa-prop.cc (ipa_print_node_jump_functions_for_edge): Dump new
flag.
(ipa_set_jf_simple_pass_through): Initialize the new flag.
(ipa_set_jf_unary_pass_through): Likewise.
(ipa_set_jf_arith_pass_through): Likewise.
(remove_described_reference): Provide a value for the new parameter
of
find_reference.
(update_jump_functions_after_inlining): Zap refdesc of new jfunc if
the previous pass_through had a flag mandating that we do so.
(propagate_controlled_uses): Likewise.  Only decrement refdesc
counters when the pass_through jump function allows it.
(ipa_edge_args_sum_t::duplicate): Provide a value for the new
parameter of find_reference.
(ipa_write_jump_function): Assert the new flag does not have to be
streamed.
* symtab.cc (symtab_node::find_reference): Add parameter use_type,
use
it in searching.

gcc/testsuite/ChangeLog:

2023-04-06  Martin Jambor  

PR ipa/107769
PR ipa/109318
* gcc.dg/ipa/pr109318.c: New test.
* gcc.dg/lto/pr107769_0.c: Likewise.

(cherry picked from commit 8e08c7886eed5824bebd0e011526ec302d622844)

[Bug libgomp/109634] Linking Imagick for PHP compiles fine but gives segfault caused by libgomp on runtime

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

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

--- Comment #3 from Andrew Pinski  ---
https://gcc.gnu.org/pipermail/gcc/2015-February/216464.html

[Bug analyzer/109635] New: -Wanalyzer-use-of-uninitialized-value false alarm involving adding 8 to index

[eggert at cs dot ucla.edu via Gcc-bugs]

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

Bug ID: 109635
   Summary: -Wanalyzer-use-of-uninitialized-value false alarm
involving adding 8 to index
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: eggert at cs dot ucla.edu
  Target Milestone: ---

Created attachment 54926
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54926=edit
compile with -O2 -fanalyzer to reproduce false positive

This is gcc (GCC) 13.0.1 20230401 (Red Hat 13.0.1-0) on x86-64. I ran into this
problem when building Coreutils. Compile the attached program with:

gcc -S -O2 -fanalyzer make-prime-list.i

The output is at the end of this bug report. It's a false alarm, since primes[i
+ 8].p is accessed only when 8 <= i + 8 < nprimes, and every entry from
primes[0] up to (but not including) primes[nprimes] is initialized by the call
to process_prime.

If you change both instances of 'i + 8' to 'i + 1' in line 1997, the false
alarm goes away. The false alarm is present if you use 'i + 2', though. I don't
know why the problem starts occuring between i + 1 and i + 2.

Here's the output:

make-prime-list.i: In function ‘output_primes’:
make-prime-list.i:1997:56: warning: use of uninitialized value ‘*primes_42(D) +
_3.p’ [CWE-457] [-Wanalyzer-use-of-uninitialized-value]
 1997 |   unsigned int d8 = i + 8 < nprimes ? primes[i + 8].p - primes[i].p
: 0xff;
  |   ~^~
  ‘main’: events 1-6
|
| 2038 | main (int argc, char **argv)
|  | ^~~~
|  | |
|  | (1) entry to ‘main’
|..
| 2045 |   if (argc != 2)
|  |  ~
|  |  |
|  |  (2) following ‘false’ branch (when ‘argc == 2’)...
|..
| 2055 |   limit = atoi (argv[1]);
|  |   ~~
|  |   |
|  |   (3) ...to here
| 2056 |   if (limit < 3)
|  |  ~
|  |  |
|  |  (4) following ‘false’ branch...
|..
| 2060 |   if ( !(limit & 1))
|  | ~~~
|  ||
|  |(5) ...to here
|..
| 2063 |   sieve = xalloc (size);
|  |   ~
|  |   |
|  |   (6) calling ‘xalloc’ from ‘main’
|
+--> ‘xalloc’: events 7-9
   |
   | 2025 | xalloc (size_t s)
   |  | ^~
   |  | |
   |  | (7) entry to ‘xalloc’
   |..
   | 2028 |   if (p)
   |  |  ~
   |  |  |
   |  |  (8) following ‘true’ branch (when ‘p’ is non-NULL)...
   | 2029 | return p;
   |  |~
   |  ||
   |  |(9) ...to here
   |
<--+
|
  ‘main’: events 10-11
|
| 2063 |   sieve = xalloc (size);
|  |   ^
|  |   |
|  |   (10) returning to ‘main’ from ‘xalloc’
| 2064 |   memset (sieve, 1, size);
| 2065 |   prime_list = xalloc (size * sizeof (*prime_list));
|  |
|  ||
|  |(11) calling ‘xalloc’ from ‘main’
|
+--> ‘xalloc’: events 12-15
   |
   | 2025 | xalloc (size_t s)
   |  | ^~
   |  | |
   |  | (12) entry to ‘xalloc’
   | 2026 | {
   | 2027 |   void *p = malloc (s);
   |  | ~~
   |  | |
   |  | (13) region created on heap here
   | 2028 |   if (p)
   |  |  ~
   |  |  |
   |  |  (14) following ‘true’ branch (when ‘p’ is non-NULL)...
   | 2029 | return p;
   |  |~
   |  ||
   |  |(15) ...to here
   |
<--+
|
  ‘main’: events 16-19
|
| 2065 |   prime_list = xalloc (size * sizeof (*prime_list));
|  |^~~~
|  ||
|  |(16) returning to ‘main’ from ‘xalloc’
| 2066 |   nprimes = 0;
| 2067 |   for (i = 0; i < size;)
|  |   
|  | |
|  | (17) following ‘true’ branch (when ‘i < size’)...
| 2068 | {
| 2069 |   unsigned p = 3 + 2 * i;
|  |~
|  |  |
|  |  (18) ...to here
| 2070 |   unsigned j;
| 2071 |   process_prime (_list[nprimes++], p);
|  |  

[Bug ada/108801] ICE, task’s secondary_stack_size from parent discriminant

[simon at pushface dot org via Gcc-bugs]

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

--- Comment #3 from simon at pushface dot org ---
Fixed in GCC 13.1.0.

[Bug libgomp/109634] Linking Imagick for PHP compiles fine but gives segfault caused by libgomp on runtime

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

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

--- Comment #2 from Andrew Pinski  ---
Could be a glibc issue too.

[Bug target/109632] Inefficient codegen when complex numbers are emulated with structs

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

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

--- Comment #3 from Tamar Christina  ---
note that even if we can't stop SLP, we should be able to generate as efficient
code by being creative about the instruction selection, that's why I marked it
as a target bug :)

[Bug libgomp/109634] Linking Imagick for PHP compiles fine but gives segfault caused by libgomp on runtime

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://github.com/Imagick/
   ||imagick/issues/609

--- Comment #1 from Andrew Pinski  ---
IIRC

[Bug libgomp/109634] New: Linking Imagick for PHP compiles fine but gives segfault caused by libgomp on runtime

[gcc_bugzilla at murphyslantech dot de via Gcc-bugs]

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

Bug ID: 109634
   Summary: Linking Imagick for PHP compiles fine but gives
segfault caused by libgomp on runtime
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc_bugzilla at murphyslantech dot de
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

When compiling the imagick (ImageLibrary to use ImageMagick in PHP) this
compiles fine (no errors only warnings), but the resulting extension is not
working, causing php to crash with a segfault. Disabling the extension again,
everything works as expected (except that functions from the extension are not
available).

The error is also tracked here: https://github.com/Imagick/imagick/issues/609,
but basically this boils down to:

==272669== Memcheck, a memory error detector
==272669== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==272669== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==272669== Command: php -v
==272669== 
==272669== Invalid read of size 8
==272669==at 0x908AADE: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==272669==by 0x400533D: call_init.part.0 (dl-init.c:70)
==272669==by 0x4005427: call_init (dl-init.c:33)
==272669==by 0x4005427: _dl_init (dl-init.c:117)
==272669==by 0x4001561: _dl_catch_exception (dl-catch.c:211)
==272669==by 0x400C345: dl_open_worker (dl-open.c:808)
==272669==by 0x400C345: dl_open_worker (dl-open.c:771)
==272669==by 0x40014DC: _dl_catch_exception (dl-catch.c:237)
==272669==by 0x400C6BB: _dl_open (dl-open.c:884)
==272669==by 0x5303BEB: dlopen_doit (dlopen.c:56)
==272669==by 0x40014DC: _dl_catch_exception (dl-catch.c:237)
==272669==by 0x4001602: _dl_catch_error (dl-catch.c:256)
==272669==by 0x53036BE: _dlerror_run (dlerror.c:138)
==272669==by 0x5303CA0: dlopen_implementation (dlopen.c:71)
==272669==by 0x5303CA0: dlopen@@GLIBC_2.34 (dlopen.c:81)
==272669==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==272669== 
==272669== 
==272669== Process terminating with default action of signal 11 (SIGSEGV)
==272669==  Access not within mapped region at address 0x0
==272669==at 0x908AADE: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==272669==by 0x400533D: call_init.part.0 (dl-init.c:70)
==272669==by 0x4005427: call_init (dl-init.c:33)
==272669==by 0x4005427: _dl_init (dl-init.c:117)
==272669==by 0x4001561: _dl_catch_exception (dl-catch.c:211)
==272669==by 0x400C345: dl_open_worker (dl-open.c:808)
==272669==by 0x400C345: dl_open_worker (dl-open.c:771)
==272669==by 0x40014DC: _dl_catch_exception (dl-catch.c:237)
==272669==by 0x400C6BB: _dl_open (dl-open.c:884)
==272669==by 0x5303BEB: dlopen_doit (dlopen.c:56)
==272669==by 0x40014DC: _dl_catch_exception (dl-catch.c:237)
==272669==by 0x4001602: _dl_catch_error (dl-catch.c:256)
==272669==by 0x53036BE: _dlerror_run (dlerror.c:138)
==272669==by 0x5303CA0: dlopen_implementation (dlopen.c:71)
==272669==by 0x5303CA0: dlopen@@GLIBC_2.34 (dlopen.c:81)
==272669==  If you believe this happened as a result of a stack
==272669==  overflow in your program's main thread (unlikely but
==272669==  possible), you can try to increase the size of the
==272669==  main thread stack using the --main-stacksize= flag.
==272669==  The main thread stack size used in this run was 8388608.
==272669== 
==272669== HEAP SUMMARY:
==272669== in use at exit: 1,105,972 bytes in 6,392 blocks
==272669==   total heap usage: 7,187 allocs, 795 frees, 1,359,342 bytes
allocated
==272669== 
==272669== LEAK SUMMARY:
==272669==definitely lost: 4,448 bytes in 139 blocks
==272669==indirectly lost: 0 bytes in 0 blocks
==272669==  possibly lost: 719,088 bytes in 4,998 blocks
==272669==still reachable: 382,436 bytes in 1,255 blocks
==272669== suppressed: 0 bytes in 0 blocks
==272669== Rerun with --leak-check=full to see details of leaked memory
==272669== 
==272669== For lists of detected and suppressed errors, rerun with: -s
==272669== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Which in turn points to gcc,libgomp or at least this is my best guess at the
moment, the error is persistent when trying to build for different versions of
php.

System Environment:
- OS Ubuntu 23.04
- gcc: gcc version 12.2.0 (Ubuntu 12.2.0-17ubuntu1)
- php versions tried to build: 8.2.5, 8.1.17, 8.1.18
- imagick version: 3.7.0

[Bug c++/105788] ICE: trying to capture 'args#0' in instantiation of generic lambda

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

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

Patrick Palka  changed:

   What|Removed |Added

   Last reconfirmed||2023-04-26
   Keywords|ice-on-invalid-code |ice-on-valid-code
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Patrick Palka  ---
Reduced:

int n = [](auto... args) {
  return ([&](auto r) {
if constexpr (sizeof(r))
  return args;
else
  return 0;
  }(0) + ...);
}(0);

[Bug sanitizer/109533] Build failure with upcoming musl release, needs libsanitizer backport (sanitizer_platform_limits_posix.cpp:182:31: error: invalid application of 'sizeof' to incomplete type '__s

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Thanks for the heads-up. Then let's close it as resolved.

[Bug target/109632] Inefficient codegen when complex numbers are emulated with structs

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

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

--- Comment #2 from Tamar Christina  ---
(In reply to Richard Biener from comment #1)
> Well, the usual unknown ABI boundary at function entry/exit.

Yes but LLVM gets it right, so should be a solve able computer science problem.
:)

Note that this was reduced from a bigger routine but end result the same, the
thing shouldn't have been vectorized.

[Bug c++/109633] segfault using cout after set with simple prog from cppreference.com

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

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

Patrick Palka  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=108969
 Resolution|FIXED   |INVALID
 CC||ppalka at gcc dot gnu.org

[Bug c++/109633] segfault using cout after set with simple prog from cppreference.com

[bremende55 at gmail dot com via Gcc-bugs]

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

Jo  changed:

   What|Removed |Added

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

--- Comment #2 from Jo  ---
Sorry for the inconvenience
lib was not found
-Wl,-rpath,/usr/local/lib64
solved the problem

[Bug sanitizer/109533] Build failure with upcoming musl release, needs libsanitizer backport (sanitizer_platform_limits_posix.cpp:182:31: error: invalid application of 'sizeof' to incomplete type '__s

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

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

--- Comment #1 from Sam James  ---
Pretty sure this is fixed by r14-263-gd53b3d94aaf211.

[Bug target/109610] [14 regression] gcc.target/powerpc/dform-3.c fails after r14-172-g0368d169492017

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
Please don't do the peephole thing!  This seems like a
target-independent problem.

The costs for r117 look odd.  Why is the cost of GENERAL_REGS so high
when the use (before the introduction of insn 13) explicitly requires
GENERAL_REGS?

Given those costs, the behaviour after the patch looks correct
(on the basis of the information its working with, I mean,
even though it's not the desired effect).

[Bug target/109632] Inefficient codegen when complex numbers are emulated with structs

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

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

--- Comment #1 from Richard Biener  ---
Well, the usual unknown ABI boundary at function entry/exit.

[Bug c++/109633] segfault using cout after set with simple prog from cppreference.com

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

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

--- Comment #1 from Richard Biener  ---
You have to use the GCC 13 runtime libraries - you likely run into a system
with older libstdc++?

Probably a duplicate of PR108969.

[Bug c++/109633] New: segfault using cout after set with simple prog from cppreference.com

[bremende55 at gmail dot com via Gcc-bugs]

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

Bug ID: 109633
   Summary: segfault using cout after set with simple prog from
cppreference.com
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bremende55 at gmail dot com
  Target Milestone: ---

Created attachment 54924
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54924=edit
*ii file from compilation

Segfault with
//  from https://en.cppreference.com/w/cpp/container/set/size
#include 
#include 

int main()
{ 
std::set nums {1, 3, 5, 7}; 
std::cout << "nums contains "  << nums.size() << " elements.\n";
}

compiled with
g++ -Wall -Wextra gcc13test.cpp
no compiler errors/warnings

starting a.out gives a segfault. gdb shows:

Reading symbols from a.out...
(No debugging symbols found in a.out)
(gdb) run
Starting program: /work/tmp/gcctest/a.out 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x77d3bf5a in std::ostream::sentry::sentry(std::ostream&) () from
/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) 


g++ -v :
Es werden eingebaute Spezifikationen verwendet.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/13.1.0/lto-wrapper
Ziel: x86_64-pc-linux-gnu
Konfiguriert mit: ../gcc-13.1.0/configure --enable-languages=c,c++
--disable-multilib
Thread-Modell: posix
Unterstützte LTO-Kompressionsalgorithmen: zlib
gcc-Version 13.1.0 (GCC)


cat /etc/os-release:
PRETTY_NAME="Ubuntu 22.04.2 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.2 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian

[Bug c++/97553] [missed optimization] constexprness not noticed when UBsan enabled

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

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||ppalka at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |13.0
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org

--- Comment #8 from Patrick Palka  ---
I think we can call this pretty much fixed for GCC 13.

[Bug ipa/109607] IPA replaces stmt with invalid gimple

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

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

--- Comment #3 from Martin Jambor  ---
(In reply to Richard Biener from comment #0)
> On cfghooks.cc we replace
> 
> BIT_FIELD_REF <*this_8(D), 8, 56>
> 

An alternative (perhaps for the release branches) would be to avoid SRA if the
parameter takes place in souch constructs.

But the patch in comment #2 looks like just the right thing to do.

[Bug target/109632] New: Inefficient codegen when complex numbers are emulated with structs

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

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

Bug ID: 109632
   Summary: Inefficient codegen when complex numbers are emulated
with structs
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64*

The following two cases are the same

struct complx_t {
float re;
float im;
};

complx_t
add(const complx_t , const complx_t ) {
  return {a.re + b.re, a.im + b.im};
}

_Complex float
add(const _Complex float *a, const _Complex float *b) {
  return {__real__ *a + __real__ *b, __imag__ *a + __imag__ *b};
}

But we generate much different code (looking at -O2),  For the first one we do:

ldr d1, [x1]
ldr d0, [x0]
faddv0.2s, v0.2s, v1.2s
fmovx0, d0
lsr x1, x0, 32
lsr w0, w0, 0
fmovs1, w1
fmovs0, w0
ret

which is bad for obvious reasons, but also also never needed to go through the
genreg for such a reversal. we could have used many other NEON instructions.

For the second one we generate the good instructions:

add(float _Complex const*, float _Complex const*):
ldp s3, s2, [x0]
ldp s0, s1, [x1]
fadds1, s2, s1
fadds0, s3, s0
ret

The difference being that in the second one we have decomposed the initial
structure by loading the elements:

   [local count: 1073741824]:
  _1 = REALPART_EXPR <*a_8(D)>;
  _2 = REALPART_EXPR <*b_9(D)>;
  _3 = _1 + _2;
  _4 = IMAGPART_EXPR <*a_8(D)>;
  _5 = IMAGPART_EXPR <*b_9(D)>;
  _6 = _4 + _5;
  _10 = COMPLEX_EXPR <_3, _6>;
  return _10;

In the first one we've kept them as vectors:

   [local count: 1073741824]:
  vect__1.6_13 = MEM  [(float *)a_8(D)];
  vect__2.9_15 = MEM  [(float *)b_9(D)];
  vect__3.10_16 = vect__1.6_13 + vect__2.9_15;
  MEM  [(float *)] = vect__3.10_16;
  return D.4435;

This part is probably a costing issue, we SLP them even though it's not
profitable because for the APCS we have to return them in separate registers.

Using -fno-tree-vectorize gets the gimple code right:

   [local count: 1073741824]:
  _1 = a_8(D)->re;
  _2 = b_9(D)->re;
  _3 = _1 + _2;
  D.4435.re = _3;
  _4 = a_8(D)->im;
  _5 = b_9(D)->im;
  _6 = _4 + _5;
  D.4435.im = _6;
  return D.4435;

But we generate worse code:

ldp s1, s0, [x0]
mov x2, 0
ldp s3, s2, [x1]
fadds1, s1, s3
fadds0, s0, s2
fmovw1, s1
fmovw0, s0
bfi x2, x1, 0, 32
bfi x2, x0, 32, 32
lsr x0, x2, 32
lsr w2, w2, 0
fmovs1, w0
fmovs0, w2

where we again use genreg as a very complicated way to do a no-op.

So there are two bugs here:

1. a costing, we shouldn't SLP
2. an expansion, the code out of expand is bad to begin with.

[Bug c++/88804] incorrect unused but set static variable in templated lambda

[fiesh at zefix dot tv via Gcc-bugs]

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

fiesh at zefix dot tv changed:

   What|Removed |Added

 CC||fiesh at zefix dot tv

--- Comment #7 from fiesh at zefix dot tv ---
I suppose this snippet also exhibits this bug here?

template  struct IntegerSequence {};

template  struct IntegralConstant {
  constexpr auto operator()() const { return i; }
};

template 
constexpr void apply(F const , IntegerSequence) {
  (f(IntegralConstant{}), ...);
}

template  constexpr void constexpr_foreach(F const ) {
  apply(f, IntegerSequence<0>{});
}

int main() {
  static int i[1] = {42};

  int j{};
  constexpr_foreach<1>([](auto const index) { j += i[index()]; });
  return j;
}

[Bug ipa/109607] IPA replaces stmt with invalid gimple

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

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

--- Comment #2 from Richard Biener  ---
(In reply to Richard Biener from comment #1)
> #0  ipa_param_body_adjustments::modify_expression (this=0x4b1f040, 
> expr_p=0x737222b8, convert=true)
> at /space/rguenther/src/gcc/gcc/ipa-param-manipulation.cc:1867
> #1  0x016f7dc5 in ipa_param_body_adjustments::modify_assignment (
> this=0x4b1f040, stmt=, 
> extra_stmts=0x7fffd0a8)
> at /space/rguenther/src/gcc/gcc/ipa-param-manipulation.cc:1890
> #2  0x016f927a in ipa_param_body_adjustments::modify_gimple_stmt (
> this=0x4b1f040, stmt=0x7fffd168, extra_stmts=0x7fffd0a8, 
> orig_stmt=)
> at /space/rguenther/src/gcc/gcc/ipa-param-manipulation.cc:2273
> #3  0x01abb925 in remap_gimple_stmt (
> stmt=, id=0x7fffd730)
> at /space/rguenther/src/gcc/gcc/tree-inline.cc:1961
> 
> Supposedly the easiest would be to make any is_gimple_reg_type IPA SRA
> replacement (I suppose all are ...) either address-taken or
> DECL_NOT_GIMPLE_REG_P.
> 
> diff --git a/gcc/ipa-param-manipulation.cc b/gcc/ipa-param-manipulation.cc
> index 42488ee09c3..473d759f983 100644
> --- a/gcc/ipa-param-manipulation.cc
> +++ b/gcc/ipa-param-manipulation.cc
> @@ -1384,6 +1384,8 @@ ipa_param_body_adjustments::common_initialization
> (tree old_fndecl,
>   DECL_CONTEXT (new_parm) = m_fndecl;
>   TREE_USED (new_parm) = 1;
>   DECL_IGNORED_P (new_parm) = 1;
> + if (is_gimple_reg_type (new_type))
> +   DECL_NOT_GIMPLE_REG_P (new_parm) = 1;
>   layout_decl (new_parm, 0);
>   m_new_decls.quick_push (new_parm);
>  
> 
> seems to work on the testcase I have.

But it doesn't work during bootstrap, in insn-recog.cc we then hit

insn-recog.cc: In function 'int pattern511(rtx)':
insn-recog.cc:23146:1: error: invalid argument to gimple call
23146 | pattern511 (rtx x1)
  | ^~
ISRA.64882
# VUSE <.MEM_19(D)>
_9 = pattern510.isra (ISRA.64882);
during GIMPLE pass: fixup_cfg
insn-recog.cc:23146:1: internal compiler error: verify_gimple failed
0x9a3bf4 _start
../sysdeps/x86_64/start.S:115
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.
make[3]: *** [Makefile:1157: insn-recog.o] Error 1

the way modify_expression is done is ugly, even more so the special-casing
of BIT_FIELD_REF and {IMAG,REAL}PART_EXPR.

I'm not sure if we guarantee conversions do not occur in some places?  At
least the call argument handling looks wrong to me and can result in invalid
GIMPLE as well.

While I can probably hack around the original assignment that's mishandled
it will feel like a hack.  Something like

@@ -1827,7 +1825,8 @@
ipa_param_body_adjustments::replace_removed_params_ssa_names (tree old_name,
necessary conversions.  */

 bool
-ipa_param_body_adjustments::modify_expression (tree *expr_p, bool convert)
+ipa_param_body_adjustments::modify_expression (tree *expr_p, bool convert,
+  gimple_seq *extra_stmts)
 {
   tree expr = *expr_p;

@@ -1862,6 +1861,11 @@ ipa_param_body_adjustments::modify_expression (tree
*expr_p, bool convert)
   gcc_checking_assert (tree_to_shwi (TYPE_SIZE (TREE_TYPE (expr)))
   == tree_to_shwi (TYPE_SIZE (TREE_TYPE (repl;
   tree vce = build1 (VIEW_CONVERT_EXPR, TREE_TYPE (expr), repl);
+  if (is_gimple_reg (repl))
+   {
+ gcc_assert (extra_stmts);
+ vce = force_gimple_operand (vce, extra_stmts, true, NULL_TREE);
+   }
   *expr_p = vce;
 }
   else
@@ -1889,7 +1893,7 @@ ipa_param_body_adjustments::modify_assignment (gimple
*stmt,
   lhs_p = gimple_assign_lhs_ptr (stmt);

   any = modify_expression (lhs_p, false);
-  any |= modify_expression (rhs_p, false);
+  any |= modify_expression (rhs_p, false, extra_stmts);
   if (any
   && !useless_type_conversion_p (TREE_TYPE (*lhs_p), TREE_TYPE (*rhs_p)))
 {

I'm going to test this nevertheless ...

[Bug target/109566] [12 Regression] powerpc: unrecognizable insn for -mcpu=e6500, -mcpu=power3, ..., -mcpu=power10

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/109566] [12 Regression] powerpc: unrecognizable insn for -mcpu=e6500, -mcpu=power3, ..., -mcpu=power10

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

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

--- Comment #20 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:

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

commit r12-9475-g2e5e72488b108e5d75049179ef91a093e5fedc49
Author: Jakub Jelinek 
Date:   Tue Apr 25 14:20:51 2023 +0200

powerpc: Fix up *branch_anddi3_dot for -m32 -mpowerpc64 [PR109566]

The following testcase reduced from newlib ICEs on powerpc-linux,
with -O2 -m32 -mpowerpc64 since r12-6433 PR102239 optimization was
added and on the original testcase since some ranger improvements in
GCC 13 made it no longer latent on newlib.
The problem is that the *branch_anddi3_dot define_insn_and_split
relies on the *rotldi3_mask_dot define_insn_and_split being recognized
during splitting.  The rs6000_is_valid_rotate_dot_mask function checks
whether
the mask is a CONST_INT which is a valid mask, but *rotl3_mask_dot in
addition to checking that it is a valid mask also has
  (mode == Pmode || UINTVAL (operands[3]) <= 0x7fff)
test in the condition.  For TARGET_64BIT that doesn't add any further
requirements, but for !TARGET_64BIT && TARGET_POWERPC64 if the AND
second operand is larger than INT_MAX it will not be recognized.

The rs6000_is_valid_rotate_dot_mask function is used solely in one spot,
condition of *branch_anddi3_dot, so the following patch adjusts it
to check for that as well.

2023-04-25  Jakub Jelinek  

PR target/109566
* config/rs6000/rs6000.cc (rs6000_is_valid_rotate_dot_mask): For
!TARGET_64BIT, don't return true if UINTVAL (mask) << (63 - nb)
is larger than signed int maximum.

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

(cherry picked from commit 97f8f2d0a0384d377ca46da88495f9a3d18d4415)

[Bug middle-end/109609] [12/13 Regression] tail call for function even when passing a ptr which references a local array still

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||12.2.0, 13.1.0
  Known to work||12.2.1, 13.1.1
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

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

[Bug middle-end/109609] [12/13 Regression] tail call for function even when passing a ptr which references a local array still

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

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

--- Comment #19 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

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

commit r12-9474-g2c7e89510fe41265b285e886d19f9895adf545e8
Author: Richard Biener 
Date:   Tue Apr 25 14:56:44 2023 +0200

tree-optimization/109609 - correctly interpret arg size in fnspec

By majority vote and a hint from the API name which is
arg_max_access_size_given_by_arg_p this interprets a memory access
size specified as given as other argument such as for strncpy
in the testcase which has "1cO313" as specifying the _maximum_
size read/written rather than the exact size.  There are two
uses interpreting it that way already and one differing.  The
following adjusts the differing and clarifies the documentation.

PR tree-optimization/109609
* attr-fnspec.h (arg_max_access_size_given_by_arg_p):
Clarify semantics.
* tree-ssa-alias.cc (check_fnspec): Correctly interpret
the size given by arg_max_access_size_given_by_arg_p as
maximum, not exact, size.

* gcc.dg/torture/pr109609.c: New testcase.

(cherry picked from commit e8d00353017f895d03a9eabae3506fd126ce1a2d)

[Bug rtl-optimization/109585] [10/11/12/13 regression] Carla/sord miscompiled with -O2 on ARM64 with flexible array member

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

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

--- Comment #26 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

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

commit r12-9473-gef6051b36241bf130bf76af0b775248635dc616e
Author: Richard Biener 
Date:   Mon Apr 24 13:31:07 2023 +0200

rtl-optimization/109585 - alias analysis typo

When r10-514-gc6b84edb6110dd2b4fb improved access path analysis
it introduced a typo that triggers when there's an access to a
trailing array in the first access path leading to false
disambiguation.

PR rtl-optimization/109585
* tree-ssa-alias.cc (aliasing_component_refs_p): Fix typo.

* gcc.dg/torture/pr109585.c: New testcase.

(cherry picked from commit 6d4bd27a60447c7505cb4783e675e98a191a8904)

[Bug tree-optimization/109573] [11/12/13 regression] ICE in vectorizable_live_operation, at tree-vect-loop.cc:9060 with -march=ivybridge since r11-3025-g095d42feed09f8

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

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

commit r12-9472-gc7de861c609573b1f219fcdf6c683612c987621f
Author: Richard Biener 
Date:   Fri Apr 21 12:57:17 2023 +0200

tree-optimization/109573 - avoid ICEing on unexpected live def

The following relaxes the assert in vectorizable_live_operation
where we catch currently unhandled cases to also allow an
intermediate copy as it happens here but also relax the assert
to checking only.

PR tree-optimization/109573
* tree-vect-loop.cc (vectorizable_live_operation): Allow
unhandled SSA copy as well.  Demote assert to checking only.

* g++.dg/vect/pr109573.cc: New testcase.

(cherry picked from commit cddfe6bc40b3dc0806e260bbfb4cac82d609a258)

[Bug tree-optimization/109154] [13/14 regression] jump threading de-optimizes nested floating point comparisons

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

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

--- Comment #58 from Jakub Jelinek  ---
As a different testcase showing what still needs to be done is e.g.
void
foo (int *p, int *q, int *r, int *s, int *t, int *u)
{
  #pragma omp simd
  for (int i = 0; i < 1024; i++)
{
  int vp = p[i];
  int vq = q[i];
  int vr = r[i];
  int vs = s[i];
  int vt = t[i];
  int vu = u[i];
  int vw;
  if (vp != 0)
{
  if (vp > 100)
{
  if (vq < 200)
vw = 1;
  else if (vr)
vw = 2;
  else
vw = 3;
}
  else if (vs > 100)
{
  if (vq < 180)
vw = 4;
  else if (vr > 20)
vw = 5;
  else
vw = 6;
}
  else
{
  if (vq < -100)
vw = 7;
  else if (vr < -20)
vw = 8;
  else
vw = 9;
}
}
  else if (vt > 10)
{
  if (vu > 100)
vw = 10;
  else if (vu < -100)
vw = 11;
  else
vw = 12;
}
  else
vw = 13;
  u[i] = vw;
}
}
with -O2 -fopenmp-simd.
I think we still need 12 VEC_COND_EXPRs to merge it all together, but if we
follow what the source is doing (or rediscover it), we can certainly
avoid so many useless  on the conditions by merging it together in the right
order.

[Bug middle-end/109631] Simple std::optional types returned on stack, not registers

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|libstdc++   |middle-end
   Keywords|ABI |missed-optimization

--- Comment #2 from Andrew Pinski  ---
Note this is not a libstdc++ issue as your clang invocation is even still using
libstdc++ :).

Anyways this is a dup of the other bug has some analysis to it.

[Bug middle-end/101326] std::optional returns forced through stack

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||david at westcontrol dot com

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

[Bug libstdc++/109631] Simple std::optional types returned on stack, not registers

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug libstdc++/109631] Simple std::optional types returned on stack, not registers

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug tree-optimization/109154] [13/14 regression] jump threading de-optimizes nested floating point comparisons

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

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #57 from Tamar Christina  ---
Ah, Cool, will take the remaining work then.

Thanks for all the patches in stage 4 everyone!

[Bug middle-end/109609] [12/13 Regression] tail call for function even when passing a ptr which references a local array still

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

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

--- Comment #18 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Richard Biener
:

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

commit r13-7252-gdf49e4602882eabe0642699fb71a70f6e120e263
Author: Richard Biener 
Date:   Tue Apr 25 14:56:44 2023 +0200

tree-optimization/109609 - correctly interpret arg size in fnspec

By majority vote and a hint from the API name which is
arg_max_access_size_given_by_arg_p this interprets a memory access
size specified as given as other argument such as for strncpy
in the testcase which has "1cO313" as specifying the _maximum_
size read/written rather than the exact size.  There are two
uses interpreting it that way already and one differing.  The
following adjusts the differing and clarifies the documentation.

PR tree-optimization/109609
* attr-fnspec.h (arg_max_access_size_given_by_arg_p):
Clarify semantics.
* tree-ssa-alias.cc (check_fnspec): Correctly interpret
the size given by arg_max_access_size_given_by_arg_p as
maximum, not exact, size.

* gcc.dg/torture/pr109609.c: New testcase.

(cherry picked from commit e8d00353017f895d03a9eabae3506fd126ce1a2d)

[Bug rtl-optimization/109585] [10/11/12/13 regression] Carla/sord miscompiled with -O2 on ARM64 with flexible array member

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

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

--- Comment #25 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Richard Biener
:

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

commit r13-7251-gbb406a6aea336966681927a27f54ee89c4fd4ea1
Author: Richard Biener 
Date:   Mon Apr 24 13:31:07 2023 +0200

rtl-optimization/109585 - alias analysis typo

When r10-514-gc6b84edb6110dd2b4fb improved access path analysis
it introduced a typo that triggers when there's an access to a
trailing array in the first access path leading to false
disambiguation.

PR rtl-optimization/109585
* tree-ssa-alias.cc (aliasing_component_refs_p): Fix typo.

* gcc.dg/torture/pr109585.c: New testcase.

(cherry picked from commit 6d4bd27a60447c7505cb4783e675e98a191a8904)

[Bug tree-optimization/109573] [11/12/13 regression] ICE in vectorizable_live_operation, at tree-vect-loop.cc:9060 with -march=ivybridge since r11-3025-g095d42feed09f8

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:263d1ed0484fc81d3f93e39cdd2f9eb0ce4d3e88

commit r13-7250-g263d1ed0484fc81d3f93e39cdd2f9eb0ce4d3e88
Author: Richard Biener 
Date:   Fri Apr 21 12:57:17 2023 +0200

tree-optimization/109573 - avoid ICEing on unexpected live def

The following relaxes the assert in vectorizable_live_operation
where we catch currently unhandled cases to also allow an
intermediate copy as it happens here but also relax the assert
to checking only.

PR tree-optimization/109573
* tree-vect-loop.cc (vectorizable_live_operation): Allow
unhandled SSA copy as well.  Demote assert to checking only.

* g++.dg/vect/pr109573.cc: New testcase.

(cherry picked from commit cddfe6bc40b3dc0806e260bbfb4cac82d609a258)

[Bug tree-optimization/109626] forwprop introduces new signed multiplication UB

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

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #2 from Mikael Morin  ---
(In reply to Richard Biener from comment #1)
> 
> I think the issue must be in (-A) * (-B) -> A * B, but I can't quite nail it.
> To result in -1 * INT_MIN we'd have to come from 1 * INT_MIN but then the
> negation of INT_MIN would already be problematic.

The original negation is made on an unsigned number (before the cast to int),
so it's not problematic.

[Bug libstdc++/90857] stl::forward_list::erase_after crashes if __pos == __last

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|13.2|14.0

[Bug c++/109278] a note without a warning

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

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

commit r13-7247-g4aeefba6cd657010a395dd187f9136cd152aac95
Author: Jakub Jelinek 
Date:   Tue Apr 25 14:38:01 2023 +0200

testsuite: Fix up ext-floating15.C tests on powerpc64-linux [PR109278]

I've noticed this test FAILs on powerpc64-linux, with
FAIL: g++.dg/cpp23/ext-floating15.C  -std=gnu++98 (test for excess errors)
Excess errors:
/home/jakub/gcc/gcc/testsuite/g++.dg/cpp23/ext-floating15.C:8:5: error:
'_Float128' is not supported on this target
/home/jakub/gcc/gcc/testsuite/g++.dg/cpp23/ext-floating15.C:8:5: error:
'_Float128' is not supported on this target
/home/jakub/gcc/gcc/testsuite/g++.dg/cpp23/ext-floating15.C:8:1: error:
variable or field 'bar' declared void
/home/jakub/gcc/gcc/testsuite/g++.dg/cpp23/ext-floating15.C:8:5: error:
'_Float128' is not supported on this target
/home/jakub/gcc/gcc/testsuite/g++.dg/cpp23/ext-floating15.C:8:6: error:
expected primary-expression before '_Float128'
and similarly other std versions.
powerpc64-linux is float128 target, but needs to add some options for it.

Fixed by adding them.

2023-04-25  Jakub Jelinek  

PR c++/109278
* g++.dg/cpp23/ext-floating15.C: Add dg-add-options float128.

(cherry picked from commit 784e03f378bb2c330b96459928d0472d38748970)

[Bug c++/109625] [14 regression] 'error: use of built-in trait ‘__type_pack_element’ in function signature; use library traits instead' when building folly

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

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #3)
> Folly should not use internal functions which is not designed for other than
> libstdc++.

The function wasn't designed for libstdc++, Clang had it first.

But Folly shouldn't assume that non-standard extensions have a
consistent/portable mangling suitable for use in APIs. In this case, it can't
be mangled at all.

[Bug c++/109625] [14 regression] 'error: use of built-in trait ‘__type_pack_element’ in function signature; use library traits instead' when building folly

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

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Arsen Arsenović from comment #1)
> do we want to match what clang does here?

No, this is an intentional choice.

[Bug libgomp/107041] [13/14 Regression] C '-Wenum-int-mismatch' diagnostic for OpenACC 'acc_on_device'

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug libgomp/107041] [13/14 Regression] C '-Wenum-int-mismatch' diagnostic for OpenACC 'acc_on_device'

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

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

commit r13-7246-gf8646b8dcb18721e776c39117f62aee7ee571f21
Author: Jakub Jelinek 
Date:   Thu Apr 20 19:26:17 2023 +0200

c: Avoid -Wenum-int-mismatch warning for redeclaration of builtin
acc_on_device [PR107041]

The new -Wenum-int-mismatch warning triggers with -Wsystem-headers in
, for obvious reasons the builtin acc_on_device uses int
type argument rather than enum which isn't defined yet when the builtin
is created, while the OpenACC spec requires it to have acc_device_t
enum argument.  The header makes sure it has int underlying type by using
negative and __INT_MAX__ enumerators.

I've tried to make the builtin typegeneric or just varargs, but that
changes behavior e.g. when one calls it with some C++ class which has
cast operator to acc_device_t, so the following patch instead disables
the warning for this builtin.

2023-04-20  Jakub Jelinek  

PR c/107041
* c-decl.cc (diagnose_mismatched_decls): Avoid -Wenum-int-mismatch
warning on acc_on_device declaration.

* gcc.dg/goacc/pr107041.c: New test.

(cherry picked from commit 3d7ab53d6c59499624aa41c8dea0664976820b3b)

[Bug rtl-optimization/106518] Exchange/swap aware register allocation (generate xchg in reload)

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

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

commit r14-245-g1f0bfbb26e532cef7347a91439008114fd88173a
Author: Roger Sayle 
Date:   Wed Apr 26 09:10:06 2023 +0100

[xstormy16] Add support for byte and word swapping instructions.

This patch adds support for xstormy16's swpb (swap bytes) and swpw (swap
words) instructions.  The most obvious application of these to implement
the __builtin_bswap16 and __builtin_bswap32 intrinsics.

Currently, __builtin_bswap16 is implemented as:
foo:mov r7,r2
shl r7,#8
shr r2,#8
or r2,r7
ret

but with this patch becomes:
foo:swpb r2
ret

Likewise, __builtin_bswap32 now becomes:
foo:swpb r2 | swpb r3 | swpw r2,r3
ret

Finally, the swpw instruction on its own can be used to exchange
two word mode registers without a temporary, so a new pattern and
peephole2 have been added to catch this.  As described in the
PR rtl-optimization/106518, register allocation can (in theory)
be more efficient on targets that provide a swap/exchange instruction.
The slightly unusual swap naming matches that used in i386.md.

2024-04-26  Roger Sayle  

gcc/ChangeLog
* config/stormy16/stormy16.md (bswaphi2): New define_insn.
(bswapsi2): New define_insn.
(swaphi): New define_insn to exchange two registers (swpw).
(define_peephole2): Recognize exchange of registers as swaphi.

gcc/testsuite/ChangeLog
* gcc.target/xstormy16/bswap16.c: New test case.
* gcc.target/xstormy16/bswap32.c: Likewise.
* gcc.target/xstormy16/swpb.c: Likewise.
* gcc.target/xstormy16/swpw-1.c: Likewise.
* gcc.target/xstormy16/swpw-2.c: Likewise.

[Bug c++/100157] Support `__type_pack_element` like Clang

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #14 from Jonathan Wakely  ---
Done for GCC 14

[Bug target/105991] [12 Regression] rldicl+sldi+add generated instead of rldimi

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

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

--- Comment #11 from Roger Sayle  ---
Doh!  This has been fixed on both the GCC 13 and GCC 12 branches. The target
milestone was when it was fixed, not when it will be fixed.

[Bug c++/99637] bit_cast doesn't work with padding bits and it should

[m.cencora at gmail dot com via Gcc-bugs]

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

m.cencora at gmail dot com changed:

   What|Removed |Added

 CC||m.cencora at gmail dot com

--- Comment #8 from m.cencora at gmail dot com ---
I think that gcc is incorrect here, because the standard says:
"Each bit of the value representation of the result is equal to the
corresponding bit in the object representation of from."

Padding bits are part of object representation, so if padding bits are properly
initialized in source object (which is the case here), the values of padding
bits should become a part of value representation of destination object.

Also when reading the proposal p0476r2 it is clearly stated that bit_cast is
suppose to be typesafe and constexpr-compatible alternative to memcpy (which by
definition copies padding bits as is).

[Bug libstdc++/109631] New: Simple std::optional types returned on stack, not registers

[david at westcontrol dot com via Gcc-bugs]

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

Bug ID: 109631
   Summary: Simple std::optional types returned on stack, not
registers
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david at westcontrol dot com
  Target Milestone: ---

A std::optional is fundamentally like a std::pair, but with nice
access features, type safety, etc.  But for simple functions it is
significantly less efficient, because in gcc it is returned on the stack even
when T fits in a single register.



On targets such as x86-64 and AARCH64, simple structs and pairs that fit in two
registers, are returned in two registers - there is no need for the caller to
reserve stack space and pass a hidden pointer to the callee function.  On clang
with its standard library, this also applies to std::optional for suitable
types T such as "int", but on gcc and its standard C++ library, the stack is
used for returning the std::optional.  Since both clang and gcc follow the
same calling conventions, this must (I believe) be a result of different
implementations of std::optional<> in the C++ libraries.

(I note that code for std::pair is more efficient here than using
std::pair.  But perhaps the details of std::optional<> require that
the contained element comes first.)



#include 
#include 

using A = std::optional;
using B = std::pair;
using C = std::pair;

A foo_A(int x) {
return x;
}

B foo_b(int x) {
B y { x, true };
return y;
}

C foo_c(int x) {
C y { true, x };
return y;
}

[Bug c++/109247] [13/14 Regression] optional o; o = {x}; wants to use explicit optional(U) constructor since r13-6765-ga226590fefb35ed6

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|13.0|13.2

--- Comment #10 from Richard Biener  ---
GCC 13.1 is being released, retargeting bugs to GCC 13.2.

[Bug tree-optimization/109213] [13/14 Regression] -Os generates significantly more code since r13-723

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|13.0|13.2

--- Comment #9 from Richard Biener  ---
GCC 13.1 is being released, retargeting bugs to GCC 13.2.

[Bug fortran/109622] [13/14 regression][OpenACC] internal compiler error: in omp_group_base, at gimplify.cc:9412 if -fopenacc is set.

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|13.0|13.2

--- Comment #8 from Richard Biener  ---
GCC 13.1 is being released, retargeting bugs to GCC 13.2.

[Bug target/109087] csmith: end of year runtime bug since r13-4839-geef81eefcdc2a581

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|13.0|13.2

--- Comment #19 from Richard Biener  ---
GCC 13.1 is being released, retargeting bugs to GCC 13.2.

[Bug ada/109472] [13/14 regression] False unread/unassigned warning for variable in local package since r13-1626-ga8d17a88a52d2f

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|13.0|13.2

--- Comment #3 from Richard Biener  ---
GCC 13.1 is being released, retargeting bugs to GCC 13.2.