[Bug c++/96442] [10/11/12/13 Regression] ICE in tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have record_type in int_fits_type_p, at tree.c:8954

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

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

commit r13-999-g6dd194e2ce201d057e4faaecc36d19e0d3695f57
Author: Roger Sayle 
Date:   Tue Jun 7 07:54:13 2022 +0100

PR c++/96442: Improved error recovery in enumerations.

This patch is a revised fix for PR c++/96442 providing a cleaner
solution, setting ENUM_UNDERLYING_TYPE to integer_type_node when
issuing an error, so that this invariant holds during the parser's
error recovery.

2022-06-07  Roger Sayle  

gcc/cp/ChangeLog
PR c++/96442
* decl.cc (start_enum): When emitting a "must be integral" error,
set ENUM_UNDERLYING_TYPE to integer_type_node, to avoid an ICE
downstream in build_enumeration.

gcc/testsuite/ChangeLog
PR c++/96442
* g++.dg/parse/pr96442.C: New test case.

[Bug target/105791] [13 Regression] ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) with -mxop

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

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

commit r13-998-gc4320bde42c6497b701e2e6b8f1c5069bed19818
Author: Roger Sayle 
Date:   Tue Jun 7 07:49:40 2022 +0100

Recognize vpcmov in combine with -mxop on x86.

By way of an apology for causing PR target/105791, where I'd overlooked
the need to support V1TImode in TARGET_XOP's vpcmov instruction, this
patch further improves support for TARGET_XOP's vpcmov instruction, by
recognizing it in combine.

Currently, the test case:

typedef int v4si __attribute__ ((vector_size (16)));
v4si foo(v4si c, v4si t, v4si f)
{
return (c&t)|(~c&f);
}

on x86_64 with -O2 -mxop generates:
vpxor   %xmm2, %xmm1, %xmm1
vpand   %xmm0, %xmm1, %xmm1
vpxor   %xmm2, %xmm1, %xmm0
ret

but with this patch now generates:
vpcmov  %xmm0, %xmm2, %xmm1, %xmm0
ret

On its own, the new combine splitter works fine on TARGET_64BIT, but
alas with -m32 combine incorrectly thinks the replacement instruction
is more expensive, as IF_THEN_ELSE isn't currently/correctly handled
in ix86_rtx_costs.  So to avoid the need for a target selector in the
new tescase, I've updated ix86_rtx_costs to report that AMD's vpcmov
has a latency of two cycles [it's now an obsolete instruction set
extension and there's unlikely to ever be a processor where this
instruction has a different timing], and while there I also added
rtx_costs for x86_64's integer conditional move instructions (which
have single cycle latency).

2022-06-07  Roger Sayle  

gcc/ChangeLog
* config/i386/i386.cc (ix86_rtx_costs): Add a new case for
IF_THEN_ELSE, and provide costs for TARGET_XOP's vpcmov and
TARGET_CMOVE's (scalar integer) conditional moves.
* config/i386/sse.md (define_split): Recognize XOP's vpcmov
from its equivalent (canonical) pxor;pand;pxor sequence.

gcc/testsuite/ChangeLog
* gcc.target/i386/xop-pcmov3.c: New test case.

[Bug target/105782] [sparc64] Emission of questionable movxtod/movdtox with -mvis3

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-06-07
 CC||ebotcazou at gcc dot gnu.org

--- Comment #3 from Eric Botcazou  ---
I guess that, under high register pressure, the register allocator rather uses
floating-point registers than spllling values on the stack.

[Bug tree-optimization/105867] [12/13 Regression] incorrect dangling-pointer warning

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-06-07
Summary|incorrect dangling-pointer  |[12/13 Regression]
   |warning |incorrect dangling-pointer
   ||warning
 Status|UNCONFIRMED |NEW
  Component|middle-end  |tree-optimization
   Target Milestone|--- |12.2
 Ever confirmed|0   |1
   Keywords||diagnostic

--- Comment #1 from Andrew Pinski  ---
Looks the warning does not notice the store was "undone" with later on.
We have:
  MEM[(struct ConsList *)this_3(D) + 8B].value = currNode_5(D);
  MEM[(struct ConsList *)this_3(D) + 8B].tail = &guard.oldNodeStack;


   [local count: 118111600]:
  MEM[(struct ConsList *)this_3(D) + 8B] = guard.oldNodeStack;
  guard ={v} {CLOBBER};
  guard ={v} {CLOBBER(eol)};
  return;

The store to this removes the stored address of the local variable.

Confirmed.

[Bug tree-optimization/105868] false positive return-local-addr with goto statement and optimization O2

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

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

--- Comment #1 from Andrew Pinski  ---
Looks like the warning happens before the jump threading of:
   [local count: 80530636]:
  # buffer_57 = PHI 
  if (&_buffer == buffer_57)
goto ; [98.77%]
  else
goto ; [1.23%]

   [local count: 79540110]:
  buffer_26 = __builtin_strdup (&_buffer);

   [local count: 746791736]:
  # _9 = PHI <0B(10), buffer_26(12), buffer_57(11), buffer_18(D)(14)>
  _buffer ={v} {CLOBBER(eol)};
  alloc_size ={v} {CLOBBER(eol)};
  return _9;

Happens.
In optimized, the threading happens and there is no reference to &_buffer in
the PHI for the retun.

[Bug c/105868] New: false positive return-local-addr with goto statement and optimization O2

[dixyes at gmail dot com via Gcc-bugs]

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

Bug ID: 105868
   Summary: false positive return-local-addr with goto statement
and optimization O2
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dixyes at gmail dot com
  Target Milestone: ---

Created attachment 53095
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53095&action=edit
retlocal.tar.zst

GCC version/System type:

```
gcc -v

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-linker-build-id --enable-lto
--enable-multilib --enable-plugin --enable-shared --enable-threads=posix
--disable-libssp --disable-libstdcxx-pch --disable-werror
--with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (GCC)

uname -a

Linux DIXXPSArch 5.18.1-arch1-1 #1 SMP PREEMPT_DYNAMIC Mon, 30 May 2022
17:53:11 + x86_64 GNU/Linux
```

This gcc is from archlinux package gcc 12.1.0-2

This also happens at these gccs:

- "12.1.0-2" in debian sid x86_64
- "12.1.1-1.fc37" in fedora rawhide x86_64
- "12.1.1-1.fc36" in fedora 36 x86_64
- "gcc12-12.1.0+git27-1.3" in opensuse tumbleweed x86_64
- "12.1.0-2" in debian sid arm64
- "12.1.0-2.1" in archlinuxarm arm64

