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

[hiraditya at msn dot com via Gcc-bugs]

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

--- Comment #3 from AK  ---
1. clang also has noalias on nothrow versions of operator new. will
`-fassume-sane-operator-new` enable that as well?

2. as per: http://eel.is/c++draft/basic.stc.dynamic#allocation-2 

"""If the request succeeds, the value returned by a replaceable allocation
function is a non-null pointer value ([basic.compound]) p0 different from any
previously returned value p1, unless that value p1 was subsequently passed to a
replaceable deallocation function."""

Does this mean that all successful new allocations can be assumed to be a
noalias as long as the pointer wasn't passed to a deallocation function? In
that case when possible, can the compiler `infer` from a bottom-up analysis
that an allocation is a noalias?

[Bug target/110625] [AArch64] Vect: SLP fails to vectorize a loop as the reduction_latency calculated by new costs is too large

[hliu at amperecomputing dot com via Gcc-bugs]

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

--- Comment #19 from Hao Liu  ---
> Hi, here's the reduced case

Hi Tarmar, thanks for the case.  I've modified it to reproduce the ICE without
LTO and have updated the patch.

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[tanksherman27 at gmail dot com via Gcc-bugs]

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

Julian Waters  changed:

   What|Removed |Added

 CC||tanksherman27 at gmail dot com

--- Comment #15 from Julian Waters  ---
It seems like the patch also doesn't fix the strftime case too, strangely
enough. gcc with that patch applied still causes a compilation failure in the
Windows JDK when encountering strftime with the %T specifier

[Bug rtl-optimization/110867] [14 Regression] ICE in combine after 7cdd0860949c6c3232e6cff1d7ca37bb5234074c

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

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

