[Bug tree-optimization/82854] more missing simplifcations

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> /* 0 - (x & 0x8000) -> x & 0x8000 */
> LLVM does

Actually RTL has done this since at least GCC 4.1.0, most likely before.

[Bug tree-optimization/71034] abs(f) u>= 0. is always true

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
EVRP is able to handle this in GCC 13+ so closing as such:
Folding statement: x_3 = ABS_EXPR ;
Global Exported: x_3 = [frange] double [0.0 (0x0.0p+0), +Inf] +NAN
Not folded
Folding statement: _1 = x_3 u>= 0.0;
Queued stmt for removal.  Folds to: 1
Folding statement: _4 = (int) _1;
Queued stmt for removal.  Folds to: 1
Folding statement: return _4;
Folded into: return 1;

[Bug tree-optimization/109691] New: Takes until forwprop2 to remove !a sometimes

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

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

Bug ID: 109691
   Summary: Takes until forwprop2 to remove !a sometimes
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: internal-improvement, missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
int f(_Bool c, int a, int b)
{
_Bool d = c;
d = !d;
if (d != 0) return a;
return b;
}
```

It takes until forwprop2 now to remove all of the code before the conditional.
In GCC 4.9.0, we used to do it almost all the way in forwprop1; with just one
assignment added.

I noticed this while looking into PR 67628 but it is not exactly an issue there
so filing it seperately.

[Bug tree-optimization/80574] GCC fail to optimize nested ternary

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|8.0 |---

--- Comment #8 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #7)
> The original testcase in comment #0 is fixed in GCC 8, I don't know what
> caused the improvement though.

Well actually if you use the C++ front-end, it still fails.

for f2_signed, we start out as:
  _1 = MAX_EXPR ;
  if (_1 >= a1_6(D))
goto ; [INV]
  else
goto ; [INV]

   :
  if (a3_4(D) < a2_5(D))
goto ; [INV]
  else
goto ; [INV]

   :

   :
  # iftmp.5_2 = PHI 
  return iftmp.5_2;

phiopt1 transforms it to:
  _1 = MAX_EXPR ;
  if (_1 >= a1_6(D))
goto ; [INV]
  else
goto ; [INV]

   :
  _3 = MAX_EXPR ;

   :
  # iftmp.12_2 = PHI <_3(3), a1_6(D)(2)>

Which is perfect.
But then we don't exactly patch that _1 and _3 are the same though we do try to
simplify it at least on the trunk:
phiopt match-simplify trying:
_1 >= a1_6(D) ? _3 : a1_6(D)

phiopt match-simplify trying:
_1 < a1_6(D) ? a1_6(D) : _3

What happens afterwards is fre (or is it pre) figures out _1 and _3 are the
same and get:
  if (_1 >= a1_6(D))
goto ; [INV]
  else
goto ; [INV]

   :

   :
  # iftmp.12_2 = PHI <_1(3), a1_6(D)(2)>

Which then phiopt2 is able to simplify.
So if we iterate phiopt and fre we should able to handle all of these but that
is NOT a reasonable solution.
I have to think of a good way of solving these really.

[Bug tree-optimization/101226] Suboptimal codegen for >>/>>>

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Here is a C/C++ example:
typedef unsigned char ubyte;
void f1()
{
extern ubyte value;
unsigned int t = value;
t >>= 5;
value = t;
}

void f2()
{
extern ubyte value;
value = value >> 5;
}

[Bug tree-optimization/98581] unexpected reassociation for umin/umax ?

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Last reconfirmed|2021-01-07 00:00:00 |2023-5-1

[Bug tree-optimization/90883] Generated code is worse if returned struct is unnamed

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

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

--- Comment #34 from Andrew Pinski  ---
aarch64 was fixed fully with r11-4973-g54bbde550ec5 .

[Bug tree-optimization/49513] DOM inhibits if-conversion and vectorization

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||10.1.0, 11.1.0, 12.1.0,
   ||8.1.0, 9.1.0
  Known to fail||7.1.0

--- Comment #5 from Andrew Pinski  ---
Looks like this was fixed in GCC 8.

[Bug tree-optimization/79119] absolute value of a pointer difference can be assumed to be less than or equal to PTRDIFF_MAX

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

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

--- Comment #4 from Andrew Pinski  ---
Hmm:
  # RANGE [irange] long unsigned int [0,
2305843009213693951][16140901064495857664, +INF]
  iftmp.0_7 = (long unsigned intD.10) _19;
  if (iftmp.0_7 > 2305843009213693951)


So that is _19 < 0 If I read this correctly.
The only reason why it was not converted is because of the /4 that was before.
So we have a hole in the range.

[Bug tree-optimization/103281] [10/12/13/14 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)

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

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

--- Comment #8 from Andrew Pinski  ---
Hmm:
  # RANGE [irange] char [0, 2] NONZERO 0x3
  c_9 = (charD.7) b.4_5;
  _1 = c_9 <= 0;



Should _1 be replaced with c_9 == 0 which then can be simplified to b.4_5 == 0
That is PR 28794 I think.

And then after that we get:
b.4_5 == (unsigned int)(b.4_5 == 0)

Which should be optimized down to false though we don't either.
unsigned f(unsigned t)
{
unsigned a = t == 0;
return t == a;
}

The general CST cases (I hope I did these correctly):
a == (a == CST) ->
CST == 0 -> false
CST == 1 -> a == 1 | a == 0
others   -> a == 0

a != (a == CST) ->
CST == 0: false
CST == 1: a != 0 || a != 1
others  : a != 0

a != (a != CST) ->
CST == 0: a == 1 | a == 0
CST == 1: true
others  : a != 1

a == (a != CST) ->
CST == 0: a == 1 | a == 0
CST == 1: false
others  : a == 1

[Bug c++/109680] [13/14 Regression] is_convertible incorrectly true

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

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

--- Comment #5 from Marek Polacek  ---
(In reply to Jakub Jelinek from comment #4)
> template 
> U __declval (int);
> template 
> T __declval (long);
> template 
> auto declval () noexcept -> decltype (__declval  (0));
> using To = int () const;
> using From = int (*) ();
> To foo () { return declval  (); }
> From bar () { return declval  (); }
> static_assert (!__is_convertible (To, From), "");
> static_assert (!__is_convertible (From, To), "");
> should show that both assertions should succeed.  

Thanks.

> Dunno if in this case the
> reason why it isn't convertible is simply the fact that functions can't be
> declared to return function/method/array types or some other reason as well.

Yeah, I'm also not sure, so I think this should fix it:

--- a/gcc/cp/method.cc
+++ b/gcc/cp/method.cc
@@ -2245,6 +2245,8 @@ is_convertible_helper (tree from, tree to)
 {
   if (VOID_TYPE_P (from) && VOID_TYPE_P (to))
 return integer_one_node;
+  if (FUNC_OR_METHOD_TYPE_P (from) || FUNC_OR_METHOD_TYPE_P (to))
+return error_mark_node;
   cp_unevaluated u;
   tree expr = build_stub_object (from);
   deferring_access_check_sentinel acs (dk_no_deferred);


Since
static_assert (!__is_convertible (int[3], int[3]), "");
already passes, arrays are handled correctly I think.

[Bug tree-optimization/109689] [14 Regression] ICE at -O1 with "-ftree-vectorize": in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:645

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

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

--- Comment #1 from Andrew Pinski  ---
Maybe r14-301-gf2d6beb7a4ddf18dd or r14-145-g2f4e45101dd812a6f (or
r14-150-gf7b9258e0d4127c1f4 ).

[Bug target/109690] bad SLP vectorization on zen

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

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

--- Comment #3 from Andrew Pinski  ---
So in the case of without -march, we get:

first:
/app/example.cpp:14:24: note: Cost model analysis for part in loop 0:
  Vector cost: 28
  Scalar cost: 24



so we reject that and then we try it again and this time for V8QI and then it
works.

With -march we get:

/app/example.cpp:14:24: note: Cost model analysis for part in loop 0:
  Vector cost: 32
  Scalar cost: 32

Which then we accept and does not retry it ...

[Bug sanitizer/83780] False positive alignment error with -fsanitize=undefined with virtual base

[ed at catmur dot uk via Gcc-bugs]

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

--- Comment #4 from Ed Catmur  ---
Clang has fixed this in
https://github.com/llvm/llvm-project/commit/4ddf140c00408ecee9d20f4470e69e0f696d8f8a
(12.0.0-rc1).

[Bug target/109690] bad SLP vectorization on zen

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

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

--- Comment #2 from Andrew Pinski  ---
Even more interesting is:
  for (int i = 0; i < 3; i++)
  a[i] = ((unsigned)a[i]) << 1;

Produces different code .

[Bug target/109690] bad SLP vectorization on zen

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

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

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

Without -march=znver1, we get:
  vect__10.6_9 = MEM  [(int *)];
  vect_patt_13.7_8 = VIEW_CONVERT_EXPR(vect__10.6_9);
  vect_patt_19.8_1 = vect_patt_13.7_8 << 1;
  vect_patt_25.9_2 = VIEW_CONVERT_EXPR(vect_patt_19.8_1);
  MEM  [(int *)] = vect_patt_25.9_2;

Which looks reasonable. But with -march=znver1 we get:

  _10 = a[0];
  _11 = _10 * 2;
  _16 = a[1];
  _17 = _16 * 2;
  _13 = {_11, _17};
  MEM  [(int *)] = _13;

So this is definitely a cost model issue.

[Bug c++/109678] [13/14 Regression] exponential time behavior on std::variant

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug tree-optimization/109690] New: bad SLP vectorization on zen

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

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

Bug ID: 109690
   Summary: bad SLP vectorization on zen
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

model name  : AMD Ryzen 7 5800X 8-Core Processor
reproduces on my znver1 laptop too.

h@ryzen3:~/gcc-kub/build/gcc> cat tt.c
int a[100];

[[gnu::noipa]]
void loop()
{
  for (int i = 0; i < 3; i++)
  a[i]+=a[i];
}
int
main()
{
for (int j = 0; j < 10; j++)
  loop ();
return 0;
}


jh@ryzen3:~/gcc-kub/build/gcc> ./xgcc -B ./ -O2 -march=native tt.c ; perf stat
./a.out

 Performance counter stats for './a.out':

   2683.95 msec task-clock:u #1.000 CPUs
utilized 
 0  context-switches:u   #0.000 /sec
 0  cpu-migrations:u #0.000 /sec
52  page-faults:u#   19.374 /sec
   13001141361  cycles:u #4.844 GHz
(83.31%)
691180  stalled-cycles-frontend:u#0.01% frontend
cycles idle(83.31%)
101980  stalled-cycles-backend:u #0.00% backend
cycles idle (83.31%)
   1228665  instructions:u   #1.00  insn per
cycle
  #0.00  stalled cycles per
insn (83.31%)
313809  branches:u   #1.118 G/sec  
(83.41%)
  1525  branch-misses:u  #0.00% of all
branches (83.36%)

   2.684376360 seconds time elapsed

   2.684369000 seconds user
   0.0 seconds sys


jh@ryzen3:~/gcc-kub/build/gcc> ./xgcc -B ./ -O2 -march=native tt.c
-fno-tree-vectorize ; perf stat ./a.out

 Performance counter stats for './a.out':

   1238.92 msec task-clock:u #1.000 CPUs
utilized 
 0  context-switches:u   #0.000 /sec
 0  cpu-migrations:u #0.000 /sec
52  page-faults:u#   41.972 /sec
6000338140  cycles:u #4.843 GHz
(83.21%)
314660  stalled-cycles-frontend:u#0.01% frontend
cycles idle(83.21%)
 0  stalled-cycles-backend:u #0.00% backend
cycles idle (83.23%)
7999796562  instructions:u   #1.33  insn per
cycle
  #0.00  stalled cycles per
insn (83.53%)
2999887795  branches:u   #2.421 G/sec  
(83.53%)
   698  branch-misses:u  #0.00% of all
branches (83.28%)

   1.239116606 seconds time elapsed

   1.239121000 seconds user
   0.0 seconds sys

[Bug tree-optimization/109689] [14 Regression] ICE at -O1 with "-ftree-vectorize": in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:645

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|ICE at -O1 with |[14 Regression] ICE at -O1
   |"-ftree-vectorize": in  |with "-ftree-vectorize": in
   |check_loop_closed_ssa_def,  |check_loop_closed_ssa_def,
   |at  |at
   |tree-ssa-loop-manip.cc:645  |tree-ssa-loop-manip.cc:645
   Target Milestone|--- |14.0
   Keywords||ice-on-valid-code,
   ||needs-bisection

[Bug c++/109666] [13/14 Regression] Segmentation fault with std::array using gcc 13 since r13-6788

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

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

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

https://gcc.gnu.org/g:07c52d1eec9671af92b7ce977b469f13a87887ad

commit r14-386-g07c52d1eec9671af92b7ce977b469f13a87887ad
Author: Jason Merrill 
Date:   Mon May 1 10:57:20 2023 -0400

c++: array DMI and member fn [PR109666]

Here it turns out I also needed to adjust cfun when stepping out of the
member function to instantiate the DMI.  But instead of adding that tweak,
let's unify with instantiate_body and just push_to_top_level instead of
trying to do the minimum subset of it.  There was no measurable change in
compile time on stdc++.h.

This should also resolve 109506 without yet another tweak.

PR c++/109666

gcc/cp/ChangeLog:

* name-lookup.cc (maybe_push_to_top_level)
(maybe_pop_from_top_level): Split out...
* pt.cc (instantiate_body): ...from here.
* init.cc (maybe_instantiate_nsdmi_init): Use them.
* name-lookup.h: Declare them..

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/nsdmi-array2.C: New test.

[Bug tree-optimization/109689] New: ICE at -O1 with "-ftree-vectorize": in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:645

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

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

Bug ID: 109689
   Summary: ICE at -O1 with "-ftree-vectorize": in
check_loop_closed_ssa_def, at
tree-ssa-loop-manip.cc:645
   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: ---

This appears to be a very recent regression.

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

[629] % 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/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230501 (experimental) (GCC)
[630] %
[630] % gcctk -O1 -ftree-vectorize small.c
during GIMPLE pass: ch_vect
small.c: In function ‘main’:
small.c:2:5: internal compiler error: in check_loop_closed_ssa_def, at
tree-ssa-loop-manip.cc:645
2 | int main() {
  | ^~~~
0x822c59 check_loop_closed_ssa_def
../../gcc-trunk/gcc/tree-ssa-loop-manip.cc:645
0x11cfc34 check_loop_closed_ssa_bb
../../gcc-trunk/gcc/tree-ssa-loop-manip.cc:659
0x11d18be verify_loop_closed_ssa(bool, loop*)
../../gcc-trunk/gcc/tree-ssa-loop-manip.cc:695
0x11d18be verify_loop_closed_ssa(bool, loop*)
../../gcc-trunk/gcc/tree-ssa-loop-manip.cc:679
0xf243f9 execute_function_todo
../../gcc-trunk/gcc/passes.cc:2116
0xf24bfe execute_todo
../../gcc-trunk/gcc/passes.cc:2152
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.
[631] %
[631] % cat small.c
int a, b, c, d, e;
int main() {
  char f;
  while (a) {
int g, h = 3;
if (b)
i:
  if (d)
goto j;
  k:
if (a) {
j:
  if (!g)
goto k;
  if (e) {
while (e)
  e = f;
h = 0;
goto i;
  }
  if (!h)
for (; g < 1; g++)
  ;
  g = ~((~c & h & c) ^ ~g);
  if (!g)
for (; a < 1; a++)
  f++;
}
  }
  return 0;
}

[Bug c++/109688] SPDLOG build fails with C++20 and -DSPDLOG_USE_STD_FORMAT=1

[rs2740 at gmail dot com via Gcc-bugs]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #6 from TC  ---
https://cplusplus.github.io/LWG/issue3636 clarifies that formatter::format
must be const, which is not the case in that example.

[Bug tree-optimization/101339] (bit_and (negate (convert thurth_value@1)) integer_onep) is not optimized to just @1

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
comment #0 was fixed with r13-793-g8fb94fc6097c .

comment #1 is still not fixed and I am not going to work on that one.

[Bug target/109456] `-ffixed` is ignored for `a` registers on RISC-V.

[gccriscvuser at proton dot me via Gcc-bugs]

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

--- Comment #7 from gccriscvuser at proton dot me ---
To be clear, when I said "generator is emitting correct code", I mean with
respect to the ABI specification.

However, this is an actual bug, not a request for enhancement, because the
emitted code is incorrect with respect to the command-line option.  The
programmer has a reasonable expectation that, if no diagnostic is issued, the
`-ffixed` command-line option is respected.

Thanks

[Bug c++/109688] SPDLOG build fails with C++20 and -DSPDLOG_USE_STD_FORMAT=1

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Jamaika from comment #4)
> https://github.com/gabime/spdlog/blob/v1.x/example/example.cpp
> ```
> for %%f in ("example.cpp") do g++.exe -v -std=gnu++20 -march=x86-64-v2
> -ftree-vectorize -g0 -O3 -fPIC -mavx -mxsave -mpclmul -maes
> -DSPDLOG_USE_STD_FORMAT=1 -c %%f -o %%~nf.o
> ```

That will not work as example.cpp depends on the spdlog headers.

PLEASE again have the exact directions on how to test this.
Also just like your previous bugs, this is lacking that. Maybe also report the
failure to the developer of spdlog since it is not obvious if it is a
libstdc++, C++ front-end bug or just a problem with spdlog.

Note saying spdlog works with MSVC does not mean it is still not buggy code.

[Bug c++/109688] SPDLOG build fails with C++20 and -DSPDLOG_USE_STD_FORMAT=1

[lukaszcz18 at wp dot pl via Gcc-bugs]

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

--- Comment #4 from Jamaika  ---
https://github.com/gabime/spdlog/blob/v1.x/example/example.cpp
```
for %%f in ("example.cpp") do g++.exe -v -std=gnu++20 -march=x86-64-v2
-ftree-vectorize -g0 -O3 -fPIC -mavx -mxsave -mpclmul -maes
-DSPDLOG_USE_STD_FORMAT=1 -c %%f -o %%~nf.o
```

[Bug c++/109688] SPDLOG build fails with C++20 and -DSPDLOG_USE_STD_FORMAT=1

[lukaszcz18 at wp dot pl via Gcc-bugs]

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

--- Comment #3 from Jamaika  ---
SPDLOG claims that MSVC compiles.

[Bug c++/109688] SPDLOG build fails with C++20 and -DSPDLOG_USE_STD_FORMAT=1

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2023-05-01

--- Comment #2 from Andrew Pinski  ---
Also how do you reproduce this issue? You just provided the error message.

[Bug c++/109688] SPDLOG build fails with C++20 and -DSPDLOG_USE_STD_FORMAT=1

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Build fail with C++20 and   |SPDLOG build fails with
   |-DSPDLOG_USE_STD_FORMAT=1   |C++20 and
   ||-DSPDLOG_USE_STD_FORMAT=1

--- Comment #1 from Andrew Pinski  ---
Are you sure this is not a bug in SPDLOG ?

[Bug c++/109688] New: Build fail with C++20 and -DSPDLOG_USE_STD_FORMAT=1

[lukaszcz18 at wp dot pl via Gcc-bugs]

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

Bug ID: 109688
   Summary: Build fail with C++20 and -DSPDLOG_USE_STD_FORMAT=1
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lukaszcz18 at wp dot pl
  Target Milestone: ---

```
Using built-in specs.
COLLECT_GCC=g++.exe
Target: x86_64-w64-mingw32
Configured with: /home/ma/m/source/gcc-g/configure --host=x86_64-w64-mingw32
--target=x86_64-w64-mingw32 --disable-nls --enable-languages=c,c++,objc,obj-c++
--with-gmp=/home/ma/m/build/for_target --with-mpfr=/home/ma/m/build/for_target
--with-mpc=/home/ma/m/build/for_target --with-isl=/home/ma/m/build/for_target
--enable-twoprocess --disable-libstdcxx-pch --disable-win32-registry
--disable-shared --enable-fully-dynamic-string --enable-libssp
--prefix=/home/ma/m/target --with-sysroot=/home/ma/m/target
Thread model: win32
Supported LTO compression algorithms: zlib
gcc version 13.0.1 20230421 (prerelease) (GCC)
COLLECT_GCC_OPTIONS='-v' '-std=gnu++20' '-march=x86-64-v2' '-ftree-vectorize'
'-g0' '-O3' '-fPIC' '-mavx' '-mxsave' '-mpclmul' '-maes' '-D'
'SPDLOG_USE_STD_FORMAT=1' '-c' '-o' 'example.o'
 C:/gcc1301/bin/../libexec/gcc/x86_64-w64-mingw32/13.0.1/cc1plus.exe -quiet -v