This do not happen at these gccs:

- gcc 11
- "12.1.0-2" in debian(ports) sid mips64el
- "12.1.0-2" in debian(ports) sid riscv64

Code:

```
#define NULL ((void *)0)
// gcc -Wextra retlocal.c -c -O2 -o retlocal.o

int uv_os_getenv(const char*, char*, unsigned long long *);
char *func(const char *name, char *buffer, unsigned long long *size)
{
char _buffer[512] = {0};
unsigned long long *size_ptr, alloc_size = 0;
int error;

if (buffer == NULL) {
if (size == NULL || *size == 0) {
alloc_size = sizeof(_buffer);
size_ptr = &alloc_size;
} else {
alloc_size = *size;
size_ptr = size;
}
if (alloc_size <= sizeof(_buffer)) {
buffer = _buffer;
} else {
_retry:
// using malloc is the same
buffer = (char *) __builtin_malloc(alloc_size);
}
} else {
size_ptr = size;
}

error = uv_os_getenv(name, buffer, size_ptr);

if (error != 0) {
if (alloc_size != 0 && buffer != _buffer) {
// using free is the same
__builtin_free(buffer);
}
if (error == 22 && size_ptr == &alloc_size) {
// comment out below, things is ok
goto _retry;
}
return NULL;
}

if (buffer == _buffer) {
// using strdup is the same
buffer = __builtin_strdup(buffer);
}

return buffer;
}
```

GCC command:

`gcc -Wextra retlocal.c -c -O2 -o retlocal.o`

Which `-Wextra` includes `-Wreturn-local-addr`, `-O2` is necessary, not sure
which optimization in O2 make this broken.

Outputs:
```
retlocal.c: In function ‘func’:
retlocal.c:51:1: warning: function may return address of local variable
[-Wreturn-local-addr]
   51 | }
  | ^
retlocal.c:8:10: note: declared here
8 | char _buffer[512] = {0};
  |  ^~~ ^~~
```

Problem:

As you can see if this code wants to return anything other than NULL, it must
reach the end of this function, while before that, a `buffer == _buffer` check
is made, so this piece of code cannot return local address of `_buffer`. The
warning is a false positive, I am not sure if the code it generated is ok.

Tempfiles is in the attachment

[Bug fortran/100607] ICE with SELECT RANK

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING

[Bug c++/105841] [12/13 Regression] Change in behavior of CTAD for alias templates

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

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

--- Comment #4 from Jason Merrill  ---
(In reply to Mike Spertus from comment #3)
> Thanks for the nudge, Jason. I will shake the bit rot off the POC and try to
> polish it to something mergeable. OK if I ping you if I have questions?

Absolutely!

[Bug target/105733] riscv: Poor codegen for large stack frames

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

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

Jim Wilson  changed:

   What|Removed |Added

 CC||wilson at gcc dot gnu.org

--- Comment #2 from Jim Wilson  ---
This is a known problem that I have commented on before.  For instance here
https://github.com/riscv-collab/riscv-gcc/issues/193

Copying my reply to here since this is a better place for the bug report:

This is a known problem. GCC first emits code using a frame pointer, and then
tries to eliminate the frame pointer during register allocation. When the frame
size is larger than the immediate field of an add, we need temporaries to
compute frame offsets. Compiler optimizations like common subexpression
elimination (cse) try to optimize the calculation of the temporaries. Then when
we try to eliminate the frame pointer, we run into trouble because the cse opt
changes interfere with the frame pointer elimination, and we end up with an
ugly inefficient mess.

This problem isn't RISC-V specific, but since RISC-V has 12-bit immediates and
most everyone else has 16-bit immediates, we hit the problem sooner, and thus
makes it much more visible for RISC-V. The example above is putting 12KB on the
stack, which is larger than 12-bits of range (4KB), but well within 16-bits of
range (64KB).

I have a prototype of a patch to fix it by allowing >12-bit offsets for frame
pointer references, and then fixing this when eliminating the frame pointer,
but this can cause other problems, and needs more work to be usable. I have no
idea when someone might try to finish the patch.

End of inclusion from github.

To improve my earlier answer, we have signed 12-bit immediates, so the trouble
actually starts at 2048 bytes, and Jessica's example is larger than that. 
Reduce BUFSIZ to 2044 and you get a reasonable result.

foo:
li  a5,4096
addia5,a5,-2048
addisp,sp,-2048
add a5,a5,a0
add a0,a5,sp
li  t0,4096
sb  zero,-2048(a0)
addit0,t0,-2048
add sp,sp,t0
jr  ra

There is still a bit of oddness here.  We are adding 2048 to a0 and then using
an address -2048(a0).  I think that is more cse trouble.  2048 requires two
instructions to load into a register which is likely confusing something
somewhere.

[Bug rtl-optimization/104637] [10/11 Regression] ICE: maximum number of LRA assignment passes is achieved (30) with -Og -fno-forward-propagate -mavx since r9-5221-gd8fcab689435a29d

[sam at gentoo dot org via Gcc-bugs]

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

--- Comment #9 from Sam James  ---
Could this be backported to 10 + 11 please?

[Bug middle-end/105867] New: incorrect dangling-pointer warning

[gman at chromium dot org via Gcc-bugs]

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

Bug ID: 105867
   Summary: incorrect dangling-pointer warning
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gman at chromium dot org
  Target Milestone: ---

Created attachment 53094
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53094&action=edit
dangling-pointer warning repo

This code (attached) could be doing something wrong but I was asked to look
into why this code gets an dangling-pointer warning in gcc 12.1 and after
looking though it it seems like maybe the code is fine and the warning is
incorrect?

compiled with 

-std=c++17 -Wall -Wextra -pedantic-errors -Wdangling-pointer -O2

note that there is a function, TIntermRebuild::printStack, which is called in
several places. It's inclusion doesn't seem like it should affect the warning.
As it is it is compiled out via a macro

#define printStack(msg)

compiling it back in (delete the line above) makes the warning go away.

[Bug c++/105841] [12/13 Regression] Change in behavior of CTAD for alias templates

[mike at spertus dot com via Gcc-bugs]

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

--- Comment #3 from Mike Spertus  ---
Thanks for the nudge, Jason. I will shake the bit rot off the POC and try to
polish it to something mergeable. OK if I ping you if I have questions?

[Bug c++/105852] [11/12/13 Regression] ice in instantiate_decl

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug fortran/100607] ICE with SELECT RANK

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
I have no idea what the problem is here.  The code cleanly dies if the invalid
code is left in place.  It compiles and runs if the invalid code is removed. 
Perhaps, the bug was fixed in the last year.  Tobias, plaease check.

