[Bug tree-optimization/108635] New: Redundant calls to C++ spaceship operator<=> with attribute pure or const

[jzwinck at gmail dot com via Gcc-bugs]

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

Bug ID: 108635
   Summary: Redundant calls to C++ spaceship operator<=> with
attribute pure or const
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jzwinck at gmail dot com
  Target Milestone: ---

This code seems to have a missed optimization in GCC 10/11/12:

#include 

struct S
{
std::weak_ordering operator<=>(const S&) const __attribute__((const));
};

int compare3way(S& a, S& b)
{
return (a < b) ? -1 : (a > b) ? 1 : 0;
}

I expect operator<=> to be called once, but it is called twice.  This can be a
major missed optimization if operator<=> is expensive.  It happens regardless
of:

 1. Using attribute((const)) or attribute((pure)).
 2. Making operator<=> a free function or a member.
 3. Comparing (a > b) or (a < b) in the second ternary expression.  This is
especially strange, because it's really calling the same pure function twice,
and that's optimized correctly when the function being called is operator<
instead of operator<=>.

Clang optimizes it as expected.

Demo: https://godbolt.org/z/jP51E6xaz

[Bug target/108583] [13 Regression] wrong code with vector division by uint16 at -O2

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

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

--- Comment #21 from Tamar Christina  ---
> 
> OK, so that's an ADD_HIGHPART_EXPR then?  Though the highpart of an
> add is only a single bit, isn't it?  For scalar you'd use the
> carry bit here and instructions like adc to consume it.  Is addhn
> to do such thing on vectors?
> 

So I think this is the only new IFN we'd need. basically we only need one
representing (a + b) >> n, for certain values of n we have a single instruction
for others we reject it.

So I think we can just do two of these back to back and that should work.  If
this is ok I can implement it today.

[Bug tree-optimization/106157] [13 Regression] ICE verify_ssa failed since r13-1268-g8c99e307b20c502e

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
The fix looks unrelated and probably changed the IL flowing into DOM.  I'd
still say "fixed" here and wait for a new testcase.  Does the original ICE on
unreduced sources still happen?

There have been many fixes in threading inbetween that could have been the real
fix as well btw.

[Bug middle-end/108623] We need to grow the precision field in tree_type_common for PowerPC

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #9 from rguenther at suse dot de  ---
On Wed, 1 Feb 2023, meissner at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108623
> 
> Michael Meissner  changed:
> 
>What|Removed |Added
> 
>Last reconfirmed||2023-02-01
>  Ever confirmed|0   |1
>  Status|UNCONFIRMED |NEW
> 
> --- Comment #6 from Michael Meissner  ---
> Yes I agree we want an assetion in sext_hwi as well.
> 
> Richard, are you going to submit the patch, or did you want me to do it (along
> with the assertion)?

Please you do it, as far as I understand Richard S. no further adjustment
is necessary but we could simplify some code after the change(?)

[Bug bootstrap/60160] Building with -flto in CFLAGS_FOR_TARGET / CXXFLAGS_FOR_TARGET

[a.heider at gmail dot com via Gcc-bugs]

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

Andre Heider  changed:

   What|Removed |Added

 CC||a.heider at gmail dot com

--- Comment #8 from Andre Heider  ---
I tried this too, and so far I ran into this build failure:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108630

With --enable-symvers=no as a workaround the build succeeds with a shared
libstdc++.

If I build the target's toolchain libraries with LTO (using
{C,CXX,LD}FLAGS_FOR_TARGET), some userland apps fail to link with mold:
mold: error: undefined symbol: __EH_FRAME_BEGIN__.lto_priv.0

Where as bfd links without errors.

As per this bug's description "1. crtstuff.c: perhaps it'd be better to compile
it with -fno-lto." I tried this patch:
diff -ur a/libgcc/Makefile.in b/libgcc/Makefile.in
--- a/libgcc/Makefile.in2022-08-19 10:09:54.664689148 +0200
+++ b/libgcc/Makefile.in2023-02-01 21:56:50.561528520 +0100
@@ -301,7 +301,7 @@
 CRTSTUFF_CFLAGS = -O2 $(GCC_CFLAGS) $(INCLUDES) $(MULTILIB_CFLAGS) -g0 \
   $(NO_PIE_CFLAGS) -finhibit-size-directive -fno-inline -fno-exceptions \
   -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize \
-  -fbuilding-libgcc -fno-stack-protector $(FORCE_EXPLICIT_EH_REGISTRY) \
+  -fbuilding-libgcc -fno-stack-protector -fno-lto
$(FORCE_EXPLICIT_EH_REGISTRY) \
   $(INHIBIT_LIBC_CFLAGS) $(USE_TM_CLONE_REGISTRY)


And then the mold linker can build the userland apps in question too.

I only saw this later, but that's one hunk of the patch in comment #4. Is that
patch correct and worth commiting?

[Bug target/108583] [13 Regression] wrong code with vector division by uint16 at -O2

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #22 from rguenther at suse dot de  ---
On Thu, 2 Feb 2023, tnfchris at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
> 
> --- Comment #21 from Tamar Christina  ---
> > 
> > OK, so that's an ADD_HIGHPART_EXPR then?  Though the highpart of an
> > add is only a single bit, isn't it?  For scalar you'd use the
> > carry bit here and instructions like adc to consume it.  Is addhn
> > to do such thing on vectors?
> > 
> 
> So I think this is the only new IFN we'd need. basically we only need one
> representing (a + b) >> n, for certain values of n we have a single 
> instruction
> for others we reject it.

But the ISA only implements n == width(a), so a true "highpart add".
So I'd add

OPTAB_D (sadd_highpart_optab, "sadd$a3_highpart")
OPTAB_D (uadd_highpart_optab, "uadd$a3_highpart")

only?  That is it's QImode + QImode -> QImode with the carry bit in
the result (sign or zero-extended)?

[Bug target/108583] [13 Regression] wrong code with vector division by uint16 at -O2

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

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