--- Comment #3 from prathamesh3492 at gcc dot gnu.org ---
(In reply to prathamesh3492 from comment #2)
> (In reply to Stefan Schulze Frielinghaus from comment #1)
> > The optimization introduced by r14-2879-g7cdd0860949c6c hits during
> > combination of insn
> > 
> > (insn 31 3 32 2 (set (reg:SI 118 [ _1 ])
> > (mem:SI (reg/v/f:SI 115 [ a ]) [1 *a_4(D)+0 S4 A64])) "t.c":15:7 758
> > {*arm_movsi_vfp}
> >  (nil))
> > 
> > and
> > 
> > (insn 9 32 10 2 (set (reg:CC 100 cc)
> > (compare:CC (reg:SI 118 [ _1 ])
> > (const_int -2147483648 [0x8000]))) "t.c":15:6 272
> > {*arm_cmpsi_insn}
> >  (nil))
> > 
> > The idea of r14-2879-g7cdd0860949c6c is to get rid of large constants while
> > performing an unsigned comparison.  In this case it looks like a 32-bit
> > constant is sign-extended into a 64-bit constant and then a 32-bit
> > comparison is done.  While writing the optimization I always assumed that
> > the constant does fit into int_mode which is apparently not the case here. 
> > Thus one possible solution would be to simply bail out in those cases:
> > 
> > diff --git a/gcc/combine.cc b/gcc/combine.cc
> > index 0d99fa541c5..e46d202d0a7 100644
> > --- a/gcc/combine.cc
> > +++ b/gcc/combine.cc
> > @@ -11998,11 +11998,15 @@ simplify_compare_const (enum rtx_code code,
> > machine_mode mode,
> >   x0 >= 0x40.  */
> >if ((code == LEU || code == LTU || code == GEU || code == GTU)
> >&& is_a  (GET_MODE (op0), _mode)
> > +  && HWI_COMPUTABLE_MODE_P (int_mode)
> >&& MEM_P (op0)
> >&& !MEM_VOLATILE_P (op0)
> >/* The optimization makes only sense for constants which are big
> > enough
> >  so that we have a chance to chop off something at all.  */
> >&& (unsigned HOST_WIDE_INT) const_op > 0xff
> > +  /* Bail out, if the constant does not fit into INT_MODE.  */
> > +  && (unsigned HOST_WIDE_INT) const_op
> > +< ((HOST_WIDE_INT_1U << (GET_MODE_PRECISION (int_mode) - 1) << 1) -
> > 1)
> >/* Ensure that we do not overflow during normalization.  */
> >&& (code != GTU || (unsigned HOST_WIDE_INT) const_op <
> > HOST_WIDE_INT_M1U))
> >  {
> > 
> > Does this resolve the problem for you?
> 
> Yes, it worked thanks! I will do a full bootstrap+test with your fix and let
> you know the results.
Bootstrap+testing works fine with your fix. Thanks!
> 
> Thanks,
> Prathamesh

[Bug modula2/110161] Comparing a typed procedure variable to 0 gives ICE or assertions

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

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

[Bug modula2/110161] Comparing a typed procedure variable to 0 gives ICE or assertions

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Gaius Mulley
:

https://gcc.gnu.org/g:26b627810a2e307d0eacf4bf290daf548feb517c

commit r13-7680-g26b627810a2e307d0eacf4bf290daf548feb517c
Author: Gaius Mulley 
Date:   Wed Aug 2 00:42:06 2023 +0100

PR modula2/110161 Comparing a typed procedure variable to 0 gives ICE or
assertion

This patch allows a proc type to be compared against an address.

gcc/m2/ChangeLog:

PR modula2/110161
* gm2-compiler/M2Check.mod (checkProcTypeEquivalence): New
procedure function.
(checkTypeKindEquivalence): Call checkProcTypeEquivalence
if either left or right is a proc type.
* gm2-compiler/M2Quads.mod (BuildRelOp): Create
combinedTok prior to creating the range check quadruple.
Use combinedTok when creating the range check quadruple.

gcc/testsuite/ChangeLog:

PR modula2/110161
* gm2/pim/fail/badxproc.mod: New test.

(cherry picked from commit 8bf244e32a0d505720396fbb7df26f824c7f77eb)

Signed-off-by: Gaius Mulley 

[Bug modula2/110161] Comparing a typed procedure variable to 0 gives ICE or assertions

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

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

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

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

commit r14-2911-g8bf244e32a0d505720396fbb7df26f824c7f77eb
Author: Gaius Mulley 
Date:   Wed Aug 2 00:34:29 2023 +0100

PR modula2/110161 Comparing a typed procedure variable to 0 gives ICE or
assertion

This patch allows a proc type to be compared against an address.

gcc/m2/ChangeLog:

PR modula2/110161
* gm2-compiler/M2Check.mod (checkProcTypeEquivalence): New
procedure function.
(checkTypeKindEquivalence): Call checkProcTypeEquivalence
if either left or right is a proc type.
* gm2-compiler/M2Quads.mod (BuildRelOp): Create
combinedTok prior to creating the range check quadruple.
Use combinedTok when creating the range check quadruple.

gcc/testsuite/ChangeLog:

PR modula2/110161
* gm2/pim/fail/badxproc.mod: New test.

Signed-off-by: Gaius Mulley 

[Bug modula2/110161] Comparing a typed procedure variable to 0 gives ICE or assertions

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

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

--- Comment #2 from Gaius Mulley  ---
Created attachment 55674
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55674=edit
Proposed fix

Here is a proposed patch which will be applied (if) the bootstrap succeeds.

[Bug middle-end/109986] missing fold (~a | b) ^ a => ~(a & b)

[gabravier at gmail dot com via Gcc-bugs]

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

Gabriel Ravier  changed:

   What|Removed |Added

 CC||gabravier at gmail dot com

--- Comment #6 from Gabriel Ravier  ---
Seems to be fixed on trunk, except that I've noticed that the f0 example does
some weird operations on BPF, but that seems like a separate issue.

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

[akrzemi1 at gmail dot com via Gcc-bugs]

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

Bug ID: 110872
   Summary: coroutine postcondition is not evaluated
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akrzemi1 at gmail dot com
  Target Milestone: ---

Created attachment 55673
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55673=edit
demo program

A postconditon declared on a coroutine should be evaluated when the coroutine
is invoked and returns to the caller. But it isn't as per the following
Compiler Explorer link.

https://godbolt.org/z/48fh3f34j

The expectation is enforced by the fact that the compiler allows mentioning the
return type of the coroutine declaration:

```
template 
struct generator
{
// ...
bool is_valid() { return false; }
};

generator val(int v) 
[[post g: g.is_valid()]]
{
co_yield v;
}
```

Generally, I would expect that preconditions and postconditions on coroutines
should work the same as if the call to the coroutine was wrapped in a
forwarding function containing the preconditions and postconditions:

```
awaitable f1(int i)  // coroutine
  [[pre: p(i)]]
  [[post r: q(r)]];

awaitable f2(int i); // coroutine

awaitable ff2(int i)
  [[pre: p(i)]]
  [[post r: q(r)]];
{
  return f2(i);
}

void caller()
{
  f1(1);  // these two calls should have analogous
  ff2(1); // precondition and postcondition semantics
}
```

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

[akrzemi1 at gmail dot com via Gcc-bugs]

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

Bug ID: 110871
   Summary: coroutine precondition should be evaluated before the
initial suspend
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akrzemi1 at gmail dot com
  Target Milestone: ---

Created attachment 55672
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55672=edit
Sample program illustrating the bug

When I declare a precondition on a coroutine, it is not evaluated when the
corresponding promise type performs the initial suspend.

While "C++20 contracts" or the "Contracts MVP"
(https://isocpp.org/files/papers/P2388R4.html) never mention how this should
work, the intuition dictates that the preconditions protect against the usage
of the incorrect combination of function parameters.

Function parameters of a coroutine may be used before the initial suspend to
initialize the promise object (when it provides a variadic constructor). The
coroutine precondition should be evaluated before this initialization,
therefore before the initial suspend.

Also, this follows from the rule of thumb that implementations should have
freedom to check the precondition either in the caller or in the callee and
either choice should not affect the program semantics. 

The following Compiler Explorer example illustrtes the issue. "Disaster!"
should  never be printed:

https://godbolt.org/z/fxMjT4vfx

[Bug fortran/88286] [OOP] gfortran reports conflicting intent(in) with an intent(in) declared class variable

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||12.3.0, 13.1.0, 14.0
  Known to fail||11.4.1
 Status|NEW |WAITING

--- Comment #2 from anlauf at gcc dot gnu.org ---
Appears fixed in 12-branch and later.  Adding known-to work.

Can we close this one?

[Bug rtl-optimization/110864] [14 Regression] ICE in combine.cc causes stage2 build failure on RISCV

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #6 from Patrick O'Neill  ---
No new regressions in the testsuite - that fix will work!

[Bug fortran/88420] Fortran OpenACC "Clause SEQ conflicts with INDEPENDENT"

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to Thomas Schwinge from comment #3)
> (In reply to Dominique d'Humieres from comment #2)
> > Shouldn't this PR be closed as FIXED?
> 
> No, this will need to be fixed in other release branches, too.

This appears fixed on 9-branch and later.

There ain't no reason to keep it open 5 years after it has been fixed.
Or are we missing something?

[Bug middle-end/110869] [14 regression] ICE in decompose, at rtl.h:2297

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #1 from Andrew Pinski  ---
> Can you test the patch in bug 110867 comment #1 to see if fixes the issue here
> too?

Sure: sparc-sun-solaris2.11 bootstrap in progress...

[Bug target/53935] [avr][c++] missing warning for non-const data in progmem

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
  Known to work||8.1.0
   Keywords||addr-space

--- Comment #2 from Georg-Johann Lay  ---
Closed as fixed in v7+.

[Bug target/96055] avr: atmega324pb not supported

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

  Known to work||12.1.0
 Resolution|--- |FIXED
   Severity|normal  |enhancement
   Priority|P3  |P5
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Georg-Johann Lay  ---
Closed as fixed in v12+.

ATmega324PB is present in the sources (gcc/config/avr/avr-mcus.def,
Author=Matwey V. Kornilov) since v12.1 at least.

If you want to use it with older versions of the compiler (and newer than
v5.1), please follow the explanation in the avr-gcc wiki at
https://gcc.gnu.org/wiki/avr-gcc#avr-gcc_v5_and_newer

[Bug rtl-optimization/110864] [14 Regression] ICE in combine.cc causes stage2 build failure on RISCV

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #5 from Patrick O'Neill  ---
The fix resolves the bootstrap error. Still running the testsuite.

[Bug rtl-optimization/110864] [14 Regression] ICE in combine.cc causes stage2 build failure on RISCV

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #4 from Patrick O'Neill  ---
Yep! Running bootstrap+regtests with the fix now.

[Bug modula2/110161] Comparing a typed procedure variable to 0 gives ICE or assertions

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

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

Gaius Mulley  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-08-01
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Gaius Mulley  ---
Confirmed thank you for the bug report and test code.

[Bug rtl-optimization/110864] [14 Regression] ICE in combine.cc causes stage2 build failure on RISCV

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

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

--- Comment #3 from Andrew Pinski  ---
Can you test the patch in bug 110867 comment #1 to see if fixes the issue here
too?

[Bug middle-end/110869] [14 regression] ICE in decompose, at rtl.h:2297

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

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

--- Comment #1 from Andrew Pinski  ---
Can you test the patch in bug 110867 comment #1 to see if fixes the issue here
too?

[Bug rtl-optimization/110867] [14 Regression] ICE in combine after 7cdd0860949c6c3232e6cff1d7ca37bb5234074c

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build, ice-on-valid-code
Summary|ICE in combine after|[14 Regression] ICE in
   |7cdd0860949c6c3232e6cff1d7c |combine after
   |a37bb5234074c   |7cdd0860949c6c3232e6cff1d7c
   ||a37bb5234074c
   Target Milestone|--- |14.0

[Bug modula2/110633] Using an unknown identifier as argument to ORD results in ICE

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #2 from Gaius Mulley  ---
Closing as now fixed during:

commit 428a9fc37547684cae2b4f8435a65c6c73131670

[Bug c++/99599] [11/12/13/14 Regression] Concepts requirement falsely reporting cyclic dependency, breaks tag_invoke pattern

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||waffl3x at protonmail dot com

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

[Bug c++/110291] [11/12/13/14 Regression] constraint on friend operator template causes bizarre duplication of RHS template parameter that is passed to the requires expression

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #3 from Patrick Palka  ---
Started with r11-2774.

This seems like an unexpected consequence of CWG2369: during overload
resolution for 'expr{} / expr{}' we have two interesting
candidates

expr::operator/(expr, expr) [with U=no_self]  // #1
expr::operator/(expr, expr) [with U=no_self]  // #2

Before CWG2369 we would discard #2 due to expr not being convertible to
expr, and we don't need to check #2's constraints.  But CWG2369 makes
us check constraints before checking non-dependent conversions, and it's during
constraint checking for #2 that we instantiate fn which
ultimately leads to the hard error :( Only GCC implements CWG2369 as far as I
know.

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

[Bug modula2/110633] Using an unknown identifier as argument to ORD results in ICE

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

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

Gaius Mulley  changed:

   What|Removed |Added

   Last reconfirmed||2023-08-01
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Gaius Mulley  ---
Now fixed on the gcc-13 branch.  Many thanks for the bug report!

[Bug c++/110822] ICE on constexpr initialized with non-constant expression also accepts-invalid

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

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

Patrick Palka  changed:

   What|Removed |Added

  Known to work|12.1.0  |
Summary|[13/14 Regression] ICE on   |ICE on constexpr
   |constexpr initialized with  |initialized with
   |non-constant expression |non-constant expression
   |also accepts-invalid|also accepts-invalid
  Known to fail|13.1.0  |14.0
   Target Milestone|13.3|---

[Bug c++/110822] [13/14 Regression] ICE on constexpr initialized with non-constant expression also accepts-invalid

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-08-01
 CC||ppalka at gcc dot gnu.org
   Keywords|accepts-invalid,|ice-checking,
   |ice-on-invalid-code |ice-on-valid-code

--- Comment #4 from Patrick Palka  ---
(In reply to Jiang An from comment #3)
> This example is valid (or should be) for libstdc++.
Thanks, I adjusted the PR to reflect this.

This seems to be a checking-only ICE and not a regression.  Reduced:

void __ostream_insert(const char*);
struct basic_string {
  const char* _M_p;
  char _M_local_buf[16] = {};
  constexpr basic_string() : _M_p(_M_local_buf) {}
  const char *data() const { return _M_p; }
};
constexpr basic_string f() { return {}; }
constexpr basic_string text = f();
int main() {
  __ostream_insert(text._M_p);
}

[Bug c++/110805] g++ crash on modules with exported class providing string constant with obscure content

[jo.hiller+gcc at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Jochen Hiller  ---
> Gcc's module support is still experimental.

Sure. Nevertheless reporting bugs may help to come from experimental to stable.

I mainly do prototype development using C++ modules with Clang 16, but trying
regularly to get it working with Gcc as well. On my list is as well to check
MSVC state of implementation.

[Bug c++/110805] g++ crash on modules with exported class providing string constant with obscure content

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

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

--- Comment #2 from Andrew Pinski  ---
Gcc's module support is still experimental.

[Bug c++/110870] g++ internal compiler error on modules with precompiled headerfile "string"

[jo.hiller+gcc at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Jochen Hiller  ---
Sorry, typo: is plog 1.1.9, not 1.1.19, see
https://github.com/SergiusTheBest/plog/releases/tag/1.1.9

* happens with plog-1.1.9, but seems unrelated

[Bug c++/110805] g++ crash on modules with exported class providing string constant with obscure content

[jo.hiller+gcc at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Jochen Hiller  ---
Side-note: same code does compile and execute fine with clang 16.0.6

[Bug c++/110870] g++ internal compiler error on modules with precompiled headerfile "string"

[jo.hiller+gcc at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Jochen Hiller  ---
Side-note: same code does compile fine with clang 16.0.6

[Bug c++/110870] New: g++ internal compiler error on modules with precompiled headerfile "string"

[jo.hiller+gcc at gmail dot com via Gcc-bugs]

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

Bug ID: 110870
   Summary: g++ internal compiler error on modules with
precompiled headerfile "string"
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jo.hiller+gcc at gmail dot com
  Target Milestone: ---

Created attachment 55671
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55671=edit
output of -freport-bug

// Info
gcc-13 --version
gcc-13 (Homebrew GCC 13.1.0) 13.1.0
macOS 13.5, arm64, Apple M1 MAX

// Steps to reproduce
* use C++20 modules with precompiled header string
* gcc 13.1 reports: "internal compiler error: in tsubst_copy, at
cp/pt.cc:17275"
* happens with plog-1.1.19, but seems unrelated

// i.cc
export module i;

// m_impl.cc
module;
#include 
module m:impl;
import i;

// m_public.c
export module m:_public;

import i;
import :impl;

// m.cc
export module m;
export import :_public;

// build
gcc-13 -std=c++20 -xc++-system-header -fmodule-header
/opt/homebrew/Cellar/gcc/13.1.0/include/c++/13/string
gcc-13 -std=c++20 -fmodules-ts -Wall -g -MMD
-I../../../third_party/plog-1.1.9/include -c i.cc -o i.o
gcc-13 -std=c++20 -fmodules-ts -Wall -g -MMD
-I../../../third_party/plog-1.1.9/include -c m_impl.cc -o m_impl.o
gcc-13 -std=c++20 -fmodules-ts -Wall -g -MMD
-I../../../third_party/plog-1.1.9/include -c m_public.cc -o m_public.o
gcc-13 -std=c++20 -fmodules-ts -Wall -g -MMD
-I../../../third_party/plog-1.1.9/include -freport-bug -c m.cc -o m.o
In file included from
/opt/homebrew/Cellar/gcc/13.1.0/include/c++/13/bits/locale_classes.h:869,
 from
/opt/homebrew/Cellar/gcc/13.1.0/include/c++/13/bits/ios_base.h:41,
 from /opt/homebrew/Cellar/gcc/13.1.0/include/c++/13/ios:44,
 from
/opt/homebrew/Cellar/gcc/13.1.0/include/c++/13/istream:40,
 from
/opt/homebrew/Cellar/gcc/13.1.0/include/c++/13/sstream:40,
 from ../../../third_party/plog-1.1.9/include/plog/Util.h:6,
 from ../../../third_party/plog-1.1.9/include/plog/Record.h:4,
 from
../../../third_party/plog-1.1.9/include/plog/Appenders/IAppender.h:2,
 from ../../../third_party/plog-1.1.9/include/plog/Logger.h:2,
 from ../../../third_party/plog-1.1.9/include/plog/Log.h:7,
 from m_impl.cc:3,
of module m:impl, imported at m_public.cc:4,
of module m:_public, imported at m.cc:3:
/opt/homebrew/Cellar/gcc/13.1.0/include/c++/13/bits/locale_classes.tcc: In
instantiation of 'const _Facet& std::use_facet(const locale&) [with _Facet =
__cxx11::numpunct@m:impl]':
/opt/homebrew/Cellar/gcc/13.1.0/include/c++/13/bits/locale_facets.tcc:80:66:  
required from 'void std::__numpunct_cache@m:impl<_CharT>::_M_cache(const
std::locale&) [with _CharT = char]'
/opt/homebrew/Cellar/gcc/13.1.0/include/c++/13/bits/locale_facets.tcc:63:18:  
required from 'const std::__numpunct_cache@m:impl<_CharT>*
std::__use_cache@m:impl
>::operator()(const std::locale&) const [with _CharT = char]'
/opt/homebrew/Cellar/gcc/13.1.0/include/c++/13/bits/locale_facets.tcc:384:33:  
required from '_InIter std::num_get@m:impl<_CharT,
_InIter>::_M_extract_int(_InIter, _InIter, std::ios_base@m:impl&,
std::ios_base@m:impl::iostate&, _ValueT&) const [with _ValueT = long int;
_CharT = char; _InIter = std::istreambuf_iterator >; std::ios_base@m:impl::iostate =
std::ios_base@m:impl::iostate]'
/opt/homebrew/Cellar/gcc/13.1.0/include/c++/13/bits/locale_facets.h:2225:30:  
required from 'std::num_get@m:impl<_CharT, _InIter>::iter_type
std::num_get@m:impl<_CharT, _InIter>::do_get(iter_type, iter_type,
std::ios_base@m:impl&, std::ios_base@m:impl::iostate&, long int&) const [with
_CharT = char; _InIter = std::istreambuf_iterator >; iter_type = std::istreambuf_iterator >; std::ios_base@m:impl::iostate =
std::ios_base@m:impl::iostate]'
/opt/homebrew/Cellar/gcc/13.1.0/include/c++/13/bits/locale_facets.h:2223:7:  
required from here
/opt/homebrew/Cellar/gcc/13.1.0/include/c++/13/bits/locale_classes.tcc:203:60:
internal compiler error: in tsubst_copy, at cp/pt.cc:17275
  203 |   if (const _Facet* __f = std::__try_use_facet<_Facet>(__loc))
  |^
Please submit a full bug report, with preprocessed source.
See  for instructions.
Preprocessed source stored into
/var/folders/_f/yfc6xzvd2sd1gsvthzlfkbdmgn/T//ccPMd0Iz.out file, please
attach this to your bugreport.
make: *** [gcc] Error 1

# see attached output file cczqIydL.out.txt

// m.cc -MDD
m.o gcm.cache/m.gcm: m.cc
m.o gcm.cache/m.gcm: m:_public.c++m
m.c++m: gcm.cache/m.gcm
.PHONY: m.c++m
gcm.cache/m.gcm:| m.o
CXX_IMPORTS += m:_public.c++m

// notes
* internal compiler error does not happen, when string will NOT be 

[Bug middle-end/110869] [14 regression] ICE in decompose, at rtl.h:2297

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

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug middle-end/110869] New: [14 regression] ICE in decompose, at rtl.h:2297

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

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

Bug ID: 110869
   Summary: [14 regression] ICE in decompose, at rtl.h:2297
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: stefansf at linux dot ibm.com
  Target Milestone: ---
  Host: sparc-sun-solaris2.11
Target: sparc-sun-solaris2.11
 Build: sparc-sun-solaris2.11

Between 20230731 (bf67bf4880ce5be0b6e48c7c35828528b7be12ed) and 20230801
(a5451b8b9f3a6ab0cb1a60bc8b0b76cca46b080f), Solaris/SPARC bootstrap broke e.g.
compiling cp/lex.cc in stage 2:

during RTL pass: combine
/vol/gcc/src/hg/master/local/gcc/cp/lex.cc: In function ‘void
cxx_dup_lang_specific_decl(tree)’:
/vol/gcc/src/hg/master/local/gcc/cp/lex.cc:1026:1: internal compiler error: in
decompose, at rtl.h:2297
 1026 | }
  | ^
0x197362f wi::int_traits >::decompose(long
long*, unsigned int, std::pair const&)
/vol/gcc/src/hg/master/local/gcc/rtl.h:2297
0x1a034ef wide_int_ref_storage::wide_int_ref_storage
>(std::pair const&)
/vol/gcc/src/hg/master/local/gcc/wide-int.h:1030
0x1a02513 generic_wide_int
>::generic_wide_int >(std::pair const&)
/vol/gcc/src/hg/master/local/gcc/wide-int.h:788
0x2151017 simplify_const_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
/vol/gcc/src/hg/master/local/gcc/simplify-rtx.cc:2131
0x214a35f simplify_context::simplify_unary_operation(rtx_code, machine_mode,
rtx_def*, machine_mode)
/vol/gcc/src/hg/master/local/gcc/simplify-rtx.cc:889
0x2147e0f simplify_context::simplify_gen_unary(rtx_code, machine_mode,
rtx_def*, machine_mode)
/vol/gcc/src/hg/master/local/gcc/simplify-rtx.cc:360
0x17e5317 simplify_gen_unary(rtx_code, machine_mode, rtx_def*, machine_mode)
/vol/gcc/src/hg/master/local/gcc/rtl.h:3520
0x300c3f3 simplify_comparison
/vol/gcc/src/hg/master/local/gcc/combine.cc:13125
0x2ff04cf simplify_set
/vol/gcc/src/hg/master/local/gcc/combine.cc:6848
0x2fed9b3 combine_simplify_rtx
/vol/gcc/src/hg/master/local/gcc/combine.cc:6353
0x2fea537 subst
/vol/gcc/src/hg/master/local/gcc/combine.cc:5609
0x2fe0b3b try_combine
/vol/gcc/src/hg/master/local/gcc/combine.cc:3339
0x2fd8a57 combine_instructions
/vol/gcc/src/hg/master/local/gcc/combine.cc:1285
0x30130a3 rest_of_handle_combine
/vol/gcc/src/hg/master/local/gcc/combine.cc:15059
0x30131c7 execute
/vol/gcc/src/hg/master/local/gcc/combine.cc:15103

I've not yet identified the culprit patch, but this one seems plausible:

commit 7cdd0860949c6c3232e6cff1d7ca37bb5234074c
Author: Stefan Schulze Frielinghaus 
Date:   Mon Jul 31 16:35:33 2023 +0200

combine: Narrow comparison of memory and constant

[Bug rtl-optimization/110867] ICE in combine after 7cdd0860949c6c3232e6cff1d7ca37bb5234074c

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

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

--- Comment #2 from prathamesh3492 at gcc dot gnu.org ---
(In reply to Stefan Schulze Frielinghaus from comment #1)
> The optimization introduced by r14-2879-g7cdd0860949c6c hits during
> combination of insn
> 
> (insn 31 3 32 2 (set (reg:SI 118 [ _1 ])
> (mem:SI (reg/v/f:SI 115 [ a ]) [1 *a_4(D)+0 S4 A64])) "t.c":15:7 758
> {*arm_movsi_vfp}
>  (nil))
> 
> and
> 
> (insn 9 32 10 2 (set (reg:CC 100 cc)
> (compare:CC (reg:SI 118 [ _1 ])
> (const_int -2147483648 [0x8000]))) "t.c":15:6 272
> {*arm_cmpsi_insn}
>  (nil))
> 
> The idea of r14-2879-g7cdd0860949c6c is to get rid of large constants while
> performing an unsigned comparison.  In this case it looks like a 32-bit
> constant is sign-extended into a 64-bit constant and then a 32-bit
> comparison is done.  While writing the optimization I always assumed that
> the constant does fit into int_mode which is apparently not the case here. 
> Thus one possible solution would be to simply bail out in those cases:
> 
> diff --git a/gcc/combine.cc b/gcc/combine.cc
> index 0d99fa541c5..e46d202d0a7 100644
> --- a/gcc/combine.cc
> +++ b/gcc/combine.cc
> @@ -11998,11 +11998,15 @@ simplify_compare_const (enum rtx_code code,
> machine_mode mode,
>   x0 >= 0x40.  */
>if ((code == LEU || code == LTU || code == GEU || code == GTU)
>&& is_a  (GET_MODE (op0), _mode)
> +  && HWI_COMPUTABLE_MODE_P (int_mode)
>&& MEM_P (op0)
>&& !MEM_VOLATILE_P (op0)
>/* The optimization makes only sense for constants which are big
> enough
>  so that we have a chance to chop off something at all.  */
>&& (unsigned HOST_WIDE_INT) const_op > 0xff
> +  /* Bail out, if the constant does not fit into INT_MODE.  */
> +  && (unsigned HOST_WIDE_INT) const_op
> +< ((HOST_WIDE_INT_1U << (GET_MODE_PRECISION (int_mode) - 1) << 1) -
> 1)
>/* Ensure that we do not overflow during normalization.  */
>&& (code != GTU || (unsigned HOST_WIDE_INT) const_op <
> HOST_WIDE_INT_M1U))
>  {
> 
> Does this resolve the problem for you?

Yes, it worked thanks! I will do a full bootstrap+test with your fix and let
you know the results.

Thanks,
Prathamesh

[Bug modula2/110865] Unable to access copied const array

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Gaius Mulley
:

https://gcc.gnu.org/g:860b0f0ef787f756c0e293671b4c4622dff63a79

commit r13-7679-g860b0f0ef787f756c0e293671b4c4622dff63a79
Author: Gaius Mulley 
Date:   Tue Aug 1 14:59:48 2023 +0100

PR modula2/110865 Unable to access copied const array

This patch allows constants of an array type to be indexed.

gcc/m2/ChangeLog:

PR modula2/110865
* gm2-compiler/M2Quads.mod (BuildDesignatorArray):
Rename t as type and d as dim.  New variable result.
Allow constants of an array type to be indexed.

gcc/testsuite/ChangeLog:

PR modula2/110865
* gm2/iso/pass/constvec.mod: New test.
* gm2/iso/pass/constvec2.mod: New test.
* gm2/iso/run/pass/constvec3.mod: New test.

(cherry picked from commit 8a47474f2cf48837d6adf4a1232a89fd398ca7fa)

Signed-off-by: Gaius Mulley 

[Bug tree-optimization/110852] [14 Regression] ICE: in get_predictor_value, at predict.cc:2695 with -O -fno-tree-fre and __builtin_expect()

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

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

--- Comment #1 from Jan Hubicka  ---
This is likely g:eab57b825bcc350e9ff44eb2fa739a80199d9bb1 which fixed
prediction order and uncovered latent bug in combininig predictions with known
probabilities.  I will take a look.

[Bug target/110625] [AArch64] Vect: SLP fails to vectorize a loop as the reduction_latency calculated by new costs is too large

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

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

--- Comment #18 from Tamar Christina  ---
Hi, here's the reduced case:


> cat analyse.i

double x264_weights_analyse___trans_tmp_1;
float x264_weights_analyse_ref_mean;
x264_weights_analyse() {
  x264_weights_analyse___trans_tmp_1 = floor(x264_weights_analyse_ref_mean);
}


> cat pixel.i

unsigned x264_pixel_satd_8x4___trans_tmp_1;
x264_pixel_satd_8x4_sum;
x264_pixel_satd_8x4() {
  for (int i; i; i++) {
x264_pixel_satd_8x4___trans_tmp_1 = i;
x264_pixel_satd_8x4_sum += x264_pixel_satd_8x4___trans_tmp_1;
  }
  return (unsigned)x264_pixel_satd_8x4_sum >> 1;
}

---

reproduce with:

gcc -c -o pixel.o pixel.i -mcpu=neoverse-v1 -flto=auto -Ofast -w
gcc -c -o analyse.o analyse.i -mcpu=neoverse-v1 -flto=auto -Ofast -w
gcc -flto=auto -Ofast pixel.o analyse.o -lm -o x264_r -r -w

[Bug target/105523] Wrong warning array subscript [0] is outside array bounds

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

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

--- Comment #34 from Georg-Johann Lay  ---
@Senthil: Can this PR be closed? Or will it be backported?

[Bug libstdc++/110862] format out of bands read on format string "{0:{0}"

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |13.3
   Last reconfirmed||2023-08-01
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED

[Bug target/110220] [13/14 Regression] ICE in patch_jump_insn, at cfgrtl.cc:1295 - avr/xmega

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
  Component|rtl-optimization|target

--- Comment #10 from Georg-Johann Lay  ---
Fixed in v13.3+.

[Bug rtl-optimization/110220] [13/14 Regression] ICE in patch_jump_insn, at cfgrtl.cc:1295 - avr/xmega

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Georg-Johann Lay
:

https://gcc.gnu.org/g:07573fc45a1fefa7e5f03e1930b188f36eba3a11

commit r13-7678-g07573fc45a1fefa7e5f03e1930b188f36eba3a11
Author: Georg-Johann Lay 
Date:   Tue Aug 1 13:49:17 2023 +0200

target/110220: Set JUMP_LABEL and LABEL_NUSES of new branch insn generated
by

target specific RTL optimization pass .avr-casesi.

gcc/
PR target/110220
* config/avr/avr.cc (avr_optimize_casesi): Set JUMP_LABEL and
LABEL_NUSES of new conditional branch instruction.

[Bug c++/110848] Consider enabling -Wvla by default in non-GNU C++ modes

[aaron at aaronballman dot com via Gcc-bugs]

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

--- Comment #10 from Aaron Ballman  ---
(In reply to Jonathan Wakely from comment #9)
> Personally I'd like it diagnosed in GNU modes, but this is pretty much the
> poster child for "conforming extension diagnosed with -pedantic" so I can
> see the argument for not diagnosing it by default.

Agreed -- I also see the argument for not diagnosing it by default. Normally I
wouldn't suggest such a thing and I would not consider this to be a precedent
to be applied to other extensions if it does get warned on by default. (I think
the only other extension that might m be in the same category
would be nested functions in C, but I've not spent nearly enough time
researching that one to be sure.)

Re: [Predicated Ins vs Branches] O3 and PGO result in 2x performance drop relative to O2

[Changbin Du via Gcc-bugs]

On Mon, Jul 31, 2023 at 08:55:35PM +0800, Changbin Du wrote:
> The result (p-core, no ht, no turbo, performance mode):
> 
> O2  O3  PGO
> cycles  2,581,832,749   8,638,401,568   9,394,200,585
> (1.07s) (3.49s) (3.80s)
> instructions12,609,600,094  11,827,675,782  12,036,010,638
> branches2,303,416,221   2,671,184,833   2,723,414,574
> branch-misses   0.00%   7.94%   8.84%
> cache-misses3,012,613   3,055,722   3,076,316
> L1-icache-load-misses   11,416,391  12,112,703  11,896,077
> icache_tag.stalls   1,553,521   1,364,092   1,896,066
> itlb_misses.stlb_hit6,856   21,756  22,600
> itlb_misses.walk_completed  14,430  4,454   15,084
> baclears.any131,573 140,355 131,644
> int_misc.clear_resteer_cycles   2,545,915   586,578,125 679,021,993
> machine_clears.count22,235  39,671  37,307
> dsb2mite_switches.penalty_cycles 6,985,838  12,929,675  8,405,493
> frontend_retired.any_dsb_miss   28,785,677  28,161,724  28,093,319
> idq.dsb_cycles_any  1,986,038,896   5,683,820,258   5,971,969,906
> idq.dsb_uops11,149,445,952  26,438,051,062  28,622,657,650
> idq.mite_uops   207,881,687 216,734,007 212,003,064
> 
> 
> Above data shows:
>   o O3/PGO lead to *2.3x/2.6x* performance drop than O2 respectively.
>   o O3/PGO reduced instructions by 6.2% and 4.5%. I think this attributes to
> aggressive inline.
>   o O3/PGO introduced very bad branch prediction. I will explain it later.
>   o Code built with O3 has high iTLB miss but much lower sTLB miss. This is 
> beyond
> my expectation.
>   o O3/PGO introduced 78% and 68% more machine clears. This is interesting and
> I don't know why. (subcategory MC is not measured yet)
The MCs are caused by memory ordering conflict and attribute to the kernel rcu
lock in I/O path, when ext4 tries to update its journal.

>   o O3 has much higher dsb2mite_switches.penalty_cycles than O2/PGO.
>   o The idq.mite_uops of O3/PGO increased 4%, while idq.dsb_uops increased 2x.
> DSB hit well. So frontend fetching and decoding is not a problem for 
> O3/PGO.
>   o Other events are mainly affected by bad branch misprediction.
> 

-- 
Cheers,
Changbin Du

[Bug ipa/110378] IPA-SRA for destructors

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

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

--- Comment #5 from Martin Jambor  ---
I have proposed a patch addressing the simplest case of the three on the
mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625895.html

[Bug libstdc++/110860] std::format("{:f}",2e304) invokes undefined behaviour

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

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

--- Comment #3 from Jonathan Wakely  ---
std::abs

[Bug libstdc++/110860] std::format("{:f}",2e304) invokes undefined behaviour

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Status|NEW |ASSIGNED
   Target Milestone|--- |13.3

--- Comment #2 from Jonathan Wakely  ---
Well it should be generic like std::and grumble grumble

Re: [Predicated Ins vs Branches] O3 and PGO result in 2x performance drop relative to O2

[Changbin Du via Gcc-bugs]

On Tue, Aug 01, 2023 at 10:44:02AM +0200, Jan Hubicka wrote:
> > > If I comment it out as above patch, then O3/PGO can get 16% and 12% 
> > > performance
> > > improvement compared to O2 on x86.
> > >
> > > O2  O3  PGO
> > > cycles  2,497,674,824   2,104,993,224   2,199,753,593
> > > instructions10,457,508,646  9,723,056,131   10,457,216,225
> > > branches2,303,029,380   2,250,522,323   2,302,994,942
> > > branch-misses   0.00%   0.01%   0.01%
> > >
> > > The main difference in the compilation output about code around the 
> > > miss-prediction
> > > branch is:
> > >   o In O2: predicated instruction (cmov here) is selected to eliminate 
> > > above
> > > branch. cmov is true better than branch here.
> > >   o In O3/PGO: bitout() is inlined into encode_file(), and branch 
> > > instruction
> > > is selected. But this branch is obviously *unpredictable* and the 
> > > compiler
> > > doesn't know it. This why O3/PGO are are so bad for this program.
> > >
> > > Gcc doesn't support __builtin_unpredictable() which has been introduced 
> > > by llvm.
> > > Then I tried to see if __builtin_expect_with_probability(e,x, 0.5) can 
> > > serve the
> > > same purpose. The result is negative.
> > 
> > But does it appear to be predictable with your profiling data?
> 
> Also one thing is that __builtin_expect and
> __builtin_expect_with_probability only affects the static branch
> prediciton algorithm, so with profile feedback they are ignored on every
> branch executed at least once during the train run.
> 
> setting probability 0.5 is really not exactly the same as hint that the
> branch will be mispredicted, since modern CPUs handle well regularly
> behaving branchs (such as a branch firing every even iteration of loop).
>
Yeah. Setting probability 0.5 is just an experimental attempt. I don't know
how the heuristic works internally.

> So I think having the builting is not a bad idea.  I was thinking if it
> makes sense to represent it withing profile_probability type and I am
> not convinced, since "unpredictable probability" sounds counceptually
> odd and we would need to keep the flag intact over all probability
> updates we do.  For things like loop exits we recompute probabilities
> from frequencies after unrolling/vectorizaiton and other things and we
> would need to invent new API to propagate the flag from previous
> probability (which is not even part of the computation right now)
> 
> So I guess the challenge is how to pass this info down through the
> optimization pipeline, since we would need to annotate gimple
> conds/switches and manage it to RTL level.  On gimple we have flags and
> on rtl level notes so there is space for it, but we would need to
> maintain the info through CFG changes.
> 
> Auto-FDO may be interesting way to detect such branches.
> 
So I suppose PGO also could. But branch instruction is selected in my test just
as O3 does. And data shows that comv works better than branch here.

> Honza
> > 
> > > I think we could come to a conclusion that there must be something can 
> > > improve in
> > > Gcc's heuristic strategy about Predicated Instructions and branches, at 
> > > least
> > > for O3 and PGO.
> > >
> > > And can we add __builtin_unpredictable() support for Gcc? As usually it's 
> > > hard
> > > for the compiler to detect unpredictable branches.
> > >
> > > --
> > > Cheers,
> > > Changbin Du

-- 
Cheers,
Changbin Du

[Bug c++/110848] Consider enabling -Wvla by default in non-GNU C++ modes

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

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

--- Comment #9 from Jonathan Wakely  ---
Personally I'd like it diagnosed in GNU modes, but this is pretty much the
poster child for "conforming extension diagnosed with -pedantic" so I can see
the argument for not diagnosing it by default.

Re: [Predicated Ins vs Branches] O3 and PGO result in 2x performance drop relative to O2

[Changbin Du via Gcc-bugs]

On Mon, Jul 31, 2023 at 03:53:26PM +0200, Richard Biener wrote:
[snip]
> > The main difference in the compilation output about code around the 
> > miss-prediction
> > branch is:
> >   o In O2: predicated instruction (cmov here) is selected to eliminate above
> > branch. cmov is true better than branch here.
> >   o In O3/PGO: bitout() is inlined into encode_file(), and branch 
> > instruction
> > is selected. But this branch is obviously *unpredictable* and the 
> > compiler
> > doesn't know it. This why O3/PGO are are so bad for this program.
> >
> > Gcc doesn't support __builtin_unpredictable() which has been introduced by 
> > llvm.
> > Then I tried to see if __builtin_expect_with_probability(e,x, 0.5) can 
> > serve the
> > same purpose. The result is negative.
> 
> But does it appear to be predictable with your profiling data?
>
I profiled the branch-misses event on a kabylake machine. 99% of the
mis-prediction blames to encode_file() function.

$ sudo perf record -e branch-instructions:pp,branch-misses:pp -c 1000 -- 
taskset -c 0 ./huffman.O3 test.data

Samples: 197K of event 'branch-misses:pp', Event count (approx.): 197618000
Overhead  Command Shared Object Symbol
  99.58%  huffman.O3  huffman.O3[.] encode_file
   0.12%  huffman.O3  [kernel.vmlinux]  [k] __x86_indirect_thunk_array
   0.11%  huffman.O3  libc-2.31.so  [.] _IO_getc
   0.01%  huffman.O3  [kernel.vmlinux]  [k] common_file_perm

Then annotate encode_file() function:

Samples: 197K of event 'branch-misses:pp', 1000 Hz, Event count (approx.): 
197618000
encode_file  /work/myWork/linux/pgo/huffman.O3 [Percent: local period]
Percent│ ↑ je  38
   │ bitout():
   │ current_byte <<= 1;
   │ 70:   add %edi,%edi
   │ if (b == '1') current_byte |= 1;
 48.70 │┌──cmp $0x31,%dl
 47.11 │├──jne 7a
   ││  or  $0x1,%edi
   ││nbits++;  
   │ 7a:└─→inc %eax
   │ if (b == '1') current_byte |= 1;
   │   mov %edi,current_byte
   │ nbits++;
   │   mov %eax,nbits
   │ if (nbits == 8) {
  1.16 │   cmp $0x8,%eax
  3.03 │ ↓ je  a0
   │ encode_file():
   │ for (s=codes[ch]; *s; s++) bitout (outfile, *s);
   │   movzbl  0x1(%r13),%edx
   │   inc %r13
   │   test%dl,%dl
   │ ↑ jne 70
   │ ↑ jmp 38
   │   nop

-- 
Cheers,
Changbin Du

[Bug rtl-optimization/110867] ICE in combine after 7cdd0860949c6c3232e6cff1d7ca37bb5234074c

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

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

Stefan Schulze Frielinghaus  changed:

   What|Removed |Added

 CC||stefansf at linux dot ibm.com

--- Comment #1 from Stefan Schulze Frielinghaus  
---
The optimization introduced by r14-2879-g7cdd0860949c6c hits during combination
of insn

(insn 31 3 32 2 (set (reg:SI 118 [ _1 ])
(mem:SI (reg/v/f:SI 115 [ a ]) [1 *a_4(D)+0 S4 A64])) "t.c":15:7 758
{*arm_movsi_vfp}
 (nil))

and

(insn 9 32 10 2 (set (reg:CC 100 cc)
(compare:CC (reg:SI 118 [ _1 ])
(const_int -2147483648 [0x8000]))) "t.c":15:6 272
{*arm_cmpsi_insn}
 (nil))

The idea of r14-2879-g7cdd0860949c6c is to get rid of large constants while
performing an unsigned comparison.  In this case it looks like a 32-bit
constant is sign-extended into a 64-bit constant and then a 32-bit comparison
is done.  While writing the optimization I always assumed that the constant
does fit into int_mode which is apparently not the case here.  Thus one
possible solution would be to simply bail out in those cases:

diff --git a/gcc/combine.cc b/gcc/combine.cc
index 0d99fa541c5..e46d202d0a7 100644
--- a/gcc/combine.cc
+++ b/gcc/combine.cc
@@ -11998,11 +11998,15 @@ simplify_compare_const (enum rtx_code code,
machine_mode mode,
  x0 >= 0x40.  */
   if ((code == LEU || code == LTU || code == GEU || code == GTU)
   && is_a  (GET_MODE (op0), _mode)
+  && HWI_COMPUTABLE_MODE_P (int_mode)
   && MEM_P (op0)
   && !MEM_VOLATILE_P (op0)
   /* The optimization makes only sense for constants which are big enough
 so that we have a chance to chop off something at all.  */
   && (unsigned HOST_WIDE_INT) const_op > 0xff
+  /* Bail out, if the constant does not fit into INT_MODE.  */
+  && (unsigned HOST_WIDE_INT) const_op
+< ((HOST_WIDE_INT_1U << (GET_MODE_PRECISION (int_mode) - 1) << 1) - 1)
   /* Ensure that we do not overflow during normalization.  */
   && (code != GTU || (unsigned HOST_WIDE_INT) const_op <
HOST_WIDE_INT_M1U))
 {

Does this resolve the problem for you?

[Bug libgcc/110868] crossback build fails for x86_64-pc-linux-gnu due to check on build environment

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
build==target just thinks it is a native compile for the target libraries
because that is what it is and it is not really supported.
The easiest way to create a cross back is to use a different triplet for the
target from the build triplet.

[Bug rtl-optimization/110220] [13/14 Regression] ICE in patch_jump_insn, at cfgrtl.cc:1295 - avr/xmega

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Georg-Johann Lay :

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

commit r14-2907-g1d379bb1191390c3be1fdd0f2fb8e8b1e2c44cd7
Author: Georg-Johann Lay 
Date:   Tue Aug 1 13:49:17 2023 +0200

target/110220: Set JUMP_LABEL and LABEL_NUSES of new branch insn generated
by

target specific RTL optimization pass .avr-casesi.

gcc/
PR target/110220
* config/avr/avr.cc (avr_optimize_casesi): Set JUMP_LABEL and
LABEL_NUSES of new conditional branch instruction.

[Bug preprocessor/80753] __has_include and __has_include_next taints subsequent I/O errors

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Fixed for GCC 14+.  No plans to backport, this used to be an accepts-invalid
bug and the general policy is not to backport bugfixes for accepts-invalid
bugs, as we would start rejecting something that wasn't rejected before.

[Bug preprocessor/110226] __has_include on a header causes GCC to ignore an non-existent header afterwards

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

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

Bug 80753 Summary: __has_include and __has_include_next taints subsequent I/O 
errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80753

   What|Removed |Added

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

[Bug tree-optimization/106293] [13/14 Regression] 456.hmmer at -Ofast -march=native regressed by 19% on zen2 and zen3 in July 2022

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

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

--- Comment #23 from Jan Hubicka  ---
Thanks,
I think I will need to work out the remaining vectorizer problems.  One issue
seems to be interaction with loop distribution.  Loop distribution seems to
intorduce alias checks that are later removed by vectorizer but I suspect the
profile is not compensated back.

Other problem is that lsplit produces loop iterating once (for the last
iteration) and does not update loop info accordingly (since it really lacks
analysis discovering this).  These loops seems to survive into ivopts

fast_algorithms.c.182t.ivopts:;;  iterations by profile: 5.312499 (unreliable,
maybe flat)
fast_algorithms.c.182t.ivopts:;;  iterations by profile: 0.009495 (unreliable,
maybe flat)
fast_algorithms.c.182t.ivopts:;;  iterations by profile: 0.009495 (unreliable,
maybe flat)
fast_algorithms.c.182t.ivopts:;;  iterations by profile: 0.009495 (unreliable,
maybe flat)
fast_algorithms.c.182t.ivopts:;;  iterations by profile: 0.009495 (unreliable,
maybe flat)
fast_algorithms.c.182t.ivopts:;;  iterations by profile: 100.08
(unreliable)
fast_algorithms.c.182t.ivopts:;;  iterations by profile: 100.00
(unreliable)
fast_algorithms.c.182t.ivopts:;;  iterations by profile: 9.662853 (unreliable,
maybe flat)
fast_algorithms.c.182t.ivopts:;;  iterations by profile: 4.646072 (unreliable)
fast_algorithms.c.182t.ivopts:;;  iterations by profile: 100.07
(unreliable)
fast_algorithms.c.182t.ivopts:;;  iterations by profile: 5.312500 (unreliable)
fast_algorithms.c.182t.ivopts:;;  iterations by profile: 473.497707 (reliable)
fast_algorithms.c.182t.ivopts:;;  iterations by profile: 100.999596 (reliable)

which is obviously bad idea.

[Bug target/110625] [AArch64] Vect: SLP fails to vectorize a loop as the reduction_latency calculated by new costs is too large

[hliu at amperecomputing dot com via Gcc-bugs]

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

--- Comment #17 from Hao Liu  ---
> Thanks! I can reduce a testcase for you if you want :)

That will be very helpful. Thanks.

[Bug target/110625] [AArch64] Vect: SLP fails to vectorize a loop as the reduction_latency calculated by new costs is too large

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

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

--- Comment #16 from Tamar Christina  ---
(In reply to Hao Liu from comment #15)
> Ah, I see.
> 
> I've sent out a quick fix patch for code review.  I'll investigate more
> about this and find out the root cause.

Thanks! I can reduce a testcase for you if you want :)

[Bug target/110625] [AArch64] Vect: SLP fails to vectorize a loop as the reduction_latency calculated by new costs is too large

[hliu at amperecomputing dot com via Gcc-bugs]

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

--- Comment #15 from Hao Liu  ---
Ah, I see.

I've sent out a quick fix patch for code review.  I'll investigate more about
this and find out the root cause.

[Bug target/110625] [AArch64] Vect: SLP fails to vectorize a loop as the reduction_latency calculated by new costs is too large

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

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

--- Comment #14 from Tamar Christina  ---
Or rather, info_for_reduction looks at the original statement if it's a
pattern, whereas vect_is_reduction only looks at the direct statement.

You'll probably want to check vect_orig_stmt if using info_for_reduction.

[Bug libgcc/110868] crossback build fails for x86_64-pc-linux-gnu due to check on build environment

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #2 from cqwrteur  ---
make[5]: Leaving directory
'/home/cqwrteur/toolchains_build/gcc_build/x86_64-w64-mingw32/x86_64-pc-linux-gnu/artifacts/hostbuild/x86_64-w64-mingw32/gcc/x86_64-pc-linux-gnu/32/libgcc'
make[4]: Leaving directory
'/home/cqwrteur/toolchains_build/gcc_build/x86_64-w64-mingw32/x86_64-pc-linux-gnu/artifacts/hostbuild/x86_64-w64-mingw32/gcc/x86_64-pc-linux-gnu/32/libgcc'
make[4]: Entering directory
'/home/cqwrteur/toolchains_build/gcc_build/x86_64-w64-mingw32/x86_64-pc-linux-gnu/artifacts/hostbuild/x86_64-w64-mingw32/gcc/x86_64-pc-linux-gnu/x32/libgcc'
make[4]: *** No rule to make target 'all'.  Stop.
make[4]: Leaving directory
'/home/cqwrteur/toolchains_build/gcc_build/x86_64-w64-mingw32/x86_64-pc-linux-gnu/artifacts/hostbuild/x86_64-w64-mingw32/gcc/x86_64-pc-linux-gnu/x32/libgcc'
make[3]: *** [Makefile:1214: multi-do] Error 1

[Bug target/110625] [AArch64] Vect: SLP fails to vectorize a loop as the reduction_latency calculated by new costs is too large

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

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

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

This patch is causing several ICEs:

For instance in x264,

during GIMPLE pass: vect
x264_src/common/pixel.c: In function 'x264_pixel_satd_8x4.constprop':
x264_src/common/pixel.c:234:21: internal compiler error: in info_for_reduction,
at tree-vect-loop.cc:5473
  234 | static NOINLINE int x264_pixel_satd_8x4( uint8_t *pix1, int i_pix1,
uint8_t *pix2, int i_pix2 )
  | ^
0xe45e23 info_for_reduction(vec_info*, _stmt_vec_info*)
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-loop.cc:5473
0xf1e317 aarch64_force_single_cycle
   
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/config/aarch64/aarch64.cc:16782
0xf1e317 aarch64_vector_costs::count_ops(unsigned int, vect_cost_for_stmt,
_stmt_vec_info*, aarch64_vec_op_count*)
   
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/config/aarch64/aarch64.cc:16807
0xf31fbb aarch64_vector_costs::add_stmt_cost(int, vect_cost_for_stmt,
_stmt_vec_info*, _slp_tree*, tree_node*, int, vect_cost_model_location)
   
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/config/aarch64/aarch64.cc:17074
0xe59edb add_stmt_cost(vector_costs*, int, vect_cost_for_stmt, _stmt_vec_info*,
_slp_tree*, tree_node*, int, vect_cost_model_location)
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vectorizer.h:1823
0xe59edb add_stmt_costs(vector_costs*, vec*)
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vectorizer.h:1870
0xe59edb vect_compute_single_scalar_iteration_cost
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-loop.cc:1624
0xe59edb vect_analyze_loop_2
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-loop.cc:2710
0xe5bb07 vect_analyze_loop_1
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-loop.cc:3329
0xe5c1cb vect_analyze_loop(loop*, vec_info_shared*)
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-loop.cc:3483
0xe90797 try_vectorize_loop_1
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vectorizer.cc:1064
0xe90797 try_vectorize_loop
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vectorizer.cc:1180
0xe90cb3 execute
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vectorizer.cc:1296

This seems to be caused because in aarch64_force_single_cycle is
unconditionally calling info_for_reduction without checking to see if this stmt
is actually a reduction.

You'll want to check STMT_VINFO_REDUC_DEF or STMT_VINFO_DEF_TYPE before calling
this.

[Bug libgcc/110868] crossback build fails for x86_64-pc-linux-gnu due to check on build environment

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #1 from cqwrteur  ---
Created attachment 55670
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55670=edit
config

[Bug libgcc/110868] New: crossback build fails for x86_64-pc-linux-gnu due to check on build environment

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 110868
   Summary: crossback build fails for x86_64-pc-linux-gnu due to
check on build environment
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

I try to do cross-back compilation for GCC, however, since ubuntu disables x32,
the sanity check for x32 will fail.

This should not happen, since i am building a compile that would run on
windows, the sanity check make no sense.

BTW, cross back incorrectly uses cc instead of just gcc.

[Bug middle-end/110857] aarch64-linux-gnu profiledbootstrap broken

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

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

--- Comment #1 from Jan Hubicka  ---
The sanity check fires since profile count involved are not compatible that
should never happen within a single function.  Would it be possible to dump
them? From debugger one should be able to call 
 p this->debug();
 p other.debug ();
from stage1 compiler that is build with -O0.

It is quite possible that this bug is carried for a while through the
optimization pipeline. It would be also useful to have
-fdump-tree-all-blocks-details and -fdump-rtl-all-blocks-details dumps.

Honza

Re: [Predicated Ins vs Branches] O3 and PGO result in 2x performance drop relative to O2

[Jan Hubicka via Gcc-bugs]

> > If I comment it out as above patch, then O3/PGO can get 16% and 12% 
> > performance
> > improvement compared to O2 on x86.
> >
> > O2  O3  PGO
> > cycles  2,497,674,824   2,104,993,224   2,199,753,593
> > instructions10,457,508,646  9,723,056,131   10,457,216,225
> > branches2,303,029,380   2,250,522,323   2,302,994,942
> > branch-misses   0.00%   0.01%   0.01%
> >
> > The main difference in the compilation output about code around the 
> > miss-prediction
> > branch is:
> >   o In O2: predicated instruction (cmov here) is selected to eliminate above
> > branch. cmov is true better than branch here.
> >   o In O3/PGO: bitout() is inlined into encode_file(), and branch 
> > instruction
> > is selected. But this branch is obviously *unpredictable* and the 
> > compiler
> > doesn't know it. This why O3/PGO are are so bad for this program.
> >
> > Gcc doesn't support __builtin_unpredictable() which has been introduced by 
> > llvm.
> > Then I tried to see if __builtin_expect_with_probability(e,x, 0.5) can 
> > serve the
> > same purpose. The result is negative.
> 
> But does it appear to be predictable with your profiling data?

Also one thing is that __builtin_expect and
__builtin_expect_with_probability only affects the static branch
prediciton algorithm, so with profile feedback they are ignored on every
branch executed at least once during the train run.

setting probability 0.5 is really not exactly the same as hint that the
branch will be mispredicted, since modern CPUs handle well regularly
behaving branchs (such as a branch firing every even iteration of loop).

So I think having the builting is not a bad idea.  I was thinking if it
makes sense to represent it withing profile_probability type and I am
not convinced, since "unpredictable probability" sounds counceptually
odd and we would need to keep the flag intact over all probability
updates we do.  For things like loop exits we recompute probabilities
from frequencies after unrolling/vectorizaiton and other things and we
would need to invent new API to propagate the flag from previous
probability (which is not even part of the computation right now)

So I guess the challenge is how to pass this info down through the
optimization pipeline, since we would need to annotate gimple
conds/switches and manage it to RTL level.  On gimple we have flags and
on rtl level notes so there is space for it, but we would need to
maintain the info through CFG changes.

Auto-FDO may be interesting way to detect such branches.

Honza
> 
> > I think we could come to a conclusion that there must be something can 
> > improve in
> > Gcc's heuristic strategy about Predicated Instructions and branches, at 
> > least
> > for O3 and PGO.
> >
> > And can we add __builtin_unpredictable() support for Gcc? As usually it's 
> > hard
> > for the compiler to detect unpredictable branches.
> >
> > --
> > Cheers,
> > Changbin Du

[Bug tree-optimization/110838] [14 Regression] wrong code on x365-3.5, -O3, sign extraction

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

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

--- Comment #7 from Sergei Trofimovich  ---
Tested https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625868.html against
x265-3.5 test suite. All passes.

Thank you!

[Bug target/43644] __uint128_t missed optimizations.

[jbeulich at suse dot com via Gcc-bugs]

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

jbeulich at suse dot com changed:

   What|Removed |Added

 CC||jbeulich at suse dot com

--- Comment #4 from jbeulich at suse dot com ---
I don't know what's different about my build, but I'm seeing the new
pr43644-2.c test failing, with this code generated:

foo:movq%rdx, %rcx
movq%rdi, %rax
movq%rsi, %rdx
addq%rcx, %rax
adcq$0, %rdx
ret

[Bug rtl-optimization/110867] New: ICE in combine after 7cdd0860949c6c3232e6cff1d7ca37bb5234074c

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

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

Bug ID: 110867
   Summary: ICE in combine after
7cdd0860949c6c3232e6cff1d7ca37bb5234074c
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prathamesh3492 at gcc dot gnu.org
  Target Milestone: ---

For the following test-case adapted from libgcc/fixed-bit.c:

typedef int DItype __attribute__ ((mode (DI)));

void
__gnu_saturate1sq (DItype *a)
{
  DItype max, min;
  max = (DItype)1 << (31 + 0);
  max = max - 1;

  min = (DItype)1 << (2 * (4 * 8) - 1);
  min = min >> (2 * (4 * 8) - 1 - (31 + 0));



  if (*a > max)
*a = max;
  else if (*a < min)
*a = min;
}

Compiling with -O2 on armv8l-unknown-linux-gnueabihf results in following ICE:
typedef int DItype __attribute__ ((mode (DI)));

during RTL pass: combine
foo.c: In function '__gnu_saturate1sq':
foo.c:19:1: internal compiler error: in decompose, at rtl.h:2297
   19 | }
  | ^
0xaa23e3 wi::int_traits >::decompose(long
long*, unsigned int, std::pair const&)
../../gcc/gcc/rtl.h:2297
0xaf5ab3 wide_int_ref_storage::wide_int_ref_storage
>(std::pair const&)
../../gcc/gcc/wide-int.h:1030
0xaf5023 generic_wide_int
>::generic_wide_int >(std::pair const&)
../../gcc/gcc/wide-int.h:788
0xf916f9 simplify_const_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
../../gcc/gcc/simplify-rtx.cc:2131
0xf8bad5 simplify_context::simplify_unary_operation(rtx_code, machine_mode,
rtx_def*, machine_mode)
../../gcc/gcc/simplify-rtx.cc:889
0xf8a591 simplify_context::simplify_gen_unary(rtx_code, machine_mode, rtx_def*,
machine_mode)
../../gcc/gcc/simplify-rtx.cc:360
0x9bd1b7 simplify_gen_unary(rtx_code, machine_mode, rtx_def*, machine_mode)
../../gcc/gcc/rtl.h:3520
0x1bd5677 simplify_comparison
../../gcc/gcc/combine.cc:13125
0x1bc2b2b simplify_set
../../gcc/gcc/combine.cc:6848
0x1bc1647 combine_simplify_rtx
../../gcc/gcc/combine.cc:6353
0x1bbf97f subst
../../gcc/gcc/combine.cc:5609
0x1bb864b try_combine
../../gcc/gcc/combine.cc:3302
0x1bb30fb combine_instructions
../../gcc/gcc/combine.cc:1264
0x1bd8d25 rest_of_handle_combine
../../gcc/gcc/combine.cc:15059
0x1bd8dd5 execute
../../gcc/gcc/combine.cc:15103
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.


Thanks,
Prathamesh

[Bug libstdc++/110862] format out of bands read on format string "{0:{0}"

[gcc at pauldreik dot se via Gcc-bugs]

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

--- Comment #2 from Paul Dreik  ---
(In reply to 康桓瑋 from comment #1)
> It does throw:
> 
> https://godbolt.org/z/5q3bb51YE

Sorry for being unclear. Yes, it throws but that is after the out of bounds
read has happened.