[Bug middle-end/105866] [13 Regression] ICE in emit_move_insn building glibc for MIPS

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

   Last reconfirmed||2022-06-06
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |roger at 
nextmovesoftware dot com

--- Comment #1 from Roger Sayle  ---
I believe this is resolved by the patch proposed here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596242.html
Sorry for the breakage/inconvenience.

[Bug tree-optimization/105864] storing nullptr_t to memory should not generate any instructions

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

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Ivan Sorokin from comment #0)
> Currently storing a nullptr_t to memory causes 0 to be written to that
> memory. As there is no way to read this value back without invoking
> undefined behavior I believe GCC can omit storing it.

You can use that value to store 0 to another pointer type, and you can pass it
to a printf-style varargs function (which is passed as (void*)0). Both of those
could be made to store 0 as needed, but maybe it simplifies things to store it
early and then the later uses are just bitwise copies of the zero value.

[Bug middle-end/105866] [13 Regression] ICE in emit_move_insn building glibc for MIPS

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

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

Joseph S. Myers  changed:

   What|Removed |Added

Version|12.0|13.0
   Target Milestone|--- |13.0

[Bug middle-end/105866] New: [13 Regression] ICE in emit_move_insn building glibc for MIPS

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

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

Bug ID: 105866
   Summary: [13 Regression] ICE in emit_move_insn building glibc
for MIPS
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: roger at nextmovesoftware dot com
  Target Milestone: ---
Target: mips*-*-*

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

Commit ed6fd2aed58f2cca99f15331bf68999c0e6df370, "PR middle-end/95126: Expand
small const structs as immediate constants.", introduces an ICE for the
attached test case (from glibc) on mips64-linux-gnu. Compile with: -mabi=n32
-O2

during RTL pass: expand
key_call.c: In function 'key_gendes':
key_call.c:224:12: internal compiler error: in emit_move_insn, at expr.cc:4012
0x95754f emit_move_insn(rtx_def*, rtx_def*)
/scratch/jmyers/glibc/many13/src/gcc/gcc/expr.cc:4011
0x7eb57e load_register_parameters
/scratch/jmyers/glibc/many13/src/gcc/gcc/calls.cc:2192
0x7f31ad expand_call(tree_node*, rtx_def*, int)
/scratch/jmyers/glibc/many13/src/gcc/gcc/calls.cc:3594
0x951d45 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/scratch/jmyers/glibc/many13/src/gcc/gcc/expr.cc:11621
0x95ee95 store_expr(tree_node*, rtx_def*, int, bool, bool)
/scratch/jmyers/glibc/many13/src/gcc/gcc/expr.cc:6106
0x960a47 expand_assignment(tree_node*, tree_node*, bool)
/scratch/jmyers/glibc/many13/src/gcc/gcc/expr.cc:5835
0x80e7ae expand_call_stmt
/scratch/jmyers/glibc/many13/src/gcc/gcc/cfgexpand.cc:2829
0x80e7ae expand_gimple_stmt_1
/scratch/jmyers/glibc/many13/src/gcc/gcc/cfgexpand.cc:3869
0x80e7ae expand_gimple_stmt
/scratch/jmyers/glibc/many13/src/gcc/gcc/cfgexpand.cc:4033
0x815a22 expand_gimple_basic_block
/scratch/jmyers/glibc/many13/src/gcc/gcc/cfgexpand.cc:6085
0x8180d2 execute
/scratch/jmyers/glibc/many13/src/gcc/gcc/cfgexpand.cc:6811
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++/105841] [12/13 Regression] Change in behavior of CTAD for alias templates

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

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC||mike at spertus dot com
   Assignee|jason at gcc dot gnu.org   |unassigned at gcc dot 
gnu.org

--- Comment #2 from Jason Merrill  ---
In alias_ctad_tweaks, I wrote:

  /* This implementation differs from the [standard] in two significant ways:   

 1) We include all template parameters of A, not just some. 
 2) The added constraint is same_type instead of deducible. 

 I believe that while it's probably possible to construct a testcase that   
 behaves differently with this simplification, it should have the same  
 effect for real uses.  Including all template parameters means that we 
 deduce all parameters of A when resolving the call, so when we're in the   
 constraint we don't need to deduce them again, we can just check whether   
 the deduction produced the desired result.  */

This testcase is an example of why my assumption above was wrong.  The effect
of the transformations specified by the standard would be roughly

template  struct B_deducible;
template  struct B_deducible> { };
template 
auto fp(BT, fTs...) -> A
  requires requires { B_deducible>(); };

decltype(fp(0,0)) b(0,0);

which works.

A year ago, Mike Spertus had a partial fix for this; any update on that?

[Bug c++/105841] [12/13 Regression] Change in behavior of CTAD for alias templates

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/53164] Undefined reference to template function instantiation

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:733a792a2b2e1662e738fa358b45a2720a8618a7

commit r13-995-g733a792a2b2e1662e738fa358b45a2720a8618a7
Author: Patrick Palka 
Date:   Mon Jun 6 14:29:12 2022 -0400

c++: function NTTP argument considered unused [PR53164, PR105848]

Here at parse time the template argument f (an OVERLOAD) in A gets
resolved ahead of time to the FUNCTION_DECL f, and we defer marking
f as used until instantiation (of g) as usual.

Later when instantiating g the type A (where f has already been
resolved) is non-dependent, so tsubst_aggr_type avoids re-processing its
template arguments, and we end up never actually marking f as used
(which means we never instantiate it) even though A::h() later calls
it, leading to a link error.

This patch works around this issue by looking through ADDR_EXPR when
calling mark_used on the substituted callee of a CALL_EXPR.

PR c++/53164
PR c++/105848

gcc/cp/ChangeLog:

* pt.cc (tsubst_copy_and_build) : Look through an
ADDR_EXPR callee when calling mark_used.

gcc/testsuite/ChangeLog:

* g++.dg/template/fn-ptr3.C: New test.

[Bug c++/105848] [12/13 Regression] undefined reference for default template argument of function type

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:733a792a2b2e1662e738fa358b45a2720a8618a7

commit r13-995-g733a792a2b2e1662e738fa358b45a2720a8618a7
Author: Patrick Palka 
Date:   Mon Jun 6 14:29:12 2022 -0400

c++: function NTTP argument considered unused [PR53164, PR105848]

Here at parse time the template argument f (an OVERLOAD) in A gets
resolved ahead of time to the FUNCTION_DECL f, and we defer marking
f as used until instantiation (of g) as usual.

