[Bug objc++/109728] lambda capture with initializer doesn't compile when compiling ObjC++ code.

[falemagn at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Fabio Alemagna  ---
Yes, clang handles this case correctly.

[Bug tree-optimization/109722] ABSU == 0 is not optimized to just a == 0

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Fixed.

[Bug tree-optimization/109722] ABSU == 0 is not optimized to just a == 0

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

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

--- Comment #4 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:6fe385eac6ff8ecddb6cbdff2c706b27b5137006

commit r14-488-g6fe385eac6ff8ecddb6cbdff2c706b27b5137006
Author: Andrew Pinski 
Date:   Thu May 4 23:37:51 2023 +

MATCH: Add ABSU == 0 to a == 0 simplification

There is already an `ABS == 0` to `a == 0` pattern,
this just extends that to ABSU too.

OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.

PR tree-optimization/109722

gcc/ChangeLog:

* match.pd: Extend the `ABS == 0` pattern
to cover `ABSU == 0` too.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/abs-1.c: New test.

[Bug tree-optimization/109691] 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

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> gcc.dg/pr81192.c might need a similar thing now too but I am not 100% sure.
> pr81192.c should really be a Gimple testcase but gimple testcases were not
> around when the testcase was added.

It is going to need to be a gimple testcase. The testcase has become too
fragile otherwise; it already has gone through a few -fno-* -fdisable-* options
already too.

[Bug target/105576] x86: Support a machine constraint to get raw symbol name

[i at maskray dot me via Gcc-bugs]

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

--- Comment #6 from Fangrui Song  ---
(In reply to Hongtao.liu from comment #4)
> constraint "i" + "%p0"?
> 
>   asm (".pushsection .xxx,\"aw\"; .dc.a %p0; .popsection" :: "i"(addr)); //
> supported on aarch64 and riscv
>   asm (".pushsection .xxx,\"aw\"; .dc.a %p0; .popsection" :: "i"()); //
> supported on aarch64

It looks like %p0 + "i" doesn't work with -fpie or -fpic...

void k();
void foo() {
  asm("call %p0" :: "i"(k));
}

[Bug libfortran/109662] bad namelist input but gfortran accepted it

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

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

--- Comment #8 from Jerry DeLisle  ---
A side comment. We have a runtime function called "notify_std". Every time I
try to use it I struggle as it is not intuitively obvious how it works. We
ought to provide some better documentation on using it in the gfortran wiki.

[Bug c++/109658] [14 Regression] ICE when building aria2-1.36.0 (internal compiler error: in instantiate_decl, at cp/pt.cc:27095) since r14-283-g95d4c0d2e6318a

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

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

Jason Merrill  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #9 from Jason Merrill  ---
*** Bug 109645 has been marked as a duplicate of this bug. ***

[Bug c++/109645] [14 Regression] ICE in instantiate_decl, at cp/pt.cc:27097 since r14-283-g95d4c0d2e6318a

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #9 from Jason Merrill  ---
Dup.

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

[Bug c++/109658] [14 Regression] ICE when building aria2-1.36.0 (internal compiler error: in instantiate_decl, at cp/pt.cc:27095) since r14-283-g95d4c0d2e6318a

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

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

--- Comment #8 from Jason Merrill  ---
*** Bug 109723 has been marked as a duplicate of this bug. ***

[Bug c++/109723] [14 regression] ICE in instantiate_decl, at cp/pt.cc:27066 when building opencv-4.7.0 since r14-283-g95d4c0d2e6318a

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

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

Jason Merrill  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|ASSIGNED|RESOLVED

--- Comment #3 from Jason Merrill  ---
dup.

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

[Bug c++/109658] [14 Regression] ICE when building aria2-1.36.0 (internal compiler error: in instantiate_decl, at cp/pt.cc:27095) since r14-283-g95d4c0d2e6318a

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #7 from Jason Merrill  ---
Fixed.

[Bug c++/109658] [14 Regression] ICE when building aria2-1.36.0 (internal compiler error: in instantiate_decl, at cp/pt.cc:27095) since r14-283-g95d4c0d2e6318a

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

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

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

https://gcc.gnu.org/g:6f18f344338b370031e75924eed2bdd1ce5c8dba

commit r14-487-g6f18f344338b370031e75924eed2bdd1ce5c8dba
Author: Jason Merrill 
Date:   Thu May 4 18:37:19 2023 -0400

Revert "c++: restore instantiate_decl assert"

In the testcase the assert fails because we use one member function from
another while we're in the middle of instantiating them all, which is
perfectly fine.  It seems complicated to detect this situation, so let's
remove the assert again.

PR c++/109658

This reverts commit 95d4c0d2e6318aef88ba0bc607dfc1ec6b7a612f.

gcc/testsuite/ChangeLog:

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

[Bug tree-optimization/109722] ABSU == 0 is not optimized to just a == 0

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-May/617
   ||494.html

--- Comment #3 from Andrew Pinski  ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617494.html

[Bug tree-optimization/109732] [14 regression] gcc miscompiles iterator comparison on nlohmann_json since r14-204-gf1f5cbaa3f716f

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

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

--- Comment #14 from Andrew Pinski  ---
Figured out a C testcase:
```
[[gnu::noipa]]
_Bool f3(_Bool a)
{
if (a==0)
  return 0;
else
  return a;
}
```
Still need: `-fdisable-tree-fre1` though because fre is able to figure out that
the return value is always a. We don't need to disable ethread any more since
cfgcleanup will not remove the forwarding BB as it has a predict statement in
it.

There are actually two conditions that need to happen to get the wrong code.
First is the order of the phi and then also the order of the edges. The above
is enough to get both.

[Bug c++/109723] [14 regression] ICE in instantiate_decl, at cp/pt.cc:27066 when building opencv-4.7.0 since r14-283-g95d4c0d2e6318a

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

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

Jason Merrill  changed:

   What|Removed |Added

   Last reconfirmed||2023-05-04
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

[Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE

[ian_harvey at bigpond dot com via Gcc-bugs]

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

--- Comment #6 from Ian Harvey  ---
A module procedure is defined by a module subprogram (F2018 15.2.2.2p3).  A
module subprogram (or any subprogram) is a syntax element (a piece of source
code), equivalent to /module-subprogram/ (see the first sentence of F2018
4.1.5p1).  The things that appear after the CONTAINS in a submodule are module
subprograms (see the definitions of /submodule/ and /module-subprogram-part/).

[Bug c++/52339] using delete ptr1->ptr2 where ptr2 destructor deletes a const ptr1 fails

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

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

--- Comment #9 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #5)
> in main it doesn't, as the nop is stripped and the COMPONENT_REF is
> TREE_READONLY and !TREE_SIDE_EFFECTS.
> tree.cc (save_expr) documents that:
>Constants, and certain read-only nodes, are returned with no
>SAVE_EXPR because that is safe.

Yeah, assuming that TREE_READONLY (t) && !TREE_SIDE_EFFECTS (t) is enough to
assume that T won't change seems bogus to me.

We could remove that line from tree_invariant_p_1, or restrict it to only apply
if DECL_P (t) is also true?

[Bug tree-optimization/109732] [14 regression] gcc miscompiles iterator comparison on nlohmann_json since r14-204-gf1f5cbaa3f716f

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-May/617
   ||492.html

--- Comment #13 from Andrew Pinski  ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617492.html

[Bug c++/100918] [10 Regression] Naming a destructor as a qualified template-id results in bogus access error

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

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

--- Comment #9 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Christian Prochaska from comment #7)
> > Since the commit above the following test fails. Is this correct?
> 
> > 
> > class T1 { };
> > class T2 { };
> > 
> > template 
> > class A { };
> > 
> > class B : A { };
> > 
> > class C : B
> > {
> > class D : A { };
> > };
> > 
> > test.cc:11:19: error: ‘class A A::A’ is private within this context
> >11 | class D : A { };
> >   |   ^
> > test.cc:7:7: note: declared private here
> > 7 | class B : A { };
> >   |   ^
> 
> 
> 
> Yes it should be rejected as A is a private name of A and A is
> private to B. clang rejects it for the same reason though has a better error
> message:
> :12:19: error: 'A' is a private member of 'A'
> class D : A { };
>   ^
> :8:11: note: constrained by implicitly private inheritance here
> class B : A { };
>   ^
> :6:7: note: member is declared here
> class A { };
>   ^

An obvious fix is to use ::A while inside C .

[Bug c++/100918] [10 Regression] Naming a destructor as a qualified template-id results in bogus access error

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Christian Prochaska from comment #7)
> Since the commit above the following test fails. Is this correct?

> 
> class T1 { };
> class T2 { };
> 
> template 
> class A { };
> 
> class B : A { };
> 
> class C : B
> {
>   class D : A { };
> };
> 
> test.cc:11:19: error: ‘class A A::A’ is private within this context
>11 | class D : A { };
>   |   ^
> test.cc:7:7: note: declared private here
> 7 | class B : A { };
>   |   ^



Yes it should be rejected as A is a private name of A and A is private
to B. clang rejects it for the same reason though has a better error message:
:12:19: error: 'A' is a private member of 'A'
class D : A { };
  ^
:8:11: note: constrained by implicitly private inheritance here
class B : A { };
  ^
:6:7: note: member is declared here
class A { };
  ^

[Bug c++/109742] ICE on unexpanded NTTP pack

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

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

--- Comment #1 from Andrew Pinski  ---
bug 109017 comment #1 looks like an exact dup of this testcase too.

[Bug c++/100918] [10 Regression] Naming a destructor as a qualified template-id results in bogus access error

[christian.prochaska--- via Gcc-bugs]

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

Christian Prochaska  changed:

   What|Removed |Added

 CC||christian.prochaska@genode-
   ||labs.com

--- Comment #7 from Christian Prochaska  
---
Since the commit above the following test fails. Is this correct?

class T1 { };
class T2 { };

template 
class A { };

class B : A { };

class C : B
{
class D : A { };
};

test.cc:11:19: error: ‘class A A::A’ is private within this context
   11 | class D : A { };
  |   ^
test.cc:7:7: note: declared private here
7 | class B : A { };
  |   ^

When class B is left out, the error does not occur:

class T1 { };
class T2 { };

template 
class A { };

class C : A
{
class D : A { };
};

[Bug c++/109742] New: ICE on unexpanded NTTP pack

[420 at zerberste dot es via Gcc-bugs]

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

Bug ID: 109742
   Summary: ICE on unexpanded NTTP pack
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 420 at zerberste dot es
  Target Milestone: ---

The following erroneous code snippet triggers an ICE on all versions since 8.1
(including trunk):

template 
void ice(){
return ([](){
return g;
}() || ...);
}

template void ice<>();


See https://godbolt.org/z/1jPbe3h9G

[Bug target/109690] bad SLP vectorization on zen

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Uroš Bizjak  ---
Created attachment 55002
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55002=edit
Patch that introduces mulv2si3

The compiled code with -march=znver1 is now the same as without the flag:

loop:
vmovq   a(%rip), %xmm0
salla+8(%rip)
vpslld  $1, %xmm0, %xmm0
vmovq   %xmm0, a(%rip)
ret

[Bug tree-optimization/109732] [14 regression] gcc miscompiles iterator comparison on nlohmann_json since r14-204-gf1f5cbaa3f716f

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

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

--- Comment #12 from Sergei Trofimovich  ---
(In reply to Andrew Pinski from comment #11)
> Created attachment 54999 [details]
> Patch which needs a message/changelog

I confirm the patch fixes real test failures on nlohmann_json-3.11.2 as well.

I also had untriaged mysterious aws-sdk-cpp-1.11.37 test failures. The failures
are gone as well with your patch.

Thank you!

[Bug libstdc++/109741] alignas(64) in libstdc++-v3/src/c++11/shared_ptr.cc

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

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

--- Comment #14 from Jonathan Wakely  ---
Libstdc++ doesn't work on "every possible architecture", just the ones GCC
supports.

I am 100% confident that alignas(void*) is wrong for every architecture GCC
supports, and I'm pretty confident alignof(max_align_t) is wrong for all of
them too (since that's either 8 or 16). I'm also confident that 64 is a good
choice for nearly all targets GCC supports.

64 is much less wrong than any of your suggestions, and is right for most GCC
targets.

[Bug testsuite/109656] [14 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7

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

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

--- Comment #5 from seurer at gcc dot gnu.org ---
make  -k check
RUNTESTFLAGS="conformance.exp=26_numerics/random/random_device/cons/token.cc"

This is from powerpc64le-unknown-linux-gnu/libstdc++-v3/testsuite/libstdc++.log

Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/git/build/gcc-test/gcc:/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libstdc++-v3/../libatomic/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libstdc++-v3/../libgomp/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs::/home/seurer/gcc/git/build/gcc-test/gcc:/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libstdc++-v3/../libatomic/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libstdc++-v3/../libgomp/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/git/build/gcc-test/./gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./isl/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-isl/.libs
Execution timeout is: 300
spawn [open ...]^M
terminate called without an active exception
FAIL: 26_numerics/random/random_device/cons/token.cc execution test

I assume the LD_LIBRARY_PATH there is the one used and nothing in it appears
out of order.

BTW, I tried various changes in configure options, build compilers, binutils,
and such in case something there was an issue but it always fails on just this
one power 8 system.  It works fine on another similar power 8 and other power X
(X!=8) systems.

[Bug c++/109730] [12/13/14 regression] ICE in contains_struct_check since r12-9441-g94569d91bd4c60

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Dup of bug 109666.

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

[Bug c++/109666] [12 Regression] Segmentation fault with std::array

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||tocic at protonmail dot ch

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

[Bug objc++/109728] lambda capture with initializer doesn't compile when compiling ObjC++ code.

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

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

--- Comment #1 from Andrew Pinski  ---
Oh this might be an ambiguity with ObjC++ parsing part.
[a b] is how you call an object-C method after all.

Is clang able to handle this case too?

[Bug libstdc++/109741] alignas(64) in libstdc++-v3/src/c++11/shared_ptr.cc

[janezz55 at gmail dot com via Gcc-bugs]

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

--- Comment #13 from Janez Zemva  ---
@Jonathan Wakely
I asked ChatGPT about this:

What is the most common size of a cache line?
The most common size of a cache line is 64 bytes. This size is used by most
modern CPUs because it strikes a balance between the amount of data that can be
stored in a cache line and the amount of overhead required to manage the cache.
However, it's important to note that different CPUs and cache designs may use
different cache line sizes based on their specific requirements and trade-offs
between performance and resource usage.

This means the "right" number is architecture-dependent and my proposals were
not  wrong for every possible architecture.

[Bug tree-optimization/109716] mesa/r300 bogus stringop-overread "reading 4 bytes from a region of size 0"

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

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

--- Comment #3 from Andrew Pinski  ---
The warning comes from:
   [local count: 64057779]:
  util_format_unswizzle_4f (_swizzled, _42, 64B);
  goto ; [100.00%]


Jump threading and having util_format_description declared as const causes a
null pointer for desc to prograted into the argument of that function.

Some places check the return value of util_format_description to see if it was
non-null whiles others do not. I am not sure if we can assert the return value
of util_format_description is non-null in r300_get_border_color but that
removes the warning.

That is:
static uint32_t r300_get_border_color(enum pipe_format format,
  const float border[4],
  boolean is_r500)
{
const struct util_format_description *desc;
float border_swizzled[4] = {0};
union util_color uc = {0};

desc = util_format_description(format);
if (desc == 0)  __builtin_unreachable();

[Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE

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

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

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #3)
> 
> I have marked this as "waiting" pending a contrary interpretation.
> 
> Cheers
> 

Paul,

I asked on the J3 mailing list about the code.

https://mailman.j3-fortran.org/pipermail/j3/2023-May/014193.html

[Bug tree-optimization/109716] mesa/r300 bogus stringop-overread "reading 4 bytes from a region of size 0"

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

[Bug tree-optimization/109714] mesa/aux/draw_llvm: bogus "may be used uninitialized warning"

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

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

--- Comment #4 from Andrew Pinski  ---
What options are being used to compile this?
I cannot reproduce it on the trunk ...

[Bug tree-optimization/109716] bogus stringop-overread "reading 4 bytes from a region of size 0"

[david at ixit dot cz via Gcc-bugs]

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

--- Comment #2 from David Heidelberg (okias)  ---
Created attachment 55001
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55001=edit
r300_state_derived.c.i.gz

Appending requested file. Thank you!

[Bug tree-optimization/109714] bogus "may be used uninitialized warning"

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

[Bug tree-optimization/109714] bogus "may be used uninitialized warning"

[david at ixit dot cz via Gcc-bugs]

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

--- Comment #3 from David Heidelberg (okias)  ---
Created attachment 55000
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55000=edit
draw_draw_llvm.c.i.gz

[Bug libstdc++/109741] alignas(64) in libstdc++-v3/src/c++11/shared_ptr.cc

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

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

--- Comment #12 from Jakub Jelinek  ---
(In reply to Jonathan Wakely from comment #11)
> > Perhaps it should at configure time check if such alignment is possible and
> > otherwise simply don't align it beyond mutex natural alignment?
> 
> Agreed.

We could as well for those arches use just larger unaligned buffer and align
manually.

[Bug target/109733] [14 Regression] ICE in extract_insn, at recog.cc:2791 since r14-475-g508f082829af68

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #5 from Uroš Bizjak  ---
Fixed.

[Bug target/109733] [14 Regression] ICE in extract_insn, at recog.cc:2791 since r14-475-g508f082829af68

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

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

commit r14-485-g8cac23781753bd8a016507dc9b21ec563e1d9b49
Author: Uros Bizjak 
Date:   Thu May 4 20:26:12 2023 +0200

i386: Tighten ashift to lea splitter operand predicates [PR109733]

The predicates of ashift to lea post-reload splitter were too broad
so the splitter tried to convert the mask shift instruction.  Tighten
operand predicates to match only general registers.

gcc/ChangeLog:

PR target/109733
* config/i386/predicates.md (index_reg_operand): New predicate.
* config/i386/i386.md (ashift to lea spliter): Use
general_reg_operand and index_reg_operand predicates.

[Bug libstdc++/109741] alignas(64) in libstdc++-v3/src/c++11/shared_ptr.cc

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

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

--- Comment #11 from Jonathan Wakely  ---
(In reply to Jakub Jelinek from comment #9)
> I think it intentionally uses 64 rather than the controversial macros.

It's been there since before we had those macros. I think using the destructive
interference size makes sense, now that we have a constant for it.

> Perhaps it should at configure time check if such alignment is possible and
> otherwise simply don't align it beyond mutex natural alignment?

Agreed.

[Bug libstdc++/109741] alignas(64) in libstdc++-v3/src/c++11/shared_ptr.cc

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

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

--- Comment #10 from Jonathan Wakely  ---
(In reply to Janez Zemva from comment #0)
> This line:
> 
> struct alignas(64) M : __gnu_cxx::__mutex { };
> 
> has been an eyesore for me for a number of years. I propose to change it

That belongs on the mailing list, not in bugzilla.

> into:
> 
> struct alignas(std::max_align_t) M : __gnu_cxx::__mutex { };

That would be completely wrong though.


(In reply to Janez Zemva from comment #1)
> alternatively, the line could be changed into:
> 
> struct alignas(void*) M : __gnu_cxx::__mutex { };
> 
> since this was probably meant with the magic number 64.

That would be even more wrong. Please just read the comment instead of making
silly assumptions about what we meant.


(In reply to Janez Zemva from comment #5)
> This line has been patched out by djgpp builds for a long time now.

Then say that, instead of suggesting incorrect changes.

[Bug c++/109738] C++20 implicit conversion is used during spaceship operator resolution instead of class's operator< for classes without spaceship operator

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

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

--- Comment #1 from Andrew Pinski  ---
clang has the same behavior as GCC .

[Bug libstdc++/109741] alignas(64) in libstdc++-v3/src/c++11/shared_ptr.cc

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
I think it intentionally uses 64 rather than the controversial macros.
Perhaps it should at configure time check if such alignment is possible and
otherwise simply don't align it beyond mutex natural alignment?

[Bug libstdc++/109741] alignas(64) in libstdc++-v3/src/c++11/shared_ptr.cc

[janezz55 at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Janez Zemva  ---
Here is the compile error:
../../../../../gcc-13.1.0/libstdc++-v3/src/c++11/shared_ptr.cc: In function
'__gnu_cxx::__mutex& __gnu_internal::get_mutex(unsigned char)':
../../../../../gcc-13.1.0/libstdc++-v3/src/c++11/shared_ptr.cc:42:44: error:
requested alignment '64' exceeds object file maximum 16
   42 |   char buffer[(sizeof (M)) * (mask + 1)];
  |^

I agree with your findings.

[Bug libstdc++/109741] alignas(64) in libstdc++-v3/src/c++11/shared_ptr.cc

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #7 from Andrew Pinski  ---
I think the fix would be export MAX_OFILE_ALIGNMENT as a predefined macro, say
__GCC_MAX_OFILE_ALIGNMENT and then do the following libstdc++:

__GCC_DESTRUCTIVE_SIZE > __GCC_MAX_OFILE_ALIGNMENT ? __GCC_MAX_OFILE_ALIGNMENT 
: __GCC_DESTRUCTIVE_SIZE 

Confirmed.

[Bug libstdc++/109741] alignas(64) in libstdc++-v3/src/c++11/shared_ptr.cc

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
Oh that has a max file object alignment of 16 bytes. Might be the only target
that is that low.

[Bug libstdc++/109741] alignas(64) in libstdc++-v3/src/c++11/shared_ptr.cc

[janezz55 at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Janez Zemva  ---
This line has been patched out by djgpp builds for a long time now.

[Bug c++/109740] -Woverloaded-virtual is too aggressive

[psmith at gnu dot org via Gcc-bugs]

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

--- Comment #2 from Paul Smith  ---
What I'm trying to say is that it's not useful (to me) for GCC to warn about
code that I could maybe write in the future but didn't actually write, and
which if I did write it would generate a compiler error anyway, rather than
"doing the wrong thing".

On the other hand, it's very useful for GCC to warn me about situations where I
could be actually getting an unexpected result, without a compiler error.  For
example if the parent method takes an int and the child method takes a char,
then I might call B.foo(10) expecting to get the parent method but actually the
child method will be invoked.  That kind of warning is very helpful.

So, it would be nice to have a way to warn about things that might miscompile
silently in unexpected ways, without also warning about things that can't
possibly miscompile in unexpected ways.

I did read the description in the docs, and the suggestion of adding using
A::foo to the child class, but that inherits all the parent class's virtual
methods into the child class which I don't want to do in all cases.

[Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #3)
> Nagfor responds to the test case with "Error: pr97122.f90, line 14: Type T
> has final subroutines but is not defined in the specification part of a
> module"
> 
> F2018:
> "C787(R753) A final-subroutine-name shall be the name of a module procedure
> with exactly one dummy argument."
> 
> Since, of necessity, the argument is declared to be of the derived type with
> the final binding, the gfortran and nagfor errors are correct IMHO. ifort
> compiles it without complaint.
> 
> I have marked this as "waiting" pending a contrary interpretation.
> 
> Cheers
> 
> Paul

Hi Paul, 

I don't see how C787 applies.

  SUBROUTINE p(arg)
TYPE(t), INTENT(INOUT) :: arg
  END SUBROUTINE p

p() has exactly one argument.  If I read F2018 correctly (which is almost
always questionable), a module procedure can appear in a submodule.

[Bug libstdc++/109741] alignas(64) in libstdc++-v3/src/c++11/shared_ptr.cc

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Janez Zemva from comment #1)
> > alternatively, the line could be changed into:
> > 
> > struct alignas(void*) M : __gnu_cxx::__mutex { };
> > 
> > since this was probably meant with the magic number 64.
> 
> The magic number 64 is the cache line size to make sure there are less
> sharing.

That is even the comment:
// increase alignment to put each lock on a separate cache line

[Bug libstdc++/109741] alignas(64) in libstdc++-v3/src/c++11/shared_ptr.cc

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Janez Zemva from comment #1)
> alternatively, the line could be changed into:
> 
> struct alignas(void*) M : __gnu_cxx::__mutex { };
> 
> since this was probably meant with the magic number 64.

The magic number 64 is the cache line size to make sure there are less sharing.

[Bug libstdc++/109741] alignas(64) in libstdc++-v3/src/c++11/shared_ptr.cc

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

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

--- Comment #2 from Andrew Pinski  ---
I think it should really be either __GCC_DESTRUCTIVE_SIZE or
__GCC_CONSTRUCTIVE_SIZE (I always forgot which one it really).

>some targets do not support this alignment.
Which targets don't support alingment of 64bytes?

[Bug libstdc++/109741] alignas(64) in libstdc++-v3/src/c++11/shared_ptr.cc

[janezz55 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Janez Zemva  ---
alternatively, the line could be changed into:

struct alignas(void*) M : __gnu_cxx::__mutex { };

since this was probably meant with the magic number 64.

[Bug libstdc++/109741] New: alignas(64) in libstdc++-v3/src/c++11/shared_ptr.cc

[janezz55 at gmail dot com via Gcc-bugs]

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

Bug ID: 109741
   Summary: alignas(64) in libstdc++-v3/src/c++11/shared_ptr.cc
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janezz55 at gmail dot com
  Target Milestone: ---

This line:

struct alignas(64) M : __gnu_cxx::__mutex { };

has been an eyesore for me for a number of years. I propose to change it into:

struct alignas(std::max_align_t) M : __gnu_cxx::__mutex { };

in which case  needs to be #included as well. The magic number 64
alone should be raising some eyebrows and some targets do not support this
alignment.

[Bug modula2/109729] gm2 (14.0.0) does not like a CHAR type FOR loop control variable any more

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #4 from Gaius Mulley  ---
Closing after successful bootstrap and patch has been applied.

[Bug modula2/109729] gm2 (14.0.0) does not like a CHAR type FOR loop control variable any more

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

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

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

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

commit r14-484-gac7c9954ece9a75c5e7c3b76a4800f2432002487
Author: Gaius Mulley 
Date:   Thu May 4 18:15:59 2023 +0100

PR modula2/109729 cannot use a CHAR type as a FOR loop iterator

This patch introduces a new quadruple ArithAddOp which is used in
the construction of FOR loop to ensure that when constant folding
is applied it does not concatenate two constant char operands into
a string constant.  Overloading only occurs with constant operands.

gcc/m2/ChangeLog:

PR modula2/109729
* gm2-compiler/M2GenGCC.mod (CodeStatement): Detect
ArithAddOp and call CodeAddChecked.
(ResolveConstantExpressions): Detect ArithAddOp and call
FoldArithAdd.
(FoldArithAdd): New procedure.
(FoldAdd): Refactor to use FoldArithAdd.
* gm2-compiler/M2Quads.def (QuadOperator): Add ArithAddOp.
* gm2-compiler/M2Quads.mod: Remove commented imports.
(QuadFrame): Changed comments to use GNU coding standards.
(ArithPlusTok): New global variable.
(BuildForToByDo): Use ArithPlusTok instead of PlusTok.
(MakeOp): Detect ArithPlusTok and return ArithAddOp.
(WriteQuad): Add ArithAddOp clause.
(WriteOperator): Add ArithAddOp clause.
(Init): Initialize ArithPlusTok.

gcc/testsuite/ChangeLog:

PR modula2/109729
* gm2/pim/run/pass/ForChar.mod: New test.

Signed-off-by: Gaius Mulley 

[Bug tree-optimization/109732] [14 regression] gcc miscompiles iterator comparison on nlohmann_json since r14-204-gf1f5cbaa3f716f

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

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

--- Comment #11 from Andrew Pinski  ---
Created attachment 54999
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54999=edit
Patch which needs a message/changelog

[Bug c++/52339] using delete ptr1->ptr2 where ptr2 destructor deletes a const ptr1 fails

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #8 from joseph at codesourcery dot com  ---
I think it's valid C99, yes: the VLA size should be evaluated exactly 
once, when the declaration is passed in the order of execution.

[Bug c++/109740] -Woverloaded-virtual is too aggressive

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

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

--- Comment #1 from Andrew Pinski  ---
The warning is specifically designed this way and even is documented to warn.
https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/C_002b_002b-Dialect-Options.html#index-Woverloaded-virtual

It is designed this way so you don't accidently have the wrong arguments (types
and/or count). The documentation even talks about that:
"In cases where the different signatures are not an accident,"

[Bug fortran/109701] I have a MWE where an omp reduction breaks if I add the option for GPU offloading (even if it isn't used).

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

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

--- Comment #7 from Jakub Jelinek  ---
That is not that surprising.  As mentioned in the linked in PR99928, that
behavior is there only in OpenMP 5.0 and wasn't like that in OpenMP 4.5 and
earlier; in OpenMP 4.5
you really need separate target (or target teams) with explicit map clause and
then distribute ... with reduction.  And this part of OpenMP 5.0 was only
implemented in GCC starting with GCC 12, older versions supported the 4.5
behavior.

[Bug c++/109740] New: -Woverloaded-virtual is too aggressive

[psmith at gnu dot org via Gcc-bugs]

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

Bug ID: 109740
   Summary: -Woverloaded-virtual is too aggressive
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: psmith at gnu dot org
  Target Milestone: ---

I understand the impetus for the -Woverloaded-virtual warning but I think it
should be further constrained, or maybe broken into levels of severity that can
be enabled.

The issue I'm running into is that a superclass has a virtual method signature
with some number of arguments, and the subclass has an overloaded method with a
different number of arguments.  For example:

  struct A { virtual void foo(int); };
  struct B : public A { void foo(); };

We do this kind of thing all the time because the subclass's version of this
method has more knowledge, or whatever, and doesn't need the extra arguments.

However, this fires the overloaded-virtual warning.  I don't think this
warrants a warning: if I call B.foo() then it will always do the right thing. 
If I call B.foo(10) it will give me an error.  There's no way that the compiler
could ever call the wrong thing "behind my back" due to some sort of type
conversion that is not obvious from the code, because the number of arguments
are different: either it does exactly what I expect and there's no need for a
warning, or I get an error and there's no need for a warning.

This subclassing capability is (IMO) useful and shouldn't be restricted, but I
would prefer to keep the warning for in other situations that could potentially
cause misbehavior.

Would it be possible to suppress this warning if the overload can't possibly
conflict due to number of arguments?

There is also the possibility that a subclass method has the same number of
arguments but they are of incompatible types which cannot be converted between.
 There is an argument to be made that this, also, shouldn't cause a warning. 
I'm not sure how straightforward it is to determine "can't be converted"
although there are some obvious ones.

[Bug tree-optimization/109732] [14 regression] gcc miscompiles iterator comparison on nlohmann_json since r14-204-gf1f5cbaa3f716f

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

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

--- Comment #10 from Andrew Pinski  ---
Created attachment 54998
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54998=edit
Gimple testcase that fails at runtime too

-O1 -fgimple -fdisable-tree-ethread -fdisable-tree-fre1


The thing is you need the false edge to be the first successor edge of BB2. So
you have to get forwprop to swap the edges from being true and false. Also
gimple front-end does not like bool constants that well.

[Bug target/109733] [14 Regression] ICE in extract_insn, at recog.cc:2791 since r14-475-g508f082829af68

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

  Attachment #54996|0   |1
is obsolete||

--- Comment #3 from Uroš Bizjak  ---
Created attachment 54997
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54997=edit
The correct patch.

[Bug target/109733] [14 Regression] ICE in extract_insn, at recog.cc:2791 since r14-475-g508f082829af68

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
 Status|NEW |ASSIGNED

--- Comment #2 from Uroš Bizjak  ---
Created attachment 54996
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54996=edit
Patch in testing.

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #22 from Andrew Macleod  ---
OK, I've finished with my analysis.  There are multiple vectors of attack here,
and we should do them all.   Some where already on my radar for this release
anyway, but this gives a nice tidy place to track them all.

First, the increased size of int_range_max needs to be addressed.Short term
we could resolve this simply by making int_range<25> instead of int_range<255>.
 That of course papers over the real problem, but still needs addressing.  Aldy
and I are discussing.

Next, prefill_stmt_dependencies exists to short-cut long chains of calls to
range_of_stmt by managing it on a stack. It uses a *lot* less stack calls, but
it is still subject to re-evaluating statements whose dependencies are updated.

ssa-names that have not been calculated have no entry in rangers global cache. 
As soon as they get an entry, they are also given a monotonically increasing
timestamp.  This allows us to quickly see if a dependence has been updated
since a value was last calculated. 

prefill_stmt_dependencies pushes un-evaluated names from statements onto a
stack as they are seen, and evaluating those first, then finally evaluating the
stmt. 

_1012 = PHI <_1947(2), _1011(1016)>

we push _1012, then _1947 and _1011 on the stack to evaluate.  _1011 and _1947
will be evaluated before _1012, thus allowing for a decent calculation of
_1012.

We avoid cycles by providing an initial value for a name when it is first
registered. When we provide this initial value, we also set the timestamp to
"always current" so we don't end up with flip flopping dependencies in cycles
causing each other to be recalculated. When we store the newly calculated
value, we set a proper timestamp.

So, on to the issues that need to be addressed.

1) We unconditionally write the new value calculated to the global cache once
the dependencies are resolved.  This gives it a new timestamp, and thus makes
any other values which used it out of date when they really aren't.   This
causes a lot of extra churn.

TODO: This should be changed to only update it when it actually changes. 
Client code shouldn't have to do this, it shoud be handled right int the
cache's set_global_value ().

2) The initial value we choose is simply VARYING. This is why 1) alone won't
solve this problem.  when we push _1947 on the stack, we set it to VARYING.. 
then proceed down along chain of other dependencies Driven by _1011 which are
resolved first.  When we get back to _1947 finally, we see: 
  _1947 = 77;
which evaluated to [77, 77], and is this different than VARYING, and thus would
cause a new timestamp to be created even if (1) were implemented.

TODO: When setting the initial value in the cache, rather than being lazy and
using varying, we should invoke fold_stmt using get_global_range_query ().  
This will fold the stmt and produce a result which resolved any ssa-names just
using known global values. THis should not be expensive, and gives us a
reasonable first approximation.  And for cases like _1947, the final result as
well.

3) When we first set the intial value for _1947 and give it the ALWAYS_CURRENT
timestamp, we lose the context of when the initial value was set.  So even with
1) & 2) implemented, we are *still* need to set a timestamp for it when its
finally calculated, even though it is the same as the original.  This will
cause any names already evaluated using its range to become stale because we
can't leave it as ALWAYS_CURRENT.(There are other places where we do need
to be able to re-evaluate.. there are 2 testsuite failures caused by this if we
just leave it as always_current)

TODO: Alter the implementation of ALWAYS_CURRENT such that a name is also given
a timestamp at the time of setting the initial value.   Then set_global_range()
will clear the ALWAYS_CURRENT tag unconditionally, but leave the original
timestamp if the value hasn't changed.  This will then provide an accurate
timestamp for the initial_value.

4) Finally, There are multiple ssa-names that are dependent on _1947. Given the
stack oriented mechanism, the first such case will push the value on the stack
to be resolved, and all the other names that depend on it will use the initial
value.  When we finally get back to evaluating it, if it DID come out
different, then all those names would again be stale, and potentially get
recalculated down the road.  

TODO: This impact could be reduced by increasing the priority of its
evaluation. Instead of waiting for evaluation all the way back to the bottom of
the stack for _1947, when a new stmt is dependent on it, we could instead move
it to the top of the stack for consideration.  We'll still be resolving
dependencies, but it will be properly evaluated sooner than later.Cycles
will have to be avoided by not re prioritizing any dependencies on statement
which have been "bumped" like this.   You have to put a stake in the ground at
some point and 

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #21 from David Binderman  ---

Two cases, depending on the text of the warning:

$ fgrep warning: mk.out | fgrep Wstack | fgrep -v "might be unbounded" | fgrep
"usage is"  | sort -rnk 6
../../trunk.year/gcc/gimple-range-infer.cc:360:1: warning: stack usage is
410496 bytes [-Wstack-usage=]
../../trunk.year/gcc/gimple-range-cache.cc:1682:1: warning: stack usage is
410496 bytes [-Wstack-usage=]
../../trunk.year/gcc/range-op.cc:2822:1: warning: stack usage is 204992 bytes
[-Wstack-usage=]
../../trunk.year/gcc/range-op.cc:2556:1: warning: stack usage is 204960 bytes
[-Wstack-usage=]
../../trunk.year/gcc/value-range.cc:2169:1: warning: stack usage is 164688
bytes [-Wstack-usage=]
../../trunk.year/gcc/range-op.cc:5085:1: warning: stack usage is 164576 bytes
[-Wstack-usage=]
../../trunk.year/gcc/gimple-range-edge.cc:117:1: warning: stack usage is 163936
bytes [-Wstack-usage=]
../../trunk.year/gcc/tree-ssa-loop-niter.cc:343:1: warning: stack usage is
123808 bytes [-Wstack-usage=]
../../trunk.year/gcc/gimple-range-fold.cc:533:1: warning: stack usage is 123424
bytes [-Wstack-usage=]
../../trunk.year/gcc/gimple-range-cache.cc:1293:1: warning: stack usage is
123312 bytes [-Wstack-usage=]
../../trunk.year/gcc/gimple-range-fold.cc:734:1: warning: stack usage is 123232
bytes [-Wstack-usage=]
../../trunk.year/gcc/gimple-range-cache.cc:1154:1: warning: stack usage is
123200 bytes [-Wstack-usage=]
../../trunk.year/gcc/range-op.cc:4851:1: warning: stack usage is 123056 bytes
[-Wstack-usage=]
$ 

and

$ fgrep warning: mk.out | fgrep Wstack | fgrep -v "might be unbounded" | fgrep
-v "usage is"  | sort -rnk 7
../../trunk.year/gcc/gimple-range-gori.cc:1465:1: warning: stack usage might be
205360 bytes [-Wstack-usage=]
../../trunk.year/gcc/range-op.cc:5135:1: warning: stack usage might be 165008
bytes [-Wstack-usage=]
../../trunk.year/gcc/gimple-range-gori.cc:604:1: warning: stack usage might be
164352 bytes [-Wstack-usage=]
../../trunk.year/gcc/gimple-range-gori.cc:743:1: warning: stack usage might be
164144 bytes [-Wstack-usage=]
../../trunk.year/gcc/gimple-range-gori.cc:1187:1: warning: stack usage might be
123280 bytes [-Wstack-usage=]
../../trunk.year/gcc/gimple-range-gori.cc:1077:1: warning: stack usage might be
123280 bytes [-Wstack-usage=]
../../trunk.year/gcc/gimple-range-fold.cc:897:1: warning: stack usage might be
123216 bytes [-Wstack-usage=]
$ 

It appears that there are some large stack sizes in various parts of gcc.

[Bug c++/101780] Missing initializers whereas structure has default initializers

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Related to PR 96868.

[Bug fortran/109701] I have a MWE where an omp reduction breaks if I add the option for GPU offloading (even if it isn't used).

[thomas.meltzer1 at gmail dot com via Gcc-bugs]

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

--- Comment #6 from tommelt  ---
Thank you.

Interestingly, I tried your suggestion:
"!$omp target teams distribute parallel do simd if(target:is_GPU)
reduction(max:max_diff) collapse(2)"

It works for gfortran v 12.2.0 

but it does not work for:
* gfortran v 11.3.0 or;
* gfortran v 10.3.0

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #20 from David Binderman  ---
(In reply to Jakub Jelinek from comment #17)
> Or just try to check for functions with largest stack usages in cc1plus?
> Doing that on the trunk gives:
> objdump -dr cc1plus | grep
> '>:\|sub.*0x.*[0-9a-f][0-9a-f][0-9a-f][0-9a-f],.*rsp' | awk
> '/>:/{I=$2}/sub.*rsp/{J=gensub(/.*(0x[0-9a-f]+),%rsp/,"\\1","1",$0);
> K=strtonum(J);printf "%d %s %s\n", K, I, $0}' | grep -v 0x |
> sort -nr
> 410440 <_ZN19infer_range_manager17register_all_usesEP9tree_node>:  275120d:
> 48 81 ec 48 43 06 00  sub$0x64348,%rsp

That's 410K on the stack. Eek !

It looks to me like the data needs to go into the heap. RAII will help
with tidyup.

> Usual Linux stack is around 8MB, but e.g. on Windows I think just 2MB.

Linux kernel has a script checkstack.pl. This might help.

I will try an experimental build of gcc with -Wstack-usage=10 and report
back.

[Bug c++/109739] New: bogus warning due to -Wmissing-field-initializers in C++20 with designated initializers on struct with empty base class

[tobias.rittweiler at contractors dot roche.com via Gcc-bugs]

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

Bug ID: 109739
   Summary: bogus warning due to -Wmissing-field-initializers in
C++20 with designated initializers on struct with
empty base class
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tobias.rittweiler at contractors dot roche.com
  Target Milestone: ---


#include 

struct Empty {};

struct S : Empty {
uint32_t Uint32;
};

void consume(const S&) {}

void test() {
S s = { .Uint32 = 42 };
consume(s);
}
>

gcc-13.1 -std=c++20 -Werror=missing-field-initializers

: In function 'void test()':
:12:26: error: missing initializer for member 'S::'
[-Werror=missing-field-initializers]
   12 | S s = { .Uint32 = 42 };
  |  ^
cc1plus: some warnings being treated as errors
Compiler returned: 1


My reading of
https://en.cppreference.com/w/cpp/language/aggregate_initialization is that
since C++17 base classes are allowed in class type to form an "aggregate" and
designated initializers are allowed since C++20.

So I would expect this example to be free of any warning.


(I am aware of the situation that the man page currently says that
`-Wmissing-field-initializers` "does not warn about designated initializers"
but that is evidently not true in the C++ frontend, as has been pointed out
before, see [1], [2].)


[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39589#c11
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868#c3

[Bug target/109733] [14 Regression] ICE in extract_insn, at recog.cc:2791 since r14-475-g508f082829af68

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Uroš Bizjak  ---
The patched compiler just happens to trigger the existing problem where:

(insn 188 416 379 18 (parallel [
(set (reg:SI 72 k4 [orig:121 _114 ] [121])
(ashift:SI (reg:SI 70 k2 [orig:112 ubound.0 ] [112])
(const_int 2 [0x2])))
(clobber (reg:CC 17 flags))
]) 811 {*ashlsi3_1}
 (nil))

gets split with a post-reload splitter a to non-existent:

(insn 429 416 379 18 (set (reg:SI 72 k4 [orig:121 _114 ] [121])
(mult:SI (reg:SI 70 k2 [orig:112 ubound.0 ] [112])
(const_int 4 [0x4]))) -1
 (nil))

Please note mask registers, which points to a post-reload splitter with too
broad predicates.

[Bug c++/109738] New: C++20 implicit conversion is used during spaceship operator resolution instead of class's operator< for classes without spaceship operator

[szhong at perforce dot com via Gcc-bugs]

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

Bug ID: 109738
   Summary: C++20 implicit conversion is used during spaceship
operator resolution instead of class's operator< for
classes without spaceship operator
   Product: gcc
   Version: 11.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: szhong at perforce dot com
  Target Milestone: ---

Using -std=c++20 -- implicit conversion is used during spaceship operator
resolution instead of class's operator< for classes without spaceship operator


testcase:
#include 
#include 
#include 
#include 

class StringWrapper {
public:
StringWrapper(const char* s)
: str_(s) {}
std::string str_;
operator const char* () const;
};

inline
StringWrapper::operator const char* () const
{
return str_.data();
}

std::ostream&
operator<<(std::ostream& os, const StringWrapper& str)
{
os << str.str_;
return os;
}

bool
operator< (const StringWrapper& lhs, const StringWrapper& rhs)
{
return lhs.str_ < rhs.str_;
}

#if defined(SPACE_SHIP)
auto operator<=>(const StringWrapper& lhs, const StringWrapper& rhs)
{
return lhs.str_ <=> rhs.str_;
}
#endif

void print_map(std::string_view comment, const
std::map, std::list >& m)
{
std::cout << comment;
// iterate using C++17 facilities
for (const auto& [key, value] : m) {
std::cout << '[';
for (const auto& i : key)
std::cout << i << ", ";
std::cout << "];";
}
std::cout << '\n';
}


int main()
{
StringWrapper a("Diane");
StringWrapper b("Harry");
StringWrapper c("Sally");
StringWrapper d("George");

std::list l1;
l1.push_back(a);
l1.push_back(c);

std::list l2;
l2.push_back(b);
l2.push_back(d);

std::map, std::list > m1;

m1.insert(m1.end(), std::map,
std::list >::value_type(l1, l2));
m1.insert(m1.end(), std::map,
std::list >::value_type(l2, l1));

print_map("m1: ", m1);

std::map, std::list > m2;

m2.insert(m2.end(), std::map,
std::list >::value_type(l2, l1));
m2.insert(m2.end(), std::map,
std::list >::value_type(l1, l2));

print_map("m2: ", m2);
}

$ g++ -std=c++20 -Wall -Wextra 20_list_compare_wrapper.cpp; ./a.out;
m1: [Harry, George, ];[Diane, Sally, ];
m2: [Diane, Sally, ];[Harry, George, ];

The problem is the std:map is no longer sorted according to StringWrapper but
sorted according const char* instead.

The debugger showed during resolution of spaceship operator, the implicit
conversion to const char* for StringWrapper is selected instead of
StringWrapper::operator<() during insertion into std::map with the key of
std::list.

This problem occurs with gcc 12.1.1 as well.


$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11.3.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-xKiWfi/gcc-11-11.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-xKiWfi/gcc-11-11.3.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.3.0 (Ubuntu 11.3.0-1ubuntu1~22.04)

system type: $ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.1 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.1 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/;
SUPPORT_URL="https://help.ubuntu.com/;
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/;
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy;
UBUNTU_CODENAME=jammy

[Bug libstdc++/109703] [12/13/14 Regression] __builtin_unreachable() reached since r13-6915-gbf78b43873b0b7

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||enrico.seiler+gccbugs@outlo
   ||ok.com

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

[Bug libstdc++/109737] [13/14] Hitting unreachable code when using std::string::assign with iterators

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Already fixed. Dup of bug 109703.

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

[Bug libstdc++/109737] New: [13/14] Hitting unreachable code when using std::string::assign with iterators

[enrico.seiler+gccbugs at outlook dot com via Gcc-bugs]

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

Bug ID: 109737
   Summary: [13/14] Hitting unreachable code when using
std::string::assign with iterators
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: enrico.seiler+gccbugs at outlook dot com
  Target Milestone: ---

The following emits "runtime error: execution reached an unreachable program
poin" when compiling with `-g -fsanitize=undefined -std=c++20`:

```

#include 
#include 
#include 

void fits_in_local_buffer()
{
std::stringstream source{"123457890123456"};
std::string str;
str.assign(std::istreambuf_iterator{source},
std::istreambuf_iterator{});
assert(str == "123457890123456");
}

void does_not_fit_in_local_buffer()
{
std::stringstream source{"1234578901234567"};
std::string str;
str.assign(std::istreambuf_iterator{source},
std::istreambuf_iterator{});
assert(str == "1234578901234567");
}

int main()
{
fits_in_local_buffer(); // OK
does_not_fit_in_local_buffer(); // Not OK
return 0;
}

```

Compiler Explorer: https://godbolt.org/z/6obr7afon

* Must be at least compiled with CPP20
* Using std::string's constructor with the iterators works.
* Unreachable was introduced with PR109299
https://github.com/gcc-mirror/gcc/commit/bf78b43873b0b7e8f9a430df38749b8b61f9c9b8
* The std::istreambuf_iterator is used as an example, but the same happens when
using, for example, a std::views::iota and using its iterators

[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds

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

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

--- Comment #44 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #43)
> works with the bounds checking code?  Does it also interact with the object
> size pass?

both array-bounds sanitizer and object size pass are updated to use this new
attribute. 
I will refine the patch a little bit before posting it in the next week.

[Bug libgomp/66005] libgomp make check time is excessive

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

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

Thomas Schwinge  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org
   Last reconfirmed|2022-01-21 00:00:00 |2023-5-4
 Status|NEW |ASSIGNED

[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #43 from Martin Uecker  ---
Yes, this is great! I am also looking forward to your patch!  It seems it works
with the bounds checking code?  Does it also interact with the object size
pass?

[Bug c++/109666] [12 Regression] Segmentation fault with std::array

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:13a269a015f888a0001af7b9ab564fadbee4a808

commit r12-9511-g13a269a015f888a0001af7b9ab564fadbee4a808
Author: Jason Merrill 
Date:   Thu May 4 10:26:25 2023 -0400

Revert "c++: DMI in template with virtual base [PR106890]"

The PR106890 patch caused PR109666; for 12.3 let's just revert it.

PR c++/109666

This reverts commit 94569d91bd4c604da755b4aae84256e7fe21196a.

[Bug c++/109666] [12 Regression] Segmentation fault with std::array

[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

 Resolution|FIXED   |---
Summary|[13/14 Regression]  |[12 Regression]
   |Segmentation fault with |Segmentation fault with
   |std::array using gcc 13 |std::array
   |since r13-6788  |
 Status|RESOLVED|ASSIGNED
   Priority|P3  |P1
Version|13.0|12.3.0
   Target Milestone|13.2|12.3

--- Comment #8 from Jason Merrill  ---
This is also broken on the 12 branch since r12-9441-g94569d91bd4c60

[Bug tree-optimization/109732] [14 regression] gcc miscompiles iterator comparison on nlohmann_json since r14-204-gf1f5cbaa3f716f

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

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

--- Comment #9 from Martin Liška  ---
I've got a C++ reduced test-case:

$ cat x.ii
template  struct is_same;
template  using enable_if_t = _Tp;
template  struct reverse_iterator {
  _Iterator current;
  typedef _Iterator iterator_type;
  reverse_iterator(iterator_type __x) : current(__x) {}
  iterator_type base() { return current; }
};
template 
bool operator==(reverse_iterator<_Iterator> __x,
reverse_iterator<_Iterator> __y) {
  return __x.base() == __y.base();
}
struct __normal_iterator {
  int _M_current;
};
template  struct __new_allocator;
template  struct allocator_traits;
template  struct allocator_traits<__new_allocator<_Tp>> {
  using const_pointer = _Tp *;
};
template  struct vector {
  typedef __normal_iterator iterator;
};
namespace {
enum value_t { null, object, array, string };
template  class = vector,
  template  class = __new_allocator>
class basic_json;
struct external_constructor {
  template <
  typename BasicJsonType, typename CompatibleStringType,
  enable_if_t::value, int> = 0>
  static void construct(BasicJsonType , CompatibleStringType) {
j.m_type = string;
  }
} to_json_s;
void to_json(basic_json<> ) { external_constructor::construct(j, to_json_s);
}
long begin_value;
long end_value = 1;
struct primitive_iterator_t {
  long m_it;
  void set_begin() { m_it = begin_value; }
  void set_end() { m_it = end_value; }
  friend bool operator==(primitive_iterator_t, primitive_iterator_t rhs) {
return rhs.m_it;
  }
};
template  struct internal_iterator {
  typename BasicJsonType::array_t::iterator array_iterator;
  primitive_iterator_t primitive_iterator;
};
template  struct iter_impl {
  using array_t = typename BasicJsonType::array_t;
  typedef typename BasicJsonType::const_pointer pointer;
  iter_impl(pointer object) : m_object(object) {
switch (m_object->m_type)
case ::object:
case array:
  m_it.array_iterator = typename array_t::iterator();
  }
  void set_begin() {
switch (m_object->m_type) {
case object:
case array:
  break;
case null:
  m_it.primitive_iterator.set_end();
  break;
default:
  m_it.primitive_iterator.set_begin();
}
  }
  template  bool operator==(IterImpl other) {
return m_it.primitive_iterator == other.m_it.primitive_iterator;
  }
  pointer m_object;
  internal_iterator m_it;
};
template  struct json_reverse_iterator : reverse_iterator
{
  json_reverse_iterator(Base it) : reverse_iterator(it) {}
};
template  class ArrayType,
  template  class AllocatorType>
struct basic_json {
  using const_pointer =
  typename allocator_traits>::const_pointer;
  using const_iterator = iter_impl;
  using const_reverse_iterator = json_reverse_iterator;
  using array_t = ArrayType;
  template  basic_json(CompatibleType) {
to_json(*this);
  }
  const_iterator cbegin() {
const_iterator result(this);
result.set_begin();
return result;
  }
  const_iterator cend() {
const_iterator result(this);
return result;
  }
  const_reverse_iterator crbegin() { return cend(); }
  const_reverse_iterator crend() { return cbegin(); }
  value_t m_type;
};
} // namespace
int seen_failures;
__attribute__((noinline)) void sne(basic_json<>::const_reverse_iterator lhs,
   basic_json<>::const_reverse_iterator rhs) {
  bool res = !(lhs == rhs);
  if (!res)
seen_failures++;
}
basic_json main_js = "";

int
main() {
  basic_json js_const(main_js);
  basic_json<>::const_reverse_iterator sit = js_const.crbegin(),
   __trans_tmp_1 = js_const.crend();
  sne(sit, __trans_tmp_1);
  return seen_failures;
}

[Bug modula2/109729] gm2 (14.0.0) does not like a CHAR type FOR loop control variable any more

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

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

Gaius Mulley  changed:

   What|Removed |Added

 CC||gaius at gcc dot gnu.org

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

Here is a proposed fix and new testsuite entry.  It introduces a new quadruple
used if the compiler needs to produce an arithmetic add rather than an add
which might be overloaded.   The FOR loop uses the arithmetic add to increment
the iterator.

[Bug analyzer/109736] New: GCC Static Analyzer evaluates `e == d + 1` to be UNKNOWN with the fact that `e == d`, e is a pointer, and d is an array

[geoffreydgr at icloud dot com via Gcc-bugs]

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

Bug ID: 109736
   Summary: GCC Static Analyzer evaluates `e == d + 1` to be
UNKNOWN with the fact that `e == d`, e is a pointer,
and d is an array
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: geoffreydgr at icloud dot com
  Target Milestone: ---

Hi, David. I found a problem that GCC Static Analyzer evaluates `e == d + 1` to
be UNKNOWN with the fact that `e == d`.  
Maybe GCC Static Analyzer should have the ability to evaluates `e == d + 1` to
be FALSE ?

See it live: https://godbolt.org/z/xKMxzvj6E

Input:
```c
void __analyzer_eval();
void __analyzer_describe();

void c()
{
int d[2] = {42,43};
int *e = d;

if (e == d)
{
__analyzer_describe(0, e);
__analyzer_describe(0, e + 1);
__analyzer_describe(0, d + 1);

__analyzer_eval(e == d + 1);
__analyzer_eval(e + 1 == d + 1);
}
}
```

Output:
```bash
: In function 'c':
:11:9: warning: svalue: ''
   11 | __analyzer_describe(0, e);
  | ^
:12:9: warning: svalue: '(+(sizetype)4)'
   12 | __analyzer_describe(0,  + 1);
  | ^~
:14:9: warning: UNKNOWN
   14 | __analyzer_eval(e ==  + 1);
  | ^~~~
:15:9: warning: TRUE
   15 | __analyzer_eval(e + 1 ==  + 1);
  | ^~~~
Compiler returned: 0

```

[Bug analyzer/109063] GCC Static Analyzer evaluates `e == + 1` to be UNKNOWN with the fact that `e == `

[geoffreydgr at icloud dot com via Gcc-bugs]

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

Geoffrey  changed:

   What|Removed |Added

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

--- Comment #1 from Geoffrey  ---
invalid case because of UB

[Bug tree-optimization/109735] [14 Regression] ICE in vectorizable_store, at tree-vect-stmts.cc:8529 since r14-322-g821ef93976e750

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

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

Martin Liška  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Last reconfirmed||2023-05-04
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Target Milestone|--- |14.0

[Bug tree-optimization/109735] New: [14 Regression] ICE in vectorizable_store, at tree-vect-stmts.cc:8529 since r14-322-g821ef93976e750

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

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

Bug ID: 109735
   Summary: [14 Regression] ICE in vectorizable_store, at
tree-vect-stmts.cc:8529 since r14-322-g821ef93976e750
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: riscv64-unknown-linux-gnu

The following is crashing:

$ ./xgcc -B.
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr83329.c
-fvect-cost-model=unlimited -Ofast -c
during GIMPLE pass: slp
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr83329.c: In
function ‘h’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr83329.c:11:6:
internal compiler error: in vectorizable_store, at tree-vect-stmts.cc:8513
   11 | void h() {
  |  ^
0x2b97b57 vectorizable_store
/home/marxin/Programming/gcc2/gcc/tree-vect-stmts.cc:8513
0x2ba28ee vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
/home/marxin/Programming/gcc2/gcc/tree-vect-stmts.cc:11595
0x2c0167f vect_schedule_slp_node
/home/marxin/Programming/gcc2/gcc/tree-vect-slp.cc:8952
0x2c0217d vect_schedule_scc
/home/marxin/Programming/gcc2/gcc/tree-vect-slp.cc:9147
0x2c0297b vect_schedule_slp(vec_info*, vec<_slp_instance*, va_heap, vl_ptr>
const&)
/home/marxin/Programming/gcc2/gcc/tree-vect-slp.cc:9287
0x2bfc2fa vect_slp_region
/home/marxin/Programming/gcc2/gcc/tree-vect-slp.cc:7496
0x2bfcb70 vect_slp_bbs
/home/marxin/Programming/gcc2/gcc/tree-vect-slp.cc:7608
0x2bfd100 vect_slp_function(function*)
/home/marxin/Programming/gcc2/gcc/tree-vect-slp.cc:7709
0x2c2055c execute
/home/marxin/Programming/gcc2/gcc/tree-vectorizer.cc:1529
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/52339] using delete ptr1->ptr2 where ptr2 destructor deletes a const ptr1 fails

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

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

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

Untested fix.

[Bug target/109734] ARM64 support for __builtin_popcountll

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

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

--- Comment #3 from Andrew Pinski  ---
Also you read the assembly incorrectly. Aarch64 gcc is producing the simd cnt
instruction to do the popcount and not the scalar instruction. Arm(32) is doing
the call. I am not 100% sure but you should try to enable neon with arm and see
if it produces it for aarch32. Anyways this bug report is a wrong in the first
place because you point to cssc feature scalar cnt instruction which is
implemented in gcc 13 already but I suspect you can't use that either.

[Bug tree-optimization/109717] -Warray-bound error with gnu++20 and fmt library

[psmith at gnu dot org via Gcc-bugs]

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

--- Comment #9 from Paul Smith  ---
> Now they're issued even when the "problem" is in a system header.

Oh interesting: I have been in the habit of including all my 3rdparty library
headers using -isystem to avoid worrying about warnings/errors in them.


Regarding this issue I understand the rock versus hard place situation.  If
there's an assert or something that can help, I can suggest it to the fmt
folks; they have been receptive to adding compiler-specific tricks in the past.
 If I can find the time I'll try to test this by editing my copy.  I still find
it strange that I can't reproduce this failure using the GDB 13.1 / fmt 9.1.0
libraries available on godbolt: it works fine there.

It would be great if this warning could be split into "this is a definite
problem" versus "this might be a problem", as some others have been, but I
understand that could be complex and a lot of work.

[Bug target/109734] ARM64 support for __builtin_popcountll

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

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

--- Comment #2 from Andrew Pinski  ---
Oh cssc feature support is only in gcc 13 and above too.

[Bug tree-optimization/109720] -Wmaybe-uninitialized triggering when I can see no path that would allow it

[psmith at gnu dot org via Gcc-bugs]

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

--- Comment #6 from Paul Smith  ---
I'm happy to provide the source for DynamicBitSet (it's basically a union of a
uint64_t and a boost::dynamic_bitset so that if you have <=64 bits you use the
uint64_t and if you have >64 bits you use boost::dynamic_bitset).  I have a
hacked-up version of the original that removes all the unnecessary methods and
also throws away some of the complexity for handling the small bitset leg of
the union, which is not used in this example.

Providing the Boost stuff is harder because, as I'm sure you're aware if you've
used Boost, it's a LOT of headers and they all include others, etc. :).  But I
can try to get the necessary headers, or Boost can be downloaded separately.

[Bug target/109734] ARM64 support for __builtin_popcountll

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

You need to enable it with -march=armv8-a+cssc .

I don't know of an arm64 core that implements cssc yet. It was added part of
armv8.7-a IIRC.

[Bug target/53929] [meta-bug] -masm=intel with global symbol

[lh_mouse at 126 dot com via Gcc-bugs]

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

--- Comment #18 from LIU Hao  ---
Would it make any sense to have GAS be more permissive about such labels,

1. unconditionally? or
2. when input is from a pipe? or
3. when a special option is in effect e.g. `--output-from-gcc`?

[Bug c/109734] New: ARM64 support for __builtin_popcountll

[rohan at garg dot io via Gcc-bugs]

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

Bug ID: 109734
   Summary: ARM64 support for __builtin_popcountll
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rohan at garg dot io
  Target Milestone: ---

Hi
I noticed that ARM32 & ARM64 has native support for popcnt [1], but gcc only
outputs the native instruction for ARM32 [2].

I was hoping that someone could add native support for ARM64 too.

[1]
https://developer.arm.com/documentation/ddi0602/2022-12/Base-Instructions/CNT--Count-bits-?lang=en
[2] https://godbolt.org/z/aG8Mx4o6W

[Bug go/98823] go testsuite and timeouts

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

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

Peter Bergner  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-05-04
 CC||bergner at gcc dot gnu.org,
   ||boger at gcc dot gnu.org

--- Comment #17 from Peter Bergner  ---
I just hit this twice yesterday (ie, infinite hang and no timeout) on our big
internal P10 development system.  Talking with Lynn Boger who is our golang
lead, she mentioned hitting this too on big systems with lots of cores.  She
had opened an upstream golang issue discussing it:

https://github.com/golang/go/issues/47246

Lynn's workaround of setting GOMAXPROCS=64 worked for me.

[Bug target/109733] [14 Regression] ICE in extract_insn, at recog.cc:2791 since r14-475-g508f082829af68

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2023-05-04
Summary|ICE in extract_insn, at |[14 Regression] ICE in
   |recog.cc:2791 since |extract_insn, at
   |r14-475-g508f082829af68 |recog.cc:2791 since
   ||r14-475-g508f082829af68
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug target/109733] New: ICE in extract_insn, at recog.cc:2791 since r14-475-g508f082829af68

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

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

Bug ID: 109733
   Summary: ICE in extract_insn, at recog.cc:2791 since
r14-475-g508f082829af68
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: ubizjak at gmail dot com
  Target Milestone: ---
  Host: x86_64-linux-gnu

I noticed the following crash:

$ cat x.f90
  use iso_c_binding
  interface
subroutine ctest_cont (a, is_cont) bind (c, name="ctest")
end subroutine
subroutine ctest_ar_cont (a, is_cont) bind (c, name="ctest")
  use iso_c_binding
  integer(C_INT), contiguous :: a(..)
  logical(C_Bool), value :: is_cont
end subroutine
  end interface
  integer(C_INT), target :: aa(10,5)
  integer(C_INT), target :: bb(10,10)
  do j = 1, 5
do i = 1, 10
end do
  end do
  call ftest (transpose (aa), is_cont=.true._c_bool) ! Implementation choice:
copy in; hence, contiguous
  call ftest (bb(2:10:2, :), is_cont=.false._c_bool)
contains
  subroutine ftest (a, is_cont)
integer(C_INT) :: a(:,:)
logical(c_bool), value, intent(in) :: is_cont
call ctest_ar_cont (a, is_cont=.true._c_bool)
  end subroutine
  subroutine ftest_ar (a, is_cont)
  end subroutine
end program

$ gfortran x.f90 -ftree-vrp -O1 -mavx512vbmi2 -m32 -march=i686 -c
x.f90:24:16:

   24 |   end subroutine
  |^
Error: unrecognizable insn:
(insn 429 416 379 18 (set (reg:SI 72 k4 [orig:121 _114 ] [121])
(mult:SI (reg:SI 70 k2 [orig:112 ubound.0 ] [112])
(const_int 4 [0x4]))) -1
 (nil))
during RTL pass: split2
x.f90:24:16: internal compiler error: in extract_insn, at recog.cc:2791
0x1f4c694 diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char
const*, __va_list_tag (*) [1], diagnostic_t)
???:0
0x1f4d2e6 internal_error(char const*, ...)
???:0
0x899ba5 fancy_abort(char const*, int, char const*)
???:0
0x76b68a _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
???:0
0x76b6a6 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
???:0
0x769bc3 extract_insn(rtx_insn*) [clone .cold]
???:0
0xef4694 extract_insn_cached(rtx_insn*)
???:0
0xbd7d24 cleanup_subreg_operands(rtx_insn*)
???:0
0xef2676 split_insn(rtx_insn*)
???:0
0xef7aa9 split_all_insns()
???:0
0xef7bb8 (anonymous namespace)::pass_split_all_insns::execute(function*)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/106484] Failure to optimize uint64_t/constant division on ARM32

[rsaxvc at gmail dot com via Gcc-bugs]

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

--- Comment #4 from rsaxvc at gmail dot com ---
Benchmarking shows the speedup to be highly variable depending on CPU core as
well as __aeabi_uldivmod() implementation, and somewhat on numerator.

The best __aeabi_uldivmod()s I've seen do use 32bit division instructions when
available, and umulh() based approach is only 2-3x faster when division
instructions are available.

When umull(32x32 with 64bit result) is available and udiv is not available or
libc doesn't use it, the umulh() based approach proposed here completes 28-38x
faster, on Cortex-M4, measured via GPIO and oscilloscope. The wide variation in
relative speed is due to variable execution time of __aeabi_uldivmod(). Similar
on ARM11.

There's a partial list of some contemporary cores have udiv here:
https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/divide-and-conquer
it does look like things are headed towards more cores having udiv available.