-iprefix C:/gcc1301/bin/../lib/gcc/x86_64-w64-mingw32/13.0.1/ -U_REENTRANT -D
SPDLOG_USE_STD_FORMAT=1 example.cpp -quiet -dumpbase example.cpp -dumpbase-ext
.cpp -march=x86-64-v2 -mavx -mxsave -mpclmul -maes -g0 -O3 -std=gnu++20
-version -ftree-vectorize -fPIC -o
C:\Users\KOMPUT~1\AppData\Local\Temp\ccxiMnxa.s
GNU C++20 (GCC) version 13.0.1 20230421 (prerelease) (x86_64-w64-mingw32)
compiled by GNU C version 13.0.1 20230421 (prerelease), GMP version
6.2.1, MPFR version 4.2.0-p4, MPC version 1.3.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory
"C:/gcc1301/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.1/../../../../include/c++/13.0.1"
ignoring duplicate directory
"C:/gcc1301/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.1/../../../../include/c++/13.0.1/x86_64-w64-mingw32"
ignoring duplicate directory
"C:/gcc1301/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.1/../../../../include/c++/13.0.1/backward"
ignoring duplicate directory
"C:/gcc1301/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.1/include"
ignoring nonexistent directory
"/home/ma/m/target/home/ma/m/target/lib/gcc/x86_64-w64-mingw32/13.0.1/../../../../include"
ignoring duplicate directory
"C:/gcc1301/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.1/include-fixed"
ignoring duplicate directory
"C:/gcc1301/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.1/../../../../x86_64-w64-mingw32/include"
ignoring nonexistent directory "/home/ma/m/target/mingw/include"
#include "..." search starts here:
#include <...> search starts here:

C:/gcc1301/bin/../lib/gcc/x86_64-w64-mingw32/13.0.1/../../../../include/c++/13.0.1

C:/gcc1301/bin/../lib/gcc/x86_64-w64-mingw32/13.0.1/../../../../include/c++/13.0.1/x86_64-w64-mingw32

C:/gcc1301/bin/../lib/gcc/x86_64-w64-mingw32/13.0.1/../../../../include/c++/13.0.1/backward
 C:/gcc1301/bin/../lib/gcc/x86_64-w64-mingw32/13.0.1/include
 C:/gcc1301/bin/../lib/gcc/x86_64-w64-mingw32/13.0.1/include-fixed

C:/gcc1301/bin/../lib/gcc/x86_64-w64-mingw32/13.0.1/../../../../x86_64-w64-mingw32/include
End of search list.
Compiler executable checksum: c5bc1656e1b332d798c0577f7a3d2ab8
In file included from C:/gcc1301/include/c++/13.0.1/bits/chrono_io.h:39,
 from C:/gcc1301/include/c++/13.0.1/chrono:3330,
 from example.cpp:8:
C:/gcc1301/include/c++/13.0.1/format: In instantiation of 'static
std::__format::_Arg_store<_Context, _Args>::_Element_t
std::__format::_Arg_store<_Context, _Args>::_S_make_elt(_Tp&) [with _Tp =
spdlog::details::dump_info<__gnu_cxx::__normal_iterator > >; _Context =
std::basic_format_context, char>; _Args =
{std::basic_format_arg,
char> >::handle}; _Element_t =
std::__format::_Arg_store,
char>,
std::basic_format_arg,
char> >::handle>::_Element_t]':
C:/gcc1301/include/c++/13.0.1/format:3252:23:   required from
'std::__format::_Arg_store<_Context, _Args>::_Arg_store(_Tp& ...) [with _Tp =
{spdlog::details::dump_info<__gnu_cxx::__normal_iterator > > >}; _Context =
std::basic_format_context, char>; _Args =
{std::basic_format_arg,
char> >::handle}]'
C:/gcc1301/include/c++/13.0.1/format:3301:14:   required from 'auto
std::make_format_args(_Args&& ...) [with _Context =
basic_format_context<__format::_Sink_iter, char>; _Args =
{spdlog::details::dump_info<__gnu_cxx::__normal_iterator > > >}]'
C:/gcc1301/x86_64-w64-mingw32/include/spdlog/logger.h:372:88:   required from
'void spdlog::logger::log_(spdlog::source_loc, spdlog::level::level_enum,
spdlog::string_view_t, Args&& ...) [with Args =
{spdlog::details::dump_info<__gnu_cxx::__normal_iterator > > >}; 

[Bug target/106532] riscv fails to build enabling ZBA/ZBB/ZBC/ZBS by default for 32bit

[david_harris at hmc dot edu via Gcc-bugs]

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

--- Comment #12 from David Harris  ---
Thank you for the speedy discovery and resolution.

[Bug target/106532] riscv fails to build enabling ZBA/ZBB/ZBC/ZBS by default for 32bit

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||david_harris at hmc dot edu

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

[Bug target/109687] riscv64-unknown-elf-gcc internal error on embench when using bit manipulation extensions

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|riscv64-elf |riscv32-elf
 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Andrew Pinski  ---
Already fixed for GCC 13.1.0

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

[Bug c/109687] riscv64-unknown-elf-gcc internal error on embench when using bit manipulation extensions

[david_harris at hmc dot edu via Gcc-bugs]

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

--- Comment #1 from David Harris  ---
harris@vlsi:~/cvw/benchmarks/embench$ riscv64-unknown-elf-gcc -v
Using built-in specs.
COLLECT_GCC=riscv64-unknown-elf-gcc
COLLECT_LTO_WRAPPER=/opt/riscv/libexec/gcc/riscv64-unknown-elf/12.2.0/lto-wrapper
Target: riscv64-unknown-elf
Configured with: /opt/riscv/riscv-gnu-toolchain/gcc/configure
--target=riscv64-unknown-elf --prefix=/opt/riscv --disable-shared
--disable-threads --enable-languages=c,c++ --with-pkgversion=
--with-system-zlib --enable-tls --with-newlib
--with-sysroot=/opt/riscv/riscv64-unknown-elf
--with-native-system-header-dir=/include --disable-libmudflap --disable-libssp
--disable-libquadmath --disable-libgomp --disable-nls
--disable-tm-clone-registry --src=/opt/riscv/riscv-gnu-toolchain/gcc
--enable-multilib
--with-multilib-generator='rv32e-ilp32e--;rv32i-ilp32--;rv32im-ilp32--;rv32iac-ilp32--;rv32imac-ilp32--;rv32imafc-ilp32f--;rv32imafdc-ilp32d--;rv64i-lp64--;rv64ic-lp64--;rv64iac-lp64--;rv64imac-lp64--;rv64imafdc-lp64d--;rv64im-lp64--;'
--with-abi=lp64d --with-arch=rv64imafdc --with-tune=rocket --with-isa-spec=2.2
'CFLAGS_FOR_TARGET=-Os   -mcmodel=medlow' 'CXXFLAGS_FOR_TARGET=-Os  
-mcmodel=medlow'
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 12.2.0 ()

[Bug c/109687] New: riscv64-unknown-elf-gcc internal error on embench when using bit manipulation extensions

[david_harris at hmc dot edu via Gcc-bugs]

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

Bug ID: 109687
   Summary: riscv64-unknown-elf-gcc internal error on embench when
using bit manipulation extensions
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david_harris at hmc dot edu
  Target Milestone: ---

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

This bug occurs when march=rv32imac_zba_zbb_zbs
but not when march=rv32imac

riscv64-unknown-elf-gcc -c -fdata-sections -ffunction-sections
-march=rv32imac_zba_zbb_zbs -mabi=ilp32 -Os -msave-restore
-I/home/harris/cvw/addins/embench-iot/support
-I/home/harris/cvw/addins/embench-iot/config/riscv32/boards/rv32wallyverilog
-I/home/harris/cvw/addins/embench-iot/config/riscv32/chips/generic
-I/home/harris/cvw/addins/embench-iot/config/riscv32 -DCPU_MHZ=1
-DWARMUP_HEAT=1 -o libminver.o
/home/harris/cvw/addins/embench-iot/src/minver/libminver.c

/home/harris/cvw/addins/embench-iot/src/minver/libminver.c: In function
'minver.part.0':
/home/harris/cvw/addins/embench-iot/src/minver/libminver.c:211:1: error:
unrecognizable insn:
  211 | }
  | ^