Later when instantiating g the type A (where f has already been
resolved) is non-dependent, so tsubst_aggr_type avoids re-processing its
template arguments, and we end up never actually marking f as used
(which means we never instantiate it) even though A::h() later calls
it, leading to a link error.

This patch works around this issue by looking through ADDR_EXPR when
calling mark_used on the substituted callee of a CALL_EXPR.

PR c++/53164
PR c++/105848

gcc/cp/ChangeLog:

* pt.cc (tsubst_copy_and_build) : Look through an
ADDR_EXPR callee when calling mark_used.

gcc/testsuite/ChangeLog:

* g++.dg/template/fn-ptr3.C: New test.

[Bug c++/105865] New: false positive expression static_cast pointer-to-member upcast in constexpr constructor

[acox at reliablecontrols dot com via Gcc-bugs]

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

Bug ID: 105865
   Summary: false positive expression static_cast
pointer-to-member upcast in constexpr constructor
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acox at reliablecontrols dot com
  Target Milestone: ---

G++ doesn't determine that an upcast on a pointer-to-member-function in a
constexpr constructor is valid when used in a constexpr context. No options to
g++ are needed, and there shouldn't be any preprocessing.

struct H
{
template 
using fn = int (T::*)(int v) const;

int a(int v) const { return v+40; }
int b(int v) const { return v+20; }

struct beta {
fn mX;

template 
constexpr beta(fn x): mX{static_cast>(x)} {}
};
};

struct I : public H{
int c(int v) const { return v+40; }
};

int main()
{
constexpr H::beta x {&I::c};
}

On newer versions it will give this error message which is visually incorrect
because it's a static_cast and not a reinterpret_cast. (this is from 12.1)

:29:31: error: 'constexpr H::beta::beta(H::fn) [with T = I; H::fn
= unsigned int (I::*)(unsigned int) const]' called in a constant expression
   29 | constexpr H::beta x {&I::c};
  |   ^
:19:19: note: 'constexpr H::beta::beta(H::fn) [with T = I; H::fn
= unsigned int (I::*)(unsigned int) const]' is not usable as a 'constexpr'
function because:
   19 | constexpr beta(fn x): mX{static_cast>(x)} {}
  |   ^~~~
:19:37: error: 'reinterpret_cast' is not a constant expression
   19 | constexpr beta(fn x): mX{static_cast>(x)} {}
  | ^

On older versions it doesn't give any indication of what went wrong. Which is
annoying with more constructor arguments and possible implicit converting
constructors. (This is from 9.4)


:29:31: error: 'constexpr H::beta::beta(H::fn) [with T = I; H::fn
= unsigned int (I::*)(unsigned int) const; uint32_t = unsigned int]' called in
a constant expression
   29 | constexpr H::beta x {&I::c};
  |   ^
:19:19: note: 'constexpr H::beta::beta(H::fn) [with T = I; H::fn
= unsigned int (I::*)(unsigned int) const; uint32_t = unsigned int]' is not
usable as a 'constexpr' function because:
   19 | constexpr beta(fn x): mX{static_cast>(x)} {}
  |   ^~~~

The issue goes away when you restructure the program to do the cast outside of
the constructor. However, if you're intending to construct many objects at
compile time this method can be cumbersome and overly verbose.

This problem was previously described here:
https://stackoverflow.com/q/46818864
I have reproduced it in a live environment here https://godbolt.org/z/vv1ocd77o
to illustrate it does work with clang

Version information (gcc -v)
Target: x86_64-linux-gnu
Configured with: ../gcc-12.1.0/configure
--prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap
--enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --enable-clocale=gnu
--enable-languages=c,c++,fortran,ada,go,d --enable-ld=yes --enable-gold=yes
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-linker-build-id
--enable-lto --enable-plugins --enable-threads=posix
--with-pkgversion=Compiler-Explorer-Build-gcc--binutils-2.38
--enable-libstdcxx-backtrace=yes
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.1.0 (Compiler-Explorer-Build-gcc--binutils-2.38) 
COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' '/app/output.s'
'-masm=intel' '-S' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
'-dumpdir' '/app/'

/opt/compiler-explorer/gcc-12.1.0/bin/../libexec/gcc/x86_64-linux-gnu/12.1.0/cc1plus
-quiet -v -imultiarch x86_64-linux-gnu -iprefix
/opt/compiler-explorer/gcc-12.1.0/bin/../lib/gcc/x86_64-linux-gnu/12.1.0/
-D_GNU_SOURCE  -quiet -dumpdir /app/ -dumpbase output.cpp -dumpbase-ext
.cpp -masm=intel -mtune=generic -march=x86-64 -g -version
-fdiagnostics-color=always -o /app/output.s
GNU C++17 (Compiler-Explorer-Build-gcc--binutils-2.38) version 12.1.0
(x86_64-linux-gnu)
compiled by GNU C version 7.5.0, GMP version 6.2.1, MPFR version 4.1.0,
MPC version 1.2.1, isl version isl-0.24-GMP

[Bug c++/105845] Provide a name mangling facility usable within C++ code

[eyalroz1 at gmx dot com via Gcc-bugs]

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

