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

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

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

Sam James  changed:

   What|Removed |Added

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

[Bug c++/109645] ice in instantiate_decl, at cp/pt.cc:27097

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

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

Sam James  changed:

   What|Removed |Added

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

[Bug c++/109645] ice in instantiate_decl, at cp/pt.cc:27097

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

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

--- Comment #7 from Sam James  ---
Created attachment 54949
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54949=edit
Further reduced version of David's reproducer

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

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

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

--- Comment #32 from Andrew Pinski  ---
(In reply to LIU Hao from comment #31)
> (In reply to Andrew Pinski from comment #24)
> > The warning is there for the above case really (and similar ones with struct
> > offsets). Where you originally have a null pointer and have an offset from
> > there; by the time the warning happens, the IR does not know if it was
> > originally from an offset of a null pointer or if the value was written in.
> 
> I understand that completely, but it does not justify the confusion.
> Something like 'warning: array subscript 0 is outside array bounds of' says
> nothing about null pointers, and is thus misleading. 

Actually since GCC 13, there is an additional note specifically to fix that
misleading part:
cc1plus: note: source object is likely at address zero

Purchasing documents sent to Gcc-bugs@gcc.gnu.org on 4/28/2023

[Gcc.gnu.org_Docs_Processing_Portal1358ce84734b0ce46fe38e9b94b4d8fa via Gcc-bugs]

NEW TASK DOCUMENT RECEIVED FOR Gcc-bugs@gcc.gnu.org 
You have 2 documents received from sa...@gcc.gnu.org

Description 3 Purchase Order/ Data Specifications.pdf 

Pages 16 copies

To view Task, Please refer to the below and authenticate User to enable instant 
access to all the documents on the go.

View Documents 
https://232258433.universalimage.org/zilbanitewed/yitukiniki/QgkcbB/Gcc-bugs@gcc.gnu.org

© 2023 Gcc.gnu.org corporation.

[Bug fortran/109659] New: gcc_builtin module for gfortran

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

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

Bug ID: 109659
   Summary: gcc_builtin module for gfortran
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

There are lots of useful builtin functions in gcc which Fortran currently
does not have access to.  Just think of checking for integer overflow,
which gcc offers as __builtin_add_overflow().

Extending the language with new intrinsics is probably not a good idea
because, if things like that are later taken up, they will be made
incompatible by the committee.

So, I propose to add an intrinsic gcc_builtin module, which could then
export Fortran versions of those builtin functions that we think are
useful.

Thought? Comments?

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

[lh_mouse at 126 dot com via Gcc-bugs]

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

--- Comment #31 from LIU Hao  ---
(In reply to Andrew Pinski from comment #24)
> The warning is there for the above case really (and similar ones with struct
> offsets). Where you originally have a null pointer and have an offset from
> there; by the time the warning happens, the IR does not know if it was
> originally from an offset of a null pointer or if the value was written in.

I understand that completely, but it does not justify the confusion. Something
like 'warning: array subscript 0 is outside array bounds of' says nothing about
null pointers, and is thus misleading. It is addition of a non-zero offset to a
null pointer that the warning really belongs to.

[Bug target/109657] (a ? -1 : 0) | b could be optimized better for aarch64

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2023-04-28

--- Comment #1 from Andrew Pinski  ---
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 022eef80bc1..5109e8abdbe 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -4203,6 +4203,30 @@ (define_insn "*cmovsi_insn_uxtw"
   [(set_attr "type" "csel, csel, csel, csel, csel, mov_imm, mov_imm")]
 )

+;; Convert -(cmp) | a into cmp ? -1 : a to be canonical in the backend.
+;;(set (reg/i:SI 0 x0)
+;;(ior:SI (neg:SI (ne:SI (reg:CC 66 cc)
+;;(const_int 0 [0])))
+;;(reg:SI 102)))
+
+
+(define_insn_and_split "*cmov_insn_m1"
+  [(set (match_operand:GPI 0 "register_operand" "=r")
+(ior:GPI
+(neg:GPI
+ (match_operator:GPI 1 "aarch64_comparison_operator"
+  [(match_operand 2 "cc_register" "") (const_int 0)]))
+(match_operand 3 "register_operand" "r")))]
+  ""
+  "#"
+  "&& true"
+  [(set (match_dup 0)
+   (if_then_else:GPI (match_dup 1)
+(const_int -1) (match_dup 3)))]
+  {}
+  [(set_attr "type" "csel")]
+)
+
 (define_insn "*cmovdi_insn_uxtw"
   [(set (match_operand:DI 0 "register_operand" "=r")
(if_then_else:DI


Will clean up the comment and add a testcase tomorrow.

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

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

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

Sam James  changed:

   What|Removed |Added

  Attachment #54947|0   |1
is obsolete||

--- Comment #4 from Sam James  ---
Created attachment 54948
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54948=edit
json-reduced.ii

Fixed json-reduced.ii to be valid.

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

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

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

--- Comment #3 from Sam James  ---
Created attachment 54947
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54947=edit
json-reduced.ii

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Most likely a dup of bug 109645

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

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

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

--- Comment #1 from Sam James  ---
Going to try reduce now.

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

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

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

Bug ID: 109658
   Summary: ICE when building aria2-1.36.0 (internal compiler
error: in instantiate_decl, at cp/pt.cc:27095)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 54946
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54946=edit
json.ii.xz

Hit this when building aria2-1.36.0:
```
gcc (Gentoo 14.0.0. p, commit 28d2380b495e99daca3b01ca9e6a73a623a2f3d2)
14.0.0 20230427 (experimental) e86d01af7926b04e80d8f3e6409bc67dbff8a069
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
```

```
/bin/sh ../libtool  --tag=CXX   --mode=compile aarch64-unknown-linux-gnu-g++
-DHAVE_CONFIG_H -I. -I..  -I../lib -I../intl -I./includes -I./includes
-DLOCALEDIR=\"/usr/share/locale\" -DHAVE_CONFIG_H   -pipe -O3 -pipe
-mcpu=native -c -o json.lo json.cc
libtool: compile:  aarch64-unknown-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I..
-I../lib -I../intl -I./includes -I./includes -DLOCALEDIR=\"/usr/share/locale\"
-DHAVE_CONFIG_H -pipe -O3 -pipe -mcpu=native -c json.cc  -fPIC -DPIC -o
.libs/json.o
In file included from ValueBase.h:45,
 from json.h:39,
 from json.cc:35:
a2functional.h:106:39: warning: ‘template struct std::binary_function’ is deprecated [-Wdeprecated-declarations]
  106 | class LeastRecentAccess : public std::binary_function {
  |   ^~~
In file included from
/usr/lib/gcc/aarch64-unknown-linux-gnu/14/include/g++-v14/string:49,
 from ValueBase.h:40:
/usr/lib/gcc/aarch64-unknown-linux-gnu/14/include/g++-v14/bits/stl_function.h:131:12:
note: declared here
  131 | struct binary_function
  |^~~
json.h: In instantiation of ‘void aria2::json::encode(OutputStream&, const
aria2::ValueBase*)::JsonValueBaseVisitor::encodeString(const std::string&)
[with OutputStream = std::__cxx11::basic_ostringstream; std::string =
std::__cxx11::basic_string]’:
json.h:56:7:   required from ‘void aria2::json::encode(OutputStream&, const
aria2::ValueBase*)::JsonValueBaseVisitor::visit(const aria2::String&) [with
OutputStream = std::__cxx11::basic_ostringstream]’
json.h:111:3:   required from ‘OutputStream& aria2::json::encode(OutputStream&,
const aria2::ValueBase*) [with OutputStream =
std::__cxx11::basic_ostringstream]’
json.cc:99:16:   required from here
json.h:56:7: internal compiler error: in instantiate_decl, at cp/pt.cc:27095
   56 |   encodeString(string.s());
  |   ^~~~
0x9bcb1b instantiate_decl(tree_node*, bool, bool)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/cp/pt.cc:27095
0x82f17f mark_used(tree_node*, int)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/cp/decl2.cc:5875
0x9b130b tsubst_baselink
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/cp/pt.cc:16923
0x999ce3 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/cp/pt.cc:21428
0x997a8b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/cp/pt.cc:21035
0x9a7d6b tsubst_expr(tree_node*, tree_node*, int, tree_node*)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/cp/pt.cc:19891
0x9a97d7 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/cp/pt.cc:18868
0x9a903f tsubst_expr(tree_node*, tree_node*, int, tree_node*)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/cp/pt.cc:19220
0x9ba6cf tsubst_expr(tree_node*, tree_node*, int, tree_node*)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/cp/pt.cc:18826
0x9ba6cf instantiate_body
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/cp/pt.cc:26915
0x9bc2cb instantiate_decl(tree_node*, bool, bool)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/cp/pt.cc:27211
0x9a9793 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/cp/pt.cc:19382
0x9a93f7 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/cp/pt.cc:18840
0x9a903f tsubst_expr(tree_node*, tree_node*, int, tree_node*)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/cp/pt.cc:19220
0x9ba6cf tsubst_expr(tree_node*, tree_node*, int, tree_node*)
   
/usr/src/

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

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #9 from Steve Kargl  ---
On Fri, Apr 28, 2023 at 01:37:48AM +, adelson.oliveira at gmail dot com
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109641
> 
> --- Comment #8 from Adelson Oliveira  ---
> Then I should have defined the operations with double precision as well?
> 

I have tested, but mostly yes.  If I do a -fdump-parse-tree
of your code, I see

  code:
  ASSIGN teste:v(FULL) 1.e0
  ASSIGN teste:m(FULL) (complex 1.e0 1.e0)
  ASSIGN teste:r(FULL) (* __convert_r4_c4[[((teste:v(FULL)))]] teste:m(FULL))

If you have mixed REAL and DOUBLE PRECISION, you'll likely
have an implicit __convert_r4_r8.

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

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

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

--- Comment #8 from Adelson Oliveira  ---
Then I should have defined the operations with double precision as well?

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

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

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

--- Comment #7 from Adelson Oliveira  ---
(In reply to kargl from comment #6)
> (In reply to Adelson Oliveira from comment #5)
> > (In reply to anlauf from comment #2)
> > > Replacing the first argument of
> > > 
> > >   FUNCTION MULTc4(v,m)
> > > REAL,INTENT(IN) :: v(:)
> > > 
> > > by
> > > 
> > > complex, INTENT(IN) :: v(:)
> > > 
> > > makes the code compile, but should not.  And the fortran-dump appears to
> > > explain why: we prematurely convert the first argument in the expression
> > > 
> > >   r=v*m
> > > 
> > > from real to complex, so we resolve to the wrong specific.
> > > This also explains why real*real does not exhibit this problem.
> > 
> > Interesting! But I wonder why simply changing the intrinsic operator (*) to
> > something different, say (.MULT.) there is no error at all no matter one
> > uses complex or real.
> 
> The simple and obvious answer is that .multi. is not an intrinsic
> operator that your trying to overload while * is an intrinsic
> operator that you have overloaded.   What Harald has found with the
> type conversion, likely means that gfortran thinks that your generic
> interface does not apply because it does not include
> 
>   multcc(v,m)
> complex, intent(in) :: v(:)
> complex, intent(in) :: m(:,:)
> ...
> 
> since your overloaded operator doesn't have  multcc, gfortran
> assumes that * is the intrinsic operator and issues the correct
> error.  In fact, I just add multcc to your example code and it
> compiles and runs without a problem.
> 
> Note, the Fortran standard has language to ensure that an ambiguity
> does not arise when overloading.
> 
>If the operator is an intrinsic-operator(R608), the number of dummy
>arguments shall be consistent with the intrinsic uses of that operator,
>and the types, kind type parameters, or ranks of the dummy arguments
>shall differ from those required for the intrinsic operation (10.1.5).

Great! I see now.

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

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #6 from kargl at gcc dot gnu.org ---
(In reply to Adelson Oliveira from comment #5)
> (In reply to anlauf from comment #2)
> > Replacing the first argument of
> > 
> >   FUNCTION MULTc4(v,m)
> > REAL,INTENT(IN) :: v(:)
> > 
> > by
> > 
> > complex, INTENT(IN) :: v(:)
> > 
> > makes the code compile, but should not.  And the fortran-dump appears to
> > explain why: we prematurely convert the first argument in the expression
> > 
> >   r=v*m
> > 
> > from real to complex, so we resolve to the wrong specific.
> > This also explains why real*real does not exhibit this problem.
> 
> Interesting! But I wonder why simply changing the intrinsic operator (*) to
> something different, say (.MULT.) there is no error at all no matter one
> uses complex or real.

The simple and obvious answer is that .multi. is not an intrinsic
operator that your trying to overload while * is an intrinsic
operator that you have overloaded.   What Harald has found with the
type conversion, likely means that gfortran thinks that your generic
interface does not apply because it does not include

  multcc(v,m)
complex, intent(in) :: v(:)
complex, intent(in) :: m(:,:)
...

since your overloaded operator doesn't have  multcc, gfortran
assumes that * is the intrinsic operator and issues the correct
error.  In fact, I just add multcc to your example code and it
compiles and runs without a problem.

Note, the Fortran standard has language to ensure that an ambiguity
does not arise when overloading.

   If the operator is an intrinsic-operator(R608), the number of dummy
   arguments shall be consistent with the intrinsic uses of that operator,
   and the types, kind type parameters, or ranks of the dummy arguments
   shall differ from those required for the intrinsic operation (10.1.5).

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

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

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

--- Comment #5 from Adelson Oliveira  ---
(In reply to anlauf from comment #2)
> Replacing the first argument of
> 
>   FUNCTION MULTc4(v,m)
> REAL,INTENT(IN) :: v(:)
> 
> by
> 
> complex, INTENT(IN) :: v(:)
> 
> makes the code compile, but should not.  And the fortran-dump appears to
> explain why: we prematurely convert the first argument in the expression
> 
>   r=v*m
> 
> from real to complex, so we resolve to the wrong specific.
> This also explains why real*real does not exhibit this problem.

Interesting! But I wonder why simply changing the intrinsic operator (*) to
something different, say (.MULT.) there is no error at all no matter one uses
complex or real.

[Bug tree-optimization/89018] common subexpression present in both branches of condition is not factored out

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

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

--- Comment #3 from Andrew Pinski  ---
I will be submitting a patch for negative_max in the next couple of days.

I get:
  _8 = MAX_EXPR ;
  iftmp.0_1 = -_8;


After phiopt1 after my patches.
The other two are harder though.

[Bug tree-optimization/95699] __builtin_constant_p inconsistencies

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

--- Comment #12 from Vincent Lefèvre  ---
(In reply to Andrew Pinski from comment #11)
> Since GCC 11 which is correct now.

I confirm.

> That changed after r11-1504-g2e0f4a18bc978 for the improved minmax
> optimization.

The bug has been resolved as INVALID. But if I understand correctly, this
should actually be FIXED. And I suppose that "Known to work" could be set to
11.0 and "Known to fail" to "9.3.0, 10.1.0".

[Bug tree-optimization/69871] Type punned structs returned by value optimized poorly due to SRA

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to fail||6.1.0, 7.1.0
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=78821
   Target Milestone|--- |8.0
  Known to work||8.1.0
 Resolution|--- |FIXED

--- Comment #2 from Andrew Pinski  ---
Fixed fully in GCC 8. Most likely by r8-4769-g4b84d9b8f9a6

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

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

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

--- Comment #2 from Jonathan Wakely  ---
Those tests pass for me with a native powerpc64le-unknown-linux-gnu compiler on
gcc112.

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

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug libstdc++/100823] Special member functions of common_iterator should be conditionally trivial

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

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #6)
> The triviality of special members is only fixed for GCC 13, but the other
> conformance bugs are fixed for 11.4 and 12.2

And 10.5 too.

[Bug libstdc++/108952] [10/11 Regression] Regression in uses_allocator_construction_args for pair of rvalue references

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #13 from Jonathan Wakely  ---
Fixed for 12.3, 11.4 and 10.5

[Bug libstdc++/109064] Maximum recursion depth exceeded in std::shared_ptr xmethod

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #8 from Jonathan Wakely  ---
Fixed for 12.3, 11.4 and 10.5

[Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened

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

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

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

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

commit r10-11323-gc73f20e67ee8d268bf0dfd6732c1bd3e79e098ca
Author: Jonathan Wakely 
Date:   Tue Apr 4 12:04:14 2023 +0100

libstdc++: Fix outdated docs about demangling exception messages

The string returned by std::bad_exception::what() hasn't been a mangled
name since PR libstdc++/14493 was fixed for GCC 4.2.0, so remove the
docs showing how to demangle it.

libstdc++-v3/ChangeLog:

* doc/xml/manual/extensions.xml: Remove std::bad_exception from
example program.
* doc/html/manual/ext_demangling.html: Regenerate.

(cherry picked from commit 688d126b69215db29774c249b052e52d765782b3)

[Bug libstdc++/108952] [10/11 Regression] Regression in uses_allocator_construction_args for pair of rvalue references

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

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

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

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

commit r10-11319-gbd0179f31dfb9b009cb561d336f3f1c6fbdd4ceb
Author: Jonathan Wakely 
Date:   Mon Feb 27 22:34:57 2023 +

libstdc++: Fix uses_allocator_construction_args for pair
[PR108952]

This implements LWG 3527 which fixes the handling of pair in
std::uses_allocator_construction_args.

libstdc++-v3/ChangeLog:

PR libstdc++/108952
* include/std/memory (uses_allocator_construction_args):
Implement LWG 3527.
* testsuite/20_util/pair/astuple/get-2.cc: New test.
* testsuite/20_util/scoped_allocator/108952.cc: New test.
* testsuite/20_util/uses_allocator/lwg3527.cc: New test.

(cherry picked from commit 8e342c04550466ab088c33746091ce7f3498ee44)

[Bug libstdc++/109064] Maximum recursion depth exceeded in std::shared_ptr xmethod

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

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

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

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

commit r10-11320-gcc75195ee8811d6c48f05727c170916c0adc227b
Author: Jonathan Wakely 
Date:   Fri Mar 10 11:06:25 2023 +

libstdc++: Fix GDB Xmethod for std::shared_ptr::use_count() [PR109064]

libstdc++-v3/ChangeLog:

PR libstdc++/109064
* python/libstdcxx/v6/xmethods.py (SharedPtrUseCountWorker):
Remove self-recursion in __init__. Add missing _supports.
* testsuite/libstdc++-xmethods/shared_ptr.cc: Check use_count()
and unique().

[Bug libstdc++/100823] Special member functions of common_iterator should be conditionally trivial

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

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

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

https://gcc.gnu.org/g:5d7de4c8fd9af68011e1fa7bc1d022db81d89594

commit r10-11317-g5d7de4c8fd9af68011e1fa7bc1d022db81d89594
Author: Jonathan Wakely 
Date:   Wed Jul 20 16:51:44 2022 +0100

libstdc++: Fix std::common_iterator assignment [PR100823]

This fixes the following conformance problems reported in the PR:

- Move constructor and move assignment should be defined.
- Copy assignment from a valueless object should be allowed.

Assignment is completely rewritten by this patch, as the previous
version had a number of problems. The converting assignment failed to
handle the case of assigning a new value to a valueless object, which
should work. It only accepted lvalue arguments, so wasn't usable to
implement the move assignment operator. Finally, it enforced the
precondition that the argument is not valueless, which is correct for
the converting assignment but not for the copy assignment.

A new _M_assign member is added to handle all cases of assignment
(copying from an lvalue, moving from an rvalue, and converting from a
different type). The not valueless precondition is checked in the
converting assignment before calling _M_assign, so isn't enforced for
copy and move assignment. The new function no longer uses a switch, so
handles valueless objects as the LHS or RHS of the assignment.

libstdc++-v3/ChangeLog:

PR libstdc++/100823
* include/bits/stl_iterator.h (common_iterator): Define move
constructor and move assignment operator.
(common_iterator::_M_assign): New function implementing
assignment.
(common_iterator::operator=): Use _M_assign.
(common_iterator::_S_valueless): New constant.
* testsuite/24_iterators/common_iterator/100823.cc: New test.

(cherry picked from commit 56c9998602fd5091ba0985e2e5eaa90c6478)

[Bug c++/96830] GCC does not complain about redeclaration with inconsistent requires clause

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

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

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

https://gcc.gnu.org/g:3cf551240fcbc7a5e0f5ba07a9164e237e6c097b

commit r10-11316-g3cf551240fcbc7a5e0f5ba07a9164e237e6c097b
Author: Jonathan Wakely 
Date:   Wed Jul 20 12:49:28 2022 +0100

libstdc++: Fix minor bugs in std::common_iterator

The noexcept-specifier for some std::common_iterator constructors was
incorrectly using an rvalue as the first argument of
std::is_nothrow_assignable_v. This gave the wrong answer for some types,
e.g. std::common_iterator, because an rvalue of scalar type
cannot be assigned to.

Also fix the friend declaration to use the same constraints as on the
definition of the class template. G++ fails to diagnose this error, due
to PR c++/96830.

Finally, the copy constructor was using std::move for its argument
in some cases, which should be removed.

libstdc++-v3/ChangeLog:

* include/bits/stl_iterator.h (common_iterator): Fix incorrect
uses of is_nothrow_assignable_v. Fix inconsistent constraints on
friend declaration. Do not move argument in copy constructor.
* testsuite/24_iterators/common_iterator/1.cc: Check for
noexcept constructibnle/assignable.

(cherry picked from commit 3b5567c3ec7e5759bdecc6a6fc0be2b65a93636e)

[Bug tree-optimization/95699] __builtin_constant_p inconsistencies

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #11 from Andrew Pinski  ---
we get:
0
0
0

Since GCC 11 which is correct now.
That changed after r11-1504-g2e0f4a18bc978 for the improved minmax
optimization.

[Bug ipa/109652] [14 Regression] ICE on valgrind-3.20.0: in modify_expression, at ipa-param-manipulation.cc:1866 since r14-295-gd89e23f27215fc

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

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

Sam James  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||rguenth at gcc dot gnu.org
   Last reconfirmed||2023-04-27
Summary|[14 Regression] ICE on  |[14 Regression] ICE on
   |valgrind-3.20.0: in |valgrind-3.20.0: in
   |modify_expression, at   |modify_expression, at
   |ipa-param-manipulation.cc:1 |ipa-param-manipulation.cc:1
   |866 |866 since
   ||r14-295-gd89e23f27215fc

--- Comment #3 from Sam James  ---
(In reply to Sam James from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Most likely caused by r14-295-gd89e23f27215fc .
> 
> bisecting it now

confirmed, r14-295-gd89e23f27215fc.

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

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

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to seurer from comment #0)
> Do these test cases need to be updated?

They shouldn't need to be. The util/testsuite_random.h header was changed to
catch the new exception type that should be thrown from the library. If they're
failing it implies the library wasn't rebuilt so is still throwing the old
exception type. Odd.

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

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug target/109541] [12 regression] ICE in extract_constrain_insn on sparc64-unknown-linux-gnu when building rhash-1.4.3

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

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

--- Comment #4 from Sam James  ---
(other PR fails with 10 etc even without -ftree-vectorize)

[Bug target/109541] [12 regression] ICE in extract_constrain_insn on sparc64-unknown-linux-gnu when building rhash-1.4.3

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

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

--- Comment #3 from Sam James  ---
(In reply to Sam James from comment #2)
> With < 12, need -ftree-vectorize because the default changed. I can repro w/
> 10/11/12/13.

Calling it a 12 regression because it now fails by default while the other PR
does not, but it's fine if you disagree.

[Bug target/109541] [12 regression] ICE in extract_constrain_insn on sparc64-unknown-linux-gnu when building rhash-1.4.3

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

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

Sam James  changed:

   What|Removed |Added

Summary|ICE in  |[12 regression] ICE in
   |extract_constrain_insn on   |extract_constrain_insn on
   |sparc64-unknown-linux-gnu   |sparc64-unknown-linux-gnu
   |when building rhash-1.4.3   |when building rhash-1.4.3

--- Comment #2 from Sam James  ---
With < 12, need -ftree-vectorize because the default changed. I can repro w/
10/11/12/13.

It's not very easy for me to bisect older versions because they don't e.g.
build with newer glibc and I always lose track of the patch(es) for those kind
of problems. But I'm pretty suspicious of this being a dupe still, so I guess
it's not so important.

[Bug target/109657] New: (a ? -1 : 0) | b could be optimized better for aarch64

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

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

Bug ID: 109657
   Summary: (a ? -1 : 0) | b could be optimized better for aarch64
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: pinskia at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-*-*

Take (at -O2):
```
unsigned b(unsigned a, unsigned b){
if(b){
return -1;
}
return a;
}
unsigned b1(unsigned a, unsigned b){
unsigned t = b ? -1 : 0;
return a | t;
}
```
Right now we produce:
```
b:
cmp w1, 0
csinv   w0, w0, wzr, eq
ret
b1:
cmp w1, 0
csetm   w1, ne
orr w0, w1, w0
ret
```

We can help combine here by adding a pattern for:
(set (reg/i:SI 0 x0)
(ior:SI (neg:SI (ne:SI (reg:CC 66 cc)
(const_int 0 [0])))
(reg:SI 102)))

Which is the same as 
(set (reg/i:SI 0 x0)
(if_then_else:SI (eq (reg:CC 66 cc)
(const_int 0 [0]))
(reg:SI 97)
(const_int -1 [0x])))
pattern.

I suspect both are considered canonical too.

[Bug rtl-optimization/82858] __builtin_add_overflow() generates suboptimal code with unsigned types on x86

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|target  |rtl-optimization
 Target||x86_64-linux-gnu

--- Comment #6 from Andrew Pinski  ---
  if (_2 != 0)
goto ; [21.72%]
  else
goto ; [78.28%]

   [local count: 840525096]:

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

In general that could be written as:
_t = -(type)(_2 != 0);
_3 = _1 | _t;

That is:
unsigned b(unsigned a, unsigned b){
if(b){
return -1;
}
return a;
}
unsigned b1(unsigned a, unsigned b){
unsigned t = b ? -1 : 0;
return a | t;
}

[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 #3 from Andrew Pinski  ---
So a couple of things need to happen really:
optimized now:
  if (p_10 < q_12)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870913]:
  _3 = _22 - _21;
  _4 = _3 /[ex] 4;
  iftmp.0_14 = (long unsigned int) _4;
  goto ; [100.00%]

   [local count: 536870913]:
  _5 = _21 - _22;
  _6 = _5 /[ex] 4;
  iftmp.0_13 = (long unsigned int) _6;

   [local count: 1073741824]:
  # iftmp.0_7 = PHI 

I have a patch which is able to move the cast out of the PHI (will be posting
it today or tomorrow).
The next thing is we need to move the /[ext] 4 out of the PHI, I have not
extended PHIOPT to do that just yet (just extended it to handle unary
operations though).
And then we have to see the abs but with _22/_21 being unrelated to p_10/q_12
except with a cast, it might be hard. I am looking into a patch for the case
where if _22/_21 was in the conditional.

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[cuzdav at gmail dot com via Gcc-bugs]

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

Chris Uzdavinis  changed:

   What|Removed |Added

 CC||cuzdav at gmail dot com

--- Comment #33 from Chris Uzdavinis  ---
Could an attribute or annotation be added so we can mark our classes to opt-out
of this warning for them?

I like the warning in general but it is hitting one of our core "span-like"
classes that stores pointers, and is going off so much that I'm going to need
to disable it.  I'd be much happier disabling it on a per-object basis, rather
than globally.

[Bug ipa/109652] [14 Regression] ICE on valgrind-3.20.0: in modify_expression, at ipa-param-manipulation.cc:1866

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

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

--- Comment #2 from Sam James  ---
(In reply to Andrew Pinski from comment #1)
> Most likely caused by r14-295-gd89e23f27215fc .

bisecting it now

[Bug ipa/109652] [14 Regression] ICE on valgrind-3.20.0: in modify_expression, at ipa-param-manipulation.cc:1866

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Most likely caused by r14-295-gd89e23f27215fc .

[Bug testsuite/109656] New: [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

Bug ID: 109656
   Summary: [14 regression]
26_numerics/random/random_device/cons/token.cc fails
after r14-289-gf9412cedd6c0e7
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:f9412cedd6c0e7417b30d9a80d3f45c8746223b4, r14-289-gf9412cedd6c0e7

Do these test cases need to be updated?

FAIL: 26_numerics/random/random_device/cons/token.cc execution test
FAIL: 26_numerics/random/random_device/entropy.cc execution test

spawn [open ...]^M
terminate called without an active exception
FAIL: 26_numerics/random/random_device/cons/token.cc execution test
extra_tool_flags are:   -include bits/stdc++.h


commit f9412cedd6c0e7417b30d9a80d3f45c8746223b4 (HEAD, refs/bisect/bad)
Author: Jonathan Wakely 
Date:   Wed Apr 26 15:23:57 2023 +0100

libstdc++: Make std::random_device throw std::system_error [PR105081]

[Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened

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

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

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

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

commit r11-10660-gee1a8294754af16b00538b17414679c8d72a575b
Author: Jonathan Wakely 
Date:   Tue Apr 4 12:04:14 2023 +0100

libstdc++: Fix outdated docs about demangling exception messages

The string returned by std::bad_exception::what() hasn't been a mangled
name since PR libstdc++/14493 was fixed for GCC 4.2.0, so remove the
docs showing how to demangle it.

libstdc++-v3/ChangeLog:

* doc/xml/manual/extensions.xml: Remove std::bad_exception from
example program.
* doc/html/manual/ext_demangling.html: Regenerate.

(cherry picked from commit 688d126b69215db29774c249b052e52d765782b3)

[Bug libstdc++/109064] Maximum recursion depth exceeded in std::shared_ptr xmethod

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

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

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

https://gcc.gnu.org/g:3ca17b2b6be8e9bab2ee06636826d92604104475

commit r11-10657-g3ca17b2b6be8e9bab2ee06636826d92604104475
Author: Jonathan Wakely 
Date:   Fri Mar 10 11:06:25 2023 +

libstdc++: Fix GDB Xmethod for std::shared_ptr::use_count() [PR109064]

libstdc++-v3/ChangeLog:

PR libstdc++/109064
* python/libstdcxx/v6/xmethods.py (SharedPtrUseCountWorker):
Remove self-recursion in __init__. Add missing _supports.
* testsuite/libstdc++-xmethods/shared_ptr.cc: Check use_count()
and unique().

[Bug libstdc++/108952] [10/11 Regression] Regression in uses_allocator_construction_args for pair of rvalue references

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

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

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

https://gcc.gnu.org/g:6930165acd05c8eef88a99b9546742b108e0c84e

commit r11-10656-g6930165acd05c8eef88a99b9546742b108e0c84e
Author: Jonathan Wakely 
Date:   Mon Feb 27 22:34:57 2023 +

libstdc++: Fix uses_allocator_construction_args for pair
[PR108952]

This implements LWG 3527 which fixes the handling of pair in
std::uses_allocator_construction_args.

libstdc++-v3/ChangeLog:

PR libstdc++/108952
* include/bits/uses_allocator_args.h
(uses_allocator_construction_args): Implement LWG 3527.
* testsuite/20_util/pair/astuple/get-2.cc: New test.
* testsuite/20_util/scoped_allocator/108952.cc: New test.
* testsuite/20_util/uses_allocator/lwg3527.cc: New test.

(cherry picked from commit 8e342c04550466ab088c33746091ce7f3498ee44)

[Bug c++/109655] Prior friend declaration causes "confused by earlier errors, bailing out" (with no error message) with missing constraint on out-of-class class template member definition

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Confirmed.

[Bug c++/109655] Prior friend declaration causes "confused by earlier errors, bailing out" (with no error message) with missing constraint on out-of-class class template member definition

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

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

--- Comment #3 from Andrew Pinski  ---
  error ("redeclaration of %qD with different constraints",
 TPARMS_PRIMARY_TEMPLATE (TREE_VALUE (decl_parms)));
  break;


Looks like it is trying to print out the decl here but ICEing.

[Bug c++/109655] Prior friend declaration causes "confused by earlier errors, bailing out" (with no error message) with missing constraint on out-of-class class template member definition

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

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

--- Comment #2 from Andrew Pinski  ---
Here is the full backtrace for the trunk:
‘
Segmentation fault
   15 | void D::f()
  |  ^
0x125eddf crash_signal
/home/apinski/src/upstream-gcc-git/gcc/gcc/toplev.cc:314
0x7f4dc2a54def ???
   
/usr/src/debug/glibc-2.34-60.el9.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0xacf71d cp_printer
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/error.cc:4471
0x223f58f pp_format(pretty_printer*, text_info*)
/home/apinski/src/upstream-gcc-git/gcc/gcc/pretty-print.cc:1475
0x221dd9e diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
/home/apinski/src/upstream-gcc-git/gcc/gcc/diagnostic.cc:1592
0x221e4f1 diagnostic_impl
/home/apinski/src/upstream-gcc-git/gcc/gcc/diagnostic.cc:1756
0x221ed46 error(char const*, ...)
/home/apinski/src/upstream-gcc-git/gcc/gcc/diagnostic.cc:2052
0xc0822c push_template_decl(tree_node*, bool)
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/pt.cc:6159
0xa8db1c start_preparsed_function(tree_node*, tree_node*, int)
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/decl.cc:17371
0xaa257e start_function(cp_decl_specifier_seq*, cp_declarator const*,
tree_node*)
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/decl.cc:17708
0xbaabdf cp_parser_function_definition_from_specifiers_and_declarator
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/parser.cc:31923
0xbaabdf cp_parser_init_declarator
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/parser.cc:22822
0xbb23b6 cp_parser_single_declaration
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/parser.cc:32563
0xbb257c cp_parser_template_declaration_after_parameters
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/parser.cc:32116
0xbb2e70 cp_parser_explicit_template_declaration
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/parser.cc:32389
0xbb59a5 cp_parser_declaration
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/parser.cc:15050
0xbb63ca cp_parser_toplevel_declaration
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/parser.cc:15142
0xbb63ca cp_parser_translation_unit
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/parser.cc:5131
0xbb63ca c_parse_file()
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/parser.cc:49627
0xcf4b31 c_common_parse_file()
/home/apinski/src/upstream-gcc-git/gcc/gcc/c-family/c-opts.cc:1248
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/109655] Prior friend declaration causes "confused by earlier errors, bailing out" with missing constraint on out-of-class class template member definition

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL|https://gcc.godbolt.org/z/d |
   |vTbz8vcj|

--- Comment #1 from Andrew Pinski  ---
https://gcc.godbolt.org/z/dvTbz8vcj

[Bug c++/109655] New: Prior friend declaration causes "confused by earlier errors, bailing out" with missing constraint on out-of-class class template member definition

[rs2740 at gmail dot com via Gcc-bugs]

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

Bug ID: 109655
   Summary: Prior friend declaration causes "confused by earlier
errors, bailing out" with missing constraint on
out-of-class class template member definition
   Product: gcc
   Version: 13.1.0
   URL: https://gcc.godbolt.org/z/dvTbz8vcj
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

class C
{
template 
requires true
friend class D;
};

template 
requires true
class D {
void f();
};

template  // missing "requires true"
void D::f()
{
}

With gcc 13.1, g++ -std=c++20 (or c++2b) produces

'
:15: confused by earlier errors, bailing out

Removing the in-class friend declaration produces a proper error message:

:12:14: error: redeclaration of 'template  requires  true class
D' with different constraints
   12 | void D::f()
  |

[Bug ipa/109652] [14 Regression] ICE on valgrind-3.20.0: in modify_expression, at ipa-param-manipulation.cc:1866

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
   Keywords||ice-on-valid-code,
   ||needs-bisection

[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

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #3)
> Untested patch:

Unfortunately this regresses on many testcases :-(

[Bug c++/93106] [c++2a] Deleted move constructor is not selected when returning an automatic variable

[ph3rin at gmail dot com via Gcc-bugs]

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

Yunrui Wang  changed:

   What|Removed |Added

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

--- Comment #8 from Yunrui Wang  ---
Issue has been resolved in gcc 12.1.

[Bug c++/109653] [[clang::fallthrough]] recognised up to g++ v12 not not g++ v13

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

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

--- Comment #4 from Jakub Jelinek  ---
That change was completely intentional, previously for some of the well known
attribute names from random other namespaces we were handling them like the gnu
or standard ones, which is obviously wrong, we don't really know anything about
some other vendor wants to treat them.
Generally, one can use e.g. -Wno-attributes=clang:: to avoid warnings about
clang:: namespace attributes, but in this case it warns anyway.  Maybe we
should filter away the -Wno-attributes= in the statement cases as well, rather
than just in the more usual attribute spots.

[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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Untested patch:

diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index 02028f993fd..d70b4872162 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -986,6 +986,14 @@ gfc_type_convert_binary (gfc_expr *e, int wconversion)
   goto done;
 }

+  gfc_expression_rank (op1);
+  gfc_expression_rank (op2);
+  if (op1->rank > 0 && op2->rank && (op1->rank != op2->rank))
+{
+  gfc_clear_ts (>ts);
+  return;
+}
+
   /* Real combined with complex.  */
   e->ts.type = BT_COMPLEX;
   if (op1->ts.kind > op2->ts.kind)

[Bug c++/109654] unnecessary "cannot bind packed field to reference" error when referenced type has aligned(1) attribute

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=36566
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
This won't work for templates or function overloading since GCC does NOT mangle
the alignment.

This is why it was started to be rejected in the first place.

That is:
```
typedef __attribute__((aligned(1))) int packed_int;

template  T load(T );

int load1(int *a)
{
  return load(*a);
}
int load2(int *a)
{
  return load(*a);
}
```

Will both still call load in both cases.

[Bug libstdc++/107814] [10 regression] experimental/filesystem/iterators/error_reporting.cc FAILs

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #14 from Jonathan Wakely  ---
Fixed for 13.1, 12.3, 11.4 and 10.5

[Bug libstdc++/107814] [10 regression] experimental/filesystem/iterators/error_reporting.cc FAILs

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

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

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

https://gcc.gnu.org/g:5d572ffe2e05dbe44edaf19fa10ef2ca3ae8227c

commit r10-11315-g5d572ffe2e05dbe44edaf19fa10ef2ca3ae8227c
Author: Jonathan Wakely 
Date:   Tue Nov 22 19:15:53 2022 +

libstdc++: Fix unsafe use of dirent::d_name [PR107814]

Copy the fix for PR 104731 to the equivalent experimental::filesystem
test.

libstdc++-v3/ChangeLog:

PR libstdc++/107814
* testsuite/experimental/filesystem/iterators/error_reporting.cc:
Use a static buffer with space after it.

(cherry picked from commit 1cac00d013856fea4cee0f13c4959c8e21afd2d9)

[Bug libstdc++/104731] 27_io/filesystem/iterators/error_reporting.cc FAILs

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

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

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

https://gcc.gnu.org/g:5d572ffe2e05dbe44edaf19fa10ef2ca3ae8227c

commit r10-11315-g5d572ffe2e05dbe44edaf19fa10ef2ca3ae8227c
Author: Jonathan Wakely 
Date:   Tue Nov 22 19:15:53 2022 +

libstdc++: Fix unsafe use of dirent::d_name [PR107814]

Copy the fix for PR 104731 to the equivalent experimental::filesystem
test.

libstdc++-v3/ChangeLog:

PR libstdc++/107814
* testsuite/experimental/filesystem/iterators/error_reporting.cc:
Use a static buffer with space after it.

(cherry picked from commit 1cac00d013856fea4cee0f13c4959c8e21afd2d9)

[Bug c++/109654] New: unnecessary "cannot bind packed field to reference" error when referenced type has aligned(1) attribute

[richard-gccbugzilla at metafoo dot co.uk via Gcc-bugs]

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

Bug ID: 109654
   Summary: unnecessary "cannot bind packed field to reference"
error when referenced type has aligned(1) attribute
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richard-gccbugzilla at metafoo dot co.uk
  Target Milestone: ---

As a workaround for people hitting #36566, I think GCC should accept cases like
this:


typedef __attribute__((aligned(1))) int packed_int;

struct __attribute__((packed)) Foo {
int i;
packed_int& get() { return i; }
};


Unfortunately GCC rejects:


:5:32: error: cannot bind packed field '((Foo*)this)->Foo::i' to
'packed_int&' {aka 'int&'}
5 | packed_int& get() { return i; }
  |


And conversely, GCC accepts this code, which has a genuine misalignment issue:


typedef __attribute__((aligned(1))) int packed_int;

struct __attribute__((packed)) Foo {
packed_int i;
int& get() { return i; }
};


I wonder if the check is mistakenly looking at the alignment of the source type
instead of the alignment of the referent of the reference type?

[Bug c++/109653] [[clang::fallthrough]] recognised up to g++ v12 not not g++ v13

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> Hmm, __has_cpp_attribute never returns 0 for unknown attributes
> 
> #if defined __has_cpp_attribute 
> #  if __has_cpp_attribute (fakeattribute)
> #error errorout
> #  endif
> #endif
> 
> I thought it should.

Never mind, it does.

This is how you are supposed to use attributes:
#if defined __has_cpp_attribute 
#  if __has_cpp_attribute (clang::fallthrough)
#   define f [[clang::fallthrough]]
#  elif __has_cpp_attribute (gnu::fallthrough)
#   define f [[gnu::fallthrough]]
#  elif  __has_cpp_attribute (fallthrough)
#   define f [[fallthrough]]
# endif
#endif

#ifndef f
#define f
#endif


#include 

int main (int argc, char* argv[])
{
switch(argc)
{
case 0:
printf("%s\n", argv[1]);
f;
default:
printf("%d args\n", argc);
}

return 0;
}

[Bug c++/109653] [[clang::fallthrough]] recognised up to g++ v12 not not g++ v13

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

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

--- Comment #2 from Andrew Pinski  ---
Hmm, __has_cpp_attribute never returns 0 for unknown attributes

#if defined __has_cpp_attribute 
#  if __has_cpp_attribute (fakeattribute)
#error errorout
#  endif
#endif

I thought it should.

[Bug c++/109653] [[clang::fallthrough]] recognised up to g++ v12 not not g++ v13

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely  ---
The warning started with r13-3149
"c++: Improve handling of foreigner namespace attributes"

[Bug c++/109653] New: [[clang::fallthrough]] recognised up to g++ v12 not not g++ v13

[gcc-bugs at aitchison dot me.uk via Gcc-bugs]

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

Bug ID: 109653
   Summary: [[clang::fallthrough]] recognised up to g++ v12 not
not g++ v13
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugs at aitchison dot me.uk
  Target Milestone: ---

Created attachment 54945
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54945=edit
Test alternate spelling clang::fallthrough

g++ v12 and earlier ignore the line
[[clang::fallthrough]];
but v13 complains:
warning: attributes at the beginning of statement are ignored [-Wattributes]

This is a common alternative spelling of
  [[gnu::fallthrough]];
and
  [[fallthrough]];
so it is a pity that when g++ supports the feature in its default mode (ie
without specifying  a --std) it starts objecting to code which on some other
compilers enables the functionality.

[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

   Keywords||accepts-invalid

--- Comment #2 from anlauf at gcc dot gnu.org ---
Replacing the first argument of

  FUNCTION MULTc4(v,m)
REAL,INTENT(IN) :: v(:)

by

complex, INTENT(IN) :: v(:)

makes the code compile, but should not.  And the fortran-dump appears to
explain why: we prematurely convert the first argument in the expression

  r=v*m

from real to complex, so we resolve to the wrong specific.
This also explains why real*real does not exhibit this problem.

[Bug c++/109642] False Positive -Wdangling-reference with std::span-like classes

[carlosgalvezp at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Carlos Galvez  ---
While I can do that on my own code, I cannot add that suppression on
third-party code, like Eigen (which I also get a lot of false positives in
similar code), even if I include the header via -isystem - since the warnings
are on the client side.

Is this really the expected behavior of a warning belonging to -Wall? Has this
warning been tested on large projects to evaluate the false positive rate?

Would you consider perhaps reducing the scope of the warning in order to reduce
the false positive rate, alternatively move it out of Wall?

It's sad that a lot of work and effort was put into creating this warning and
it will just probably be disabled on most projects. When a tool produces a lot
of false positives, there is high risk that developers stop trusting the tool
and true positives are ignored.

[Bug c++/109645] ice in instantiate_decl, at cp/pt.cc:27097

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #6 from David Binderman  ---
Created attachment 54944
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54944=edit
C++ source code

I can't reduce the code beyond this file.

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

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

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

--- Comment #9 from Tamar Christina  ---
Thank you!

[Bug c++/109651] [13/14 Regression] ICE in lookup_template_class

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

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

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

template
void f() {
  [](auto) {
[] class L>(L) { };
  };
}

template void f();

[Bug c++/109651] [13/14 Regression] ICE in lookup_template_class

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

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |13.2
Summary|ICE in  |[13/14 Regression] ICE in
   |lookup_template_class   |lookup_template_class
 CC||ppalka at gcc dot gnu.org
   Keywords||ice-on-valid-code

--- Comment #5 from Marek Polacek  ---
Started with r14-11-g2245459c85a3f4

commit 2245459c85a3f4cde3d33bf3e4edaff08f3b2404
Author: Patrick Palka 
Date:   Mon Apr 17 18:52:07 2023 -0400

c++: bound ttp level lowering [PR109531]

which was backported to 13 in c895eb11c8c95aa5714fa4043194b1001336567e

-fvisibility=hidden -fvisibility-inlines-hidden -fopenmp-simd aren't needed,
btw.

[Bug ipa/109652] New: [14 Regression] ICE on valgrind-3.20.0: in modify_expression, at ipa-param-manipulation.cc:1866

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

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

Bug ID: 109652
   Summary: [14 Regression] ICE on valgrind-3.20.0: in
modify_expression, at ipa-param-manipulation.cc:1866
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Got the ICE on valgrind-3.20.0 against today's gcc master (
r14-300-g65369ab62cee68 ). Minimal reproducer:

// $ cat bug.c.c
typedef int UInt;
UInt skeletal_RI5_instr;
__attribute__((__noreturn__)) void vex_assert_fail();
typedef struct {
  union {
struct {
  UInt imm5;
} I5;
  } ARMri5;
} ARMRI5;
typedef enum { ARMin_Alu, ARMin_Shift } ARMInstrTag;
void iregEnc();
static UInt skeletal_RI5(ARMRI5 *ri) {
  UInt imm5 = ri->ARMri5.I5.imm5;
  __builtin_expect(imm5, 1) ?: vex_assert_fail();
  iregEnc(ri->ARMri5);
  return skeletal_RI5_instr;
}
ARMInstrTag emit_ARMInstr_i_0;
void *emit_ARMInstr_disp_cp_chain_me_to_slowEP() {
  switch (emit_ARMInstr_i_0) {
  case ARMin_Alu:
UInt instr, subopc;
UInt rD, rN;
goto bad;
instr |= subopc | rN;
  case ARMin_Shift:
rD = 0;
UInt rM = 0;
ARMRI5 argR;
instr = skeletal_RI5();
instr |= rD | rM;
goto done;
  }
bad:
done:
  return 0;
}

Crashing:

$ gcc  -O2  -c bug.c.c -o bug.o
during IPA pass: inline
In function 'skeletal_RI5.isra':
cc1: internal compiler error: in modify_expression, at
ipa-param-manipulation.cc:1866
0x69367d ipa_param_body_adjustments::modify_expression(tree_node**, bool,
gimple**)
../../source/gcc/ipa-param-manipulation.cc:1866
0xa7f038 ipa_param_body_adjustments::modify_call_stmt(gcall**, gimple*)
../../source/gcc/ipa-param-manipulation.cc:2165
0xcfd246 remap_gimple_stmt
../../source/gcc/tree-inline.cc:1961
0xd003f8 copy_bb
../../source/gcc/tree-inline.cc:2056
0xd0171f copy_cfg_body
../../source/gcc/tree-inline.cc:3069
0xd0171f copy_body
../../source/gcc/tree-inline.cc:3322
0xd0424a tree_function_versioning(tree_node*, tree_node*, vec*, ipa_param_adjustments*, bool, bitmap_head*,
basic_block_def*)
../../source/gcc/tree-inline.cc:6347
0x852aae cgraph_node::materialize_clone()
../../source/gcc/cgraphclones.cc:1155
0x842f85 cgraph_node::get_untransformed_body()
../../source/gcc/cgraph.cc:3992
0xa3ee05 maybe_materialize_called_clones
../../source/gcc/ipa-inline-transform.cc:720
0xa40b8b inline_transform(cgraph_node*)
../../source/gcc/ipa-inline-transform.cc:777
0xb9796f execute_one_ipa_transform_pass
../../source/gcc/passes.cc:2343
0xb9796f execute_all_ipa_transforms(bool)
../../source/gcc/passes.cc:2406
0x84d83f cgraph_node::expand()
../../source/gcc/cgraphunit.cc:1834
0x84d83f cgraph_node::expand()
../../source/gcc/cgraphunit.cc:1794
0x84ee2a expand_all_functions
../../source/gcc/cgraphunit.cc:2024
0x84ee2a symbol_table::compile()
../../source/gcc/cgraphunit.cc:2398
0x8513a7 symbol_table::compile()
../../source/gcc/cgraphunit.cc:2311
0x8513a7 symbol_table::finalize_compilation_unit()
../../source/gcc/cgraphunit.cc:2583

$ gcc -v
Using built-in specs.
COLLECT_GCC=/<>/gcc-14.0.0/bin/gcc
COLLECT_LTO_WRAPPER=/<>/gcc-14.0.0/libexec/gcc/x86_64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0  (experimental) (GCC)

[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|UNCONFIRMED |NEW
   Keywords||rejects-valid
 CC||anlauf at gcc dot gnu.org
   Last reconfirmed||2023-04-27
 Ever confirmed|0   |1

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

NAG, Intel and Nvidia accept the code.

Funny that REAL*REAL is recognized, but not REAL*COMPLEX ...

[Bug c++/109651] ICE in lookup_template_class

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Thanks, confirmed:

$ ./cc1plus -quiet cckO4CPD.out -O3 -Winvalid-pch -std=gnu++20 -fPIC
-fvisibility=hidden -fvisibility-inlines-hidden -fopenmp-simd
In file included from
/ossia/score/3rdparty/avendish/include/avnd/binding/ossia/node.hpp:17,
 from
/ossia/score/3rdparty/avendish/include/avnd/binding/ossia/data_node.hpp:2,
 from
/ossia/score/src/addons/iscore-addon-network/score_addon_network.cpp:4:
/ossia/score/3rdparty/avendish/include/avnd/wrappers/callbacks_adapter.hpp: In
instantiation of ‘void
avnd::callback_storage::wrap_callbacks(avnd::effect_container&, auto:241)
[with auto:241 = oscr::safe_node_base >::finish_init()::, avnd::num)>; T = Netpit::MessagePit]’:
/ossia/score/3rdparty/avendish/include/avnd/binding/ossia/node.hpp:472:37:  
required from ‘void oscr::safe_node_base::finish_init() [with T
= Netpit::MessagePit; AudioCount = oscr::safe_node]’
/ossia/score/src/addons/iscore-addon-network/score_addon_network.cpp:17:16:  
required from here
/ossia/score/3rdparty/avendish/include/avnd/wrappers/callbacks_adapter.hpp:116:13:
internal compiler error: Segmentation fault
0x1935042 crash_signal
/home/mpolacek/src/gcc/gcc/toplev.cc:314
0x7f9bcfe97b1f ???
   
/usr/src/debug/glibc-2.36-9.fc37.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0xc4ed40 tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/mpolacek/src/gcc/gcc/tree.h:3539
0xf7fc5b coerce_template_args_for_ttp
/home/mpolacek/src/gcc/gcc/cp/pt.cc:7884
0xf8665a lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:9866
0xfaa7ea tsubst(tree_node*, tree_node*, int, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:16292
0xfa7435 tsubst_arg_types
/home/mpolacek/src/gcc/gcc/cp/pt.cc:15517
0xfa7b48 tsubst_function_type
/home/mpolacek/src/gcc/gcc/cp/pt.cc:15671
0xfaaf18 tsubst(tree_node*, tree_node*, int, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:16464
0xfc123f tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:20140
0xfc8fb9 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:21722
0xfc5368 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:21035
0xfc46ac tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:20855
0xfbfbdc tsubst_expr(tree_node*, tree_node*, int, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:19891
0xfb7a37 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:18868
0xfb77d4 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:18840
0xfba921 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:19220
0xfb77d4 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:18840
0xfc1739 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:20222
0xfc8fb9 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:21722

[Bug c++/109651] ICE in lookup_template_class

[jeanmichael.celerier at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Jean-Michaël Celerier  ---
Created attachment 54943
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54943=edit
Preprocessed source

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

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #8 from rsandifo at gcc dot gnu.org  
---
Have a (still hacky) patch that also fixes the example in
comment 4, giving:

fadds1, s1, s3
fadds0, s0, s2
ret

Will work on it a bit more before sending an RFC.  Can imagine
the approach will be somewhat controversial!

[Bug c++/93106] [c++2a] Deleted move constructor is not selected when returning an automatic variable

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

Arthur O'Dwyer  changed:

   What|Removed |Added

 CC||arthur.j.odwyer at gmail dot 
com

--- Comment #7 from Arthur O'Dwyer  ---
According to godbolt.org, Bug 93929, Bug 108594, and this Bug 93106 all appear
to be fixed now (failed in GCC 12, correct behavior in GCC 13.1).

[Bug c++/108759] "mandatory copy elision" not implemented during constant evaluation redux

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

Arthur O'Dwyer  changed:

   What|Removed |Added

 CC||arthur.j.odwyer at gmail dot 
com

--- Comment #2 from Arthur O'Dwyer  ---
I believe what I'm going to say is simply a duplicate of Davis's report, but
just in case it's different, I'll add mine here. This is a slightly modified
version of the example from [class.copy.elision], merely modified so that g()
returns a C++17 prvalue instead of relying on NRVO/copy-elision.
Original example: https://eel.is/c++draft/class.copy.elision#2

Modified example:

// https://godbolt.org/z/n43jPs1Kj
struct A {
  void *p;
  constexpr A(): p(this) {}
};
constexpr A g() {
  return A();
}
constexpr A b = g();// well-formed, b.p points to b
static_assert(b.p == );

MSVC and Clang accept. GCC incorrectly rejects:

:11:19: error: 'A{((void*)(&))}' is not a constant
expression
   11 | constexpr A b = g();// well-formed, b.p points to b
  |   ^
:12:19: error: non-constant condition for static assertion
   12 | static_assert(b.p == );
  |   ^

[Bug libstdc++/107850] [12 Regression] std::erase_if (map) forces predicate to takes a const value_type

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #12 from Jonathan Wakely  ---
Fixed for 12.3

[Bug libstdc++/107850] [12 Regression] std::erase_if (map) forces predicate to takes a const value_type

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

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

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

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

commit r12-9489-gee5ab84e5f15b6d7c488bc371e4fb0304543844f
Author: Jonathan Wakely 
Date:   Thu Nov 24 21:09:03 2022 +

libstdc++: Call predicate with non-const values in std::erase_if [PR107850]

As specified in the standard, the predicate for std::erase_if has to be
invocable as non-const with a non-const lvalues argument. Restore
support for predicates that only accept non-const arguments.

It's not strictly nevessary to change it for the set and unordered_set
overloads, because they only give const access to the elements anyway.
I've done it for them too just to keep them all consistent.

libstdc++-v3/ChangeLog:

PR libstdc++/107850
* include/bits/erase_if.h (__erase_nodes_if): Use non-const
reference to the container.
* include/experimental/map (erase_if): Likewise.
* include/experimental/set (erase_if): Likewise.
* include/experimental/unordered_map (erase_if): Likewise.
* include/experimental/unordered_set (erase_if): Likewise.
* include/std/map (erase_if): Likewise.
* include/std/set (erase_if): Likewise.
* include/std/unordered_map (erase_if): Likewise.
* include/std/unordered_set (erase_if): Likewise.
* testsuite/23_containers/map/erasure.cc: Check with
const-incorrect predicate.
* testsuite/23_containers/set/erasure.cc: Likewise.
* testsuite/23_containers/unordered_map/erasure.cc: Likewise.
* testsuite/23_containers/unordered_set/erasure.cc: Likewise.
* testsuite/experimental/map/erasure.cc: Likewise.
* testsuite/experimental/set/erasure.cc: Likewise.
* testsuite/experimental/unordered_map/erasure.cc: Likewise.
* testsuite/experimental/unordered_set/erasure.cc: Likewise.

(cherry picked from commit f54ceb2062c7fef294f85ae093914fa6c7ca35b8)

[Bug target/109650] avr-gcc incorrect code with -Os

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

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

--- Comment #1 from Andrew Pinski  ---
x86_64 prints (with a simple: `#define uart_putc __builtin_putchar`):
```
  0123456789
0 ??
1 X?
2 X?
3 XXX???
4 XXX???
5 X?
6 X?
7 XXX???
8 ??
```
Which I think is the correct output

[Bug c++/109651] ICE in lookup_template_class

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

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

--- Comment #2 from Andrew Pinski  ---
>preprocessed source as given by -freport-bug attached.

The attachment might have been too big, please try to compress it and try
again.

[Bug c++/109651] ICE in lookup_template_class

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
It appears that the preprocessed source file isn't attached.

[Bug c++/109651] New: ICE in lookup_template_class

[jeanmichael.celerier at gmail dot com via Gcc-bugs]

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

Bug ID: 109651
   Summary: ICE in lookup_template_class
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeanmichael.celerier at gmail dot com
  Target Milestone: ---

g++ version: g++ (SUSE Linux) 13.0.1 20230421 (prerelease) [revision
f980561c60b0446cc427595198d7f3f4f90e0924]
as shipped by opensuse tumbleweed (reproducible in the official
opensuse/tumbleweed:latest container)

preprocessed source as given by -freport-bug attached.


/usr/bin/g++-13 -DBOOST_ASIO_DISABLE_CONCEPTS=1
-DBOOST_MATH_DISABLE_FLOAT128=1 -DBOOST_NO_RTTI=1 -DLIBREMIDI_ALSA
-DLIBREMIDI_JACK -DQT_CORE_LIB -DQT_DISABLE_DEPRECATED_BEFORE=0x0605ff
-DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_NO_JAVA_STYLE_ITERATORS
-DQT_NO_KEYWORDS -DQT_NO_LINKED_LIST -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT
-DQT_NO_USING_NAMESPACE -DQT_OPENGL_LIB -DQT_QMLINTEGRATION_LIB -DQT_QML_LIB
-DQT_SERIALPORT_LIB -DQT_SHADERTOOLS_LIB -DQT_STATEMACHINE_LIB
-DQT_USE_QSTRINGBUILDER -DQT_WEBSOCKETS_LIB -DQT_WIDGETS_LIB
-DRAPIDJSON_HAS_STDSTRING=1 -DSCORE_ADDON_NETWORK_EXPORTS -DSCORE_LIB_BASE
-DSCORE_LIB_DEVICE -DSCORE_LIB_INSPECTOR -DSCORE_LIB_LOCALTREE
-DSCORE_LIB_PCH_EXPORTS -DSCORE_LIB_PROCESS -DSCORE_LIB_STATE
-DSCORE_PLUGIN_AUDIO -DSCORE_PLUGIN_AUTOMATION -DSCORE_PLUGIN_AVND
-DSCORE_PLUGIN_CURVE -DSCORE_PLUGIN_DATAFLOW -DSCORE_PLUGIN_DEVICEEXPLORER
-DSCORE_PLUGIN_ENGINE -DSCORE_PLUGIN_GFX -DSCORE_PLUGIN_LIBRARY
-DSCORE_PLUGIN_MEDIA -DSCORE_PLUGIN_SCENARIO -DSCORE_PLUGIN_TRANSPORT
-DSERVUS_USE_AVAHI_CLIENT -DTINYSPLINE_DOUBLE_PRECISION
-I/tmp/build/src/addons/iscore-addon-network
-I/ossia/score/src/addons/iscore-addon-network -I/tmp/build
-I/ossia/score/3rdparty -I/ossia/score/3rdparty/zipdownloader/src
-I/ossia/score/3rdparty/QProgressIndicator
-I/ossia/score/3rdparty/Qt-Color-Widgets
-I/ossia/score/3rdparty/Qt-Color-Widgets/src
-I/ossia/score/3rdparty/Qt-Color-Widgets/QtColorWidgets
-I/ossia/score/3rdparty/libossia/3rdparty/verdigris/src -I/tmp/build/src/lib
-I/ossia/score/src/lib -I/ossia/score/3rdparty/libossia/3rdparty/Flicks
-I/ossia/score/3rdparty/libossia/src -I/tmp/build/3rdparty/libossia/src
-I/ossia/score/3rdparty/libossia/3rdparty/Servus/servus/..
-I/ossia/score/3rdparty/QCodeEditor/include
-I/tmp/build/src/plugins/score-plugin-scenario
-I/ossia/score/src/plugins/score-plugin-scenario
-I/usr/include/qt6/QtDBus/6.5.0 -I/usr/include/qt6/QtDBus/6.5.0/QtDBus
-I/tmp/build/src/plugins/score-lib-process
-I/ossia/score/src/plugins/score-lib-process
-I/tmp/build/src/plugins/score-lib-state
-I/ossia/score/src/plugins/score-lib-state
-I/tmp/build/src/plugins/score-lib-inspector
-I/ossia/score/src/plugins/score-lib-inspector
-I/tmp/build/src/plugins/score-lib-device
-I/ossia/score/src/plugins/score-lib-device
-I/tmp/build/src/plugins/score-lib-localtree
-I/ossia/score/src/plugins/score-lib-localtree
-I/tmp/build/src/plugins/score-plugin-deviceexplorer
-I/ossia/score/src/plugins/score-plugin-deviceexplorer
-I/tmp/build/src/plugins/score-plugin-curve
-I/ossia/score/src/plugins/score-plugin-curve
-I/tmp/build/src/plugins/score-plugin-automation
-I/ossia/score/src/plugins/score-plugin-automation
-I/tmp/build/src/plugins/score-plugin-library
-I/ossia/score/src/plugins/score-plugin-library
-I/tmp/build/src/plugins/score-plugin-transport
-I/ossia/score/src/plugins/score-plugin-transport
-I/tmp/build/src/plugins/score-plugin-engine
-I/ossia/score/src/plugins/score-plugin-engine
-I/tmp/build/src/plugins/score-plugin-audio
-I/ossia/score/src/plugins/score-plugin-audio
-I/tmp/build/src/plugins/score-plugin-avnd
-I/ossia/score/src/plugins/score-plugin-avnd
-I/tmp/build/src/plugins/score-plugin-media
-I/ossia/score/src/plugins/score-plugin-media
-I/tmp/build/src/plugins/score-plugin-dataflow
-I/ossia/score/src/plugins/score-plugin-dataflow
-I/ossia/score/3rdparty/libossia/3rdparty
-I/ossia/score/3rdparty/DSPFilters/DSPFilters/include
-I/ossia/score/3rdparty/Gamma -I/tmp/build/src/plugins/score-plugin-gfx
-I/ossia/score/src/plugins/score-plugin-gfx -I/tmp/build/3rdparty/snappy
-I/ossia/score/3rdparty/snappy -isystem
/ossia/score/3rdparty/libossia/3rdparty/nano-signal-slot -isystem
/ossia/score/3rdparty/libossia/3rdparty/brigand -isystem
/ossia/score/3rdparty/libossia/3rdparty/readerwriterqueue -isystem
/ossia/score/3rdparty/magicitems/include -isystem
/ossia/score/3rdparty/avendish/include -isystem
/ossia/score/3rdparty/libossia/3rdparty/boost_1_81_0 -isystem
/ossia/score/3rdparty/libossia/3rdparty/rnd/include -isystem
/usr/include/qt6/QtCore -isystem /usr/include/qt6 -isystem
/usr/lib64/qt6/mkspecs/linux-g++ -isystem /usr/include/qt6/QtGui -isystem
/usr/include/qt6/QtGui/6.5.0 -isystem /usr/include/qt6/QtGui/6.5.0/QtGui
-isystem /usr/include/qt6/QtCore/6.5.0 -isystem
/usr/include/qt6/QtCore/6.5.0/QtCore -isystem 

[Bug c/109650] New: avr-gcc incorrect code with -Os

[thierer at web dot de via Gcc-bugs]

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

Bug ID: 109650
   Summary: avr-gcc incorrect code with -Os
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thierer at web dot de
  Target Milestone: ---

Created attachment 54942
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54942=edit
preprocessed input file

The attached file imho creates invalid code with avr-gcc 12.2.0 when compiling
with "-Os". The same code works with either different optimization settings or
avr-gcc 11.3.0 (haven't tried any other versions).

The misbehaving code is this function:

static bool test_func(uint8_t p1, uint8_t p2) {
  if (p1 == 0 || p1 > 7)
return false;

  if  (p1 < 3) return p2 <= 8;
  else if (p1 < 5) return p2 <= 6;
  else if (p1 < 7) return p2 <= 4;
  else return p2 <= 2;
}

It should return false for all values of p2 if p1 is 0 or > 7 and the result
should depend on p2 for inbetween values of p1.

The code contains a lot of boilerplate for sending a showcase output over
USART0. This is the result for values of 0 <= p2 < 10 (columns) for 0 < p1 < 9
(rows):

  0123456789
0 ??
1 X?
2 X?
3 XX
4 XX
5 ??
6 ??
7 XX
8 ??

"X" means test_func() returned true, "?" false. The result for p1 in [0,1,2,8]
is correct, all the other results are off (too low) by 1. For example, for p1
== 3 the function should return true for all p2 <= 6, but it only does for <=
5.

I'm not too familiar with AVR assembly, but the problem seems to be that the
comparisons that calculate the result value all use the same brlo (branch if
lower) instruction at .L34, but the compiler fails to compensate for the
"lower" instead of "lower or equal" for all but the first (<= 8) condition:

.L21:
cpi r17,lo8(7)
brsh .L25
cpi r28,lo8(3)
brsh .L12
cpi r29,lo8(9)  ; this correctly compares to 9 == 8+1
.L34:
brlo .L27
.L25:
ldi r24,lo8(63)
.L11:

[...]

.L12:
cpi r28,lo8(5)
brsh .L15
cpi r29,lo8(6)  ; but this does not (should be 6+1 == 7)
rjmp .L34
.L15:
cpi r28,lo8(7)
breq .L17
cpi r29,lo8(4)  ; neither does this (should be 4+1 == 5)
rjmp .L34
.L17:
cpi r29,lo8(2)  ; nor this (should be 2+1 == 3)
rjmp .L34
.L27:


Tested with the respective Arch Linux x86_64 avr-gcc packages.

Output of "avr-gcc -v":

> avr-gcc -v -save-temps -Wall -Wextra -mmcu=atmega1284p -Os 
> --param=min-pagesize=0 avr-bug.c
Using built-in specs.
Reading specs from /usr/lib/gcc/avr/12.2.0/device-specs/specs-atmega1284p
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/12.2.0/lto-wrapper
Target: avr
Configured with: /build/avr-gcc/src/gcc-12.2.0/configure
--disable-install-libiberty --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-linker-build-id --disable-nls
--disable-werror --disable-__cxa_atexit --enable-checking=release
--enable-clocale=gnu --enable-gnu-unique-object --enable-gold
--enable-languages=c,c++ --enable-ld=default --enable-lto --enable-plugin
--enable-shared --infodir=/usr/share/info --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --prefix=/usr --target=avr
--with-as=/usr/bin/avr-as --with-gnu-as --with-gnu-ld --with-ld=/usr/bin/avr-ld
--with-plugin-ld=ld.gold --with-system-zlib --with-isl
--enable-gnu-indirect-function
Thread model: single
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra'  '-Os'
'--param=min-pagesize=0' '-mdouble=32' '-mlong-double=64'
'-specs=device-specs/specs-atmega1284p' '-mmcu=avr51' '-dumpdir' 'a-'
 /usr/lib/gcc/avr/12.2.0/cc1 -E -quiet -v -imultilib avr51
-D__AVR_ATmega1284P__ -D__AVR_DEVICE_NAME__=atmega1284p avr-bug.c -mn-flash=2
-mno-skip-bug -mdouble=32 -mlong-double=64 -mmcu=avr51 -Wall -Wextra -Os
-fpch-preprocess -o a-avr-bug.i
ignoring nonexistent directory
"/usr/lib/gcc/avr/12.2.0/../../../../avr/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/avr/12.2.0/include
 /usr/lib/gcc/avr/12.2.0/include-fixed
 /usr/lib/gcc/avr/12.2.0/../../../../avr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra'  '-Os'
'--param=min-pagesize=0' '-mdouble=32' '-mlong-double=64'
'-specs=device-specs/specs-atmega1284p' '-mmcu=avr51' '-dumpdir' 'a-'
 /usr/lib/gcc/avr/12.2.0/cc1 -fpreprocessed a-avr-bug.i -mn-flash=2
-mno-skip-bug -quiet -dumpdir a- -dumpbase avr-bug.c -dumpbase-ext .c
-mdouble=32 -mlong-double=64 -mmcu=avr51 -Os -Wall -Wextra -version
--param=min-pagesize=0 -o a-avr-bug.s
GNU C17 (GCC) version 12.2.0 (avr)
compiled by GNU C version 12.1.1 20220730, GMP version 6.2.1, 

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

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

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

Peter Bergner  changed:

   What|Removed |Added

 CC||meissner at gcc dot gnu.org,
   ||segher at gcc dot gnu.org

--- Comment #8 from Peter Bergner  ---
Adding Mike and Segher for their input.

[Bug c++/109645] ice in instantiate_decl, at cp/pt.cc:27097

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from David Binderman  ---
This commit 

commit 95d4c0d2e6318aef88ba0bc607dfc1ec6b7a612f
Author: Jason Merrill 
Date:   Thu Mar 16 16:55:39 2023 -0400

c++: restore instantiate_decl assert

looks to be a hot candidate.

[Bug c++/109623] constexpr restrictions are not relaxed enough

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Most likely, mine thus.

[Bug c++/109649] [13/14 Regression] GCC accepts invalid inaccessible friend declaration of member function

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Changed in r13-55-ge9d2adc17d0dbe:

commit e9d2adc17d0dbe46db67e1b618dea888d5c7aca3
Author: Jason Merrill 
Date:   Fri Apr 8 13:48:25 2022 -0400

c++: reorganize friend template matching [PR91618]

[Bug target/105325] power10: Error: operand out of range

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

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

Peter Bergner  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-April/6
   ||16805.html

--- Comment #16 from Peter Bergner  ---
Another test case from Nick's dup bugzilla (PR108239):

--- test.c ---
// powerpc64le-linux-gnu-gcc -O2 -mcpu=power10 -mno-pcrel -c test.c

#include 

static inline uint32_t readl(uint32_t *addr)
{
uint32_t ret;
__asm__ __volatile__("lwz %0,%1" : "=r" (ret) : "m" (*addr));
return ret;
}

int test(void *addr)
{
return readl(addr + 0x8024);
}

[Bug libstdc++/40380] class documentation should mention include file to use

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

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

--- Comment #9 from Jonathan Wakely  ---
Grr, I've just noticed that classes defined in a header with no file extension
do not get an implicit @headerfile, the way that classes defined in a foo.h
header do. See https://github.com/doxygen/doxygen/issues/10010

This is frustrating for libstdc++, because **none** of the public headers have
an extension, so we can't rely on all the contents of e.g. 
getting a correct #include  displayed. The _only_ classes
which show a #include are the ones in a .h file where it's always wrong (until
we add an explicit @headerfile to them).

So unless that doxygen issue gets fixed, we need an explicit @headerfile on
every single class in the library. Sigh.

[Bug target/105325] power10: Error: operand out of range

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

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

Peter Bergner  changed:

   What|Removed |Added

 CC||npiggin at gmail dot com

--- Comment #15 from Peter Bergner  ---
*** Bug 108239 has been marked as a duplicate of this bug. ***

[Bug target/108239] -mprefixed causes too large displacements for extended inline asm memory operands

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

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #1 from Peter Bergner  ---
This is a dup or PR105325.

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

[Bug c++/109649] [13/14 Regression] GCC accepts invalid inaccessible friend declaration of member function

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||13.1.0
 Status|UNCONFIRMED |NEW
  Known to work||12.2.0
 Ever confirmed|0   |1
   Keywords||needs-bisection
Summary|GCC accepts invalid |[13/14 Regression] GCC
   |inaccessible friend |accepts invalid
   |declaration of member   |inaccessible friend
   |function|declaration of member
   ||function
   Target Milestone|--- |13.2
   Last reconfirmed||2023-04-27

--- Comment #1 from Andrew Pinski  ---
Confirmed.

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

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
We could probably disable the warning when the temporary is of empty class
type?

[Bug c++/109649] New: GCC accepts invalid inaccessible friend declaration of member function

[jlame646 at gmail dot com via Gcc-bugs]

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

Bug ID: 109649
   Summary: GCC accepts invalid inaccessible friend declaration of
member function
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jlame646 at gmail dot com
  Target Milestone: ---

The following invalid programs explained here:
https://stackoverflow.com/a/76120963/12002570 can be compiled with gcc but
rejected by msvc and clang. See demo: https://godbolt.org/z/Mz8cq3G5n

```
template 
class X {

void f(){}
};
class Y
{
friend void X::f();  
};

int main()
{
X t;
t.f();
Y b;
}
```

As we can note the above program compiles with gcc trunk.

[Bug c++/109642] False Positive -Wdangling-reference with std::span-like classes

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Sorry, you need to use

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdangling-reference"
...
#pragma GCC diagnostic pop

when using MySpan here, because the compiler can't figure out it's
std::span-like.

[Bug c/90885] GCC should warn about 2^16 and 2^32 and 2^64 [-Wxor-used-as-pow]

[warp at iki dot fi via Gcc-bugs]

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

warp at iki dot fi changed:

   What|Removed |Added

 CC||warp at iki dot fi

--- Comment #30 from warp at iki dot fi ---
Note that a few of the examples in that first tweet are actually misleading.
More particularly, the example in png.c. At first glance it looks like C and an
example of this mistake, but if you look at the context it becomes clear that
it actually isn't C at all (because that line appears in a context where it
would be illegal code, namely, inside the initialization list of an array).
It's actually BC code embedded in the C source code, for some reason. In BC
2^32 is legitimately 2 to the power of 32.

The other examples are probably legitimate, though.