(insn 435 0 0 (set (reg:SI 275)
(const_int 2048 [0x800])) -1
 (expr_list:REG_EQUAL (const_int 2048 [0x800])
(nil)))
during RTL pass: reload
/home/harris/cvw/addins/embench-iot/src/minver/libminver.c:211:1: internal
compiler error: in extract_insn, at recog.cc:2791
0x619df0 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/opt/riscv/riscv-gnu-toolchain/gcc/gcc/rtl-error.cc:108
0x619e12 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/opt/riscv/riscv-gnu-toolchain/gcc/gcc/rtl-error.cc:116
0x6192dc extract_insn(rtx_insn*)
/opt/riscv/riscv-gnu-toolchain/gcc/gcc/recog.cc:2791
0x9fe384 ira_remove_insn_scratches(rtx_insn*, bool, _IO_FILE*, rtx_def*
(*)(rtx_def*))
/opt/riscv/riscv-gnu-toolchain/gcc/gcc/ira.cc:5356
0xa39509 remove_insn_scratches
/opt/riscv/riscv-gnu-toolchain/gcc/gcc/lra.cc:2091
0xa3ae47 lra_emit_move(rtx_def*, rtx_def*)
/opt/riscv/riscv-gnu-toolchain/gcc/gcc/lra.cc:512
0xa4e49d curr_insn_transform
/opt/riscv/riscv-gnu-toolchain/gcc/gcc/lra-constraints.cc:4608
0xa4fc54 lra_constraints(bool)
/opt/riscv/riscv-gnu-toolchain/gcc/gcc/lra-constraints.cc:5203
0xa3d8d2 lra(_IO_FILE*)
/opt/riscv/riscv-gnu-toolchain/gcc/gcc/lra.cc:2375
0x9f86d9 do_reload
/opt/riscv/riscv-gnu-toolchain/gcc/gcc/ira.cc:5940
0x9f86d9 execute
/opt/riscv/riscv-gnu-toolchain/gcc/gcc/ira.cc:6126
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/109456] `-ffixed` is ignored for `a` registers on RISC-V.