--- Comment #23 from Tamar Christina  ---
(In reply to rguent...@suse.de from comment #22)
> On Thu, 2 Feb 2023, tnfchris at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
> > 
> > --- Comment #21 from Tamar Christina  ---
> > > 
> > > OK, so that's an ADD_HIGHPART_EXPR then?  Though the highpart of an
> > > add is only a single bit, isn't it?  For scalar you'd use the
> > > carry bit here and instructions like adc to consume it.  Is addhn
> > > to do such thing on vectors?
> > > 
> > 
> > So I think this is the only new IFN we'd need. basically we only need one
> > representing (a + b) >> n, for certain values of n we have a single 
> > instruction
> > for others we reject it.
> 
> But the ISA only implements n == width(a), so a true "highpart add".
> So I'd add
> 
> OPTAB_D (sadd_highpart_optab, "sadd$a3_highpart")
> OPTAB_D (uadd_highpart_optab, "uadd$a3_highpart")
> 
> only?  That is it's QImode + QImode -> QImode with the carry bit in
> the result (sign or zero-extended)?

Sure that works I think, I'll do that then.

[Bug middle-end/108435] [13 Regression] ICE in as_a, at is-a.h:242 since r13-142-g705bcedf6eae2d7c

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

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

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

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

commit r13-5643-g0f349928e16fdc7dba52561e8d40347909f9f0ff
Author: Jakub Jelinek 
Date:   Thu Feb 2 09:54:18 2023 +0100

nested, openmp: Wrap OMP_CLAUSE_*_GIMPLE_SEQ into GIMPLE_BIND for
declare_vars [PR108435]

When gimplifying OMP_CLAUSE_{LASTPRIVATE,LINEAR}_STMT, we wrap it always
into a GIMPLE_BIND, but when putting statements directly into
OMP_CLAUSE_{LASTPRIVATE,LINEAR}_GIMPLE_SEQ, we do it only if needed (there
are any temporaries that need to be declared in the sequence).
convert_nonlocal_omp_clauses was relying on the GIMPLE_BIND to be there
always
because it called declare_vars on it.

The following patch wraps it into GIMPLE_BIND in tree-nested if we need to
declare_vars on it on demand.

2023-02-02  Jakub Jelinek  

PR middle-end/108435
* tree-nested.cc (convert_nonlocal_omp_clauses)
: If info->new_local_var_chain and
*seq
is not a GIMPLE_BIND, wrap the sequence into a new GIMPLE_BIND
before calling declare_vars.
(convert_nonlocal_omp_clauses) : Merge
with the OMP_CLAUSE_LASTPRIVATE handling except for whether
seq is initialized to &OMP_CLAUSE_LASTPRIVATE_GIMPLE_SEQ (clause)
or &OMP_CLAUSE_LINEAR_GIMPLE_SEQ (clause).

* gcc.dg/gomp/pr108435.c: New test.

[Bug tree-optimization/108601] [13 Regression] vector peeling ICEs with VLA in gcc_r in SPEC2017 since g:c13223b790bbc5e4a3f5605e057eac59b61b2c85

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

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

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

https://gcc.gnu.org/g:209f02b0a9e9adc0bf0247cb5eef04e0f175d64e

commit r13-5644-g209f02b0a9e9adc0bf0247cb5eef04e0f175d64e
Author: liuhongt 
Date:   Wed Feb 1 13:30:12 2023 +0800

Don't peel nonlinear iv(mult or shift) for epilog when vf is not constant.

Normally when vf is not constant, it will be prevented by
vectorizable_nonlinear_inductions, but for this case, it failed going
into

if (STMT_VINFO_RELEVANT_P (stmt_info))
  {
need_to_vectorize = true;
if (STMT_VINFO_DEF_TYPE (stmt_info) == vect_induction_def
   && ! PURE_SLP_STMT (stmt_info))
  ok = vectorizable_induction (loop_vinfo,
   stmt_info, NULL, NULL,
   &cost_vec);

since the iv is never used outside of the loop, and will be dce later, so
vectorizer doesn't bother checking if it's vectorizable. it's
true but hit gcc_assert in vect_can_peel_nonlinear_iv_p when vf is not
constant. One solution is ignoring the nonlinear iv peeling if it's
!STMT_VINFO_RELEVANT_P (stmt_info) just like the upper code, the other
solution is returning false earlier in the
vect_can_peel_nonlinear_iv_p when vf is not constant, the patch chooses
the second incase there's other cases using vect_can_advance_ivs_p which
calls vect_can_peel_nonlinear_iv_p.
Also remove vect_peel_nonlinear_iv_p from
vectorizable_nonlinear_inductions.

gcc/ChangeLog:

PR tree-optimization/108601
* tree-vectorizer.h (vect_can_peel_nonlinear_iv_p): Removed.
* tree-vect-loop.cc
(vectorizable_nonlinear_induction): Remove
vect_can_peel_nonlinear_iv_p.
(vect_can_peel_nonlinear_iv_p): Don't peel
nonlinear iv(mult or shift) for epilog when vf is not
constant and moved the defination to ..
* tree-vect-loop-manip.cc (vect_can_peel_nonlinear_iv_p):
.. Here.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/pr108601.c: New test.

[Bug middle-end/108623] We need to grow the precision field in tree_type_common for PowerPC

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

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

--- Comment #10 from rsandifo at gcc dot gnu.org  
---
(In reply to rguent...@suse.de from comment #9)
> Please you do it, as far as I understand Richard S. no further adjustment
> is necessary but we could simplify some code after the change(?)
Yeah.  AFAIK, nothing outside these two macros relies on the representation.

[Bug rtl-optimization/108596] [10/11/12 Regression] error: EDGE_CROSSING missing across section boundary

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #7 from David Binderman  ---
(In reply to Jakub Jelinek from comment #6)
> Fixed on the trunk so far.

linux-6.2-rc6 builds fine, when built with -O3.

Thanks for the quick fix.

[Bug libstdc++/104883] should define all std::errc enumerators

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:

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

commit r12-9099-gaa18735f7aa99b40c56b3e3aacb1b28cb805bb90
Author: Jonathan Wakely 
Date:   Tue Jan 31 22:16:31 2023 +

libstdc++: Fix build failures for avr

The abr-libc  does not define EOVERFLOW, which means that
std::errc::value_too_large is not defined, and so  cannot be
compiled. Define value_too_large for avr with a value that does not
clash with any that is defined in . This is a kluge to fix
bootstrap for avr; it can be removed after PR libstdc++/104883 is
resolved.

The avr-libc  fails to meet the C and POSIX requirements that
each error macro has a distinct integral value, and is usable in #if
directives. Add a special case for avr to system_error.cc so that only
the valid errors are recognized. Also disable the errno checks in
std::filesystem::remove_all that assume a meaningful value for errno.

On avr-libc  exists but does not define the POSIX functions
needed by std::filesystem, so _GLIBCXX_HAVE_UNISTD_H is not sufficient
to check for basic POSIX APIs. Check !defined __AVR__ as well as
_GLIBCXX_HAVE_UNISTD_H before using those functions. This is a kluge and
we should really have a specific macro that says the required functions
are available.

libstdc++-v3/ChangeLog:

* config/os/generic/error_constants.h (errc::value_too_large)
[__AVR__]: Define.
* src/c++11/system_error.cc
(system_category::default_error_condition) [__AVR__]: Only match
recognize values equal to EDOM, ERANGE, ENOSYS and EINTR.
* src/c++17/fs_ops.cc (fs::current_path) [__AVR__]: Do not check
for ENOENT etc. in switch.
(fs::remove_all) [__AVR__]: Likewise.
* src/filesystem/ops-common.h [__AVR__]: Do not use POSIX open,
close etc.

(cherry picked from commit 2d2e163d12f64a5e68f9e0381751ed9d5d6d3617)

[Bug tree-optimization/108635] Redundant calls to C++ spaceship operator<=> with attribute pure or const

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

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

--- Comment #1 from Andrew Pinski  ---
I suspect you need noexcept too. Otherwise you could in theory have an
exception.

[Bug tree-optimization/108635] Redundant calls to C++ spaceship operator<=> with attribute pure or const

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
GCC still makes two calls even if it's noexcept.

[Bug tree-optimization/108635] Redundant calls to C++ spaceship operator<=> with attribute pure or const

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Then it might be a dup of bug 45115

[Bug tree-optimization/45115] pure functions returning structs are not optimized.

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||jzwinck at gmail dot com

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

[Bug tree-optimization/108635] Redundant calls to C++ spaceship operator<=> with attribute pure or const

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Yes it is a dup.

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

[Bug ipa/107300] [13 Regression] ICE: verify_ssa failed (error: virtual definition of statement not up to date)

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r13-5645-gd2423144eb36a68fd0da9224857ce807714874a7
Author: Jakub Jelinek 
Date:   Thu Feb 2 10:54:54 2023 +0100

Replace IFN_TRAP with BUILT_IN_UNREACHABLE_TRAP [PR107300]

For PR106099 I've added IFN_TRAP as an alternative to __builtin_trap
meant for __builtin_unreachable purposes (e.g. with -funreachable-traps
or some sanitizers) which doesn't need vops because __builtin_unreachable
doesn't need them either.  This works in various cases, but unfortunately
IPA likes to decide on the redirection to unreachable just by tweaking
the cgraph edge to point to a different FUNCTION_DECL.  As internal
functions don't have a decl, this causes problems like in the following
testcase.

The following patch fixes it by removing IFN_TRAP again and replacing
it with user inaccessible BUILT_IN_UNREACHABLE_TRAP, so that e.g.
builtin_decl_unreachable can return it directly and we don't need to tweak
it later in wherever we actually replace the call stmt.

2023-02-02  Jakub Jelinek  

PR ipa/107300
* builtins.def (BUILT_IN_UNREACHABLE_TRAP): New builtin.
* internal-fn.def (TRAP): Remove.
* internal-fn.cc (expand_TRAP): Remove.
* tree.cc (build_common_builtin_nodes): Define
BUILT_IN_UNREACHABLE_TRAP if not yet defined.
(builtin_decl_unreachable): Use BUILT_IN_UNREACHABLE_TRAP
instead of BUILT_IN_TRAP.
* gimple.cc (gimple_build_builtin_unreachable): Remove
emitting internal function for BUILT_IN_TRAP.
* asan.cc (maybe_instrument_call): Handle
BUILT_IN_UNREACHABLE_TRAP.
* cgraph.cc (cgraph_edge::verify_corresponds_to_fndecl): Handle
BUILT_IN_UNREACHABLE_TRAP instead of BUILT_IN_TRAP.
* ipa-devirt.cc (possible_polymorphic_call_target_p): Handle
BUILT_IN_UNREACHABLE_TRAP.
* builtins.cc (expand_builtin, is_inexpensive_builtin): Likewise.
* tree-cfg.cc (verify_gimple_call,
pass_warn_function_return::execute): Likewise.
* attribs.cc (decl_attributes): Don't report exclusions on
BUILT_IN_UNREACHABLE_TRAP either.

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

[Bug tree-optimization/108625] [11/12/13 Regression] forwprop introduces new UB

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
we come from

  t_2 = -x_1(D);
  t1_3 = (unsigned char) t_2;
  t2_4 = (unsigned char) t_2;
  _5 = t1_3 + t2_4;

where

  t_2 + t_2

"simplifies", but somehow the ! constraint isn't honored.  We do

res_op->set_op (NOP_EXPR, type, 1);
{
  tree _o1[2], _r1;
  _o1[0] = captures[0];
  _o1[1] = captures[1];
  gimple_match_op tem_op (res_op->cond.any_else (), op,
TREE_TYPE (_o1[0]), _o1[0], _o1[1]); 
  tem_op.resimplify (lseq, valueize);
  _r1 = maybe_push_res_to_seq (&tem_op, NULL);
  if (!_r1) goto next_after_fail1082;
  res_op->ops[0] = _r1;

so the intent is that the maybe_push_res_to_seq (..., NULL) will catch
not simplified operands of the (convert).

The issue is that we go through

 /* A + (-B) -> A - B */
 (simplify
  (plus:c @0 (convert? (negate @1))) 
  /* Apply STRIP_NOPS on the negate.  */
  (if (tree_nop_conversion_p (type, TREE_TYPE (@1))
   && !TYPE_OVERFLOW_SANITIZED (type))
   (with
{
 tree t1 = type;
 if (INTEGRAL_TYPE_P (type)
 && TYPE_OVERFLOW_WRAPS (type) != TYPE_OVERFLOW_WRAPS (TREE_TYPE (@1)))
   t1 = TYPE_OVERFLOW_WRAPS (type) ? type : TREE_TYPE (@1);
}  
(convert (minus (convert:t1 @0) (convert:t1 @1))

and

/* Basic strip-useless-type-conversions / strip_nops.  */
(for cvt (convert view_convert float fix_trunc)
 (simplify
  (cvt @0)
  (if ((GIMPLE && useless_type_conversion_p (type, TREE_TYPE (@0)))
   || (GENERIC && type == TREE_TYPE (@0)))
   @0)))

which defeats the check because the

  tem_op.resimplify (lseq, valueize);

ends up with

  _7 = t_2 - x_1(D);

in the 'lseq' and plain _7 in tem_op.  We could fix this by using a
NULL lseq in the resimplification as well at the expense of not
catching some more complicated simplifications to "leafs" or
alternatively do a more complicated check for the force_leaf case,
checking the actual leaf and if SSA name, verify the definition is
not in 'lseq'.

I'm going to test the simpler NULL lseq to resimplify variant.

[Bug target/107674] [11/12/13 Regressions] arm: MVE codegen regressions on VCTP and vector LDR/STR instructions

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Andre Simoes Dias Vieira
:

https://gcc.gnu.org/g:75b58e77706e8b5057770f040005950940a9a0f5

commit r13-5646-g75b58e77706e8b5057770f040005950940a9a0f5
Author: Andre Vieira 
Date:   Thu Feb 2 10:00:57 2023 +

arm: Fix sign of MVE predicate mve_pred16_t [PR 107674]

The ACLE defines mve_pred16_t as an unsigned short.  This patch makes sure
GCC
treats the predicate as an unsigned type, rather than signed.

gcc/ChangeLog:

PR target/107674
* config/arm/arm-builtins.cc (arm_simd_builtin_type): Rewrite to
use
new qualifiers parameter and use unsigned short type for MVE
predicate.
(arm_init_builtin): Call arm_simd_builtin_type with qualifiers
parameter.
(arm_init_crypto_builtins): Likewise.

gcc/testsuite/ChangeLog:

PR target/107674
* gcc.target/arm/mve/mve_vpt.c: New test.

[Bug target/108443] arm: MVE wrongly re-interprets predicate constants

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Andre Simoes Dias Vieira
:

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

commit r13-5648-ge0bc13d396002f88b8c27e3a23c7eaee54d379d5
Author: Andre Vieira 
Date:   Thu Feb 2 10:01:30 2023 +

arm: Fix MVE predicates synthesis [PR 108443]

This patch fixes the way we synthesize MVE predicate immediates and fixes
some
other inconsistencies around predicates. For instance this patch fixes the
modes
used in the vctp intrinsics, to couple them with predicate modes with the
appropriate lane numbers. For this V2QI is added to represent a predicate
created by vctp64q. The reason we use V2QI and not for instance a V2BI with
8-bit boolean modes is because we are trying to avoid having two 'INT'
modes of
the same size. We make sure we use the V2QI mode instead of HI for any
instruction working on two lanes of 64-bits consuming a predicate.

gcc/ChangeLog:

PR target/108443
* config/arm/arm.h (VALID_MVE_PRED_MODE): Add V2QI.
* config/arm/arm.cc (thumb2_legitimate_address_p): Use HImode for
addressing MVE predicate modes.
(mve_bool_vec_to_const): Change to represent correct MVE predicate
format.
(arm_hard_regno_mode_ok): Use VALID_MVE_PRED_MODE instead of
checking
modes.
(arm_vector_mode_supported_p): Likewise.
(arm_mode_to_pred_mode): Add V2QI.
* config/arm/arm-builtins.cc (UNOP_PRED_UNONE_QUALIFIERS): New
qualifier.
(UNOP_PRED_PRED_QUALIFIERS): New qualifier
(BINOP_PRED_UNONE_PRED_QUALIFIERS): New qualifier.
(v2qi_UP): New macro.
(v4bi_UP): New macro.
(v8bi_UP): New macro.
(v16bi_UP): New macro.
(arm_expand_builtin_args): Make it able to expand the new predicate
modes.
* config/arm/arm-modes.def (V2QI): New mode.
* config/arm/arm-simd-builtin-types.def (Pred1x16_t, Pred2x8_t
Pred4x4_t): Remove unused predicate builtin types.
* config/arm/arm_mve.h (__arm_vctp16q, __arm_vctp32q,
__arm_vctp64q,
__arm_vctp8q, __arm_vpnot, __arm_vctp8q_m, __arm_vctp64q_m,
__arm_vctp32q_m, __arm_vctp16q_m): Use predicate modes.
* config/arm/arm_mve_builtins.def (vctp16q, vctp32q, vctp64q,
vctp8q,
vpnot, vctp8q_m, vctp16q_m, vctp32q_m, vctp64q_m): Likewise.
* config/arm/constraints.md (DB): Check for VALID_MVE_PRED_MODE
instead
of MODE_VECTOR_BOOL.
* config/arm/iterators.md (MVE_7, MVE_7_HI): Add V2QI
(MVE_VPRED): Likewise.
(MVE_vpred): Add V2QI and map upper case predicate modes to lower
case.
(MVE_vctp): New mode attribute.
(mode1): Remove.
(VCTPQ): Remove.
(VCTPQ_M): Remove.
* config/arm/mve.md (mve_vctpqhi): Rename this...
(mve_vctpq): ... to this. And use new mode
attributes.
(mve_vpnothi): Rename this...
(mve_vpnotv16bi): ... to this.
(mve_vctpq_mhi): Rename this...
(mve_vctpq_m):... to this.
(mve_vldrdq_gather_base_z_v2di,
mve_vldrdq_gather_offset_z_v2di,
mve_vldrdq_gather_shifted_offset_z_v2di,
mve_vstrdq_scatter_base_p_v2di,
mve_vstrdq_scatter_offset_p_v2di,
mve_vstrdq_scatter_offset_p_v2di_insn,
mve_vstrdq_scatter_shifted_offset_p_v2di,
mve_vstrdq_scatter_shifted_offset_p_v2di_insn,
mve_vstrdq_scatter_base_wb_p_v2di,
mve_vldrdq_gather_base_wb_z_v2di,
mve_vldrdq_gather_base_nowb_z_v2di,
mve_vldrdq_gather_base_wb_z_v2di_insn):  Use V2QI insead of
HI for
predicates.
* config/arm/unspecs.md (VCTP8Q, VCTP16Q, VCTP32Q, VCTP64Q):
Replace
these...
(VCTP): ... with this.
(VCTP8Q_M, VCTP16Q_M, VCTP32Q_M, VCTP64Q_M): Replace these...
(VCTP_M): ... with this.
* config/arm/vfp.md (*thumb2_movhi_vfp, *thumb2_movhi_fp16): Use
VALID_MVE_PRED_MODE instead of checking for MODE_VECTOR_BOOL class.

gcc/testsuite/ChangeLog:

* gcc.target/arm/mve/pr108443-run.c: New test.
* gcc.target/arm/mve/pr108443.c: New test.

[Bug target/107674] [11/12/13 Regressions] arm: MVE codegen regressions on VCTP and vector LDR/STR instructions

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Andre Simoes Dias Vieira
:

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

commit r13-5647-gd45ec8a732f449647afa89e46b80a4e0614ec28d
Author: Andre Vieira 
Date:   Thu Feb 2 10:01:13 2023 +

arm: Remove unnecessary zero-extending of MVE predicates before use [PR
107674]

This patch teaches GCC that zero-extending a MVE predicate from 16-bits to
32-bits and then only using 16-bits is a no-op.
It does so in two steps:
- it lets gcc know that it can access any MVE predicate mode using any
other MVE
predicate mode without needing to copy it, using the TARGET_MODES_TIEABLE_P
hook,
- it teaches simplify_subreg to optimize a subreg with a vector outermode,
by
replacing this outermode with a same-sized integer mode and trying the
avalailable optimizations, then if successful it surrounds the result with
a
subreg casting it back to the original vector outermode.

gcc/ChangeLog:

PR target/107674
* config/arm/arm.cc (arm_hard_regno_mode_ok): Use new MACRO.
(arm_modes_tieable_p): Make MVE predicate modes tieable.
* config/arm/arm.h (VALID_MVE_PRED_MODE):  New define.
* simplify-rtx.cc (simplify_context::simplify_subreg): Teach
simplify_subreg to simplify subregs where the outermode is not
scalar.

gcc/testsuite/ChangeLog:

* gcc.target/arm/mve/mve_vpt.c: Change to remove unecessary
zero-extend.

[Bug c++/108626] GCC doesn't deduplicate string literals for const char*const and const char[]

[marat at slonopotamus dot org via Gcc-bugs]

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

--- Comment #5 from Marat Radchenko  ---
So, does "String literals, and compound literals with const-qualified types,
need not designate distinct objects." apply here or not? If not, how does the
case where it applies look like?

https://en.cppreference.com/w/c/language/compound_literal explicitly says
(though I do understand this is not a 100% reliable source):

Compound literals of const-qualified character or wide character array types
may share storage with string literals.


(const char []){"abc"} == "abc" // might be 1 or 0, implementation-defined


Comparison with string literals isn't actually implementation-defined but
instead unspecified behavior, but the point here is that they think it is
possible memory is shared.

[Bug tree-optimization/45115] pure functions returning structs are not optimized.

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

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

--- Comment #4 from Jonathan Wakely  ---
This affects C++20 three-way comparisons, which return trivial structs wrapping
an integer.

>From PR 108635:

#include 

struct S
{
std::weak_ordering operator<=>(const S&) const __attribute__((const));
};

int compare3way(S& a, S& b)
{
return (a < b) ? -1 : (a > b) ? 1 : 0;
}

I expect operator<=> to be called once, but it is called twice.  This can be a
major missed optimization if operator<=> is expensive.  It happens regardless
of:

 1. Using attribute((const)) or attribute((pure)).
 2. Making operator<=> a free function or a member.
 3. Comparing (a > b) or (a < b) in the second ternary expression.  This is
especially strange, because it's really calling the same pure function twice,
and that's optimized correctly when the function being called is operator<
instead of operator<=>.

Clang optimizes it as expected.

Demo: https://godbolt.org/z/jP51E6xaz

[Bug tree-optimization/108500] [11/12 Regression] -O -finline-small-functions results in "internal compiler error: Segmentation fault" on a very large program (700k function calls)

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org

--- Comment #14 from Richard Biener  ---
Thanks for the new testcase.  With -O0 (and a --enable-checking=release built
compiler) this builds in ~11 minutes (on a Ryzen 9 7900X) with

 integrated RA  :  38.96 (  6%)   1.94 ( 20%)  42.00 (  6%)
 3392M ( 23%)
 LRA non-specific   :  18.93 (  3%)   1.24 ( 13%)  23.78 (  4%)
  450M (  3%)
 LRA virtuals elimination   :   5.67 (  1%)   0.05 (  1%)   5.75 (  1%)
  457M (  3%)
 LRA reload inheritance : 318.25 ( 49%)   0.24 (  2%) 318.51 ( 48%)
0  (  0%)
 LRA create live ranges : 199.24 ( 31%)   0.12 (  1%) 199.38 ( 30%)
  228M (  2%)
645.67user 10.29system 11:04.42elapsed 98%CPU (0avgtext+0avgdata
30577844maxresident)k
3936200inputs+1091808outputs (122053major+10664929minor)pagefaults 0swaps

so register allocation taking all of the time.  There's maybe the possibility
to gate some of its features on the # of BBs or insns (or whatever the actual
"bad" thing is - I didn't look closer yet).

It also seems to use 30GB of peak memory at -O0 ...

For -O the situation is "better":

 tree PTA   : 987.21 ( 99%)   0.41 ( 12%) 987.70 ( 99%)
  128  (  0%)
992.56user 3.53system 16:36.20elapsed 99%CPU (0avgtext+0avgdata
2968740maxresident)k
42576inputs+8outputs (28major+717414minor)pagefaults 0swaps

which suggests a clear workaround, -fno-tree-pta, which makes it compile
in 5s for me.

Doing -O -finline-small-functions -fno-tree-pta we get a very high
compile-time in SRAs propagate_all_subaccesses which probably sees
a very large struct copy chain

  tem1 = s2;
  s2 = tem1;
  tem2 = s2;
  s2 = tem2;
...

and somehow ends up quadratic (possibly switching the candidate_bitmap
to tree form at the start of propagate_all_subaccesses will help a bit).
tree form bitmap doesn't help, I guess we end up queueing all elements in
the copy chain to the worklist and via the chains end up with a O(n^2)
working set.  The testcase can probably be shortened to get at this
problem.  SRA is actually quite important here, so disabling SRA as a
workaround doesn't look to improve the situation a lot.

Still with -fno-tree-sra added we get good compile time and DCE/DSE
remove all code plus -fno-tree-pta isn't required.

Martin, can you look at the SRA issue?  Do you want me to create a separate
bugreport for this?  The IL into SRA looks like

   :
  s2D.2755 = {};
  s1D.2756 = {};
  _unusedD.2002766 = s1D.2756;
  sD.2002767 = s2D.2755;
  s2D.2755 = sD.2002767;
  _unusedD.2002766 ={v} {CLOBBER(eol)};
  sD.2002767 ={v} {CLOBBER(eol)};
  _unusedD.2002764 = s1D.2756;
  sD.2002765 = s2D.2755;
  s2D.2755 = sD.2002765;
  _unusedD.2002764 ={v} {CLOBBER(eol)};
  sD.2002765 ={v} {CLOBBER(eol)};
  _unusedD.2002762 = s1D.2756;
  sD.2002763 = s2D.2755;
  s2D.2755 = sD.2002763;
  _unusedD.2002762 ={v} {CLOBBER(eol)};
  sD.2002763 ={v} {CLOBBER(eol)};
  _unusedD.2002760 = s1D.2756;
  sD.2002761 = s2D.2755;
  s2D.2755 = sD.2002761;
  _unusedD.2002760 ={v} {CLOBBER(eol)};
  sD.2002761 ={v} {CLOBBER(eol)};
...

[Bug libstdc++/108630] build failure with LTO enabled

[a.heider at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Andre Heider  ---
While this is a libstdc++ related LTO issue, there's at least another libgcc
one, see the linked bug #60160.

With the workaround here and the patch there the LTOed target libraries look
alot more sane, but I can't judge if that solves everything that needs to be
solved.

Based on some light testing on qemu that's at least a "works for me now" state
;)

[Bug tree-optimization/108500] [11/12 Regression] -O -finline-small-functions results in "internal compiler error: Segmentation fault" on a very large program (700k function calls)

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

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

--- Comment #15 from Richard Biener  ---
To not look at "nothing" (after successful SRA it should indeed become almost
nothing) I've added a store to a volatile 'x' global variable to the end
of main:

...
  s2 = f(s1,s2);
  x = s2;
  return 0;
}

not using main but a function returning a struct would probably work as well.
Otherwise DCE/DSE will remove all code.  Doing that reveals that RTL DSE
(more specifically rtx_equal_for_cselib_1) is very slow (via
dse_step1 calling cselib_process_insn).

I do wonder if you can share the "real" testcase?  It doesn't need to
be able to link, preprocessed source would be enough.

[Bug rtl-optimization/108086] [11/12/13 Regression] internal compiler error: in set_accesses, at rtl-ssa/internals.inl:449

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

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

--- Comment #16 from rsandifo at gcc dot gnu.org  
---
(In reply to Richard Biener from comment #13)
> (In reply to Richard Biener from comment #12)
> > A regression from GCC 10 which compiles this in 90s at -O1.
> > 
> > Richard?  Can you please look at this special-case of BB0 insn_info?
> 
> The following might be one way to "fix" it (until we do a bigger testcase)
> 
> diff --git a/gcc/rtl-ssa/insns.h b/gcc/rtl-ssa/insns.h
> index f7215972845..b0144f258b2 100644
> --- a/gcc/rtl-ssa/insns.h
> +++ b/gcc/rtl-ssa/insns.h
> @@ -403,8 +403,7 @@ private:
>// MAX_RECOG_OPERANDS is the maximum number of pseudos that can be
>// defined by an instruction, so the number of definitions should fit
>// easily in 16 bits.
> -  unsigned int m_num_uses;
> -  unsigned int m_num_defs : 16;
> +  unsigned int m_num_uses : 24;
The problem is that:

  // The number of definitions and the number uses.  FIRST_PSEUDO_REGISTER + 1
  // is the maximum number of accesses to hard registers and memory, and
  // MAX_RECOG_OPERANDS is the maximum number of pseudos that can be
  // defined by an instruction, so the number of definitions should fit
  // easily in 16 bits.

holds for real instructions, but not for artificial instructions.
Since we don't have any new justification for a limit less than 32 bits,
I think we'll just have to grow the structure.

[Bug ipa/107944] [11/12/13 Regression] ICE in cgraph_node::get_untransformed_body since r13-48-g27ee75dbe81bb7

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

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

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

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

commit r11-10496-ge36385be53d51539e1c295a80085115b24fede32
Author: Martin Jambor 
Date:   Thu Feb 2 12:22:22 2023 +0100

ipa: Release body more carefully when removing nodes (PR 107944)

The code removing function bodies when the last call graph clone of a
node is removed is too aggressive when there are nodes up the
clone_of chain which still need them.  Fixed by expanding the check.

gcc/ChangeLog:

2023-01-18  Martin Jambor  

PR ipa/107944
* cgraph.c (cgraph_node::remove): Check whether nodes up the
lcone_of chain also do not need the body.

(cherry picked from commit db959e250077ae6b4fc08f53fb322719582c5de6)

[Bug ipa/107944] [11/12/13 Regression] ICE in cgraph_node::get_untransformed_body since r13-48-g27ee75dbe81bb7

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

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Jambor  ---
Should be fixed everywhere.

[Bug c++/108626] GCC doesn't deduplicate string literals for const char*const and const char[]

[de34 at live dot cn via Gcc-bugs]

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

--- Comment #6 from Jiang An  ---
(In reply to Marat Radchenko from comment #5)
> So, does "String literals, and compound literals with const-qualified types,
> need not designate distinct objects." apply here or not? If not, how does
> the case where it applies look like?

I strongly believe that when compiling as C, the objects in your example are
allowed to be merged. But I'm not sure whether this is applicable to C++.

In C++ one may write:

constexpr char x = a[0]; // OK.
if constexpr (a == b) { // If the objects are merged then the following code is
in affect.
constexpr char y = b[0]; // Error! Because `b` is not usable in constant
expressions.
}

I'm afraid that it would be unreasonable for compiler to handle such confusing
case.

> https://en.cppreference.com/w/c/language/compound_literal explicitly says
> (though I do understand this is not a 100% reliable source):
> 
> Compound literals of const-qualified character or wide character array types
> may share storage with string literals.
> 
> 
> (const char []){"abc"} == "abc" // might be 1 or 0, implementation-defined
> 
> 
> Comparison with string literals isn't actually implementation-defined but
> instead unspecified behavior, but the point here is that they think it is
> possible memory is shared.


I've corrected the comment on cppreference. Now it's saying "unspecified".

[Bug c++/108636] New: C++20 to undefined reference to `std::filesystem::__cxx11::path::_List::type(std::filesystem::__cxx11::path::_Type)' with -fkeep-inline-functions

[hnc at singularity dot fr via Gcc-bugs]

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

Bug ID: 108636
   Summary: C++20 to undefined reference to
`std::filesystem::__cxx11::path::_List::type(std::file
system::__cxx11::path::_Type)' with
-fkeep-inline-functions
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hnc at singularity dot fr
  Target Milestone: ---

Hi

Compilers:
GCC 10.1 to 12.2

Code:
```
#include 
int main() { return 0; }
```

Flags:
`-std=c++20 -pedantic -fkeep-inline-functions`
(adding `-lstdc++fs` does not help)

The compilation fails with this link error:
```
in function `std::filesystem::__cxx11::path::path(std::basic_string_view >, std::filesystem::__cxx11::path::_Type)':
/usr/include/c++/12/bits/fs_path.h:606: undefined reference to
`std::filesystem::__cxx11::path::_List::type(std::filesystem::__cxx11::path::_Type)'
```

It compiles without `-fkeep-inline-functions` flag.

Thanks

[Bug sanitizer/108637] New: ASAN at -O2 misses a stack-use-after-scope

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 108637
   Summary: ASAN at -O2 misses a stack-use-after-scope
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

For the following code, ASAN at -O2 cannot detect the stack-use-after-scope.
This happens since GCC-11. GCC-10 and below work fine.

I understand that there is a type-incompatible warning. But I believe it should
not affect the ASAN anyway.

Compiler explorer: https://godbolt.org/z/WcbadP961

% cat a.c
char a, b, c;
short d;
int main() {
  {
long e = a;
for (; b <= 0; b++) {
  char *f;
  d = 2;
  for (; d; d--) {
int g = 111;
f = &g;
if (e)
  c = 0;
  }
  *f += 1;
  a = *f;
}
  }
}
%
% gcc-tk -fsanitize=address -O2 a.c && ./a.out
%
% gcc-tk -fsanitize=address -O1 a.c && ./a.out
=
==1==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fb285e00020
at pc 0x00401272 bp 0x7ffda17739c0 sp 0x7ffda17739b8
READ of size 1 at 0x7fb285e00020 thread T0
#0 0x401271 in main /a.c:15
#1 0x7fb28883d082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#2 0x4010bd in _start (/output.s+0x4010bd) (BuildId:
cb6e8e9c15b7d8e5515d7e6b8591d2b77b5f3e21)

Address 0x7fb285e00020 is located in stack of thread T0 at offset 32 in frame
#0 0x401185 in main /a.c:3

  This frame has 1 object(s):
[32, 36) 'g' (line 10) <== Memory access at offset 32 is inside this
variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism, swapcontext or vfork
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-use-after-scope /a.c:15 in main
Shadow bytes around the buggy address:
...
%

[Bug libstdc++/108636] C++20 to undefined reference to `std::filesystem::__cxx11::path::_List::type(std::filesystem::__cxx11::path::_Type)' with -fkeep-inline-functions

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||link-failure
   Last reconfirmed||2023-02-02
  Component|c++ |libstdc++

[Bug tree-optimization/108625] [11/12/13 Regression] forwprop introduces new UB

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:605d1297b91c2c7c23ccfe669e66dda5791d1f55

commit r13-5651-g605d1297b91c2c7c23ccfe669e66dda5791d1f55
Author: Richard Biener 
Date:   Thu Feb 2 11:09:26 2023 +0100

middle-end/108625 - wrong folding due to misinterpreted !

The following fixes a problem with ! handling in genmatch which isn't
conservative enough when intermediate simplifications push to the
sequence but the final operation appears to just pick an existing
(but in this case newly defined in the sequence) operand.  The easiest
fix is to disallow adding to the sequence when processing !.

PR middle-end/108625
* genmatch.cc (expr::gen_transform): Also disallow resimplification
from pushing to lseq with force_leaf.
(dt_simplify::gen_1): Likewise.

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

[Bug tree-optimization/108625] [11/12 Regression] forwprop introduces new UB

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
Summary|[11/12/13 Regression]   |[11/12 Regression] forwprop
   |forwprop introduces new UB  |introduces new UB
  Known to work||13.0

[Bug debug/106746] [13 Regression] '-fcompare-debug' failure (length) with -O2 -fsched2-use-superblocks since r13-2041-g6624ad73064de241

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

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

--- Comment #27 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:465a9c51e7d5bafa7a81195b5af20f2a54f22210

commit r13-5652-g465a9c51e7d5bafa7a81195b5af20f2a54f22210
Author: Jakub Jelinek 
Date:   Thu Feb 2 13:52:45 2023 +0100

sched-deps, cselib: Fix up some -fcompare-debug issues and regressions
[PR108463]

On Sat, Jan 14, 2023 at 08:26:00AM -0300, Alexandre Oliva via Gcc-patches
wrote:
> The testcase used to get scheduled differently depending on the
> presence of debug insns with MEMs.  It's not clear to me why those
> MEMs affected scheduling, but the cselib pre-canonicalization of the
> MEM address is not used at all when analyzing debug insns, so the
> memory allocation and lookup are pure waste.  Somehow, avoiding that
> waste fixes the problem, or makes it go latent.

Unfortunately, this patch breaks the following testcase.
The code in sched_analyze_2 did 2 things:
1) cselib_lookup_from_insn
2) shallow_copy_rtx + cselib_subst_to_values_from_insn
Now, 1) is precondition of 2), we can only subst the VALUEs if we
have actually looked the address up, but as can be seen on that testcase,
we are relying on at least the 1) to be done because we subst the values
later on even on DEBUG_INSNs and actually use those when needed.
cselib_subst_to_values_from_insn mostly just replaces stuff in the
returned rtx, except for:
  /* This used to happen for autoincrements, but we deal with them
 properly now.  Remove the if stmt for the next release.  */
  if (! e)
{
  /* Assign a value that doesn't match any other.  */
  e = new_cselib_val (next_uid, GET_MODE (x), x);
}
which is like that since 2011, I hope it is never reachable and we should
in stage1 replace that with gcc_assert or just remove (then it will
segfault on following
  return e->val_rtx;
).

So, I (as done in the patch below) reinstalled the 1) and not 2) for
DEBUG_INSNs.  This fixed the new testcase, but broke again the PR106746
testcases.

I've spent a day debugging that and found the problem is that as documented
in a large comment in cselib.cc above n_useless_values variable definition,
we spend quite a few effort on making sure that VALUEs created on
DEBUG_INSNs don't affect the cselib decisions for non-DEBUG_INSNs such as
pruning of useless values etc., but if a VALUE created that way is then
looked up/needed from non-DEBUG_INSNs, we promote it to non-debug.

The reason for -fcompare-debug failure is that there is one large
DEBUG_INSN
with 16 MEMs in it mostly with addresses that so far didn't appear in the
IL
otherwise.  Later on, we see an instruction storing into MEM destination
and invalidate that MEM.  Unfortunately, there is a bug caused by the
introduction of SP_DERIVED_VALUE_P where alias.cc isn't able to
disambiguate
MEMs with sp + optional offset in address vs. MEMs with address being a
VALUE having SP_DERIVED_VALUE_P + constant (or the SP_DERIVED_VALUE_P
itself), which ought to be possible when REG_VALUES (REGNO
(stack_pointer_rtx)) has SP_DERIVED_VALUE_P + constant location.  Not sure
if I should try to fix that in stage4 or defer for stage1.
Anyway, the cselib_invalidate_mem call because of this invalidates
basically
all MEMs with the exception of 5 which have MEM_EXPRs that guarantee
non-aliasing with the sp based store.
Unfortunately, n_useless_values which in my understanding should be always
the same between -g and -g0 compilations diverges, has 3 more useless
values
for -g.

Now, these were initially VALUEs created for DEBUG_INSN lookups.  As I
said,
cselib.cc has code to promote such VALUEs (well, their location elements)
to
non-debug if they are looked up from non-DEBUG_INSNs.  The problem is that
when looking some completely unrelated MEM from a non-DEBUG_INSN we run
into
a hash collision and so call cselib_hasher::equal to check if the unrelated
MEM is equal to the one from DEBUG_INSN only element.  The equal static
member function calls rtx_equal_for_cselib_1 and if that returns true,
promotes the location to non-DEBUG, otherwise returns false.  So far so
good.  But rtx_equal_for_cselib_1 internally performs various other cselib
lookups, all done with the non-DEBUG_INSN cselib_current_insn, so they
all promote to non-debug.  And that is wrong, because if it was -g0
compilation, such hashtable entry wouldn't be there at all (or would be
but wouldn't contain that locs element), so with -g0 we wouldn't call
that rtx_equal_for_cselib_1 at all.  So, I think we need to pretend
that such lookup which only happens with -g and not -g0 actually comes
from some DEBUG_INSN (note, the lookups rtx_equal_for_

[Bug target/108484] [13 Regression] ICE building glibc for ia64 in cselib_subst_to_values, at cselib.cc:2148

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

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

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

https://gcc.gnu.org/g:465a9c51e7d5bafa7a81195b5af20f2a54f22210

commit r13-5652-g465a9c51e7d5bafa7a81195b5af20f2a54f22210
Author: Jakub Jelinek 
Date:   Thu Feb 2 13:52:45 2023 +0100

sched-deps, cselib: Fix up some -fcompare-debug issues and regressions
[PR108463]

On Sat, Jan 14, 2023 at 08:26:00AM -0300, Alexandre Oliva via Gcc-patches
wrote:
> The testcase used to get scheduled differently depending on the
> presence of debug insns with MEMs.  It's not clear to me why those
> MEMs affected scheduling, but the cselib pre-canonicalization of the
> MEM address is not used at all when analyzing debug insns, so the
> memory allocation and lookup are pure waste.  Somehow, avoiding that
> waste fixes the problem, or makes it go latent.

Unfortunately, this patch breaks the following testcase.
The code in sched_analyze_2 did 2 things:
1) cselib_lookup_from_insn
2) shallow_copy_rtx + cselib_subst_to_values_from_insn
Now, 1) is precondition of 2), we can only subst the VALUEs if we
have actually looked the address up, but as can be seen on that testcase,
we are relying on at least the 1) to be done because we subst the values
later on even on DEBUG_INSNs and actually use those when needed.
cselib_subst_to_values_from_insn mostly just replaces stuff in the
returned rtx, except for:
  /* This used to happen for autoincrements, but we deal with them
 properly now.  Remove the if stmt for the next release.  */
  if (! e)
{
  /* Assign a value that doesn't match any other.  */
  e = new_cselib_val (next_uid, GET_MODE (x), x);
}
which is like that since 2011, I hope it is never reachable and we should
in stage1 replace that with gcc_assert or just remove (then it will
segfault on following
  return e->val_rtx;
).

So, I (as done in the patch below) reinstalled the 1) and not 2) for
DEBUG_INSNs.  This fixed the new testcase, but broke again the PR106746
testcases.

I've spent a day debugging that and found the problem is that as documented
in a large comment in cselib.cc above n_useless_values variable definition,
we spend quite a few effort on making sure that VALUEs created on
DEBUG_INSNs don't affect the cselib decisions for non-DEBUG_INSNs such as
pruning of useless values etc., but if a VALUE created that way is then
looked up/needed from non-DEBUG_INSNs, we promote it to non-debug.

The reason for -fcompare-debug failure is that there is one large
DEBUG_INSN
with 16 MEMs in it mostly with addresses that so far didn't appear in the
IL
otherwise.  Later on, we see an instruction storing into MEM destination
and invalidate that MEM.  Unfortunately, there is a bug caused by the
introduction of SP_DERIVED_VALUE_P where alias.cc isn't able to
disambiguate
MEMs with sp + optional offset in address vs. MEMs with address being a
VALUE having SP_DERIVED_VALUE_P + constant (or the SP_DERIVED_VALUE_P
itself), which ought to be possible when REG_VALUES (REGNO
(stack_pointer_rtx)) has SP_DERIVED_VALUE_P + constant location.  Not sure
if I should try to fix that in stage4 or defer for stage1.
Anyway, the cselib_invalidate_mem call because of this invalidates
basically
all MEMs with the exception of 5 which have MEM_EXPRs that guarantee
non-aliasing with the sp based store.
Unfortunately, n_useless_values which in my understanding should be always
the same between -g and -g0 compilations diverges, has 3 more useless
values
for -g.

Now, these were initially VALUEs created for DEBUG_INSN lookups.  As I
said,
cselib.cc has code to promote such VALUEs (well, their location elements)
to
non-debug if they are looked up from non-DEBUG_INSNs.  The problem is that
when looking some completely unrelated MEM from a non-DEBUG_INSN we run
into
a hash collision and so call cselib_hasher::equal to check if the unrelated
MEM is equal to the one from DEBUG_INSN only element.  The equal static
member function calls rtx_equal_for_cselib_1 and if that returns true,
promotes the location to non-DEBUG, otherwise returns false.  So far so
good.  But rtx_equal_for_cselib_1 internally performs various other cselib
lookups, all done with the non-DEBUG_INSN cselib_current_insn, so they
all promote to non-debug.  And that is wrong, because if it was -g0
compilation, such hashtable entry wouldn't be there at all (or would be
but wouldn't contain that locs element), so with -g0 we wouldn't call
that rtx_equal_for_cselib_1 at all.  So, I think we need to pretend
that such lookup which only happens with -g and not -g0 actually comes
from some DEBUG_INSN (note, the lookups rtx_equal_for_c

[Bug rtl-optimization/108463] [13 Regression] ICE: in cselib_subst_to_values, at cselib.cc:2148 with -O2 -fsched2-use-superblocks -g

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

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

--- Comment #16 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:465a9c51e7d5bafa7a81195b5af20f2a54f22210

commit r13-5652-g465a9c51e7d5bafa7a81195b5af20f2a54f22210
Author: Jakub Jelinek 
Date:   Thu Feb 2 13:52:45 2023 +0100

sched-deps, cselib: Fix up some -fcompare-debug issues and regressions
[PR108463]

On Sat, Jan 14, 2023 at 08:26:00AM -0300, Alexandre Oliva via Gcc-patches
wrote:
> The testcase used to get scheduled differently depending on the
> presence of debug insns with MEMs.  It's not clear to me why those
> MEMs affected scheduling, but the cselib pre-canonicalization of the
> MEM address is not used at all when analyzing debug insns, so the
> memory allocation and lookup are pure waste.  Somehow, avoiding that
> waste fixes the problem, or makes it go latent.

Unfortunately, this patch breaks the following testcase.
The code in sched_analyze_2 did 2 things:
1) cselib_lookup_from_insn
2) shallow_copy_rtx + cselib_subst_to_values_from_insn
Now, 1) is precondition of 2), we can only subst the VALUEs if we
have actually looked the address up, but as can be seen on that testcase,
we are relying on at least the 1) to be done because we subst the values
later on even on DEBUG_INSNs and actually use those when needed.
cselib_subst_to_values_from_insn mostly just replaces stuff in the
returned rtx, except for:
  /* This used to happen for autoincrements, but we deal with them
 properly now.  Remove the if stmt for the next release.  */
  if (! e)
{
  /* Assign a value that doesn't match any other.  */
  e = new_cselib_val (next_uid, GET_MODE (x), x);
}
which is like that since 2011, I hope it is never reachable and we should
in stage1 replace that with gcc_assert or just remove (then it will
segfault on following
  return e->val_rtx;
).

So, I (as done in the patch below) reinstalled the 1) and not 2) for
DEBUG_INSNs.  This fixed the new testcase, but broke again the PR106746
testcases.

I've spent a day debugging that and found the problem is that as documented
in a large comment in cselib.cc above n_useless_values variable definition,
we spend quite a few effort on making sure that VALUEs created on
DEBUG_INSNs don't affect the cselib decisions for non-DEBUG_INSNs such as
pruning of useless values etc., but if a VALUE created that way is then
looked up/needed from non-DEBUG_INSNs, we promote it to non-debug.

The reason for -fcompare-debug failure is that there is one large
DEBUG_INSN
with 16 MEMs in it mostly with addresses that so far didn't appear in the
IL
otherwise.  Later on, we see an instruction storing into MEM destination
and invalidate that MEM.  Unfortunately, there is a bug caused by the
introduction of SP_DERIVED_VALUE_P where alias.cc isn't able to
disambiguate
MEMs with sp + optional offset in address vs. MEMs with address being a
VALUE having SP_DERIVED_VALUE_P + constant (or the SP_DERIVED_VALUE_P
itself), which ought to be possible when REG_VALUES (REGNO
(stack_pointer_rtx)) has SP_DERIVED_VALUE_P + constant location.  Not sure
if I should try to fix that in stage4 or defer for stage1.
Anyway, the cselib_invalidate_mem call because of this invalidates
basically
all MEMs with the exception of 5 which have MEM_EXPRs that guarantee
non-aliasing with the sp based store.
Unfortunately, n_useless_values which in my understanding should be always
the same between -g and -g0 compilations diverges, has 3 more useless
values
for -g.

Now, these were initially VALUEs created for DEBUG_INSN lookups.  As I
said,
cselib.cc has code to promote such VALUEs (well, their location elements)
to
non-debug if they are looked up from non-DEBUG_INSNs.  The problem is that
when looking some completely unrelated MEM from a non-DEBUG_INSN we run
into
a hash collision and so call cselib_hasher::equal to check if the unrelated
MEM is equal to the one from DEBUG_INSN only element.  The equal static
member function calls rtx_equal_for_cselib_1 and if that returns true,
promotes the location to non-DEBUG, otherwise returns false.  So far so
good.  But rtx_equal_for_cselib_1 internally performs various other cselib
lookups, all done with the non-DEBUG_INSN cselib_current_insn, so they
all promote to non-debug.  And that is wrong, because if it was -g0
compilation, such hashtable entry wouldn't be there at all (or would be
but wouldn't contain that locs element), so with -g0 we wouldn't call
that rtx_equal_for_cselib_1 at all.  So, I think we need to pretend
that such lookup which only happens with -g and not -g0 actually comes
from some DEBUG_INSN (note, the lookups rtx_equal_for_

[Bug bootstrap/60160] Building with -flto in CFLAGS_FOR_TARGET / CXXFLAGS_FOR_TARGET

[a.heider at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Andre Heider  ---
See also https://github.com/rui314/mold/issues/977
mold v1.10.1 can't handle crt files which are built with LTO enabled.

But it sounds more like LTO on crt as-is produces the wrong thing?
__EH_FRAME_BEGIN__.lto_priv.0 resides in .eh_frame then.

[Bug ipa/107300] [13 Regression] ICE: verify_ssa failed (error: virtual definition of statement not up to date)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
Should be fixed now.

[Bug rtl-optimization/108463] [13 Regression] ICE: in cselib_subst_to_values, at cselib.cc:2148 with -O2 -fsched2-use-superblocks -g

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #17 from Jakub Jelinek  ---
Should be fixed now.

[Bug debug/106746] [13 Regression] '-fcompare-debug' failure (length) with -O2 -fsched2-use-superblocks since r13-2041-g6624ad73064de241

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #28 from Jakub Jelinek  ---
Should be fixed now.

[Bug target/108484] [13 Regression] ICE building glibc for ia64 in cselib_subst_to_values, at cselib.cc:2148

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Should be fixed now.

[Bug target/108484] [13 Regression] ICE building glibc for ia64 in cselib_subst_to_values, at cselib.cc:2148

[sam at gentoo dot org via Gcc-bugs]

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

--- Comment #7 from Sam James  ---
Could you add 108463 to See Also? Thanks.

[Bug c/108638] New: Another ice in decompose, at wide-int.h:984

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 108638
   Summary: Another ice in decompose, at wide-int.h:984
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C code:

long orte_pre_condition_transports_print_j;
int orte_pre_condition_transports_print_int_ptr_0;
orte_pre_condition_transports_print() {
  for (;;)
if (orte_pre_condition_transports_print_int_ptr_0)
  for (; orte_pre_condition_transports_print_j < sizeof(int);)
orte_pre_condition_transports_print_int_ptr_0 |=
orte_pre_condition_transports_print_j
<< orte_pre_condition_transports_print_j;
}

compiled by recent gcc, does this:

$ /home/dcb36/gcc/results/bin/gcc -c -w -O1 bug879.c 2>&1 | fgrep "internal c"
bug879.c:3:1: internal compiler error: in decompose, at wide-int.h:984
$ 

This was ok at g:da3aca031be736fe, dated 20230129, but not ok at
g:77906341efc5cb69, dated  20230131.

[Bug c++/108626] GCC doesn't deduplicate string literals for const char*const and const char[]

[marat at slonopotamus dot org via Gcc-bugs]

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

--- Comment #7 from Marat Radchenko  ---
While playing with it more, I found that clang behaves in a very strange way.
While they do combine `const char* const` + `const char[]`, the DO NOT combine
two `const char[]` together. I don't have any explanation for that. Reported as
https://github.com/llvm/llvm-project/issues/60476.

[Bug libstdc++/108636] C++20 undefined reference to `std::filesystem::__cxx11::path::_List::type(std::filesystem::__cxx11::path::_Type)' with -fkeep-inline-functions

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

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

--- Comment #1 from Jonathan Wakely  ---
Trunk has some additional errors:

/usr/bin/ld: /tmp/ccXeUWH9.o: in function
`std::filesystem::__cxx11::directory_iterator::operator==(std::default_sentinel_t)
const':
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/fs_dir.h:436:
undefined reference to `std::__shared_ptr::operator bool() const'
/usr/bin/ld: /tmp/ccXeUWH9.o: in function
`std::filesystem::__cxx11::recursive_directory_iterator::operator==(std::default_sentinel_t)
const':
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/fs_dir.h:544:
undefined reference to
`std::__shared_ptr::operator bool() const'


I think the answer is "don't use -fkeep-inline-functions"

[Bug c/108638] Another ice in decompose, at wide-int.h:984

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Confirmed.  backtrace eventually lands in ranger territorry:

0x1a9808e irange::operator==(irange const&) const
/space/rguenther/src/gcc/gcc/value-range.cc:1297
0x2e65f02 range_operator::fold_range(irange&, tree_node*, irange const&, irange
const&, relation_trio) const
/space/rguenther/src/gcc/gcc/range-op.cc:271
0x2e6cf9d operator_lshift::fold_range(irange&, tree_node*, irange const&,
irange const&, relation_trio) const
/space/rguenther/src/gcc/gcc/range-op.cc:2246
0x2e77330 range_op_handler::fold_range(vrange&, tree_node*, vrange const&,
vrange const&, relation_trio) const
/space/rguenther/src/gcc/gcc/range-op.cc:4583
0x2cf743d fold_using_range::range_of_range_op(vrange&,
gimple_range_op_handler&, fur_source&)
/space/rguenther/src/gcc/gcc/gimple-range-fold.cc:589
...

possibly crossing some type boundary through relations?

[Bug tree-optimization/108638] [13 Regression] Another ice in decompose, at wide-int.h:984

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
  Component|c   |tree-optimization
Summary|Another ice in decompose,   |[13 Regression] Another ice
   |at wide-int.h:984   |in decompose, at
   ||wide-int.h:984
   Priority|P3  |P1

[Bug libstdc++/108636] C++20 undefined reference to `std::filesystem::__cxx11::path::_List::type(std::filesystem::__cxx11::path::_Type)' with -fkeep-inline-functions

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #2 from Jonathan Wakely  ---
The problem with path::_List::type(_Type) is that it's only ever used by a
private constructor of path, which is only ever called from within the library.
But when you use -fkeep-inline-functions that private constructor gets compiled
into your code even though you don't (and can't) ever use it.

The fix is to move the definitions of those private constructors into the
library too, so that they aren't compiled into your code even with
-fkeep-inline-functions.

diff --git a/libstdc++-v3/include/bits/fs_path.h
b/libstdc++-v3/include/bits/fs_path.h
index 1cbfaaa5427..0d7bb10c1a0 100644
--- a/libstdc++-v3/include/bits/fs_path.h
+++ b/libstdc++-v3/include/bits/fs_path.h
@@ -596,12 +596,7 @@ namespace __detail
   _Multi = 0, _Root_name, _Root_dir, _Filename
 };

-path(basic_string_view __str, _Type __type)
-: _M_pathname(__str)
-{
-  __glibcxx_assert(__type != _Type::_Multi);
-  _M_cmpts.type(__type);
-}
+path(basic_string_view __str, _Type __type);

 enum class _Split { _Stem, _Extension };

@@ -851,8 +846,7 @@ namespace __detail

   struct path::_Cmpt : path
   {
-_Cmpt(basic_string_view __s, _Type __t, size_t __pos)
-  : path(__s, __t), _M_pos(__pos) { }
+_Cmpt(basic_string_view __s, _Type __t, size_t __pos);

 _Cmpt() : _M_pos(-1) { }

diff --git a/libstdc++-v3/src/c++17/fs_path.cc
b/libstdc++-v3/src/c++17/fs_path.cc
index 93149c4b415..aaea7d2725d 100644
--- a/libstdc++-v3/src/c++17/fs_path.cc
+++ b/libstdc++-v3/src/c++17/fs_path.cc
@@ -187,6 +187,19 @@ struct path::_Parser
   { return origin + c.str.data() - input.data(); }
 };

+inline
+path::path(basic_string_view __str, _Type __type)
+: _M_pathname(__str)
+{
+  __glibcxx_assert(__type != _Type::_Multi);
+  _M_cmpts.type(__type);
+}
+
+inline
+path::_Cmpt::_Cmpt(basic_string_view __s, _Type __t, size_t __pos)
+: path(__s, __t), _M_pos(__pos)
+{ }
+
 struct path::_List::_Impl
 {
   using value_type = _Cmpt;


The good news is this doesn't have any ABI impact, so can be backported to the
release branches.

For the other undefined symbols noted in comment 1, those require new symbols
to be exported from the library. The good news there is that the comparisons
with default_sentinel_t are new in GCC 13 and so we don't need to backport
anything.

[Bug tree-optimization/108500] [11/12 Regression] -O -finline-small-functions results in "internal compiler error: Segmentation fault" on a very large program (700k function calls)

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

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

--- Comment #16 from Richard Biener  ---
(In reply to Richard Biener from comment #14)
> Martin, can you look at the SRA issue?  Do you want me to create a separate
> bugreport for this?  The IL into SRA looks like
> 
>:
>   s2D.2755 = {};
>   s1D.2756 = {};
>   _unusedD.2002766 = s1D.2756;
>   sD.2002767 = s2D.2755;
>   s2D.2755 = sD.2002767;
>   _unusedD.2002766 ={v} {CLOBBER(eol)};
>   sD.2002767 ={v} {CLOBBER(eol)};
>   _unusedD.2002764 = s1D.2756;
>   sD.2002765 = s2D.2755;
>   s2D.2755 = sD.2002765;
>   _unusedD.2002764 ={v} {CLOBBER(eol)};
>   sD.2002765 ={v} {CLOBBER(eol)};
>   _unusedD.2002762 = s1D.2756;
>   sD.2002763 = s2D.2755;
>   s2D.2755 = sD.2002763;
>   _unusedD.2002762 ={v} {CLOBBER(eol)};
>   sD.2002763 ={v} {CLOBBER(eol)};
>   _unusedD.2002760 = s1D.2756;
>   sD.2002761 = s2D.2755;
>   s2D.2755 = sD.2002761;
>   _unusedD.2002760 ={v} {CLOBBER(eol)};
>   sD.2002761 ={v} {CLOBBER(eol)};
> ...

struct s1 {
   char a[20] ;
   char b[20] ;
};
struct s2 {
   int id;
   char a[20];
};
static inline  __attribute__((always_inline)) struct s2
f(struct s1 _unused, struct s2 s)
{ 
  return s;
} 

volatile struct s2 x;
int main(void)
{
  struct s2 s2 = {0};
  struct s1 s1 = {0};
#define TEN \
  s2 = f(s1,s2); \
  s2 = f(s1,s2); \
  s2 = f(s1,s2); \
  s2 = f(s1,s2); \
  s2 = f(s1,s2); \
  s2 = f(s1,s2); \
  s2 = f(s1,s2); \
  s2 = f(s1,s2); \
  s2 = f(s1,s2); \
  s2 = f(s1,s2);
  TEN
  TEN
  x = s2;
  return 0;
}

shows this.  With

diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc
index ad0c738645d..ab3f47badcb 100644
--- a/gcc/tree-sra.cc
+++ b/gcc/tree-sra.cc
@@ -2980,6 +2980,7 @@ propagate_subaccesses_from_lhs (struct access *lacc,
struct access *racc)
 static void
 propagate_all_subaccesses (void)
 {
+  unsigned cnt = 0;
   propagation_budget = new hash_map;
   while (rhs_work_queue_head)
 {
@@ -2994,6 +2995,7 @@ propagate_all_subaccesses (void)
{
  struct access *lacc = link->lacc;

+ cnt++;
  if (!bitmap_bit_p (candidate_bitmap, DECL_UID (lacc->base)))
continue;
  lacc = lacc->group_representative;
@@ -3019,6 +3021,7 @@ propagate_all_subaccesses (void)
while (lacc);
}
 }
+  fprintf (stderr, "%d\n", cnt);

   while (lhs_work_queue_head)
 {

we have with one TEN
> ./cc1 -quiet t.c -O
0
220
120

and with two TEN
> ./cc1 -quiet t.c -O
0
840
440

and with four TEN
> ./cc1 -quiet t.c -O
0
3280
1680

that's quadratic and has a quite high linear factor as well.

[Bug analyzer/108633] -Wanalyzer-fd-type-mismatch erroneously emitted on missing error-checking in qemu's tests/qtest/libqtest.c

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r13-5655-gd84dc419e692d42c3b1e0c82e972c8a6f4c71389
Author: David Malcolm 
Date:   Thu Feb 2 09:11:36 2023 -0500

analyzer: fix -Wanalyzer-fd-type-mismatch false +ve on "listen" [PR108633]

gcc/analyzer/ChangeLog:
PR analyzer/108633
* sm-fd.cc (fd_state_machine::check_for_fd_attrs): Add missing
"continue".
(fd_state_machine::on_listen): Don't issue phase-mismatch or
type-mismatch warnings for the "invalid" state.

gcc/testsuite/ChangeLog:
PR analyzer/108633
* gcc.dg/analyzer/fd-pr108633.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/108633] -Wanalyzer-fd-type-mismatch erroneously emitted on missing error-checking in qemu's tests/qtest/libqtest.c

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #2 from David Malcolm  ---
Should be fixed by the above patch.

[Bug tree-optimization/108639] New: ICE on valid code at -O1 and above: in decompose, at wide-int.h:984

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 108639
   Summary: ICE on valid code at -O1 and above: in decompose, at
wide-int.h:984
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

It appears to be a recent regression.

Compiler Explorer: https://godbolt.org/z/aE6Tssrq6

[538] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/13.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
--with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.1 20230202 (experimental) [master r13-5642-g66d700af5bb] (GCC)
[539] %
[539] % gcctk -O1 small.c
small.c: In function ‘main’:
small.c:3:18: warning: division by zero [-Wdiv-by-zero]
3 |   a = a ? 0 || 0 % 0 : 0;
  |  ^
during GIMPLE pass: dom
small.c:2:5: internal compiler error: in decompose, at wide-int.h:984
2 | int main() {
  | ^~~~
0x7b6a92 wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int > const&)
../../gcc-trunk/gcc/wide-int.h:984
0x7b7838 wi::int_traits >::decompose(long*,
unsigned int, generic_wide_int const&)
../../gcc-trunk/gcc/value-range.h:940
0x7b7838 wide_int_ref_storage::wide_int_ref_storage
>(generic_wide_int const&, unsigned int)
../../gcc-trunk/gcc/wide-int.h:1034
0x7b7838 generic_wide_int
>::generic_wide_int
>(generic_wide_int const&, unsigned int)
../../gcc-trunk/gcc/wide-int.h:790
0x7b7838 bool wi::eq_p,
generic_wide_int >(generic_wide_int const&,
generic_wide_int const&)
../../gcc-trunk/gcc/wide-int.h:1873
0x7b7838 wi::binary_traits,
generic_wide_int,
wi::int_traits >::precision_type,
wi::int_traits
>::precision_type>::predicate_result
operator==,
generic_wide_int >(generic_wide_int const&,
generic_wide_int const&)
../../gcc-trunk/gcc/wide-int.h:3307
0x7b7838 irange::operator==(irange const&) const
../../gcc-trunk/gcc/value-range.cc:1297
0x7b7838 irange::operator==(irange const&) const
../../gcc-trunk/gcc/value-range.cc:1266
0x1e4fc26 range_operator::fold_range(irange&, tree_node*, irange const&, irange
const&, relation_trio) const
../../gcc-trunk/gcc/range-op.cc:271
0x1e5030c operator_lshift::fold_range(irange&, tree_node*, irange const&,
irange const&, relation_trio) const
../../gcc-trunk/gcc/range-op.cc:2246
0x1d4db80 fold_using_range::range_of_range_op(vrange&,
gimple_range_op_handler&, fur_source&)
../../gcc-trunk/gcc/gimple-range-fold.cc:589
0x1d4f56a fold_using_range::fold_stmt(vrange&, gimple*, fur_source&,
tree_node*)
../../gcc-trunk/gcc/gimple-range-fold.cc:489
0x1d40d7c gimple_ranger::fold_range_internal(vrange&, gimple*, tree_node*)
../../gcc-trunk/gcc/gimple-range.cc:257
0x1d40d7c gimple_ranger::range_of_stmt(vrange&, gimple*, tree_node*)
../../gcc-trunk/gcc/gimple-range.cc:318
0x1d42ac0 gimple_ranger::range_of_expr(vrange&, tree_node*, gimple*)
../../gcc-trunk/gcc/gimple-range.cc:126
0x1028acf cprop_operand
../../gcc-trunk/gcc/tree-ssa-dom.cc:1972
0x102a969 cprop_into_stmt
../../gcc-trunk/gcc/tree-ssa-dom.cc:2049
0x102a969 dom_opt_dom_walker::optimize_stmt(basic_block_def*,
gimple_stmt_iterator*, bool*)
../../gcc-trunk/gcc/tree-ssa-dom.cc:2277
0x102bd13 dom_opt_dom_walker::before_dom_children(basic_block_def*)
../../gcc-trunk/gcc/tree-ssa-dom.cc:1682
0x1d0a0f7 dom_walker::walk(basic_block_def*)
../../gcc-trunk/gcc/domwalk.cc:311
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.
[540] %
[540] % cat small.c
long a;
int main() {
  a = a ? 0 || 0 % 0 : 0;
  a = a << a;
  return 0;
}

[Bug c++/108626] GCC doesn't deduplicate string literals for const char*const and const char[]

[marat at slonopotamus dot org via Gcc-bugs]

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

--- Comment #8 from Marat Radchenko  ---
Also, quote from C17 standard:

Like string literals, const-qualified compound literals can be placed into
read-only memory and *can even be shared*. (6.5.2.5 p 13).

[Bug tree-optimization/108639] ]13 Regression] ICE on valid code at -O1 and above: in decompose, at wide-int.h:984 since r13-5578

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Version|unknown |13.0
 Ever confirmed|0   |1
   Priority|P3  |P1
 CC||jakub at gcc dot gnu.org
Summary|ICE on valid code at -O1|]13 Regression] ICE on
   |and above: in decompose, at |valid code at -O1 and
   |wide-int.h:984  |above: in decompose, at
   ||wide-int.h:984 since
   ||r13-5578
   Target Milestone|--- |13.0
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-02-02

--- Comment #1 from Jakub Jelinek  ---
Started with r13-5578-g809d661aff99ae0287baf4a52269425de62381e6

[Bug c/108640] New: ICE compiling busybox for m68k in change_address_1, at emit-rtl.cc:2283

[aarnold.gcc at antonarnold dot de via Gcc-bugs]

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

Bug ID: 108640
   Summary: ICE compiling busybox for m68k in change_address_1, at
emit-rtl.cc:2283
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aarnold.gcc at antonarnold dot de
  Target Milestone: ---

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

Compiling busybox for a m68k-nommu target via buildroot fails with an ICE:

  CC  coreutils/ls.o
Using built-in specs.
COLLECT_GCC=/opt/m68k-buildroot-uclinux-uclibc_sdk-buildroot/bin/m68k-linux-gcc.br_real
Target: m68k-buildroot-uclinux-uclibc
Configured with: ./configure
--prefix=/home/dev/projects/buildroot-tp50/output/host
--sysconfdir=/home/dev/projects/buildroot-tp50/output/host/etc --enable-static
-q --target=m68k-buildroot-uclinux-uclibc --with
-sysroot=/home/dev/projects/buildroot-tp50/output/host/m68k-buildroot-uclinux-uclibc/sysroot
--enable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib
--disable-decimal-float --enable-plugins --ena
ble-lto --with-gmp=/home/dev/projects/buildroot-tp50/output/host
--with-mpc=/home/dev/projects/buildroot-tp50/output/host
--with-mpfr=/home/dev/projects/buildroot-tp50/output/host
--with-pkgversion='Buildroot 87
ts51/P0003-V0009-14872-g19d8c0fb50' --with-bugurl=http://bugs.buildroot.net/
--without-zstd --disable-libquadmath --disable-libquadmath-support
--disable-libsanitizer --disable-tls --enable-threads --without-isl
--without-cloog --enable-languages=c,c++
--with-build-time-tools=/home/dev/projects/buildroot-tp50/output/host/m68k-buildroot-uclinux-uclibc/bin
--disable-shared --disable-libgomp --silent
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.2.0 (Buildroot m68k-dev) 
COLLECT_GCC_OPTIONS='--sysroot=/opt/m68k-buildroot-uclinux-uclibc_sdk-buildroot/m68k-buildroot-uclinux-uclibc/sysroot'
'-fstack-protector-strong' '-std=gnu99' '-I' 'include' '-I' 'libbb' '-include'
'include/autoconf.h' '-D' '_GNU_SOURCE' '-D' 'NDEBUG' '-D' '_LARGEFILE_SOURCE'
'-D' '_LARGEFILE64_SOURCE' '-D' '_FILE_OFFSET_BITS=64' '-D' 'BB_VER="1.35.0"'
'-v' '-save-temps' '-freport-bug' '-D' '_LARGEFILE_SOURCE' '-D'
'_LARGEFILE64_SOURCE' '-D' '_FILE_OFFSET_BITS=64' '-O1' '-g0'
'-fno-dwarf2-cfi-asm' '-static' '-Wall' '-Wshadow' '-Wwrite-strings' '-Wundef'
'-Wstrict-prototypes' '-Wunused' '-Wunused-parameter' '-Wunused-function'
'-Wunused-value' '-Wmissing-prototypes' '-Wmissing-declarations'
'-Wno-format-security' '-Wdeclaration-after-statement' '-Wold-style-definition'
'-finline-limit=0' '-fno-builtin-strlen' '-fomit-frame-pointer'
'-ffunction-sections' '-fdata-sections' '-fno-guess-branch-probability'
'-funsigned-char' '-static-libgcc' '-falign-functions=1' '-falign-jumps=1'
'-falign-labels=1' '-falign-loops=1' '-fno-unwind-tables'
'-fno-asynchronous-unwind-tables' '-fno-builtin-printf' '-Os' '-D'
'KBUILD_BASENAME="ls"' '-D' 'KBUILD_MODNAME="ls"' '-c' '-o' 'coreutils/ls.o'
'-mcpu=68020' '-dumpdir' 'coreutils/'

/opt/m68k-buildroot-uclinux-uclibc_sdk-buildroot/bin/../libexec/gcc/m68k-buildroot-uclinux-uclibc/12.2.0/cc1
-E -quiet -v -I include -I libbb -iprefix
/opt/m68k-buildroot-uclinux-uclibc_sdk-buildroot/bin/../lib/gcc/m68k-buildroot-uclinux-uclibc/12.2.0/
-isysroot
/opt/m68k-buildroot-uclinux-uclibc_sdk-buildroot/m68k-buildroot-uclinux-uclibc/sysroot
-D _GNU_SOURCE -D NDEBUG -D _LARGEFILE_SOURCE -D _LARGEFILE64_SOURCE -D
_FILE_OFFSET_BITS=64 -D BB_VER="1.35.0" -D _LARGEFILE_SOURCE -D
_LARGEFILE64_SOURCE -D _FILE_OFFSET_BITS=64 -D KBUILD_BASENAME="ls" -D
KBUILD_MODNAME="ls" -include include/autoconf.h -MD coreutils/.ls.o.d
coreutils/ls.c -mcpu=68020 -std=gnu99 -Wall -Wshadow -Wwrite-strings -Wundef
-Wstrict-prototypes -Wunused -Wunused-parameter -Wunused-function
-Wunused-value -Wmissing-prototypes -Wmissing-declarations -Wno-format-security
-Wdeclaration-after-statement -Wold-style-definition -fstack-protector-strong
-freport-bug -fno-dwarf2-cfi-asm -finline-limit=0 -fno-builtin-strlen
-fomit-frame-pointer -ffunction-sections -fdata-sections
-fno-guess-branch-probability -funsigned-char -falign-functions=1
-falign-jumps=1 -falign-labels=1 -falign-loops=1 -fno-unwind-tables
-fno-asynchronous-unwind-tables -fno-builtin-printf -O1 -Os -fpch-preprocess -o
coreutils/ls.i
ignoring duplicate directory
"/opt/m68k-buildroot-uclinux-uclibc_sdk-buildroot/bin/../lib/gcc/../../lib/gcc/m68k-buildroot-uclinux-uclibc/12.2.0/include"
ignoring nonexistent directory
"/opt/m68k-buildroot-uclinux-uclibc_sdk-buildroot/m68k-buildroot-uclinux-uclibc/sysroot/usr/local/include"
ignoring duplicate directory
"/opt/m68k-buildroot-uclinux-uclibc_sdk-buildroot/bin/../lib/gcc/../../lib/gcc/m68k-buildroot-uclinux-uclibc/12.2.0/include-fixed"
ignoring duplicate directory
"/opt/m68k-buil

[Bug rtl-optimization/108508] [12/13 Regression] ICE in insert_def_after, at rtl-ssa/accesses.cc:622 since r12-4759-g95bb87b2458bfa

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

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

--- Comment #4 from CVS Commits  ---
The trunk branch has been updated by Richard Sandiford :

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

commit r13-5657-gf4e1b46618ef3bd7933992ab79f663ab9112bb80
Author: Richard Sandiford 
Date:   Thu Feb 2 14:53:34 2023 +

rtl-ssa: Fix splitting of clobber groups [PR108508]

Since rtl-ssa isn't a real/native SSA representation, it has
to honour the constraints of the underlying rtl representation.
Part of this involves maintaining an rpo list of definitions
for each rtl register, backed by a splay tree where necessary
for quick lookup/insertion.

However, clobbers of a register don't act as barriers to
other clobbers of a register.  E.g. it's possible to move one
flag-clobbering instruction across an arbitrary number of other
flag-clobbering instructions.  In order to allow passes to do
that without quadratic complexity, the splay tree groups all
consecutive clobbers into groups, with only the group being
entered into the splay tree.  These groups in turn have an
internal splay tree of clobbers where necessary.

This means that, if we insert a new definition and use into
the middle of a sea of clobbers, we need to split the clobber
group into two groups.  This was quite a difficult condition
to trigger during development, and the PR shows that the code
to handle it had (at least) two bugs.

First, the process involves searching the clobber tree for
the split point.  This search can give either the previous
clobber (which will belong to the first of the split groups)
or the next clobber (which will belong to the second of the
split groups).  The code for the former case handled the
split correctly but the code for the latter case didn't.

Second, I'd forgotten to add the second clobber group to the
main splay tree. :-(

gcc/
PR rtl-optimization/108508
* rtl-ssa/accesses.cc (function_info::split_clobber_group): When
the splay tree search gives the first clobber in the second group,
make sure that the root of the first clobber group is updated
correctly.  Enter the new clobber group into the definition splay
tree.

gcc/testsuite/
PR rtl-optimization/108508
* gcc.target/aarch64/pr108508.c: New test.

[Bug rtl-optimization/108086] [11/12/13 Regression] internal compiler error: in set_accesses, at rtl-ssa/internals.inl:449

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

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

--- Comment #17 from CVS Commits  ---
The trunk branch has been updated by Richard Sandiford :

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

commit r13-5658-gcd41085a37b8288dbdfe0f81027ce04b978578f1
Author: Richard Sandiford 
Date:   Thu Feb 2 14:53:34 2023 +

rtl-ssa: Extend m_num_defs to a full unsigned int [PR108086]

insn_info tried to save space by storing the number of
definitions in a 16-bit bitfield.  The justification was:

  // ...  FIRST_PSEUDO_REGISTER + 1
  // is the maximum number of accesses to hard registers and memory, and
  // MAX_RECOG_OPERANDS is the maximum number of pseudos that can be
  // defined by an instruction, so the number of definitions should fit
  // easily in 16 bits.

But while that reasoning holds (I think) for real instructions,
it doesn't hold for artificial instructions.  I don't think there's
any sensible higher limit we can use, so this patch goes for a full
unsigned int.

gcc/
PR rtl-optimization/108086
* rtl-ssa/insns.h (insn_info): Make m_num_defs a full unsigned int.
Adjust size-related commentary accordingly.

[Bug tree-optimization/108639] ]13 Regression] ICE on valid code at -O1 and above: in decompose, at wide-int.h:984 since r13-5578

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #2 from Jakub Jelinek  ---
The problem is in
271   if (relation_equiv_p (rel) && lh == rh)
We see
  # RANGE [irange] int [0, 1] NONZERO 0x1
  # iftmp.0_6 = PHI <_10(3), 0(2)>
  # RANGE [irange] long int [0, 1] NONZERO 0x1
  _3 = (long int) iftmp.0_6;
  # RANGE [irange] unsigned int [0, 1] NONZERO 0x1
  _4 = (unsigned int) iftmp.0_6;
  # RANGE [irange] long int [-INF, +INF] NONZERO 0x3
  _5 = _3 << _4;
so lhs and rhs indeed have the same range, but unlike most binary operations,
shifts/rotates have the same type between lhs and rhs1, but rhs2 can have
different type.
So, the lh == rh comparison ICEs because the wide_ints have different precision
(but same values).

[Bug debug/108641] New: Hooking MS-MPI system into the NONMEM installation failed

[weilongzhang0538 at foxmail dot com via Gcc-bugs]

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

Bug ID: 108641
   Summary: Hooking MS-MPI system into the NONMEM installation
failed
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: weilongzhang0538 at foxmail dot com
  Target Milestone: ---

About install MS-mpi and Hooking MS-MPI system into the NONMEM

I want——
 "From a command window, cd to the ..\mpi\mpi_wing(i) directory, and recompile.
Make sure your command window has the proper environment variables defined,
that it points to the proper gfortran compiler system for your NONMEM
Installation. In the case of “easy install” nm74g64 or nm73g64, best to click
on your desktop window icons provided for these, so that the special command
window is opened with its particular environment variables set:
Call msmpi_buildg.bat (gfortran) ”

but

“C:\nm75g64\mpi\mpi_wing>Call msmpi_buildg.bat

C:\nm75g64\mpi\mpi_wing>gfortran -c -D_WIN64 -D INPTR_KIND()=8 -fno-range-check
mpi.f90

C:\nm75g64\mpi\mpi_wing>copy mpi.mod ..\..\resource
已复制 1 个文件。

C:\nm75g64\mpi\mpi_wing>gfortran -c pnm_mpi.f90 -I..\..\resource
pnm_mpi.f90:45.28:

  USE SIZES, ONLY: ISIZE
1
Fatal Error: Wrong module version '6' (expected '5') for file 'sizes.mod'
opened at (1)
gfortran: internal compiler error: Aborted (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
C:\nm75g64\mpi\mpi_wing>”

I got a fatal error maybe because of  gfortran version 。。。

who know that what vision gfortran   is right for MS-MPI 10.012498.5？？


I feel  so bad； Hope for your help

[Bug tree-optimization/108639] ]13 Regression] ICE on valid code at -O1 and above: in decompose, at wide-int.h:984 since r13-5578

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 54391
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54391&action=edit
gcc13-pr108639.patch

Untested fix.

[Bug c++/104647] [10/11/12/13 Regression] ICE in get_or_insert_ctor_field, at cp/constexpr.cc:3705 since r9-3836-g4be5c72cf3ea3ee9

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
This seems to have been fixed by r13-4564.

[Bug tree-optimization/108638] [13 Regression] Another ice in decompose, at wide-int.h:984

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Dup.

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

[Bug tree-optimization/108639] ]13 Regression] ICE on valid code at -O1 and above: in decompose, at wide-int.h:984 since r13-5578

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #4 from Jakub Jelinek  ---
*** Bug 108638 has been marked as a duplicate of this bug. ***

[Bug c++/104647] [10/11/12/13 Regression] ICE in get_or_insert_ctor_field, at cp/constexpr.cc:3705 since r9-3836-g4be5c72cf3ea3ee9

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|10.5|13.0

[Bug c++/107897] [13 Regression] mangling conflicts with a previous mangle since r13-3601

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
The error can be certainly worked around with -fabi-compat-version=18, but I
wonder
if we just shouldn't disable mangling aliases for decls where
write_closure_type_name
has been called and LAMBDA_EXPR_SCOPE_SIG_DISCRIMINATOR !=
LAMBDA_EXPR_SCOPE_ONLY_DISCRIMINATOR.  Because the mangling change doesn't look
like mangle this differently, but use different numbering scheme in the same
mangling.
If yes, it could be arranged by
  if ((LAMBDA_EXPR_SCOPE_SIG_DISCRIMINATOR (lambda)
   != LAMBDA_EXPR_SCOPE_ONLY_DISCRIMINATOR (lambda))
  && abi_warn_or_compat_version_crosses (18))
G.need_abi_warning = true;
not setting just the G.need_abi_warning flag but some new flag in G which would
disable creation of the mangling alias.

Thoughts on that?

[Bug lto/106170] [13 Regression] x86_64-w64-mingw32 host GCC with win32 thread model does not provide pthread.h. lto-plugin fails with canadian compilation

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #20 from Jakub Jelinek  ---
.

[Bug ipa/108384] [13 Regression] error: conversion of register to a different size in ‘view_convert_expr’

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

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

--- Comment #13 from Martin Jambor  ---
I have proposed a fix on the mailing list:

https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611194.html

[Bug c++/60512] would be useful if gcc implemented __has_feature similary to clang

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

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

Jason Merrill  changed:

   What|Removed |Added

 Resolution|WORKSFORME  |---
 CC||jason at gcc dot gnu.org
 Status|RESOLVED|NEW

--- Comment #12 from Jason Merrill  ---
I agree that __has_feature seems redundant with feature test macros, but it
does seem reasonable to implement for portability.

[Bug libstdc++/108636] C++20 undefined reference to `std::filesystem::__cxx11::path::_List::type(std::filesystem::__cxx11::path::_Type)' with -fkeep-inline-functions

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r13-5662-gdb8d6fc572ec316ccfcf70b1dffe3be0b1b37212
Author: Jonathan Wakely 
Date:   Thu Feb 2 14:06:40 2023 +

libstdc++: Fix std::filesystem errors with -fkeep-inline-functions
[PR108636]

With -fkeep-inline-functions there are linker errors when including
. This happens because there are some filesystem::path
constructors defined inline which call non-exported functions defined in
the library. That's usually not a problem, because those constructors
are only called by code that's also inside the library. But when the
header is compiled with -fkeep-inline-functions those inline functions
are emitted even though they aren't called. That then creates an
undefined reference to the other library internsl. The fix is to just
move the private constructors into the library where they are called.
That way they are never even seen by users, and so not compiled even if
-fkeep-inline-functions is used.

On trunk there is a second problem, which is that the new equality
operators for comparing directory iterators with default_sentinel use
the shared_ptr::operator bool() conversion operator. The shared_ptr
specializations used by directory iterators are explicitly instantiated
in the library, but the bool conversion operators are not exported. This
causes linker errors at -O0 or with -fkeep-inline-functions. That just
requires the conversion operators to be exported.

libstdc++-v3/ChangeLog:

PR libstdc++/108636
* config/abi/pre/gnu.ver (GLIBCXX_3.4.31): Export shared_ptr
conversion operators for directory iterator comparisons with
std::default_sentinel_t.
* include/bits/fs_path.h (path::path(string_view, _Type))
(path::_Cmpt::_Cmpt(string_view, _Type, size_t)): Move inline
definitions to ...
* src/c++17/fs_path.cc: ... here.
* testsuite/27_io/filesystem/path/108636.cc: New test.

[Bug c++/108642] New: ACLE function __arm_wsr missing when compiling in C++ mode for AArch64

[david.spickett at linaro dot org via Gcc-bugs]

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

Bug ID: 108642
   Summary: ACLE function __arm_wsr missing when compiling in C++
mode for AArch64
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.spickett at linaro dot org
  Target Milestone: ---

This was found by a user trying to compile llvm's libc (which is largely
written in c++) using g++ 8.5.0 for AArch64. I then tried versions up to 12.2.0
and a recent trunk build.

https://godbolt.org/z/qxaYxdTcv, and I've copied the details below.

The following source:
```
#include 
#include 

void writeStatusWord(uint32_t fpsr) { __arm_wsr("fpsr", fpsr); }
```

When compiled with g++ gives the error:
```
:4:39: error: '__arm_wsr' was not declared in this scope
4 | void writeStatusWord(uint32_t fpsr) { __arm_wsr("fpsr", fpsr); }
  |   ^
```

When compiled as C, there is instead a warning and it does compile:
```
:4:39: warning: implicit declaration of function '__arm_wsr'
[-Wimplicit-function-declaration]
4 | void writeStatusWord(uint32_t fpsr) { __arm_wsr("fpsr", fpsr); }
  |   ^
```

The expected result would be that in either mode, we can compile without errors
or warnings.

This __arm_wsr function should be present after including arm_acle.h according
to https://github.com/ARM-software/acle/releases/tag/r2022Q4 (acle-2022Q4.pdf
). See "11.1 Special register intrinsics".

I looked in the arm_acle.h gcc/g++ is including and see no reference to it.
Which makes me wonder if it's a compiler builtin that somehow isn't present for
C++.

Over in clang there is a builtin for it, that is then #defined into the
__arm_wsr name in the header.

[Bug c++/108643] New: Initializing parameter by ref in coroutine function causes memory corruption

[menkaur at gmail dot com via Gcc-bugs]

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

Bug ID: 108643
   Summary: Initializing parameter by ref in coroutine function
causes memory corruption
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: menkaur at gmail dot com
  Target Milestone: ---

Created attachment 54392
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54392&action=edit
example code

I'm using libcoro (https://github.com/jbaldwin/libcoro) for generator class, on
my system it's compiled and installed

To reproduce bug, you have to write coroutine as follows:

coro::generator vector_to_generator(const std::vector &test)
{
for (auto &i : test)
{
co_yield i;
}
}

test method looks like this:
coro::generator test(coro::generator source, const
std::string &prompt)
{
for (auto &i : source)
{
std::cout << prompt << i << std::endl;
co_yield i;
}
}



if we initialize test with initializer list instead of another object, this
will result in memory corruption:

for (auto &i : test(vector_to_generator({1, 2, 3, 4, 5, 6, 7, 8, 9, 10}),
"test:"))
{
}

expected output:

test:1671954983
test:5
test:-724690709
test:621133568
test:5
test:6
test:7
test:8
test:9
test:10

(or segfault, which is how I found it)

[Bug target/108642] ACLE function __arm_wsr missing for AArch64

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-02-02
 Target||aarch64-linux-gnu
Summary|ACLE function __arm_wsr |ACLE function __arm_wsr
   |missing when compiling in   |missing for AArch64
   |C++ mode for AArch64|
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
They are not implemented at all for either C or C++.

Confirmed.

[Bug target/108642] ACLE function __arm_wsr missing for AArch64

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

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

--- Comment #2 from Andrew Pinski  ---
Note the ACLE does not require "fpsr" to be supported either only
"o0:op1:CRn:CRm:op2" format is listed there ...

[Bug target/108642] ACLE function __arm_wsr missing for AArch64

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

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

--- Comment #3 from Andrew Pinski  ---
GCC has a builtin already for getting fpsr already too:
__builtin_aarch64_get_fpsr

Which of course is not documented ...

[Bug target/108642] ACLE function __arm_wsr missing for AArch64

[david.spickett at linaro dot org via Gcc-bugs]

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

--- Comment #4 from David Spickett  ---
Of course, I was just looking at at assembly output in compiler explorer and
then locally I didn't link the object. That's why it seemed to work.

Compiling and linking I get:
$ ./bin/aarch64-none-linux-gnu-gcc /tmp/test.c -o /tmp/test.o
/tmp/test.c: In function ‘writeStatusWord’:
/tmp/test.c:4:39: warning: implicit declaration of function ‘__arm_wsr’
[-Wimplicit-function-declaration]
4 | void writeStatusWord(uint32_t fpsr) { __arm_wsr("fpsr", fpsr); }
  |   ^
<...>aarch64-none-linux-gnu/bin/ld: /tmp/ccLie8Sh.o: in function
`writeStatusWord':
test.c:(.text+0x18): undefined reference to `__arm_wsr'
collect2: error: ld returned 1 exit status

Which makes more sense.

[Bug target/108642] ACLE function __arm_wsr missing for AArch64

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> Which of course is not documented ...

They are documented but not in a decent way:
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/AArch64-Built-in-Functions.html#AArch64-Built-in-Functions

[Bug libstdc++/108636] [10/11/12 Regression] C++20 undefined reference to `std::filesystem::__cxx11::path::_List::type(std::filesystem::__cxx11::path::_Type)' with -fkeep-inline-functions

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

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|C++20 undefined reference   |[10/11/12 Regression] C++20
   |to  |undefined reference to
   |`std::filesystem::__cxx11:: |`std::filesystem::__cxx11::
   |path::_List::type(std::file |path::_List::type(std::file
   |system::__cxx11::path::_Typ |system::__cxx11::path::_Typ
   |e)' with|e)' with
   |-fkeep-inline-functions |-fkeep-inline-functions
  Known to fail||10.4.0, 11.3.0, 12.2.0,
   ||9.1.0
   Target Milestone|--- |10.5
  Known to work||8.5.0

--- Comment #4 from Jonathan Wakely  ---
Fixed on trunk so far. Backports to follow.

[Bug tree-optimization/108500] [11/12 Regression] -O -finline-small-functions results in "internal compiler error: Segmentation fault" on a very large program (700k function calls)

[dhekir at gmail dot com via Gcc-bugs]

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

--- Comment #17 from dhekir at gmail dot com ---
To be honest, the "real" test case is very similar to the last one I sent: it's
a semi-generated code, with some initialization of the data in the beginning,
and then a lot of statements which perform not necessarily useful operations,
and in the end a few assertions are checked (e.g. that the initialized data was
not tampered with).

So, in reality, I expected GCC to discard most of the program after
optimization and execute it almost instantly. When I encountered the
segmentation fault during compilation, I thought it might also be relevant for
other users, so I submitted the bug.

Now, however, that the issue is mostly a "performance" issue, it's less likely
that other users will encounter such a huge program with "useful" purposes, so
I understand completely if you decide this is just not interesting/useful
enough.

To be honest, I tried compiling the code with other open source C compilers
(Clang, and another not-so-mature one), and one failed with a stack overflow,
and the other didn't complete until 1h30m, so I terminated it.

So, the simple fact that you were able to succesfully compile it with those
options is already very interesting to me and sufficient for my "real" test
case.

[Bug tree-optimization/108639] [13 Regression] ICE on valid code at -O1 and above: in decompose, at wide-int.h:984 since r13-5578

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

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org

--- Comment #5 from Aldy Hernandez  ---
(In reply to Jakub Jelinek from comment #3)
> Created attachment 54391 [details]
> gcc13-pr108639.patch
> 
> Untested fix.

I think the problem is more fundamental than that.  The equality operator for
irange is not ICEing for the sub-range comparison (which also have different
precision), but is dying in the nonzero mask comparison.

[Bug tree-optimization/108639] [13 Regression] ICE on valid code at -O1 and above: in decompose, at wide-int.h:984 since r13-5578

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

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

--- Comment #6 from Aldy Hernandez  ---
Created attachment 54393
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54393&action=edit
untested patch for irange::operator==

[Bug tree-optimization/108639] [13 Regression] ICE on valid code at -O1 and above: in decompose, at wide-int.h:984 since r13-5578

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

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

--- Comment #7 from Aldy Hernandez  ---
Jakub, take a look and see if you agree.  I've fired off some tests.

[Bug c++/107574] [10/11/12/13 Regression] ICE: tree check in cp_fold_convert with ptr to member field cast inside a class not completed and inherent since r9-50-gd760b06868d660bc

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug fortran/108641] Hooking MS-MPI system into the NONMEM installation failed

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID
  Component|debug   |fortran

--- Comment #1 from Andrew Pinski  ---
>Fatal Error: Wrong module version '6' (expected '5') for file 'sizes.mod' 
>opened at (1)


This means the modules you are using was compiled with a newer version of
Gfortran.
I think you should ask where you got the module from what exact version of
GCC/gfortran is for their library.

[Bug tree-optimization/108639] [13 Regression] ICE on valid code at -O1 and above: in decompose, at wide-int.h:984 since r13-5578

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

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

--- Comment #8 from Jakub Jelinek  ---
(In reply to Aldy Hernandez from comment #5)
> (In reply to Jakub Jelinek from comment #3)
> > Created attachment 54391 [details]
> > gcc13-pr108639.patch
> > 
> > Untested fix.
> 
> I think the problem is more fundamental than that.  The equality operator
> for irange is not ICEing for the sub-range comparison (which also have
> different precision), but is dying in the nonzero mask comparison.

Well, that is obvious, because for the actual range boundaries you compare
trees, not wide_ints.  And operand_equal_p does allow comparing of trees with
different types.
It in that case calls tree_int_cst_equal.  But when you switch the boundaries
from trees to wide_ints, they will ICE again as well.

I think for the operator==, the important question is, shall ranges with same
values but non-compatible types compare
1) equal
2) non-equal
3) be an ICE (e.g. gcc_checking_assert)
The current state is 3) without the assert and my patch was trying to fix the
caller.
Your patch is changing it to 1), in that case no change would be needed in the
particular lh == rh user, but are we sure that everywhere where non-compatible
types could appear we don't imply from operator== returning true that the types
are actually the same?
If we did 2) e.g. by adding a types_compatible_p (type (), b.type ()) check,
then we'd
need to change this lh == rh user too, because for the shifts we really just
care about values and not the exact types which can differ.

[Bug libstdc++/104866] [12 Regression] this_thread_sleep.h doesn't compile if _GLIBCXX_NO_SLEEP is defined

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

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to fail||11.1.0
  Known to work|11.2.1  |10.4.0
   Target Milestone|12.0|11.4

--- Comment #5 from Jonathan Wakely  ---
I incorrectly marked this as Known-to-work: 11.2.1 but the bug was present
since 11.1.0

It's fixed for 11.4.0 now.

[Bug libstdc++/104866] [12 Regression] this_thread_sleep.h doesn't compile if _GLIBCXX_NO_SLEEP is defined

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:502fd5575bfe0793ef4dc90dd714755e9878f308

commit r11-10497-g502fd5575bfe0793ef4dc90dd714755e9878f308
Author: Detlef Vollmann 
Date:   Thu Mar 10 16:57:25 2022 +

libstdc++: Move closing brace outside #endif [PR104866]

libstdc++-v3/ChangeLog:

PR libstdc++/104866
* include/bits/this_thread_sleep.h: Fix order of #endif and
closing brace of namespace.

(cherry picked from commit b5417a0ba7e26bec2abf05cad6c6ef840a9be41c)

[Bug tree-optimization/107561] [13 Regression] g++.dg/pr71488.C and [g++.dg/warn/Warray-bounds-16.C -m32] regression due to -Wstringop-overflow problem

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

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org

--- Comment #6 from Hans-Peter Nilsson  ---
IMHO these tests and AFAICT the underlying issue has seen no attention for
months and should be xfailed.  On it...

[Bug tree-optimization/108639] [13 Regression] ICE on valid code at -O1 and above: in decompose, at wide-int.h:984 since r13-5578

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #9 from Andrew Macleod  ---
(In reply to Jakub Jelinek from comment #8)
> (In reply to Aldy Hernandez from comment #5)
> > (In reply to Jakub Jelinek from comment #3)
> > > Created attachment 54391 [details]
> > > gcc13-pr108639.patch
> > > 
> > > Untested fix.
> > 
> > I think the problem is more fundamental than that.  The equality operator
> > for irange is not ICEing for the sub-range comparison (which also have
> > different precision), but is dying in the nonzero mask comparison.
> 
> Well, that is obvious, because for the actual range boundaries you compare
> trees, not wide_ints.  And operand_equal_p does allow comparing of trees
> with different types.
> It in that case calls tree_int_cst_equal.  But when you switch the
> boundaries from trees to wide_ints, they will ICE again as well.
> 
> I think for the operator==, the important question is, shall ranges with
> same values but non-compatible types compare
> 1) equal
> 2) non-equal
> 3) be an ICE (e.g. gcc_checking_assert)
> The current state is 3) without the assert and my patch was trying to fix
> the caller.

3) is not a desired result for sure.

I think 1) is our desired outcome... I initially considered 2) as desirable as
we could simply check the types before doing any other work.   As I thought
about it tho, I can't think of any good reason why we would want them to be
unequal.

If they compare equal this way (ignoring type), then performing a cast on
either of them to the same type as the other would also compare equal... its
symmetrical so that actually makes them equal in my book.

[Bug sanitizer/108637] ASAN at -O2 misses a stack-use-after-scope

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
PRE removes the load/stores from/to *f .
Basically the compiler is able to remove the use-after-scope usage with -O2 and
above.

[Bug sanitizer/108085] gcc trunk's ASAN at -O3 missed a stack-use-after-scope

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

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

--- Comment #4 from Andrew Pinski  ---
Hmm, using the C++ front-end, the use-after-scope still happens at -O3 but not
with the C front-end.

[Bug target/108640] ICE compiling busybox for m68k in change_address_1, at emit-rtl.cc:2283

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Mikael Pettersson  ---
I can reproduce. Doesn't happen with the m68k-linux-gnu target though.

> cross-m68k-uclinux/bin/m68k-unknown-uclinux-uclibc-gcc -Os -c /tmp/ls.i 
during RTL pass: final
coreutils/ls.c: In function 'ls_main':
coreutils/ls.c:1265:1: internal compiler error: in change_address_1, at
emit-rtl.cc:2283
0x40c57b change_address_1
/mnt/scratch/cross/sources/gcc-12.2.0/gcc/emit-rtl.cc:2283
0x64e80d adjust_address_1(rtx_def*, machine_mode, poly_int<1u, long>, int, int,
int, poly_int<1u, long>)
/mnt/scratch/cross/sources/gcc-12.2.0/gcc/emit-rtl.cc:2417
0xc6da2f output_iorsi3(rtx_def**)
/mnt/scratch/cross/sources/gcc-12.2.0/gcc/config/m68k/m68k.cc:5498
0x691b05 final_scan_insn_1
/mnt/scratch/cross/sources/gcc-12.2.0/gcc/final.cc:2827
0x692108 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/mnt/scratch/cross/sources/gcc-12.2.0/gcc/final.cc:2940
0x692395 final_1
/mnt/scratch/cross/sources/gcc-12.2.0/gcc/final.cc:1997
0x692b92 rest_of_handle_final
/mnt/scratch/cross/sources/gcc-12.2.0/gcc/final.cc:4285
0x692b92 execute
/mnt/scratch/cross/sources/gcc-12.2.0/gcc/final.cc:4363
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 sanitizer/108085] gcc trunk's ASAN at -O3 missed a stack-use-after-scope

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

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

--- Comment #5 from Andrew Pinski  ---
The difference between the two front-ends is at the original.
The C++ front-end adds a BLOCK around the loop while the C front-end does not.

This difference changes where the ASAN_MARK is placed with respect to the
return statement.

[Bug tree-optimization/108639] [13 Regression] ICE on valid code at -O1 and above: in decompose, at wide-int.h:984 since r13-5578

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

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

--- Comment #10 from Jakub Jelinek  ---
Ok then.
I won't test my patch then, the testcases from it were:
--- gcc/testsuite/gcc.c-torture/compile/pr108638.c.jj   2022-11-21
10:04:00.210677046 +0100
+++ gcc/testsuite/gcc.c-torture/compile/pr108638.c  2023-02-02
16:51:06.082371450 +0100
@@ -0,0 +1,12 @@
+/* PR tree-optimization/108638 */
+
+long long a;
+int b;
+
+void
+foo (void)
+{
+  for (a = 0; a < __SIZEOF_LONG_LONG__ * __CHAR_BIT__; a++)
+if (b)
+  b |= a << a;
+}
--- gcc/testsuite/gcc.c-torture/compile/pr108639.c.jj   2023-02-02
16:26:44.113600462 +0100
+++ gcc/testsuite/gcc.c-torture/compile/pr108639.c  2023-02-02
16:26:23.309902211 +0100
@@ -0,0 +1,11 @@
+/* PR tree-optimization/108639 */
+
+long long a;
+
+int
+main ()
+{
+  a = a ? 0 || 0 % 0 : 0;
+  a = a << a;
+  return 0;
+}

[Bug other/108644] New: Format string warnings related to longs under MigW-W64/MSYS2 on Windows 10

[jdx at o2 dot pl via Gcc-bugs]

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

Bug ID: 108644
   Summary: Format string warnings related to longs under
MigW-W64/MSYS2 on Windows 10
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jdx at o2 dot pl
  Target Milestone: ---
  Host: x86_64-w64-mingw32
 Build: x86_64-w64-mingw32

Below are three excerpts from my gcc's build log. I believe that all these
warnings are caused by the fact that on Windows (at least x86_64 Win 10, but
AFAIR it applies to all versions) sizeof(long) = 4. The warnings do not appear
on a x86_64 Linux, where sizeof(long) = 8. I think that some of the warnings
could be fixed by using size_t and %zu format string instead of long and %l.



make[3]: Entering directory '/d/Works/xcomp/gcc-build/lto-plugin'
/bin/sh ./libtool  --tag=CC --tag=disable-static  --mode=compile gcc
-DHAVE_CONFIG_H -I. -I../../../gcc/lto-plugin 
-I../../../gcc/lto-plugin/../include -DHAVE_CONFIG_H  -Wall 
-DBASE_VERSION='"13.0.1"' -g -O2 -c -o lto-plugin.lo
../../../gcc/lto-plugin/lto-plugin.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../../gcc/lto-plugin
-I../../../gcc/lto-plugin/../include -DHAVE_CONFIG_H -Wall
-DBASE_VERSION=\"13.0.1\" -g -O2 -c ../../../gcc/lto-plugin/lto-plugin.c 
-DDLL_EXPORT -DPIC -o .libs/lto-plugin.o
../../../gcc/lto-plugin/lto-plugin.c: In function 'dump_symtab':
../../../gcc/lto-plugin/lto-plugin.c:501:19: warning: 'I' flag used with '%x'
gnu_printf format [-Wformat=]
  501 |   fprintf (f, "%u %" PRI_LL "x %s %s\n",
  |   ^~
../../../gcc/lto-plugin/lto-plugin.c:501:34: note: format string is defined
here
  501 |   fprintf (f, "%u %" PRI_LL "x %s %s\n",
  |  ^
../../../gcc/lto-plugin/lto-plugin.c:501:19: warning: format '%x' expects
argument of type 'unsigned int', but argument 4 has type 'long long unsigned
int' [-Wformat=]
  501 |   fprintf (f, "%u %" PRI_LL "x %s %s\n",
  |   ^~
  502 |(unsigned int) slot, symtab->aux[j].id,
  | ~
  |   |
  |   long long unsigned
int
../../../gcc/lto-plugin/lto-plugin.c:501:34: note: format string is defined
here
  501 |   fprintf (f, "%u %" PRI_LL "x %s %s\n",
  |   ~~~^
  |  |
  |  unsigned int
  |   %" PRI_LL "llx
../../../gcc/lto-plugin/lto-plugin.c: In function 'process_symtab':
../../../gcc/lto-plugin/lto-plugin.c:1088:16: warning: 'I' flag used with '%x'
gnu_scanf format [-Wformat=]
 1088 | sscanf (s, ".%" PRI_LL "x", &obj->out->id);
  |^~~~
../../../gcc/lto-plugin/lto-plugin.c:1088:29: note: format string is defined
here
 1088 | sscanf (s, ".%" PRI_LL "x", &obj->out->id);
  | ^
../../../gcc/lto-plugin/lto-plugin.c:1088:16: warning: format '%x' expects
argument of type 'unsigned int *', but argument 3 has type 'long long unsigned
int *' [-Wformat=]
 1088 | sscanf (s, ".%" PRI_LL "x", &obj->out->id);
  |^~~~ ~
  | |
  | long long unsigned int *
../../../gcc/lto-plugin/lto-plugin.c:1088:29: note: format string is defined
here
 1088 | sscanf (s, ".%" PRI_LL "x", &obj->out->id);
  |  ~~~^
  | |
  | unsigned int *
  |  %" PRI_LL "llx
../../../gcc/lto-plugin/lto-plugin.c: In function 'process_symtab_extension':
../../../gcc/lto-plugin/lto-plugin.c:1140:16: warning: 'I' flag used with '%x'
gnu_scanf format [-Wformat=]
 1140 | sscanf (s, ".%" PRI_LL "x", &obj->out->id);
  |^~~~
../../../gcc/lto-plugin/lto-plugin.c:1140:29: note: format string is defined
here
 1140 | sscanf (s, ".%" PRI_LL "x", &obj->out->id);
  | ^
../../../gcc/lto-plugin/lto-plugin.c:1140:16: warning: format '%x' expects
argument of type 'unsigned int *', but argument 3 has type 'long long unsigned
int *' [-Wformat=]
 1140 | sscanf (s, ".%" PRI_LL "x", &obj->out->id);
  |^~~~ ~
  | |
  | long long unsigned int *
../../../gcc/lto-plugin/lto-plugin.c:1140:29: note: format string is defined
here
 1140 | sscanf (s, ".%" PRI_LL "x", &obj->out->id);
  |  ~~~^
  | |
  | u

[Bug fortran/96255] [F2018] Implement optional type spec for index in DO CONCURRENT

[Boyce at engineer dot com via Gcc-bugs]

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

Scott Boyce  changed:

   What|Removed |Added

 CC||Boyce at engineer dot com

--- Comment #10 from Scott Boyce  ---
Just wanted to see if there was any change on this. I just was about to post
the same issue (and found this one) for compiling with 11.3.0 and 12.1.0 on
Ubuntu.

I used this feature all the time for routines that don't have any available
integers and it seems silly to create an extra int at the top of a routine just
for a loop index.

Its also nice for keeping the variable isolated from the other parts of a
routine, when its only purpose is to serve as a loop index.

[Bug other/108644] Format string warnings related to longs under MigW-W64/MSYS2 on Windows 10

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

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

--- Comment #1 from Andrew Pinski  ---
The lto-plugin warnings are not a GCC issue really.
../../../gcc/lto-plugin/lto-plugin.c:501:19: warning: 'I' flag used with '%x'
gnu_printf format [-Wformat=]


Those are done correctly and using the right arguments and all. The issue is
rather how PRI_LL is defined but fprintf specifies gnu_printf rather than
win32_printf format 
Where is PRI_LL definition coming from? Please provide the preprocessed source
(and add -g3 to keep the #define's in there).
I suspect there is a bug in mingw's stdint.h in some cases ...




This one looks like a mising '()':
../../../gcc/gcc/ira-conflicts.cc:153:25: warning: format '%ld' expects
argument of type 'long int', but argument 3 has type 'long long unsigned int'
[-Wformat=]
  153 |"+++Allocating %ld bytes for conflict table (uncompressed size
%ld)\n",
  |   ~~^
  | |
  | long int
  |   %lld
  154 |(long) allocated_words_num * sizeof (IRA_INT_TYPE),
  |~~
  |   |
  |   long long unsigned int

Maybe it should have been `(long) (allocated_words_num * sizeof
(IRA_INT_TYPE))`
Likewise for the next one:

  155 |(long) object_set_words * ira_objects_num * sizeof
(IRA_INT_TYPE));

Should have been `(long)(object_set_words * ira_objects_num * sizeof
(IRA_INT_TYPE))`

[Bug other/108644] Format string warnings related to longs under MigW-W64/MSYS2 on Windows 10

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

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

--- Comment #2 from Andrew Pinski  ---
h8300.cc should be using HOST_WIDE_INT_PRINT_DEC instead.

Can you file that issue seperately?