--- Comment #2 from Eyal Rozenberg  ---
(In reply to Jiang An from comment #1)
> I don't think this is a bug of libstdc++.

Well, it's not a bug, it's a feature request. But - I certainly won't bikeshed
about the choice of component.

> Perhaps you may use extern "C" and __attribute__((alias("specified_name"))
> (can be also spelled as [[gnu::alias("specified_name")]] since C++11 mode)
> as workaround.

I'm not trying to force a mangled name, I want to get the mangled name in
pre-existing code.

[Bug c/105863] RFE: __attribute__((incbin("file"))) or __builtin_incbin("file")

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #2 from Alexander Monakov  ---
This is #embed, see https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2967.htm

[Bug c/105863] RFE: __attribute__((incbin("file"))) or __builtin_incbin("file")

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

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

--- Comment #1 from Andrew Pinski  ---
The c standard was standardizing this already so we should follow that instead
of making something new.

[Bug tree-optimization/105864] New: storing nullptr_t to memory should not generate any instructions

[vanyacpp at gmail dot com via Gcc-bugs]

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

Bug ID: 105864
   Summary: storing nullptr_t to memory should not generate any
instructions
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vanyacpp at gmail dot com
  Target Milestone: ---

Currently storing a nullptr_t to memory causes 0 to be written to that memory.
As there is no way to read this value back without invoking undefined behavior
I believe GCC can omit storing it.

This will make nullptr_t behave more similar to an empty struct that has only
padding bytes in it.

using nullptr_t = decltype(nullptr);

void test(nullptr_t* p)
{
*p = nullptr;
}

struct empty
{};

void test(empty* p)
{
*p = empty();
}

test(decltype(nullptr)*):
mov QWORD PTR [rdi], 0
ret
test(empty*):
ret

[Bug target/105856] [13 Regression] ice in emit_move_insn, at expr.cc:4011

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from David Binderman  ---
Roger makes an interesting comment about test case coverage in the C and C++
testsuite.

There are about 45,000 C test cases and about 19,000 C++ test cases.
This gives pretty good coverage in practice, with only occasional problems 
failing to be found.

The much stronger test of compiling an entire Linux distribution on x86_64, 
which I do most weeks, generates about 340,000 object modules, so it is a far
bigger
and more comprehensive testcase.

It would be an obvious extension to compile a Linux distribution on
a different architecture. Maybe ARM or PowerPC or another primary gcc target ?

[Bug target/103503] RFE: no save registers attribute

[hpa at zytor dot com via Gcc-bugs]

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

--- Comment #4 from H. Peter Anvin  ---
The interrupt attribute typically does two things:

1. It changes the return instruction;
2. It marks all registers as saved.

2 is exactly the *opposite* of what I want; I would like to improve performance
by the fact that the compiler-invisible entry flow has already saved all
registers, whether or not they are saved in the ABI. Thus, I would like it to
treat all (non-fixed) registers as *clobbered*, not *saved*.

Ideally, "nosaved" and "interrupt" should be possible to use together, to get
effect #1 of the interrupt attribute, but that is usually less important.

[Bug c/105863] New: RFE: __attribute__((incbin("file"))) or __builtin_incbin("file")

[hpa at zytor dot com via Gcc-bugs]

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

Bug ID: 105863
   Summary: RFE: __attribute__((incbin("file"))) or
__builtin_incbin("file")
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hpa at zytor dot com
  Target Milestone: ---

It is a *very* common operation to want to include a preexisting binary object
into a compiled project. There are a number of ways to do this, but they all
suffer significant shortcomings.

The most common ways are to use a preprocessor to convert the input binary
object to textual source, or to wrap an object in assembly code and use
.incbin.  The former is *extremely* inefficient, the latter has a number of
pitfalls, including the one described in bug 66871, the need for
platform-specific coding, sizeof() not being functional, etc.

I would like to suggest a variable attribute __attribute__((incbin("file")))
which statically initializes a variable to the contents of the given binary
file, or a __builtin_incbin("file") which would expand to an initializer; the
end result would look either like:

char foobar[] __attribute__((incbin("foobar.bin")));
char foobar[] = __builtin_incbin("foobar.bin");

[Bug middle-end/85751] RFE: option to align code using breakpoint instructions when unreachable

[hpa at zytor dot com via Gcc-bugs]

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

--- Comment #2 from H. Peter Anvin  ---
Goodness... I missed the question here.
The intent was to just take advantage of existing padding: the execution flow
should not go there.

[Bug middle-end/105862] New: missed inlining opportunity of _Sp_counted_deleter::_M_destroy

[vanyacpp at gmail dot com via Gcc-bugs]

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

Bug ID: 105862
   Summary: missed inlining opportunity of
_Sp_counted_deleter::_M_destroy
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vanyacpp at gmail dot com
  Target Milestone: ---

This sample is reduced from a real usage of shared_ptr.

#include 
#include 


struct sp_counted_base
{
sp_counted_base() noexcept
: use_count(1)
{}

virtual void destroy() noexcept
{}

void release() noexcept
{
if (--use_count == 0)
destroy();
}

private:
sp_counted_base(sp_counted_base const&) = delete;
sp_counted_base& operator=(sp_counted_base const&) = delete;

int use_count;
};

struct sp_counted_deleter final : sp_counted_base
{
virtual void destroy() noexcept
{
::operator delete(this);
}
};


void test()
{
sp_counted_deleter* mem = static_cast(::operator
new(sizeof(sp_counted_deleter)));
::new (mem) sp_counted_deleter();
sp_counted_base* pi = mem;
pi->release();
}

https://godbolt.org/z/dG8h7f1Kn


sp_counted_deleter::destroy():
jmp operator delete(void*)
test():
sub rsp, 8
mov edi, 16
calloperator new(unsigned long)
mov QWORD PTR [rax], OFFSET FLAT:vtable for sp_counted_deleter+16
mov rdi, rax
mov DWORD PTR [rax+8], 0
add rsp, 8
jmp sp_counted_deleter::destroy()

In the output assembly the call to sp_counted_deleter::destroy is left
uninlined. I tested the same sample on Clang and it somehow manages to inline
this function. It would be great if GCC was able to inline it too.

[Bug libstdc++/105844] [10/11/12/13 Regression] std::lcm(50000, 49999) is UB but accepted in a constexpr due to cast to unsigned

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

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

--- Comment #5 from Jonathan Wakely  ---
I think the fix we want is simply:

--- a/libstdc++-v3/include/std/numeric
+++ b/libstdc++-v3/include/std/numeric
@@ -68,6 +68,7 @@
 #if __cplusplus >= 201402L
 # include 
 # include 
+# include 
 #endif

 #if __cplusplus >= 201703L
@@ -102,7 +103,15 @@ namespace __detail
   static_assert(is_unsigned<_Up>::value, "result type must be unsigned");
   static_assert(sizeof(_Up) >= sizeof(_Tp),
  "result type must be at least as wide as the input type");
-  return __val < 0 ? -(_Up)__val : (_Up)__val;
+
+  if (__val >= 0)
+   return static_cast<_Up>(__val);
+
+  if _GLIBCXX17_CONSTEXPR (sizeof(_Up) == sizeof(_Tp))
+   {
+ __glibcxx_assert(__val != __gnu_cxx::__int_traits<_Tp>::__min);
+   }
+  return -static_cast<_Up>(__val);
 }

   template void __absu(bool) = delete;

[Bug c++/105852] [11/12/13 Regression] ice in instantiate_decl

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

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

Sergei Trofimovich  changed:

   What|Removed |Added

 CC||slyfox at gcc dot gnu.org

--- Comment #6 from Sergei Trofimovich  ---
Got identical ICE on nodejs-16.15.1 on this week's gcc shapshot. Ended up
reducing to the same example as David's in #c1.

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

[Bug c++/102168] -Wnon-virtual-dtor shouldn't fire for protected dtor in a class with a friend declaration

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

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

--- Comment #7 from Jonathan Wakely  ---
Like I said, this warning should never be used :-)