[gccriscvuser at proton dot me via Gcc-bugs]

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

--- Comment #6 from gccriscvuser at proton dot me ---
I'm willing to agree that the generator is emitting correct code, but in that
case, there should be an error- or fatal-level diagnostic indicating that
`-ffixed` is not supported for `a4` (solution 3 above).

It would be even better if the diagnostic were issued only if there is at least
one function that takes so many parameters that `a4` is needed.  The diagnostic
message could point at the function(s) themselves to assist the programmer in
correcting the issue.  If none of the functions use `a4` as a parameter, then
no diagnostic is needed.

[Bug target/59666] IBM long double arithmetic results invalid in non-default rounding modes

[vital.had at gmail dot com via Gcc-bugs]

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

Sergey Fedorov  changed:

   What|Removed |Added

 CC||vital.had at gmail dot com

--- Comment #8 from Sergey Fedorov  ---
(In reply to Vincent Lefèvre from comment #1)
> (In reply to Joseph S. Myers from comment #0)
> It seems to be like that "by design" (though this is not satisfactory) and
> part of the ppc64 ABI for instance:
> 
> http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#PREC
> 
> "The software support is restricted to round-to-nearest mode. Programs that
> use extended precision must ensure that this rounding mode is in effect when
> extended-precision calculations are performed."

Also true for AIX:
https://www.ibm.com/docs/sr/xcafbg/9.0.0?topic=SS3KZ4_9.0.0/com.ibm.xlf111.bg.doc/xlfopg/fp-overview.html

Does anyone know whether this is also true for Darwin on PowerPC though?

[Bug c++/109680] [13/14 Regression] is_convertible incorrectly true

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

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

--- Comment #4 from Jakub Jelinek  ---
template 
U __declval (int);
template 
T __declval (long);
template 
auto declval () noexcept -> decltype (__declval  (0));
using To = int () const;
using From = int (*) ();
To foo () { return declval  (); }
>From bar () { return declval  (); }
static_assert (!__is_convertible (To, From), "");
static_assert (!__is_convertible (From, To), "");
should show that both assertions should succeed.  Dunno if in this case the
reason why it isn't convertible is simply the fact that functions can't be
declared to return function/method/array types or some other reason as well.

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

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #15 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2023-May/059246.html

[Bug c++/109680] [13/14 Regression] is_convertible incorrectly true

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug middle-end/109686] Errorneous infinite loop detection (-Winfinite-recursion)

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

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

--- Comment #3 from Arsen Arsenović  ---
no problem, thank you for reporting

[Bug middle-end/107334] Incorrect "infinite recursion detected" warning if base case aborts

[madhur4127 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Madhur Chauhan  ---
I feel changing the warning text will still cause troubles for people using
-Werror. This forces to use ignore pragmas or disable this warning completely,
none of them are ideal.

Maybe disable warning in this case?

[Bug middle-end/109686] Errorneous infinite loop detection (-Winfinite-recursion)

[madhur4127 at gmail dot com via Gcc-bugs]

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

Madhur Chauhan  changed:

   What|Removed |Added

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

--- Comment #2 from Madhur Chauhan  ---
Yes it's a dupe. Sorry.

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

[Bug middle-end/107334] Incorrect "infinite recursion detected" warning if base case aborts

[madhur4127 at gmail dot com via Gcc-bugs]

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

Madhur Chauhan  changed:

   What|Removed |Added

 CC||madhur4127 at gmail dot com

--- Comment #2 from Madhur Chauhan  ---
*** Bug 109686 has been marked as a duplicate of this bug. ***

[Bug middle-end/109686] Errorneous infinite loop detection (-Winfinite-recursion)

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

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

Arsen Arsenović  changed:

   What|Removed |Added

 CC||arsen at gcc dot gnu.org

--- Comment #1 from Arsen Arsenović  ---
possibly dupe of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107334 ?

[Bug c++/109666] [13/14 Regression] Segmentation fault with std::array using gcc 13 since r13-6788

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/109686] New: Errorneous infinite loop detection (-Winfinite-recursion)

[madhur4127 at gmail dot com via Gcc-bugs]

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

Bug ID: 109686
   Summary: Errorneous infinite loop detection
(-Winfinite-recursion)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: madhur4127 at gmail dot com
  Target Milestone: ---

This code: 

```
#define myassert(x) \
do { \
if (! (x) ) \
abort(); \
}  while (false)

static void recursive(int n) {
myassert(n > 0);
recursive(n - 1);
printf("%d\n", n);
}
```

should not result in infinite recursion. Assert fails for all non-positive
integers. For positive numbers it counts down to 0 and then fails.

This affect GCC12, GCC13 and trunk: https://compiler-explorer.com/z/57qrnzdEK

[Bug libgcc/109685] New: Memory leak in `__deregister_frame`

[markus.boeck02 at gmail dot com via Gcc-bugs]

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

Bug ID: 109685
   Summary: Memory leak in `__deregister_frame`
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: markus.boeck02 at gmail dot com
  Target Milestone: ---

Sorry that I can't ship a proper reproducer, since I believe this essentially
requires a JIT or extracts of binary sections I am not yet familiar with. If I
do figure out a viable minimal reproducer I'll post them later.

With the recent release of GCC 13 landing on my fedora machine I have suddenly
started getting memory leaks reports by the leak sanitizer within a JIT
application of mine using `__register_frame` and `__deregister_frame`, pointing
to memory allocated by libgcc. I have then gone through debugging sessions with
GDB and found following oddities which I believe should be the causes of the
leak:

First of all, the memory allocation being leaked happens in `start_fde_sort`
https://github.com/gcc-mirror/gcc/blob/12de8da8961d294904d6af90b9cc27a5ba1ccfd0/libgcc/unwind-dw2-fde.c#L507
```
if ((accu->linear = malloc (size)))
{
  accu->linear->count = 0;
  if ((accu->aux = malloc (size)))
accu->aux->count = 0;
  return 1;
}
```

Specifically the assignment to `accu->linear`. `accu->aux` is only temporarily
working memory that gets properly freed later. 
`accu->linear` instead gets put into an `object` that is inserted into a global
btree
(pointer is assigned to `u.sort`
https://github.com/gcc-mirror/gcc/blob/12de8da8961d294904d6af90b9cc27a5ba1ccfd0/libgcc/unwind-dw2-fde.c#L918)

The above call chains happens the first time unwinding happens since objects
are lazily initialized.

Later during JIT shutdown, `__deregsiter_frame` is called to erase all the
unwind information that has been produced.

This leads us to following code:
```
#ifdef ATOMIC_FDE_FAST_PATH
  ...
  uintptr_type range[2];
  get_pc_range (, range);

  // And remove
  ob = btree_remove (_frames, range[0]);
#else
  ...
#endif

  gcc_assert (in_shutdown || ob);
  return (void *) ob;
```
https://github.com/gcc-mirror/gcc/blob/12de8da8961d294904d6af90b9cc27a5ba1ccfd0/libgcc/unwind-dw2-fde.c#L242

with the caller calling `free` on the returned `ob`. 
Problem is that the `ob` may still have the pointer previously set by
`init_object` within its `u.sort` field. No attempt to free it is done within
the `ATOMIC_FDE_FAST_PATH` region however (something that does happen in the
#else region, which is seemingly not the default or maybe not enabled by the
distribution).

This therefore leads to the memory pointed to by `ob->u.sort` to become
unreachable and leak. 
The `ATOMIC_FDE_FAST_PATH` fast path was only added after the GCC 12 release
which would also explain why the LSAN only caught the leak after the GCC 13
release

[Bug tree-optimization/105723] [12 Regression] Optimization false positive warning (-Wstringop-overflow)

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

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

--- Comment #6 from Sam James  ---
(In reply to Andrew Pinski from comment #5)
> Dup of bug 107852 then.
> 
> *** This bug has been marked as a duplicate of bug 107852 ***

.. would've helped if i'd checked the bug referenced, ha. thank you!

[Bug fortran/109684] New: compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)

[wangmianzhi1 at linuxmail dot org via Gcc-bugs]

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

Bug ID: 109684
   Summary: compiling failure: complaining about a final
subroutine of a type being not PURE (while it is
indeed PURE)
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wangmianzhi1 at linuxmail dot org
  Target Milestone: ---

Created attachment 54964
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54964=edit
build with cmake

This issue emerges after upgrading to Fedora 38 (gcc version 13.1.1 20230426)
from Fedora 37 (gcc 12.x series). There was no issue in Fedora 37.

The issue takes place when:
mkdir build; cd build; cmake ..; make

GCC would popup an error message like this:
/home/mianzhi/Desktop/final_subroutine_not_pure/src/test/basicFEM1.f90:3:0:

3 | function basicFEM1() result(ierr)
  | 
Error: Contained procedure ‘__final_modotgrid_Otgrid’ at (1) of a PURE
procedure must also be PURE

The f90 file that actually contains the otGrid type with its final procedure
compiles fine. The basicFEM1.f90 uses module modFileIO, which has an interface
that involves type otGrid.

The attached is a stripped-down version of the code. I've tried to further
simplify the code but removing seemingly irrelevant things could prevent the
error from happening.

Thank you very much for your help.

Best regards,
Mianzhi

[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

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

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

Bug 105723 Summary: [12 Regression] Optimization false positive warning 
(-Wstringop-overflow)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105723

   What|Removed |Added

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

[Bug libstdc++/107852] [12 Regression] Spurious warnings stringop-overflow and array-bounds copying data as bytes into vector

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||jeffrey.reynolds@ticketmast
   ||er.com

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

[Bug tree-optimization/105723] [12 Regression] Optimization false positive warning (-Wstringop-overflow)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Dup of bug 107852 then.

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

[Bug debug/109676] [13/14 regression] ICE in simplify_subreg, at simplify-rtx.cc:7426 when building firefox with -O2 -march=alderlake -g since r13-3378-gf6c168f8c06047

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

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

--- Comment #13 from Jakub Jelinek  ---
Created attachment 54963
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54963=edit
gcc14-pr109676.patch

Untested fix.

[Bug c++/109677] [11/12/13/14 Regression] Access control bypass for function template default argument brace initialization of private default constructor

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

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

Patrick Palka  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||jason at gcc dot gnu.org

--- Comment #2 from Patrick Palka  ---
Started with r11-1615-g6b161257f9f8c7

[Bug analyzer/109437] -Wanalyzer-out-of-bounds is emitted at most once per frame.

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

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

Benjamin Priour  changed:

   What|Removed |Added

 CC||vultkayn at gcc dot gnu.org

--- Comment #1 from Benjamin Priour  ---
(In reply to Benjamin Priour from comment #0)
> OOB refers to Out-Of-Bounds.
> 
> Curiously, it seems that if a frame was a cause for a OOB (either by
> containing the spurious code or by being a caller to such code), it will
> only emit one set of warning, rather than at each unique compromising
> statements.
> 
> 
> int consecutive_oob_in_frame ()
> {
> int arr[] = {1,2,3,4,5,6,7};
> int y1 = arr[9]; // only  this one is diagnosed
> int y2 = arr[10]; // no OOB warning emitted here ...
> int y3 = arr[50]; // ... nor here.
> return (y1+y2+y3);
> }
> 
> int main () {
> consecutive_oob_in_frame (); // OOB warning emitted
> int x [] = {1,2};
> x[5]; /* silent, probably because another set of OOB warnings
> has already been issued with this frame being the source */
> return 0;
> }
> 
> 
> As per David suggestion, it might be worth to implement
> pending_diagnostic::supercedes_p vfunc for the OOB checker.

Actually the cause seems to be related to
[https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109439]. Indeed, the further
warning are not emitted only after an OOB read. Consider:

int arr[] = {1,2,3,4,5,6,7};
arr[9] = 7; // 1 warning OOB
arr[15] = 12; // 1 warning OOB
int y = arr[12]; // 2 Warnings as in PR109439, terminate path
arr[11]; // No warnings

The reason is because of the poisoned_value diagnostic that is implementing the
diagnostic_path::terminate_path method

[Bug c++/109683] [13/14 Regression] False cyclic dependency error reported for constraint

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

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

Patrick Palka  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=105797
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
   Last reconfirmed||2023-05-01
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Keywords||rejects-valid
   Target Milestone|--- |13.2
 CC||ppalka at gcc dot gnu.org

--- Comment #2 from Patrick Palka  ---
Thanks for the bug report.  Started with r13-980-gdf4f95dbd4764f which made
function parameters used in a constraint no longer induce a dependency on all
contextual template parameters.

So another workaround would be to make the constructor's constraints explicitly
depend on the second template parameter of the class:

template 
struct VariantConstructors {
  VariantConstructors(T&& t)
requires(requires { T(t); typename U; });
};

...

[Bug c++/109683] [13/14 Regression] False cyclic dependency error reported for constraint

[ali.mpfard at gmail dot com via Gcc-bugs]

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

Ali Mohammad Pur Fard  changed:

   What|Removed |Added

 CC||ali.mpfard at gmail dot com

--- Comment #1 from Ali Mohammad Pur Fard  ---
As a note, using a type alias for `T` in the constraint seems to work around
the issue:
```
template 
struct VariantConstructors {
  using U = T;
  VariantConstructors(T&& t)
requires(requires { U(t); });
};

// Everything below is the same as the repro case

template 
struct InheritFromEntries : Ts... {};

template 
struct InheritFromPack: InheritFromEntries... {
  using InheritFromEntries::InheritFromEntries...;
};

template 
struct Variant : InheritFromPack>...>
{};

template 
class Outer;
struct Inner {
Inner(Outer);
};
template
class Outer {
Variant value_;
};

struct Empty {};
void fn(Outer x) {}
```

(https://godbolt.org/z/1GTrjcvG6)

[Bug debug/109676] [13/14 regression] ICE in simplify_subreg, at simplify-rtx.cc:7426 when building firefox with -O2 -march=alderlake -g since r13-3378-gf6c168f8c06047

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

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

--- Comment #12 from Jakub Jelinek  ---
The mode is changed in:
1637case REG:
1638  PUT_MODE (src, V1TImode);
1639  /* Call fix_debug_reg_uses only if SRC is never defined.  */
1640  if (!DF_REG_DEF_CHAIN (REGNO (src)))
1641fix_debug_reg_uses (src);
but because DF_REG_DEF_CHAIN (REGNO (src)) - it contains the
(insn 97 96 98 9 (set (reg:V1TI 91 [ p ])
(mem/c:TI (plus:DI (reg/f:DI 19 frame)
(const_int -32 [0xffe0])) [0 p+0 S16 A128]))
"pr109676.C":26:12 87 {*movti_internal}
 (nil))
insn which sets it, fix_debug_reg_uses isn't called.

[Bug tree-optimization/105723] [12 Regression] Optimization false positive warning (-Wstringop-overflow)

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

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

Sam James  changed:

   What|Removed |Added

 CC||rguenther at suse dot de

--- Comment #4 from Sam James  ---
(In reply to Richard Biener from comment #3)
> Needs bisection as to what fixed it on trunk.

Inverse bisect says:

fd8dd6c0384969170e594be34da278a072d5eb76 is the first bad commit
commit fd8dd6c0384969170e594be34da278a072d5eb76
Author: Richard Biener 
Date:   Tue Nov 29 12:56:22 2022 +0100

tree-optimization/107852 - missed optimization with PHIs

i.e. r13-4389-gfd8dd6c0384969. It doesn't revert cleanly on trunk so I can't
test if it's sane or not.

[Bug c++/109683] New: [13/14 Regression] False cyclic dependency error reported for constraint

[dani at danielbertalan dot dev via Gcc-bugs]

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

Bug ID: 109683
   Summary: [13/14 Regression] False cyclic dependency error
reported for constraint
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dani at danielbertalan dot dev
  Target Milestone: ---

The following code (reduced from a custom std::variant-like type) compiles with
GCC 12.2 and Clang, but is rejected by GCC 13+:

```
template 
struct VariantConstructors {
  VariantConstructors(T&& t)
requires(requires { T(t); });
};

template 
struct InheritFromEntries : Ts... {};

template 
struct InheritFromPack: InheritFromEntries... {
  using InheritFromEntries::InheritFromEntries...;
};

template 
struct Variant : InheritFromPack>...>
{};

template 
class Outer;
struct Inner {
Inner(Outer);
};
template
class Outer {
Variant value_;
};

struct Empty {};
void fn(Outer x) {}
```

The following compiler error is produced (arguments: -std=c++20):

: In instantiation of 'VariantConstructors
>::VariantConstructors(T&&) requires requires{T(VariantConstructors >::__ct ::t);} [with T = Inner;
 = Variant]':
:12:51:   required from 'struct
InheritFromPack >,
VariantConstructors > >'
:16:8:   required from 'struct Variant'
:25:23:   required from 'class Outer'
:4:25:   required from 'VariantConstructors
>::VariantConstructors(T&&) requires requires{T(VariantConstructors >::__ct ::t);} [with T = Inner;
 = Variant]'
:12:51:   required from 'struct
InheritFromPack >,
VariantConstructors > >'
:16:8:   required from 'struct Variant'
:25:23:   required from 'class Outer'
:29:23:   required from here
:3:3:   required by the constraints of 'template
VariantConstructors >::VariantConstructors(T&&)
requires requires{T(VariantConstructors >::__ct
::t);}'
:4:14:   in requirements  [with T = Inner]
:4:14: error: satisfaction of atomic constraint
'requires{T(VariantConstructors >::__ct ::t);}
[with T = T]' depends on itself
4 | requires(requires { T(t); });
  | ~^~~

Reproducer on Compiler Explorer: https://godbolt.org/z/TbcoanG5T
The non-reduced preprocessed source can be found here:
https://godbolt.org/z/69dMMoWKh

[Bug debug/109676] [13/14 regression] ICE in simplify_subreg, at simplify-rtx.cc:7426 when building firefox with -O2 -march=alderlake -g since r13-3378-gf6c168f8c06047

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #11 from Jakub Jelinek  ---
This looks like a STV bug to me.  Before the stv pass, we have correct
(debug_insn 114 47 51 8 (var_location:TI D#3 (reg:TI 91 [ p ])) -1
 (nil))
but stv changes that to invalid
(debug_insn 114 47 51 8 (var_location:TI D#3 (reg:V1TI 91 [ p ])) -1
 (nil))
where the modes no longer match.  Will have a look...

[Bug c++/109680] [13/14 Regression] is_convertible incorrectly true

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
r13-2822-g8a7bcf95a82c3dd implemented __is_{,nothrow_}convertible for GCC 13,
CCing Marek.

[Bug tree-optimization/93265] memcmp comparisons of structs wrapping a primitive type not as compact/efficient as direct comparisons of the underlying primitive type under -Os

[pskocik at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Petr Skocik  ---
Here's another example (which may be summarizing it more nicely)

struct a{ char _[4]; };
#include 
int cmp(struct a A, struct a B){ return !!memcmp(,,4); }

Expected x86-64 codegen (✓ for gcc -O2/-O3 and for clang -Os/-O2/-O3)   
xor eax, eax
cmp edi, esi
setne   al
ret

gcc -Os codegen:
subq$24, %rsp
movl$4, %edx
movl%edi, 12(%rsp)
leaq12(%rsp), %rdi
movl%esi, 8(%rsp)
leaq8(%rsp), %rsi
callmemcmp
testl   %eax, %eax
setne   %al
addq$24, %rsp
movzbl  %al, %eax
ret

https://godbolt.org/z/G5eE5GYv4