[Bug libstdc++/105844] [10/11/12/13 Regression] std::lcm(50000, 49999) is UB but accepted in a constexpr due to cast to unsigned

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2022-06-06
   Priority|P3  |P2
 Status|UNCONFIRMED |ASSIGNED
  Known to fail||10.3.0, 11.1.0, 12.1.0,
   ||13.0, 9.4.0
  Known to work||10.2.0, 9.3.0
 Ever confirmed|0   |1
Summary|std::lcm(5, 4) is   |[10/11/12/13 Regression]
   |UB but accepted in a|std::lcm(5, 4) is
   |constexpr due to cast to|UB but accepted in a
   |unsigned|constexpr due to cast to
   ||unsigned
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Keywords||accepts-invalid
   Target Milestone|--- |10.4

--- Comment #4 from Jonathan Wakely  ---
This is a regression introduced by the fix for PR 92978.

[Bug c++/102168] -Wnon-virtual-dtor shouldn't fire for protected dtor in a class with a friend declaration

[pdimov at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Peter Dimov  ---
Yes, I suppose you're right. The warning warns that Derived _can be_ deleted
via Base*, and that's correct - if not very useful in practice in this specific
case.

In fact the private destructor case is even less useful. ~Derived won't compile
unless it's Derived that is Base's friend, in which case everything is actually
fine.

I suppose we'll have to live with it. The annoying part is that there's no
warning, and then you add an unrelated friend declaration while refactoring,
and the warning appears.

[Bug middle-end/105849] A couple of new clang warnings

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

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

--- Comment #2 from Jonathan Wakely  ---
N.B. the finalize> function is correct. The Clang warning is
saying "this class is not final, so the dynamic type might be different from
the static type" (in which case we would have UB) but that is not actually the
case here. It's correct by construction, because the finalize function is
instantiated for the type being allocated, so the static type matches the
dynamic type.

By making value_range_equiv final, we enforce that the static type is the same
as the dynamic type, by forbidding derivation from that type.

[Bug c++/102168] -Wnon-virtual-dtor shouldn't fire for protected dtor in a class with a friend declaration

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

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

--- Comment #5 from Jonathan Wakely  ---
But isn't the whole point of the warning to flag that "it is possible but
unsafe to delete an instance of a derived class through a pointer to the class
itself or base class." If it isn't intended to be derived from, that's not a
concern (there shouldn't be any derived classes). If it's intended to be
derived from, then there could be derived classes, and so an instance of such a
derived class could be deleted through a pointer to the base.

So isn't this exactly the case that the warning wants to warn about?

I'm not saying it's a good warning (I think it should never be used) but I
don't see how "the class is intended to be a base class" would make it
incorrect to warn about the possibility of deleting a derived class through a
pointer to base.

[Bug c++/105861] New: OpenMP target construct not properly privatizing C++ member variables

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

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

Bug ID: 105861
   Summary: OpenMP target construct not properly privatizing C++
member variables
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cltang at gcc dot gnu.org
  Target Milestone: ---

struct C {
  omp_allocator_handle_t a;
  void foo (void) {
#pragma omp target private (a)
 a = (omp_allocator_handle_t) 0;
  }
};

int main (void)
{
  C c;
  c.foo ();
  return 0;
}

After C++ front-end processing we get:

{
omp_allocator_handle_t D.2823 [value-expr: ((struct C *) this)->a];
  #pragma omp target private(D.2823)
{
  {
<;
  }
}
}

The OMP field privatization seems to be doing something here.
However gimplify turns this into:

void C::foo (struct C * const this)
{
  omp_allocator_handle_t a [value-expr: ((struct C *) this)->a];

  #pragma omp target num_teams(1) thread_limit(0) private(a) \
  map(alloc:MEM[(char *)this] [len: 0]) map(firstprivate:this [pointer
assign, bias: 0])
{
  this->a = 0;
}
}

Which is incorrect. Proper privatization should look something like this (which
works for omp parallel/task):

void C::foo (struct C * const this)
{
  omp_allocator_handle_t a [value-expr: ((struct C *) this)->a];

  #pragma omp parallel private(a)
{
  a = 0;
}
} 

Suspect that some where in gimplify, there's some insufficient handling of the
omp_disregard_value_expr langhook
under OMP_TARGET case. Creating issue here to track this.

[Bug target/105856] [13 Regression] ice in emit_move_insn, at expr.cc:4011

[roger at nextmovesoftware dot com via Gcc-bugs]

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

--- Comment #3 from Roger Sayle  ---
Patch proposed:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596242.html

[Bug middle-end/105853] [13 regression] ice in pieces_addr constructor

[roger at nextmovesoftware dot com via Gcc-bugs]

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

--- Comment #3 from Roger Sayle  ---
Patch proposed:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596242.html

[Bug middle-end/105849] A couple of new clang warnings

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

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to David Binderman from comment #0)
> Standard practice is to have virtual destructor in the presence of virtual
> functions.

Or a protected destructor, or to make the class final.

int_range cannot be final, but it looks as though value_range_equiv can be.

But I think the warning for int_range<1> is a false positive anyway. The
warning comes from instantiating finalizer> in ggc_alloc, but it's
not actually used, because that class has a trivial destructor. So this should
work:

diff --git a/gcc/ggc.h b/gcc/ggc.h
index aeec1bafb9b..af0a4c005d7 100644
--- a/gcc/ggc.h
+++ b/gcc/ggc.h
@@ -160,14 +160,7 @@ extern void dump_ggc_loc_statistics ();
 ((T *) ggc_realloc ((P), (N) * sizeof (T) MEM_STAT_INFO))

 template
-void
-finalize (void *p)
-{
-  static_cast (p)->~T ();
-}
-
-template
-inline bool
+constexpr bool
 need_finalization_p ()
 {
 #if GCC_VERSION >= 4003
@@ -177,6 +170,19 @@ need_finalization_p ()
 #endif
 }

+template
+typename std::enable_if ()>::type
+finalize (void *p)
+{
+  static_cast (p)->~T ();
+}
+
+template
+typename std::enable_if ()>::type
+finalize (void *)
+{
+}
+
 template
 inline T *
 ggc_alloc (ALONE_CXX_MEM_STAT_INFO)
diff --git a/gcc/value-range-equiv.h b/gcc/value-range-equiv.h
index 0a52d1372a1..95a129124b2 100644
--- a/gcc/value-range-equiv.h
+++ b/gcc/value-range-equiv.h
@@ -24,7 +24,7 @@ along with GCC; see the file COPYING3.  If not see

 /* Note value_range_equiv cannot currently be used with GC memory,
only value_range is fully set up for this.  */
-class GTY((user)) value_range_equiv : public value_range
+class GTY((user)) value_range_equiv final : public value_range
 {
  public:
   value_range_equiv () : value_range () { m_equiv = NULL; }


(It would be better to use "if constexpr" in ggc_alloc, but that's a C++17
feature, so overloading with std::enable_if is needed for C++11.)

[Bug c++/105852] [11/12/13 Regression] ice in instantiate_decl

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

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

Patrick Palka  changed:

   What|Removed |Added

  Known to work||11.3.0
  Known to fail||13.0
Summary|[13 Regression] ice in  |[11/12/13 Regression] ice
   |instantiate_decl|in instantiate_decl

--- Comment #5 from Patrick Palka  ---
(In reply to Patrick Palka from comment #4)
> Started with r13-985-g284ae8b46f5eef.

... which was also backported to the 11 and 12 branches.

[Bug c++/105846] [C++2b] constexpr unique_ptr doesn't work with virtual types

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-06-06

--- Comment #5 from Jonathan Wakely  ---
Reduced to remove the library dependency:

// This is just a simple (incomplete) unique_ptr implementation that should
work with C++20/GCC >= 10.1.
// The details of this class don't matter. It also fails with std::unique_ptr
with GCC=12.1/trunk
template
class simple_pointer {
private:
T *ptr{};
public:
constexpr simple_pointer() noexcept = default;
constexpr simple_pointer(T *p) noexcept : ptr{p} {}
simple_pointer(const simple_pointer &) = delete;
constexpr simple_pointer(simple_pointer &&p) noexcept : ptr{p.ptr} {}
constexpr ~simple_pointer() noexcept { delete ptr; }

void operator=(const simple_pointer &) = delete;
constexpr simple_pointer &operator=(simple_pointer &&p) noexcept {
delete ptr;
ptr = p.ptr;
p.ptr = nullptr;
return *this;
}

constexpr T &operator*() const noexcept { return *ptr; }
constexpr T *operator->() const noexcept { return ptr; }
};

template
constexpr simple_pointer make_simple() {
return simple_pointer(new T());
}

// Just some random struct that has a vtable.
struct S {
int x{42};

// Removing this virtual...
constexpr virtual ~S() noexcept = default;
};

// ... or this consteval makes it work again.
consteval int run() {
auto p = make_simple();
return p->x;
}

int main() {
return run();
}



105846.C: In function ‘int main()’:
105846.C:46:15:   in ‘constexpr’ expansion of ‘run()’
105846.C:43:1:   in ‘constexpr’ expansion of ‘(&
p)->simple_pointer::~simple_pointer()’
105846.C:12:44: error: ‘virtual constexpr S::~S()’ used before its definition
   12 | constexpr ~simple_pointer() noexcept { delete ptr; }
  |^~

[Bug c++/105852] [13 Regression] ice in instantiate_decl

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

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

Patrick Palka  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Known to work||12.1.0
 CC||jason at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
   Last reconfirmed||2022-06-06
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=105761

--- Comment #4 from Patrick Palka  ---
Started with r13-985-g284ae8b46f5eef.

[Bug c++/105845] Provide a name mangling facility usable within C++ code

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|normal  |enhancement
  Component|libstdc++   |c++

[Bug analyzer/105860] New: Miscompilation causing clobbered union contents

[tpg+gcc at mutabah dot net via Gcc-bugs]

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

Bug ID: 105860
   Summary: Miscompilation causing clobbered union contents
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: tpg+gcc at mutabah dot net
  Target Milestone: ---

Created attachment 53092
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53092&action=edit
Reproduction source file, compile with `gcc -O1`

Found while debugging this issue with auto-generated code:
https://github.com/thepowersgang/mrustc/issues/266#issuecomment-1147389581

gcc generates code that reads 32-bits from offset 8 of a union, and then writes
that value back to offset 4 before copying 64-bits from offset 4, causing data
corruption.
This issue is present on gcc 10.3.0 (`gcc (Ubuntu 10.3.0-1ubuntu1~20.04)
10.3.0`) and on gcc 11.1 (`gcc-11 (Ubuntu 11.1.0-1ubuntu1~20.04) 11.1.0`), but
not on gcc 9.4.0 (`gcc-9 (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0`)

Compiler flags required: `-O1`


Disassembly with comments pointing to the faulty instructions.
```

:
   0:   f3 0f 1e fa endbr64 
   4:   41 56   push   %r14
   6:   41 55   push   %r13
   8:   41 54   push   %r12
   a:   49 89 fcmov%rdi,%r12
   d:   55  push   %rbp
   e:   53  push   %rbx
   f:   48 83 ec 10 sub$0x10,%rsp
  13:   8b 5c 24 40 mov0x40(%rsp),%ebx
  17:   8b 6c 24 48 mov0x48(%rsp),%ebp   ; Read word 3
  1b:   81 fb 01 ff ff ff   cmp$0xff01,%ebx
  21:   74 4d   je 70

  23:   81 fb 03 ff ff ff   cmp$0xff03,%ebx
  29:   74 5d   je 88

-- SNIP ---
  88:   89 6c 24 44 mov%ebp,0x44(%rsp)   ; Write word 3 over
word 2
  8c:   48 8b 44 24 44  mov0x44(%rsp),%rax   ; Read words 2/3
(values from 3/3)
  91:   48 89 47 04 mov%rax,0x4(%rdi); Write to words 2/3
of output
  95:   eb af   jmp46

```

[Bug c++/105824] Accepts invalid issue with implicit conversion of a scoped enumeration type

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-06-06
   Keywords||accepts-invalid
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
I thought I'd seen a bug report about this before, but I can't find one now, so
confirmed. Not a regression.

[Bug c++/105841] [12/13 Regression] Change in behavior of CTAD for alias templates

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

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

Patrick Palka  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=103852
  Known to work||11.3.0
  Known to fail||12.1.0, 13.0
   Last reconfirmed||2022-06-06
 CC||jason at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
   Target Milestone|--- |12.2
Summary|Change in behavior of CTAD  |[12/13 Regression] Change
   |for alias templates |in behavior of CTAD for
   ||alias templates
 Status|UNCONFIRMED |NEW
   Keywords||rejects-valid
 Ever confirmed|0   |1

--- Comment #1 from Patrick Palka  ---
We started rejecting the testcase after r12-7984-ga11f204e5a30d1.

Reduced rejects-valid example:

template
struct A { A(...); };

template
A(T, Ts...) -> A;

template
using B = A;

B b(0, 0);

Removing B's default template argument makes us accept again.

[Bug c++/102168] -Wnon-virtual-dtor shouldn't fire for protected dtor in a class with a friend declaration

[pdimov at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Peter Dimov  ---
Warning on a private destructor + a friend declaration makes sense, because a
private destructor implies that the type is not intended to be derived from.
But warning on a protected destructor + a friend does not.

[Bug c++/105842] rejects-valid: static member function overload set constrained by concepts for class template results in ambiguous call

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

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

Patrick Palka  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Keywords||rejects-valid
 CC||ppalka at gcc dot gnu.org
   Last reconfirmed||2022-06-06
  Known to fail||10.3.0, 11.3.0, 12.1.0,
   ||13.0, 9.4.0

--- Comment #1 from Patrick Palka  ---
Confirmed, doesn't seem to be a regression.

[Bug c++/105848] [12/13 Regression] undefined reference for default template argument of function type

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
  Known to fail||13.0
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
Summary|[12 Regression] undefined   |[12/13 Regression]
   |reference for default   |undefined reference for
   |template argument of|default template argument
   |function type   |of function type
 Status|NEW |ASSIGNED

--- Comment #2 from Patrick Palka  ---
Started with r12-6075-g2decd2cabe5a4f.

[Bug target/105506] Error building GCC 12.1.0 against MinGW-w64: fatal error: cannot execute 'cc1': CreateProcess: No such file or directory

[martin at martin dot st via Gcc-bugs]

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

--- Comment #8 from Martin Storsjö  ---
(In reply to Brecht Sanders from comment #7)
> So I guess the question that remains is: Where is -D__USE_MINGW_ACCES
> missing in the configuration of GCC 12?
> 
> It would seem to me the answer lies in code added since GCC 11 that contains
> access()/X_OK.

I bisected, and it seems like a build system adjustment makes it lose the flags
that are added in config/mh-mingw (where they are added to CFLAGS, CXXFLAGS and
a bunch of other *_CXXFLAGS). The built GCC reproduces the issue since this
commit:

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=4a5e71f2348adcc49939804889d9f1a64d97005a

Unfortunately, the build system changes here are slightly complex, so it's not
entirely obvious to me where the flags that are added to CFLAGS/CXXFLAGS are
lost.

(Due to other commits around it, cross compiling GCC from linux to windows
fails entirely, until a couple commits later though -
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=ab18659afc054434cef4d4757a3519f1100adc52
- but I tested the commit above with this one cherrypicked on top.)

[Bug c++/105840] confusing diagnostic when naming the wrong class in a constructor

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

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

--- Comment #4 from Jonathan Wakely  ---
For a destructor we do a bit better, but it could still be improved. 

struct A {
  ~A();
};

struct C {
  ~A();
};

105840.C:14:3: error: declaration of ‘~A’ as member of ‘C’
   14 |   ~A();
  |   ^

Yes, the formal reason the code is invalid is that ~A cannot be a member of C,
but the actual reason is that the author made a typo or forgot to change it
after copy&paste.

Maybe similar wording should be used for the constructor and destructor cases,
and a fix-it suggesting changing the "A" to "C" would be nice.

Clang gives a user-friendly message, but no fix-it:

105840.C:6:3: error: expected the class name after '~' to name the enclosing
class
  ~A();
  ^
1 error generated.



For a similar case where A hasn't been declared yet, we don't do so well:

struct Foo {
  ~Fo();
};

105840.C:2:6: error: expected class-name before ‘(’ token
2 |   ~Fo();
  |  ^


This is just a typo, but because "Fo" hasn't been declared prior to this, we
give a very different diagnostic compared to the "~A" case. It would be nice if
this also used similar wording to the other examples, and also gave a fix-it.

Clang does quite well here:

105840.C:2:4: error: undeclared identifier 'Fo' in destructor name
  ~Fo();
   ^~
   Foo
1 error generated.


Although I don't see any reason why Clang gives such different wording for the
"undeclared identifier" and "expected [...] to name the enclosing class" cases.
In both cases the problem is a destructor with a name that isn't the enclosing
class. Whether the name has been declared or not is irrelevant. I think Barry's
suggestion in comment 2 (or something like it) would be good for destructors
too, whether or not the "unrelated class 'A'" has previously been declared.

[Bug bootstrap/105831] Nonportable syntax in "test" and "[" commands.

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

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

--- Comment #2 from Jonathan Wakely  ---
Right. The patch looks correct, but patches should be sent to the list, not
added to bugzilla:
https://gcc.gnu.org/contribute.html#patches

[Bug c++/102168] -Wnon-virtual-dtor shouldn't fire for protected dtor in a class with a friend declaration

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Blocks||81930
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=16168,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=22395,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=56879

--- Comment #3 from Jonathan Wakely  ---
The "there's a suitable friend" check was done intentionally, see r209056 which
was done to fix PR c++/56879


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81930
[Bug 81930] [meta-bug] Issues with -Weffc++

[Bug c++/102168] -Wnon-virtual-dtor shouldn't fire for protected dtor in a class with a friend declaration

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

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

--- Comment #2 from Jonathan Wakely  ---
The -Wnon-virtual-dtor warning is just dumb, that's why I added Clang's
-Wdelete-non-virtual-dtor which should be used instead.

[Bug target/105506] Error building GCC 12.1.0 against MinGW-w64: fatal error: cannot execute 'cc1': CreateProcess: No such file or directory

[brechtsanders at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #7 from Brecht Sanders  
---
Thank you for sharing your insights.

I can confirm building with CFLAGS="-D__USE_MINGW_ACCESS" works.

So I guess the question that remains is: Where is -D__USE_MINGW_ACCES missing
in the configuration of GCC 12?

It would seem to me the answer lies in code added since GCC 11 that contains
access()/X_OK.

[Bug tree-optimization/105855] missed optimization - vectorization -fsanitize=signed-integer-overflow

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #2 from Martin Uecker  ---
Clang seems to do a combined check before the loop without creating a new
version.

[Bug libstdc++/105845] Provide a name mangling facility usable within C++ code

[de34 at live dot cn via Gcc-bugs]

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

Jiang An  changed:

   What|Removed |Added

 CC||de34 at live dot cn

--- Comment #1 from Jiang An  ---
I don't think this is a bug of libstdc++.

Perhaps you may use extern "C" and __attribute__((alias("specified_name")) (can
be also spelled as [[gnu::alias("specified_name")]] since C++11 mode) as
workaround.

See also:
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html