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

[i at maskray dot me via Gcc-bugs]

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

Bug ID: 105576
   Summary: x86: Support a machine constraint to get raw symbol
name
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: i at maskray dot me
  Target Milestone: ---

An raw symbolic operand is useful in inline asm (e.g. in C++ to get the mangled
name, or in C to let the compiler do some asm checking). In aarch64 and riscv,
there is a documented (supported) approach.
documented on
https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html#Machine-Constraints

extern int var;
void *addr(void) { return  }
void addr_via_asm(void) {
  asm (".pushsection .xxx,\"aw\"; .dc.a %0; .popsection" :: "S"(addr)); //
supported on aarch64 and riscv
  asm (".pushsection .xxx,\"aw\"; .dc.a %0; .popsection" :: "S"()); //
supported on aarch64
}

On x86, it is unclear which should be preferred. It seems that the operand
modifier 'p' can be used for a function,
but not a variable.

asm (".pushsection .xxx,\"aw\"; .dc.a %p0; .popsection" :: "m"(addr));

[Bug c++/105575] Segment when riscv64-g++ compile .cc

[yahan at iscas dot ac.cn via Gcc-bugs]

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

--- Comment #7 from Lu Yahan  ---
pipeline00 and pipline01 is tar.gz file and split into two part

[Bug tree-optimization/105414] constant folding for fmin/max(snan, snan) is wrong

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

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

HaoChen Gui  changed:

   What|Removed |Added

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

--- Comment #12 from HaoChen Gui  ---
Fixed.

[Bug preprocessor/101168] gnu++14 complains about altivec types defined with using keyword in the same file with preprocessor macros

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

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

Jiu Fu Guo  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Jiu Fu Guo  ---
Fixed in trunk.

[Bug c++/105575] Segment when riscv64-g++ compile .cc

[yahan at iscas dot ac.cn via Gcc-bugs]

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

Lu Yahan  changed:

   What|Removed |Added

  Attachment #52963|0   |1
is obsolete||

--- Comment #6 from Lu Yahan  ---
Created attachment 52964
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52964=edit
pipeline00

[Bug c++/105575] Segment when riscv64-g++ compile .cc

[yahan at iscas dot ac.cn via Gcc-bugs]

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

Lu Yahan  changed:

   What|Removed |Added

  Attachment #52961|0   |1
is obsolete||

--- Comment #5 from Lu Yahan  ---
Created attachment 52963
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52963=edit
pipeline

[Bug c++/105575] Segment when riscv64-g++ compile .cc

[yahan at iscas dot ac.cn via Gcc-bugs]

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

Lu Yahan  changed:

   What|Removed |Added

  Attachment #52959|0   |1
is obsolete||
  Attachment #52960|0   |1
is obsolete||

--- Comment #4 from Lu Yahan  ---
Created attachment 52962
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52962=edit
pipeline01

[Bug c++/105575] Segment when riscv64-g++ compile .cc

[yahan at iscas dot ac.cn via Gcc-bugs]

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

--- Comment #3 from Lu Yahan  ---
Created attachment 52961
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52961=edit
piplein00

[Bug c++/105575] Segment when riscv64-g++ compile .cc

[yahan at iscas dot ac.cn via Gcc-bugs]

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

--- Comment #2 from Lu Yahan  ---
Created attachment 52960
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52960=edit
pipelein.tar.gz

[Bug c++/105575] Segment when riscv64-g++ compile .cc

[yahan at iscas dot ac.cn via Gcc-bugs]

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

--- Comment #1 from Lu Yahan  ---
Created attachment 52959
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52959=edit
pipeline.ii

[Bug c++/105575] New: Segment when riscv64-g++ compile .cc

[yahan at iscas dot ac.cn via Gcc-bugs]

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

Bug ID: 105575
   Summary: Segment when riscv64-g++ compile .cc
   Product: gcc
   Version: og11 (devel/omp/gcc-11)
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yahan at iscas dot ac.cn
  Target Milestone: ---

luyahan@plct-dev-7:~/v8/v8/out/riscv64.nati.relasegcc $
riscv64-unknown-linux-gnu-g++ -MMD -MF obj/v8_compiler/pipeline.o.d -DUSE_UDEV
-DUSE_AURA=1 -DUSE_GLIB=1 -DUSE_OZONE=1 -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D_FORTIFY_SOURCE=2 -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_LIBCPP_ABI_UNSTABLE
-D_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS
-D_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS -D_LIBCPP_ENABLE_NODISCARD
-DCR_LIBCXX_REVISION=79a2e924d96e2fc1e4b937c42efd08898fa472d7 -DNDEBUG
-DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0
-DV8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=64 -DV8_INTL_SUPPORT -DENABLE_HANDLE_ZAPPING
-DV8_USE_EXTERNAL_STARTUP_DATA -DV8_ATOMIC_OBJECT_FIELD_WRITES
-DV8_ENABLE_LAZY_SOURCE_POSITIONS -DV8_SHARED_RO_HEAP -DV8_WIN64_UNWINDING_INFO
-DV8_ENABLE_REGEXP_INTERPRETER_THREADED_DISPATCH -DV8_ENABLE_WEBASSEMBLY
-DV8_ALLOCATION_FOLDING -DV8_ALLOCATION_SITE_TRACKING
-DV8_ADVANCED_BIGINT_ALGORITHMS -DV8_DEPRECATION_WARNINGS
-DV8_IMMINENT_DEPRECATION_WARNINGS -DV8_TARGET_ARCH_RISCV64 -D__riscv_xlen=64
-DCAN_USE_FPU_INSTRUCTIONS -DV8_HAVE_TARGET_OS -DV8_TARGET_OS_LINUX
-DV8_RUNTIME_CALL_STATS -DU_USING_ICU_NAMESPACE=0 -DU_ENABLE_DYLOAD=0
-DUSE_CHROMIUM_ICU=1 -DU_ENABLE_TRACING=1 -DU_ENABLE_RESOURCE_TRACING=0
-DU_STATIC_IMPLEMENTATION -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_FILE -I../.. -Igen
-I../../buildtools/third_party/libc++ -I../../include -Igen/include
-I../../third_party/icu/source/common -I../../third_party/icu/source/i18n -Wall
-Wno-unused-local-typedefs -Wno-maybe-uninitialized
-Wno-deprecated-declarations -Wno-comments -Wno-packed-not-aligned
-Wno-missing-field-initializers -Wno-unused-parameter -fno-ident
-fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector
-funwind-tables -fPIC -pipe -pthread -Wno-builtin-macro-redefined -D__DATE__=
-D__TIME__= -D__TIMESTAMP__= -fno-omit-frame-pointer -g0 -fno-builtin-abs
-fvisibility=hidden -Wno-strict-overflow -Wno-return-type
-Wno-int-in-bool-context -O3 -fdata-sections -ffunction-sections -Wno-narrowing
-Wno-class-memaccess -std=gnu++17 -fno-aligned-new -fno-exceptions -fno-rtti
-nostdinc++ -isystem../../buildtools/third_party/libc++/trunk/include
-isystem../../buildtools/third_party/libc++abi/trunk/include
-fvisibility-inlines-hidden -c ../../src/compiler/pipeline.cc -o
obj/v8_compiler/pipeline.o
riscv64-unknown-linux-gnu-g++: internal compiler error: Segmentation fault
signal terminated program cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug target/105514] rv64 qsort gets wrong result when '-O2 -DDEBUG'.

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

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

[Bug target/105514] rv64 qsort gets wrong result when '-O2 -DDEBUG'.

[chenglulu at loongson dot cn via Gcc-bugs]

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

chenglulu  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #4 from chenglulu  ---
(In reply to Richard Biener from comment #3)
> indeed strict aliasing violation

Ok,thanks!

[Bug c++/105574] Internal compiler error when co_yield a r-value vector of non-POD type

[wang_ruihan at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from Ruihan Wang  ---
Created attachment 52958
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52958=edit
Preprocessed source file

[Bug c++/105574] New: Internal compiler error when co_yield a r-value vector of non-POD type

[wang_ruihan at hotmail dot com via Gcc-bugs]

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

Bug ID: 105574
   Summary: Internal compiler error when co_yield a r-value vector
of non-POD type
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wang_ruihan at hotmail dot com
  Target Milestone: ---

* System Info
Distributor ID: Ubuntu
Description:Ubuntu 21.10
Release:21.10
Codename:   impish

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

* Build Command
g++ -std=c++20 -fcoroutines -save-temps ../src/bug.cpp

* Description
The following code snippet (bug.cpp) will trigger an internal compiler error:

#include 
#include 
#include 
#include 
#include 
#include 

template
class generator {
public:
struct promise_type {
generator get_return_object() {
return generator{Handle::from_promise(*this)};
}
static std::suspend_always initial_suspend() noexcept {
return {}; 
}
static std::suspend_always final_suspend() noexcept { 
return {}; 
}
std::suspend_always yield_value(T value) noexcept {
current_value = std::move(value);
return {};
}
// Disallow co_await in generator coroutines.
void await_transform() = delete;
[[noreturn]]
static void unhandled_exception() {
throw;
}

std::optional current_value;
};

using Handle = std::coroutine_handle;

explicit generator(const Handle coroutine) : 
m_coroutine{coroutine}
{}

generator() = default;
~generator() { 
if (m_coroutine) {
m_coroutine.destroy(); 
}
}

generator(const generator&) = delete;
generator& operator=(const generator&) = delete;

generator(generator&& other) noexcept : 
m_coroutine{other.m_coroutine}
{ 
other.m_coroutine = {}; 
}
generator& operator=(generator&& other) noexcept {
if (this != ) {
if (m_coroutine) {
m_coroutine.destroy();
}
m_coroutine = other.m_coroutine;
other.m_coroutine = {};
}
return *this;
}

private:
Handle m_coroutine;
};

struct Foo {
Foo() { }
};

generator> bug() {
/* This one compiled fine */
// auto v = std::vector{ Foo() };
// co_yield v;

/* This one hit internal compiler error */
co_yield std::vector{ Foo() };
}

int main() {
bug();
return 0;
}


The error message is the following:

../src/bug.cpp: In function ‘generator > bug()’:
../src/bug.cpp:82:1: internal compiler error: in build_special_member_call, at
cp/call.c:10188
   82 | }
  | ^
0x7d7a1e build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
../../src/gcc/cp/call.c:10188
0x9c3758 flatten_await_stmt
../../src/gcc/cp/coroutines.cc:3023
0x9c38b0 flatten_await_stmt
../../src/gcc/cp/coroutines.cc:3055
0x9c38b0 flatten_await_stmt
../../src/gcc/cp/coroutines.cc:3055
0x9c38b0 flatten_await_stmt
../../src/gcc/cp/coroutines.cc:3055
0x9c756e maybe_promote_temps
../../src/gcc/cp/coroutines.cc:3241
0x9c756e await_statement_walker
../../src/gcc/cp/coroutines.cc:3879
0xf49a8a 

[Bug target/105573] ICE when building numpy on SPARC64

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||105312

--- Comment #5 from Andrew Pinski  ---
We should commit the testcase and then close it as a dup of bug 105312 then.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105312
[Bug 105312] [11 Regression] ICE in gimple_expand_vec_cond_expr on arm-linux
since r12-834-ga6eacbf1055520

[Bug target/105573] ICE when building numpy on SPARC64

[sam at gentoo dot org via Gcc-bugs]

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

--- Comment #4 from Sam James  ---
Confirmed: if I apply that patch, 11.3.0 works.

[Bug target/105573] ICE when building numpy on SPARC64

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Marek Polacek from comment #2)
> This seems to have been fixed in GCC 12 -- I can reproduce with
> --target=sparc64-unknown-linux-gnu with GCC 11, but not GCC 12.

If that is the case, it most likely been fixed by the patch which fixed PR
105312.

[Bug target/105573] ICE when building numpy on SPARC64

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
This seems to have been fixed in GCC 12 -- I can reproduce with
--target=sparc64-unknown-linux-gnu with GCC 11, but not GCC 12.

[Bug d/105544] gdc fails to compile d source from stdin

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

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

--- Comment #4 from ibuclaw at gcc dot gnu.org ---
Ah, it's likely something even more fiendish than that.

What encodings are you using?  (i.e: locale -a)

[Bug target/105573] ICE when building numpy on SPARC64

[sam at gentoo dot org via Gcc-bugs]

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

--- Comment #1 from Sam James  ---
It occurs with -mcpu=native or -mcpu=niagara4 but not if I drop that.

```
$ for t in param target; do cmd="gcc -Q -O2 --help=$t"; diff -U0 <(LANG=C $cmd)
<(LANG=C $cmd -mcpu=niagara4); done
--- /dev/fd/63  2022-05-11 15:01:56.915134318 -0700
+++ /dev/fd/62  2022-05-11 15:01:56.915134318 -0700
@@ -85,2 +85,2 @@
-  --param=l1-cache-size=   64
-  --param=l2-cache-size=   512
+  --param=l1-cache-size=   16
+  --param=l2-cache-size=   128
@@ -223 +223 @@
-  --param=simultaneous-prefetches= 3
+  --param=simultaneous-prefetches= 2
--- /dev/fd/63  2022-05-11 15:01:56.965136466 -0700
+++ /dev/fd/62  2022-05-11 15:01:56.975136897 -0700
@@ -6 +6 @@
-  -mcbcond [disabled]
+  -mcbcond [enabled]
@@ -8 +8 @@
-  -mcpu=   v9
+  -mcpu=   niagara4
@@ -16 +16 @@
-  -mfmaf   [disabled]
+  -mfmaf   [enabled]
@@ -27 +27 @@
-  -mpopc   [disabled]
+  -mpopc   [enabled]
@@ -36 +36 @@
-  -mtune=  v9
+  -mtune=  niagara4
@@ -41,3 +41,3 @@
-  -mvis[disabled]
-  -mvis2   [disabled]
-  -mvis3   [disabled]
+  -mvis[enabled]
+  -mvis2   [enabled]
+  -mvis3   [enabled]
```

It looks like -mvis3 is the trigger:
```
$ sparc64-unknown-linux-gnu-gcc -O2 -pipe -c loops.i -mvis3
[...]
during GIMPLE pass: isel
loops.i:3:33: internal compiler error: in gimple_expand_vec_cond_expr, at
gimple-isel.cc:267
3 | __attribute__((optimize("O3"))) UINT_sign() {
  | ^
0x5c4b2f internal_error(char const*, ...)
???:0
0x5bc583 fancy_abort(char const*, int, char const*)
???:0
[...]
```

[Bug c++/105573] New: ICE when building numpy on SPARC64

[sam at gentoo dot org via Gcc-bugs]

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

Bug ID: 105573
   Summary: ICE when building numpy on SPARC64
   Product: gcc
   Version: 11.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sam at gentoo dot org
  Target Milestone: ---

Created attachment 52957
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52957=edit
loops.i

Originally reported downstream in Gentoo at https://bugs.gentoo.org/843575 by
Agostino Sarubbo (ago).

Occurs when building numpy 1.22.3 on SPARC64 with GCC 11.3 (but also seen it
with: numpy 1.22.3/gcc 11.2.1_p20220115; numpy 1.21.1/gcc 10.3.0).

I've minimised a reproducer (attached) and can reproduce it myself:
```
$ cat loops.i
UINT_sign_args, UINT_sign_steps;
*UINT_sign_ip1;
__attribute__((optimize("O3"))) UINT_sign() {
  char *op1 = UINT_sign_args;
  int os1 = UINT_sign_steps, i;
  for (; i; i++, op1 += os1) {
unsigned in = *(unsigned *)UINT_sign_ip1;
int *out = op1;
*out = in > 0;
  }
}

$ sparc64-unknown-linux-gnu-gcc -O2 -pipe -mcpu=niagara4 -c loops.i
loops.i:1:1: warning: data definition has no type or storage class
1 | UINT_sign_args, UINT_sign_steps;
  | ^~
loops.i:1:1: warning: type defaults to ‘int’ in declaration of ‘UINT_sign_args’
[-Wimplicit-int]
loops.i:1:17: warning: type defaults to ‘int’ in declaration of
‘UINT_sign_steps’ [-Wimplicit-int]
1 | UINT_sign_args, UINT_sign_steps;
  | ^~~
loops.i:2:1: warning: data definition has no type or storage class
2 | *UINT_sign_ip1;
  | ^
loops.i:2:2: warning: type defaults to ‘int’ in declaration of ‘UINT_sign_ip1’
[-Wimplicit-int]
2 | *UINT_sign_ip1;
  |  ^
loops.i:3:33: warning: return type defaults to ‘int’ [-Wimplicit-int]
3 | __attribute__((optimize("O3"))) UINT_sign() {
  | ^
loops.i: In function ‘UINT_sign’:
loops.i:4:15: warning: initialization of ‘char *’ from ‘int’ makes pointer from
integer without a cast [-Wint-conversion]
4 |   char *op1 = UINT_sign_args;
  |   ^~
loops.i:8:16: warning: initialization of ‘int *’ from incompatible pointer type
‘char *’ [-Wincompatible-pointer-types]
8 | int *out = op1;
  |^~~
during GIMPLE pass: isel
loops.i:3:33: internal compiler error: in gimple_expand_vec_cond_expr, at
gimple-isel.cc:267
3 | __attribute__((optimize("O3"))) UINT_sign() {
  | ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
```

Please let me know if you need further information or hardware access (but I've
reproduced this above using a cross-compiler without issues).

[Bug ipa/100413] [11/12/13 Regression] ICE: failed to reclaim unneeded function with custom flags since r11-4267-g0e590b68fa374365

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

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

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

https://gcc.gnu.org/g:988fbc636639621dadc5cecbe77aa3f9aefedefb

commit r12-8368-g988fbc636639621dadc5cecbe77aa3f9aefedefb
Author: Martin Jambor 
Date:   Wed May 11 23:25:40 2022 +0200

ipa: Release body of clone_of when removing its last clone (PR 100413)

In the PR, the verifier complains that we did not manage to remove the
body of a node and it is right.  The node is kept for materialization
of two clones but after one is materialized, the other one is removed
as unneeded (as a part of delete_unreachable_blocks_update_callgraph).
The problem is that the node removal does not check for this situation
and can leave the clone_of node there with a body attached to it even
though there is no use for it any more.  This patch does checks for it
and handles the situation in a simlar way that
cgraph_node::materialize_clone does it, except that it also has to be
careful that the removed node itself does not have any clones, which
would still need the clone_of's body.  Failing to do that results in a
bootstrap failure.

gcc/ChangeLog:

2022-04-27  Martin Jambor  

PR ipa/100413
* cgraph.cc (cgraph_node::remove): Release body of the node this
is clone_of if appropriate.

gcc/testsuite/ChangeLog:

2022-04-27  Martin Jambor  

PR ipa/100413
* g++.dg/ipa/pr100413.C: New test.

(cherry picked from commit 27ee75dbe81bb781214c66a9e6a759c08b7deb60)

[Bug libstdc++/104605] _GLIBCXX_USE_C99_STDINT_TR1 macro is not defined for canadian cross freestanding C++ toolchain

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #4 from cqwrteur  ---
error: 'uintptr_t' is not a member of 'std'; did you mean 'uintmax_t'?

The bug still exists in GCC 13.0.0

[Bug c++/97474] [9 Regression] produces wrong code with references to another field

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|9.5 |10.3

[Bug c++/97474] [9 Regression] produces wrong code with references to another field

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #21 from Jason Merrill  ---
Not backporting to 9.

[Bug target/105572] timeout with -march=bdver2

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
The problem seems to exist before git revision 82a4c5c704433249, dated about a
month ago.

[Bug fortran/49566] [DWARF/DEBUG] Add coarray shapes (codimensions) to the debug output

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

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

--- Comment #4 from Eric Gallager  ---
Does this still need to be in WAITING?

[Bug c/105572] New: timeout with -march=bdver2

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 105572
   Summary: timeout with -march=bdver2
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 52956
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52956=edit
C source code

For the attached C code, adding -march=bdver2 causes the compiler to 
spend a lot of time.

$ time /home/dcb/gcc/results/bin/gcc  -w -c -g -O3 bug810.c

real0m3.344s
user0m3.133s
sys 0m0.089s
$ (ulimit -t 300; time /home/dcb/gcc/results/bin/gcc  -w -c -g -O3
-march=bdver2  bug810.c)
gcc: fatal error: Killed signal terminated program as
compilation terminated.

real5m20.276s
user5m8.801s
sys 0m0.880s
$  /home/dcb/gcc/results/bin/gcc  -v 2>&1 | fgrep exp
gcc version 13.0.0 20220511 (experimental) (5b2a24ebfc0b2b4c) 
$

[Bug bootstrap/105567] [13 regression] bootstrap failure on arm due to bogus constructor warning

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

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug c++/105541] [12/13 Regression] ICE: Segmentation fault when template lambda in requires-clause

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:88459c3965e2a2f62ab4d4c8b2ac8460b1a15c33

commit r13-332-g88459c3965e2a2f62ab4d4c8b2ac8460b1a15c33
Author: Jason Merrill 
Date:   Wed May 11 14:53:26 2022 -0400

c++: lambda template in requires [PR105541]

Since the patch for PR103408, the template parameters for the lambda in
this
test have level 1 instead of 2, and we were treating null template args as
1
level of arguments, so tsubst_template_parms decided it had nothing to do.
Fixed by distinguishing between <> and no args at all, which is what we
have
in our "substitution" in a requires-expression.

PR c++/105541

gcc/cp/ChangeLog:

* cp-tree.h (TMPL_ARGS_DEPTH): 0 for null args.
* parser.cc (cp_parser_enclosed_template_argument_list):
Use 0-length TREE_VEC for <>.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/lambda-requires1.C: New test.

[Bug c++/105571] New: Spurious "set but not used" on static constexpr local, used in lambda

[cuzdav at gmail dot com via Gcc-bugs]

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

Bug ID: 105571
   Summary: Spurious "set but not used" on static constexpr local,
used in lambda
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cuzdav at gmail dot com
  Target Milestone: ---

With -Wall, in every c++ language level on virtually every version of g++ as
far back as 4.9, g++ warns ("variable 'THIS_IS_USED' set but not used") on the
following complete code:


template 
void for_each(IterT b, IterT e, FuncT f) {
while (b != e) {
f(*b++);
}
}

volatile int sink; 
void xxx(int x) {
sink = x;
}

void foo() {
static constexpr auto THIS_IS_USED = 1;  
int arr[10]{1,2,3,4,5,6,7,8,9,10};

for_each(arr, arr+10, [](auto v) {
xxx(THIS_IS_USED + v);
});
}


: In function 'void foo()':
:15:27: warning: variable 'THIS_IS_USED' set but not used
[-Wunused-but-set-variable]
   15 | static constexpr auto THIS_IS_USED = 1;
  |   ^~~~
Compiler returned: 0

https://godbolt.org/z/b1s5Yqb3r


This appears to be related to the "auto" parameter in the lambda.  Changing it
to 'int' makes the problem go away.

[Bug testsuite/105570] new test case gfortran.dg/pr102860.f90 uses invalid option

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Jakub Jelinek  ---
Fixed.

[Bug middle-end/102860] [12 regression] libgomp.fortran/simd2.f90 ICEs after r12-4526

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

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

--- Comment #17 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

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

commit r9-10157-g6d79958a50eb5419ebb9baa5ef880aabeef05467
Author: Jakub Jelinek 
Date:   Wed May 11 20:37:01 2022 +0200

testsuite: Fix up pr102860.f90 for gcc 9 [PR105570]

Apparently -mcpu=power10 is gcc 10+, but the PR102860 change otherwise
made sense also for 9.x.  So just adjusting testcase...

2022-05-11  Jakub Jelinek  

PR middle-end/102860
PR testsuite/105570
* gfortran.dg/pr102860.f90: Use -mcpu=power9 instead of
-mcpu=power10.

[Bug testsuite/105570] new test case gfortran.dg/pr102860.f90 uses invalid option

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

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

--- Comment #2 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

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

commit r9-10157-g6d79958a50eb5419ebb9baa5ef880aabeef05467
Author: Jakub Jelinek 
Date:   Wed May 11 20:37:01 2022 +0200

testsuite: Fix up pr102860.f90 for gcc 9 [PR105570]

Apparently -mcpu=power10 is gcc 10+, but the PR102860 change otherwise
made sense also for 9.x.  So just adjusting testcase...

2022-05-11  Jakub Jelinek  

PR middle-end/102860
PR testsuite/105570
* gfortran.dg/pr102860.f90: Use -mcpu=power9 instead of
-mcpu=power10.

[Bug c++/105569] [12/13 Regression] -Waddress warns on dynamic_cast

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

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

--- Comment #3 from Marek Polacek  ---
Actually this is probably a better fix; I don't suppose we want to issue
warnings for the compiler-generated POINTER_PLUS_EXPRs.

--- a/gcc/cp/class.cc
+++ b/gcc/cp/class.cc
@@ -518,6 +518,8 @@ build_base_path (enum tree_code code,

   expr = build1 (NOP_EXPR, ptr_target_type, expr);

+  suppress_warning (expr, OPT_Waddress);
+
  indout:
   if (!want_pointer)
 {

[Bug bootstrap/105567] [13 regression] bootstrap failure on arm due to bogus constructor warning

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:4dc86f716fe6087f1cf786d69c0c6f3f5af810f0

commit r13-331-g4dc86f716fe6087f1cf786d69c0c6f3f5af810f0
Author: Jason Merrill 
Date:   Wed May 11 09:44:57 2022 -0400

c++: fix arm-eabi bootstrap [PR105567]

Since my r13-112, in the template we were changing 'return' to 'return
this'
on cdtor_returns_this targets, and then getting confused by that when
instantiating.  So only make that change at instantiation time.

PR bootstrap/105567

gcc/cp/ChangeLog:

* typeck.cc (check_return_expr): Don't mess with ctor return value
while parsing a template.

gcc/testsuite/ChangeLog:

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

[Bug c++/103672] [10/11 Regression] using with template class> causes internal compiler error

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug fortran/105230] [9/10/11/12/13 Regression] ICE in find_array_section, at fortran/expr.cc:1634

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:0acdbe29f66017fc5cca40dcbd72a0dd41491d07

commit r13-330-g0acdbe29f66017fc5cca40dcbd72a0dd41491d07
Author: Harald Anlauf 
Date:   Tue May 10 23:41:57 2022 +0200

Fortran: fix error recovery on invalid array section

gcc/fortran/ChangeLog:

PR fortran/105230
* expr.cc (find_array_section): Correct logic to avoid NULL
pointer dereference on invalid array section.

gcc/testsuite/ChangeLog:

PR fortran/105230
* gfortran.dg/pr105230.f90: New test.

Co-authored-by: Steven G. Kargl 

[Bug fortran/105542] [F03] Orthogonal standard-conforming type finalization tests

[everythingfunctional at protonmail dot com via Gcc-bugs]

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

Brad Richardson  changed:

   What|Removed |Added

 CC||everythingfunctional@proton
   ||mail.com

--- Comment #4 from Brad Richardson  ---
Hi Jerry,

I recently added some new tests that are causing gfortran to crash, see the
runtime error you show:

At line 42 of file test/usage_test.f90
Fortran runtime error: Attempt to DEALLOCATE unallocated 'the_resource'

The output that Damian shows is from prior to adding those tests, and the
reported test failures describe the aspects of finalization that gfortran is
not performing correctly. You can check out commit f7cfe04 to see those
failures. Specifically gfortran fails to finalize:

* a non-allocatable object on the LHS of an intrinsic assignment
* an allocated allocatable LHS of an intrinsic assignment
* a function reference on the RHS of an intrinsic assignment
* a specification expression function result

Let me know if you need any more help identifying/exploring the test failures.

PS glad you had a good experience with fpm

[Bug c++/101194] [9/10 Regression] aggregate init requires default constructor

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Patrick Palka
:

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

commit r10-10716-g5fcedef529c7564b6485ab2893c08865798a66ec
Author: Patrick Palka 
Date:   Wed Jun 30 20:44:52 2021 -0400

c++: cxx_eval_array_reference and empty elem type [PR101194]

Here the initializer for x is represented as an empty CONSTRUCTOR due to
its empty element type.  So during constexpr evaluation of the ARRAY_REF
x[0], we end up trying to value initialize the omitted element at index 0,
which fails because the element type is not default constructible.

This patch makes cxx_eval_array_reference specifically handle the case
where the element type is an empty type.

PR c++/101194

gcc/cp/ChangeLog:

* constexpr.c (cxx_eval_array_reference): When the element type
is an empty type and the corresponding element is omitted, just
return an empty CONSTRUCTOR instead of attempting value
initialization.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-empty16.C: New test.

(cherry picked from commit a688c284dd3848b6c4ea553035f0f9769fb4fbc9)

[Bug c++/105569] [12/13 Regression] -Waddress warns on dynamic_cast

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Candidate fix:

--- a/gcc/cp/rtti.cc
+++ b/gcc/cp/rtti.cc
@@ -844,6 +844,9 @@ build_dynamic_cast (location_t loc, tree type, tree expr,
   if (r != error_mark_node)
 maybe_warn_about_useless_cast (loc, type, expr, complain);
   protected_set_expr_location (r, loc);
+  tree sr = r;
+  STRIP_TYPE_NOPS (sr);
+  suppress_warning (sr, OPT_Waddress);
   return r;
 }

[Bug c++/55004] [meta-bug] constexpr issues

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

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

Bug 99700 Summary: [10 Regression] uninitialized variable accepted as a 
constant expression in C++ 20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99700

   What|Removed |Added

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

[Bug c++/99700] [10 Regression] uninitialized variable accepted as a constant expression in C++ 20

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|10.4|11.0
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Patrick Palka  ---
The patch doesn't apply cleanly to the 10 branch, and since this is only a
C++20 regression, it doesn't seem worth backporting.

[Bug c++/95986] Partial specialization of class template is not found when class template has NTTP of class type

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug testsuite/105570] new test case gfortran.dg/pr102860.f90 uses invalid option

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

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

--- Comment #1 from Jakub Jelinek  ---
Oops, I was just testing the backports on x86_64-linux.
The fix itself is generic, and thus IMHO worth the backport, so I think the
options are kill the testcase on the branch, or just stop using -mcpu=power9
there.

[Bug c++/95982] [10 Regression] ICE with non-type template parameter that is itself the instantiation of a template

[bence.kodaj at gmail dot com via Gcc-bugs]

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

Bence Kodaj  changed:

   What|Removed |Added

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

--- Comment #7 from Bence Kodaj  ---
Fixed in GCC 11.1.

[Bug c++/95986] Partial specialization of class template is not found when class template has NTTP of class type

[bence.kodaj at gmail dot com via Gcc-bugs]

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

Bence Kodaj  changed:

   What|Removed |Added

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

--- Comment #4 from Bence Kodaj  ---
Fixed in GCC 12.1.

[Bug testsuite/105570] New: new test case gfortran.dg/pr102860.f90 uses invalid option

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

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

Bug ID: 105570
   Summary: new test case gfortran.dg/pr102860.f90 uses invalid
option
   Product: gcc
   Version: 9.4.1
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:95f6eb7ae707482fdeed57b0906dacb8e675385d, r9-10118
make  -k check-gcc-fortran RUNTESTFLAGS="dg.exp=gfortran.dg/pr102860.f90"
FAIL: gfortran.dg/pr102860.f90   -O  (test for excess errors)
# of unexpected failures1

commit 95f6eb7ae707482fdeed57b0906dacb8e675385d (HEAD, refs/bisect/bad)
Author: Jakub Jelinek 
Date:   Wed Jan 19 15:03:45 2022 +0100

match.pd, optabs: Avoid vectorization of {FLOOR,CEIL,ROUND}_{DIV,MOD}_EXPR
[PR102860]


spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-9-test/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/git/build/gcc-9-test/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/git/build/gcc-9-test/powerpc64le-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/git/gcc-9-test/gcc/testsuite/gfortran.dg/pr102860.f90
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -O -O2 -mcpu=power10 -S -o pr102860.s
gfortran: error: unrecognized argument in option '-mcpu=power10'
gfortran: note: valid arguments to '-mcpu=' are: 401 403 405 405fp 440 440fp
464 464fp 476 476fp 505 601 602 603 603e 604 604e 620 630 740 7400 7450 750 801
821 823 8540 8548 860 970 G3 G4 G5 a2 cell e300c2 e300c3 e500mc e500mc64 e5500
e6500 ec603e native power3 power4 power5 power5+ power6 power6x power7 power8
power9 powerpc powerpc64 powerpc64le rs64 titan; did you mean 'power3'?
compiler exited with status 1
FAIL: gfortran.dg/pr102860.f90   -O  (test for excess errors)
Excess errors:
gfortran: error: unrecognized argument in option '-mcpu=power10'


gcc 9 does not support power10

[Bug c++/95986] Partial specialization of class template is not found when class template has NTTP of class type

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

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

Patrick Palka  changed:

   What|Removed |Added

  Known to fail||10.3.0, 11.3.0
 CC||ppalka at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||ice-on-valid-code
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=103672
   Last reconfirmed||2022-05-11
  Known to work||12.1.0

--- Comment #3 from Patrick Palka  ---
This appears to be fixed in GCC 12 ever since r12-6773-g09845ad7569bac.

[Bug c++/105569] [12/13 Regression] -Waddress warns on dynamic_cast

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
Summary|-Waddress warns on  |[12/13 Regression]
   |dynamic_cast|-Waddress warns on
   ||dynamic_cast
 CC||mpolacek at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
   Last reconfirmed||2022-05-11
 Ever confirmed|0   |1
   Priority|P3  |P2
   Keywords||diagnostic
   Target Milestone|--- |12.2

--- Comment #1 from Marek Polacek  ---
Started with r12-4059-g4dc7ce6fb39179.  Maybe all we need is a
warning_sentinel.

[Bug c++/105569] New: -Waddress warns on dynamic_cast

[anton.reinhard at protonmail dot com via Gcc-bugs]

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

Bug ID: 105569
   Summary: -Waddress warns on dynamic_cast
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anton.reinhard at protonmail dot com
  Target Milestone: ---

compiling with -Waddress yields a useless warning compiling the following code:

Compiler version:
$ 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) 

Compiled using:
$ g++ warn.cpp -Waddress
warn.cpp: In function ‘int main()’:
warn.cpp:12:22: warning: comparing the result of pointer addition ‘(((A*)ref) +
((sizetype)(*(long int*)((& ref)->B::_vptr.B + -24’ and NULL [-Waddress]
   12 | bool b = nullptr == dynamic_cast();
  |  ^

The file warn.cpp:
class A {};

class B : public virtual A {};

class C : public A {};

int main() {
B* object = new B();
B  = *object;

// -Waddress warns here
bool b = nullptr == dynamic_cast();

// -Waddress doesn't warn anymore
auto ptr = dynamic_cast(); 
bool b2 = ptr == nullptr;

C* cobject = new C();
C  = *cobject;

// -Waddress also doesn't warn anymore
bool b3 = nullptr == dynamic_cast();
}

The warning:
warn.cpp: In function ‘int main()’:
warn.cpp:12:22: warning: comparing the result of pointer addition ‘(((A*)ref) +
((sizetype)(*(long int*)((& ref)->B::_vptr.B + -24’ and NULL [-Waddress]
   12 | bool b = nullptr == dynamic_cast();
  |  ^

However, dynamic_cast should return nullptr if the cast failed, so this warning
seems invalid to me. I don't know if just the warning is in error or if the
produced code is buggy.
It only happens when the derived class inherits with virtual (see class C)
It doesn't warn in versions previous to gcc-12, or in any clang versions I've
tried which makes me think it's a bug and not me making a mistake.

[Bug rtl-optimization/105559] [9/10/11/12 Regression] -g and -O3 cause timeout since r12-156-g8d4c374c4419a875

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #7 from David Binderman  ---
Thanks for the fast work. Less than 2.5 hours from reported to fixed
for a bug that hadn't been found for a couple of years.

I should also mention that this bug was produced from code produced by csmith, 
a most excellent C source code generator program.

There is a school of thought that says running csmith regularly over the gcc
trunk
will find bugs.

[Bug target/105355] -msmall-data-limit= unexpectedly accepts a separate argument

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

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

palmer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||palmer at gcc dot gnu.org

--- Comment #6 from palmer at gcc dot gnu.org ---
Sorry, I hadn't seen the original bug.  This looks good to me, I don't think
there was any use case for something like "-msmall-data-limit= N" (ie, with the
space).  Looks like that's been there since the original port, so it was
probably just an oversight.

[Bug libstdc++/103911] std::from_chars shouldn't call isdigit

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:39099827b0f731b5f2da696f6f580156c8a7819c

commit r11-9979-g39099827b0f731b5f2da696f6f580156c8a7819c
Author: Patrick Palka 
Date:   Mon May 2 07:01:33 2022 -0400

libstdc++: Don't use std::tolower in  [PR103911]

As with std::isdigit in r12-6281-gc83ecfbe74a5cf, we shouldn't be using
std::tolower in  either.

PR libstdc++/103911

libstdc++-v3/ChangeLog:

* src/c++17/floating_from_chars.cc (find_end_of_float): Accept
two delimeters for the exponent part in the form of a possibly
NULL string of length two.  Don't use std::tolower.
(pattern): Adjust calls to find_end_of_float accordingly.

(cherry picked from commit 86d821ddf5615e693ead667b2580898f46de8eb9)

[Bug c++/105565] [10/11/12/13 Regression] constexpr function with bigger integral cause internal compiler error

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #6 from Marek Polacek  ---
(Now actually looking at the patch...)

I think you're right, it's likely those concept_check_p calls that did that. 
Doesn't look like we can avoid that.  Thus closing.

[Bug c++/101603] [meta-bug] pointer to member functions issues

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

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

Bug 103455 Summary: [9 Regression] internal compiler error: in dependent_type_p 
since r9-713-gd9338471b91bbe6e1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103455

   What|Removed |Added

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

[Bug c++/103455] [9 Regression] internal compiler error: in dependent_type_p since r9-713-gd9338471b91bbe6e1

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #15 from Patrick Palka  ---
Fixed for GCC 9.5/10.4/11.3/12.

[Bug c++/104225] [9 Regression] accepts-invalid new expression that uses deleted implicit default constructor of class specialization

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #8 from Patrick Palka  ---
Fixed for 9.5/10.4/11.3/12.

[Bug c++/100288] [11/12/13 Regression] g++-11 internal error and fails to precompile a concept

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #11 from Patrick Palka  ---
(In reply to Patrick Palka from comment #10)
> Fixed for 9.5/10.4/11.3/12.

Whoops, wrong PR...

[Bug c++/100288] [11/12/13 Regression] g++-11 internal error and fails to precompile a concept

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #10 from Patrick Palka  ---
Fixed for 9.5/10.4/11.3/12.

[Bug c++/99885] CTAD fails for auto const& NTTP

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|11.0|9.5

[Bug c++/99885] CTAD fails for auto const& NTTP

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

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

Bug 83476 Summary: [9 Regression] Template argument deduction fails with 
reference template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83476

   What|Removed |Added

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

[Bug c++/83476] [9 Regression] Template argument deduction fails with reference template parameter

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #11 from Patrick Palka  ---
Should be fixed for 9.5, 10.4, and 11/12.

[Bug c++/103455] [9 Regression] internal compiler error: in dependent_type_p since r9-713-gd9338471b91bbe6e1

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

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

--- Comment #14 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Patrick Palka
:

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

commit r9-10156-g3d1c151bc1f4a3231f62dc3af758fb7a19f8f904
Author: Patrick Palka 
Date:   Sat Mar 26 10:20:16 2022 -0400

c++: ICE when building builtin operator->* set [PR103455]

Here when constructing the builtin operator->* candidate set according
to the available conversion functions for the operand types, we end up
considering a candidate with C1=T (through B's dependent conversion
function) and C2=F, during which we crash from DERIVED_FROM_P because
dependent_type_p sees a TEMPLATE_TYPE_PARM outside of a template
context.

Sidestepping the question of whether we should be considering such a
dependent conversion function here in the first place, it seems futile
to test DERIVED_FROM_P for anything other than an actual class type, so
this patch fixes this ICE by simply guarding the DERIVED_FROM_P test
with CLASS_TYPE_P instead of MAYBE_CLASS_TYPE_P.

PR c++/103455

gcc/cp/ChangeLog:

* call.c (add_builtin_candidate) : Test
CLASS_TYPE_P instead of MAYBE_CLASS_TYPE_P.

gcc/testsuite/ChangeLog:

* g++.dg/overload/builtin6.C: New test.

(cherry picked from commit 04f19580e8dbdbc7366d0f5fd068aa0cecafdc9d)

[Bug c++/101532] [12 Regression] ICE in finish_expr_stmt, at cp/semantics.c:859

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:4df77364f7fd9ce88c012843fff124346e4d3c06

commit r9-10155-g4df77364f7fd9ce88c012843fff124346e4d3c06
Author: Patrick Palka 
Date:   Tue Jan 25 15:04:49 2022 -0500

c++: deleted fn and noexcept inst [PR101532, PR104225]

Here when attempting to use B's implicitly deleted default constructor,
mark_used rightfully returns false, but for the wrong reason: it
tries to instantiate the synthesized noexcept specifier which then only
silently fails because get_defaulted_eh_spec suppresses diagnostics
for deleted functions.  This lack of diagnostics causes us to crash on
the first testcase below (thanks to the assert in finish_expr_stmt), and
silently accept the second testcase.

To fix this, this patch makes mark_used avoid attempting to instantiate
the noexcept specifier of a deleted function, so that we'll instead
directly reject (and diagnose) the function due to its deletedness.

PR c++/101532
PR c++/104225

gcc/cp/ChangeLog:

* decl2.c (mark_used): Don't consider maybe_instantiate_noexcept
on a deleted function.

gcc/testsuite/ChangeLog:

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

(cherry picked from commit bc90dd0ecf02e11d47d1af7f627e2e2acaa40106)

[Bug c++/104225] [9 Regression] accepts-invalid new expression that uses deleted implicit default constructor of class specialization

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:4df77364f7fd9ce88c012843fff124346e4d3c06

commit r9-10155-g4df77364f7fd9ce88c012843fff124346e4d3c06
Author: Patrick Palka 
Date:   Tue Jan 25 15:04:49 2022 -0500

c++: deleted fn and noexcept inst [PR101532, PR104225]

Here when attempting to use B's implicitly deleted default constructor,
mark_used rightfully returns false, but for the wrong reason: it
tries to instantiate the synthesized noexcept specifier which then only
silently fails because get_defaulted_eh_spec suppresses diagnostics
for deleted functions.  This lack of diagnostics causes us to crash on
the first testcase below (thanks to the assert in finish_expr_stmt), and
silently accept the second testcase.

To fix this, this patch makes mark_used avoid attempting to instantiate
the noexcept specifier of a deleted function, so that we'll instead
directly reject (and diagnose) the function due to its deletedness.

PR c++/101532
PR c++/104225

gcc/cp/ChangeLog:

* decl2.c (mark_used): Don't consider maybe_instantiate_noexcept
on a deleted function.

gcc/testsuite/ChangeLog:

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

(cherry picked from commit bc90dd0ecf02e11d47d1af7f627e2e2acaa40106)

[Bug c++/99885] CTAD fails for auto const& NTTP

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Patrick Palka
:

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

commit r9-10154-gc6432e17960799509c48df6b500a8d069110980b
Author: Patrick Palka 
Date:   Wed Apr 14 08:54:30 2021 -0400

c++: Fix deduction with reference NTTP [PR83476]

In the testcase ref11.C below, during deduction for the call f(a),
uses_deducible_template_parms returns false for the dependent
specialization A because the generic template argument V here is
wrapped in an implicit INDIRECT_REF (formed from template_parm_to_arg).
Since uses_deducible_template_parms returns false, unify_one_argument
exits early without ever attempting to deduce 'n' for 'V'.  This patch
fixes this by making deducible_expression look through such implicit
INDIRECT_REFs.

gcc/cp/ChangeLog:

PR c++/83476
PR c++/99885
* pt.c (deducible_expression): Look through implicit
INDIRECT_REFs as well.

gcc/testsuite/ChangeLog:

PR c++/83476
PR c++/99885
* g++.dg/cpp1z/class-deduction85.C: New test.
* g++.dg/template/ref11.C: New test.

(cherry picked from commit 2ccc05a5141506fde0e20dec702c717fd67bf6ee)

[Bug c++/83476] [9 Regression] Template argument deduction fails with reference template parameter

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

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Patrick Palka
:

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

commit r9-10154-gc6432e17960799509c48df6b500a8d069110980b
Author: Patrick Palka 
Date:   Wed Apr 14 08:54:30 2021 -0400

c++: Fix deduction with reference NTTP [PR83476]

In the testcase ref11.C below, during deduction for the call f(a),
uses_deducible_template_parms returns false for the dependent
specialization A because the generic template argument V here is
wrapped in an implicit INDIRECT_REF (formed from template_parm_to_arg).
Since uses_deducible_template_parms returns false, unify_one_argument
exits early without ever attempting to deduce 'n' for 'V'.  This patch
fixes this by making deducible_expression look through such implicit
INDIRECT_REFs.

gcc/cp/ChangeLog:

PR c++/83476
PR c++/99885
* pt.c (deducible_expression): Look through implicit
INDIRECT_REFs as well.

gcc/testsuite/ChangeLog:

PR c++/83476
PR c++/99885
* g++.dg/cpp1z/class-deduction85.C: New test.
* g++.dg/template/ref11.C: New test.

(cherry picked from commit 2ccc05a5141506fde0e20dec702c717fd67bf6ee)

[Bug c++/105565] [10/11/12/13 Regression] constexpr function with bigger integral cause internal compiler error

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

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

--- Comment #5 from Patrick Palka  ---
I suspect the changes to cxx_eval_call_expression and/or
cxx_eval_constant_expression caused these functions to use more stack space per
recursive call, and this marginal increase was enough to overflow the stack
during constexpr evaluation for this testcase.

[Bug c++/105565] [10/11/12/13 Regression] constexpr function with bigger integral cause internal compiler error

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

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

--- Comment #4 from Marek Polacek  ---
(In reply to Patrick Palka from comment #3)
> Seems we're hitting a stack overflow due to the excessive recursion, same
> with Clang.  Not sure if we can realistically do much about that..

Not sure, either.  But it looks like r278775 exacerbated the problem somehow,
the test reliably fails/compiles after/before that revision.  I wonder why,
it's a concepts patch.

[Bug c++/105565] [10/11/12/13 Regression] constexpr function with bigger integral cause internal compiler error

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #3 from Patrick Palka  ---
Seems we're hitting a stack overflow due to the excessive recursion, same with
Clang.  Not sure if we can realistically do much about that..

[Bug middle-end/105566] [13 regression] ICE in gfortran.dg/ubsan/bind-c-intent-out-2.f90 after r13-222-g28896b38fabce8

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

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

Siddhesh Poyarekar  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Siddhesh Poyarekar  ---
I pushed a fix for this moments ago:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70090#c8

[Bug other/105527] configure option --with-zstd is not documented

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

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

--- Comment #4 from Martin Liška  ---
I welcome that, please send it to gcc-patches mailing list.

[Bug middle-end/105539] -ftrivial-auto-var-init=zero happening too late?

[qing.zhao at oracle dot com via Gcc-bugs]

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

--- Comment #9 from Qing Zhao  ---
> It's a conditional uninit use which we do not warn on early by design
> (for the fear of too many false positives, that is).
Okay. 
> 
>> 2. the ccp optimization deletes the if (z) statement completely:
>> 
>> [opc@qinzhao-aarch64-ol8 105539]$ cat t.c.034t.ccp1
>> 
>> ;; Function x (x, funcdef_no=0, decl_uid=3591, cgraph_uid=1, symbol_order=0)
>> 
>> Removing basic block 3
>> Merging blocks 2 and 4
>> int x (int z)
>> {
>>  int y;
>> 
>>   :
>>  return 10;
>> 
>> }
> 
> That's expected from optimistic lattice propagation which merges TOP with
> the constant.

If y is initialized to 0 at declaration site, the “if z” statement is NOT
deleted by CCP. 

However, per design of -ftrivial-auto-var-init, we intent to not treat

y = .DEFERRED_INIT (4, 2, &"y"[0]);
Same as
y= 0 

In order to keep -Wuninitialized warning analysis working as expected.

So, yes, I agree that this issue is unavoided based on the current design. 

> 
>> are the above two bugs?
> 
> Well, it works as designed.  But sure, that we fail to diagnose the uninit
> use is unfortunate and there exist bugs for this specific issue already.

[Bug other/105527] configure option --with-zstd is not documented

[bruno at clisp dot org via Gcc-bugs]

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

--- Comment #3 from Bruno Haible  ---
Created attachment 52955
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52955=edit
Patch to document also --with-zstd-include and --with-zstd-lib

Hi Martin,

The patch you added is pretty minimal: it refers to undocumented options
--with-zstd-include and --with-zstd-lib; it suggests that --with-zstd can be
used without an argument; and it does not clarify how this option applies to
cross-compilation.

How about adding the same details as for the --with-isl, --with-isl-include,
--with-isl-lib options, mutatis mutandis? Find attached a patch that does that.

[Bug driver/105568] New: Superfluous --jobserver-auth= check taints further diagnostics

[pexu--- via Gcc-bugs]

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

Bug ID: 105568
   Summary: Superfluous --jobserver-auth= check taints further
diagnostics
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: p...@gcc-bugzilla.mail.kapsi.fi
  Target Milestone: ---

Hi.

When linking with -flto=jobserver both gcc/gcc.cc and gcc/lto-wrapper.cc check
if MAKEFLAGS contains "--jobserver-auth=" and if so attempt to further
scrutinize its contents.

Unfortunately, detect_jobserver() (at gcc/gcc.cc), which is executed always
when linking, silently removes the entire "--jobserver-auth=" (up until next
space) shall this scrutinization attempt fail.

This makes jobserver_active_p() (at gcc/lto-wrapper.cc) always complain about a
missing "--jobserver-auth=".  Indeed, this might be now technically true, but
it is very confusing and misleading if this was done because detect_jobserver()
was not satisfied with the given "--jobserver-auth=".

There a many reasons why the given "--jobserver-auth=" might be treated as
non-functioning.  Either GNU make is using an another jobserver type (named
semaphore), the given file descriptors are inaccessible because GNU make and
GCC are using different emulation layers (e.g. Mingw and Cygwin) or those
simply are indeed not inherited, i.e. user forgot to add `+' to invoking GNU
rule.

Therefore it might be still necessary to remove the "--jobserver-auth=" but I
presume this should done after jobserver_active_p().  Actually, this is already
being done, as the entire MAKEFLAGS is emptied unless jobserver logic is
enabled.

[Bug driver/105564] Bad error for -ftrivial-auto-var-init without a choice argument

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

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

--- Comment #3 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #2)
> -ftrivial-auto-var-init to -Wtrivial-auto-var-init is just a single letter
> change, addition of trailing = is a single letter addition, so guess the
> distance is the same and we just choose one.  But perhaps we could special
> case the missing trailing = if it the option is otherwise exact match.

Yep, and both have equal scores and we prefer the option that differs earlier
as was implemented in PR69968. But yes, I bet we can do special handling of
trailing equal sign.

[Bug bootstrap/105567] [13 regression] bootstrap failure on arm due to bogus constructor warning

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
Version|unknown |13.0

[Bug middle-end/105566] [13 regression] ICE in gfortran.dg/ubsan/bind-c-intent-out-2.f90 after r13-222-g28896b38fabce8

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug bootstrap/105567] [13 regression] bootstrap failure on arm due to bogus constructor warning

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug bootstrap/105567] New: [13 regression] bootstrap failure on arm due to bogus constructor warning

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

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

Bug ID: 105567
   Summary: [13 regression] bootstrap failure on arm due to bogus
constructor warning
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rearnsha at gcc dot gnu.org
  Target Milestone: ---

On arm constructors implicitly return 'this', but this is leading to a boottrap
failure.

Reduced testcase:

typedef unsigned int size_t;
template struct vec;
template
class auto_vec : public vec
{
  auto_vec (size_t s )
  {
  {
 return;
  }
  }
};
struct function {
  struct control_flow_graph *cfg;
};
struct edge_iterator {
};
struct control_flow_graph {
  int x_n_basic_blocks;
};
bool
mark_dfs_back_edges (struct function *fun)
{
  auto_vec stack (((fun)->cfg->x_n_basic_blocks) + 1);
}

Compile with 'cc1plus -march=armv8-a+simd -mfloat-abi=hard -O2 -g -Wall
-fno-exceptions -quiet '

[Bug middle-end/70090] add non-constant variant of __builtin_object_size for _FORTIFY_SOURCE and -fsanitize=object-size

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Siddhesh Poyarekar
:

https://gcc.gnu.org/g:546c6210eb08f583ee4f53a0fd7886b6c958c7fa

commit r13-325-g546c6210eb08f583ee4f53a0fd7886b6c958c7fa
Author: Siddhesh Poyarekar 
Date:   Wed May 11 19:13:09 2022 +0530

middle-end/70090: Register __bdos for sanitizers if necessary

The asan initializer registers __builtin_object_size for languages that
don't have it, e.g. Fortran.  Register __builtin_dynamic_object_size too
(we need both because __builtin_dynamic_object_size computation may
involve generating __builtin_object_size as a fallback) so that
gfortran.dg/ubsan/bind-c-intent-out-2.f90 does not crash anymore.

gcc/ChangeLog:

PR middle-end/70090
* asan.cc (initialize_sanitizer_builtins): Register
__builtin_dynamic_object_size if necessary.

Signed-off-by: Siddhesh Poyarekar 

[Bug middle-end/105566] New: new test case ICEs

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

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

Bug ID: 105566
   Summary: new test case ICEs
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:28896b38fabce818e59266b0063a46b3bc1b700f, r13-222-g28896b38fabce8
make  -k check-gcc
RUNTESTFLAGS="ubsan.exp=gfortran.dg/ubsan/bind-c-intent-out-2.f90"
FAIL: gfortran.dg/ubsan/bind-c-intent-out-2.f90   -O1  (internal compiler
error: Segmentation fault)
FAIL: gfortran.dg/ubsan/bind-c-intent-out-2.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/ubsan/bind-c-intent-out-2.f90   -O2  (internal compiler
error: Segmentation fault)
FAIL: gfortran.dg/ubsan/bind-c-intent-out-2.f90   -O2  (test for excess errors)
FAIL: gfortran.dg/ubsan/bind-c-intent-out-2.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal compiler
error: Segmentation fault)
FAIL: gfortran.dg/ubsan/bind-c-intent-out-2.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
FAIL: gfortran.dg/ubsan/bind-c-intent-out-2.f90   -O3 -g  (internal compiler
error: Segmentation fault)
FAIL: gfortran.dg/ubsan/bind-c-intent-out-2.f90   -O3 -g  (test for excess
errors)
FAIL: gfortran.dg/ubsan/bind-c-intent-out-2.f90   -Os  (internal compiler
error: Segmentation fault)
FAIL: gfortran.dg/ubsan/bind-c-intent-out-2.f90   -Os  (test for excess errors)


spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/ubsan/bind-c-intent-out-2.f90
-fdiagnostics-plain-output
-B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libsanitizer/
-B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libsanitizer/ubsan/
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libsanitizer/ubsan/.libs
-fdiagnostics-plain-output -O1 -fsanitize=undefined -fcheck=all
-B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libatomic/.libs
-B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libquadmath/.libs
-lm -o ./bind-c-intent-out-2.exe^M
during GIMPLE pass: ubsan^M
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/ubsan/bind-c-intent-out-2.f90:39:19:
internal compiler error: Segmentation fault^M
0x10caea33 crash_signal^M
/home/seurer/gcc/git/gcc-test/gcc/toplev.cc:322^M
0x11101880 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)^M
/home/seurer/gcc/git/gcc-test/gcc/tree.h:3570^M
0x11101880 build_call_expr_loc_array(unsigned int, tree_node*, int,
tree_node**)^M
/home/seurer/gcc/git/gcc-test/gcc/tree.cc:10629^M
0x11101a63 build_call_expr_loc(unsigned int, tree_node*, int, ...)^M
/home/seurer/gcc/git/gcc-test/gcc/tree.cc:10662^M
0x10ce9027 instrument_object_size^M
/home/seurer/gcc/git/gcc-test/gcc/ubsan.cc:2173^M
0x10cf165b execute^M
/home/seurer/gcc/git/gcc-test/gcc/ubsan.cc:2428^M


commit 28896b38fabce818e59266b0063a46b3bc1b700f (HEAD, refs/bisect/bad)
Author: Siddhesh Poyarekar 
Date:   Tue May 10 12:51:42 2022 +0530

middle-end/70090: Dynamic sizes for -fsanitize=object-size

[Bug c++/105563] Consteval copy-constructor is allowed in not-constant expression

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

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-05-11
 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/105565] [10/11/12/13 Regression] constexpr function with bigger integral cause internal compiler error

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

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||compile-time-hog,
   ||memory-hog, needs-reduction
Summary|[11 Regression] constexpr   |[10/11/12/13 Regression]
   |function with bigger|constexpr function with
   |integral  cause internal|bigger integral  cause
   |compiler error  |internal compiler error
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |10.4
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-05-11

--- Comment #2 from Marek Polacek  ---
Confirmed, I think.  We've started to run out of memory with r278775.  It'd be
nice to understand why, and perhaps do something about it, if possible.

[Bug c++/105565] [11 Regression] constexpr function with bigger integral cause internal compiler error

[chenzhipeng02 at agora dot io via Gcc-bugs]

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

--- Comment #1 from chenzhipeng  ---
Comment on attachment 52954
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52954
isPrimeConstexpr for 1073741789 compiled successfully but 2147483647 fail

>#include 
>
>using LL = long long;
>
>constexpr bool isPrimeR(LL n, LL c) {
>  return (c * c > n) ? true : (n % c == 0) ? false : isPrimeR(n, c + 2);
>}
>
>constexpr bool isPrimeConstexpr(LL n) {
>  return (n <= 1) ? false : n < 4 || (n % 2 == 1 && isPrimeR(n, 3));
>}
>
>int main() {
>  {
>constexpr LL m = 1073741789LL;  // prime
>constexpr bool x = isPrimeConstexpr(m);
>std::cout << m << " is " <<  (x ? "prime" : "not prime") << '\n';
>  }
>
>  // g++-11: internal compiler error: Segmentation fault: 11 signal terminated 
> program cc1plus
>  // {
>  //   constexpr LL m = 44657LL * 44683LL;  // 1995408731
>  //   constexpr bool x = isPrimeConstexpr(m);
>  //   std::cout << m << " is " <<  (x ? "prime" : "not prime") << '\n';
>  // }
>
>  // g++-11: internal compiler error: Segmentation fault: 11 signal terminated 
> program cc1plus
>  // {
>  //   constexpr LL m = 2147483647LL;  // prime 2^31 - 1
>  //   constexpr bool x = isPrimeConstexpr(m);
>  //   std::cout << m << " is " <<  (x ? "prime" : "not prime") << '\n';
>  // }
>
>  return 0;
>}

[Bug c++/105565] New: [11 Regression] constexpr function with bigger integral cause internal compiler error

[chenzhipeng02 at agora dot io via Gcc-bugs]

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

Bug ID: 105565
   Summary: [11 Regression] constexpr function with bigger
integral  cause internal compiler error
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chenzhipeng02 at agora dot io
  Target Milestone: ---

Created attachment 52954
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52954=edit
isPrimeConstexpr for 1073741789 compiled successfully but 2147483647 fail

The following code is bugInConstexpr.cpp in the Attachment

#include 
using LL = long long;

constexpr bool isPrimeR(LL n, LL c) {
  return (c * c > n) ? true : (n % c == 0) ? false : isPrimeR(n, c + 2);
}

constexpr bool isPrimeConstexpr(LL n) {
  return (n <= 1) ? false : n < 4 || (n % 2 == 1 && isPrimeR(n, 3));
}

int main() {
  {
constexpr LL m = 1073741789LL;  // prime
constexpr bool x = isPrimeConstexpr(m);
std::cout << m << " is " <<  (x ? "prime" : "not prime") << '\n';
  }

  // g++-11: internal compiler error: Segmentation fault: 11 signal terminated
program cc1plus
  // {
  //   constexpr LL m = 44657LL * 44683LL;  // 1995408731
  //   constexpr bool x = isPrimeConstexpr(m);
  //   std::cout << m << " is " <<  (x ? "prime" : "not prime") << '\n';
  // }

  // g++-11: internal compiler error: Segmentation fault: 11 signal terminated
program cc1plus
  // {
  //   constexpr LL m = 2147483647LL;  // prime 2^31 - 1
  //   constexpr bool x = isPrimeConstexpr(m);
  //   std::cout << m << " is " <<  (x ? "prime" : "not prime") << '\n';
  // }

  return 0;
}

It is used to check whether the constexpr number is prime or not.

$ g++-11 bugInConstexpr.cpp -std=c++17 -fconstexpr-depth=10

will compile successfully, but if m changes to be 2147483647, it will compile
fail
with message

g++-11: internal compiler error: Segmentation fault: 11 signal terminated
program cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

!!! But Work fine in gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0

$ g++-11 -v

Using built-in specs.
COLLECT_GCC=g++-11
COLLECT_LTO_WRAPPER=/opt/homebrew/Cellar/gcc/11.1.0_1/libexec/gcc/aarch64-apple-darwin20/11.1.0/lto-wrapper
Target: aarch64-apple-darwin20
Configured with: ../configure --prefix=/opt/homebrew/Cellar/gcc/11.1.0_1
--libdir=/opt/homebrew/Cellar/gcc/11.1.0_1/lib/gcc/11 --disable-nls
--enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran
--program-suffix=-11 --with-gmp=/opt/homebrew/opt/gmp
--with-mpfr=/opt/homebrew/opt/mpfr --with-mpc=/opt/homebrew/opt/libmpc
--with-isl=/opt/homebrew/opt/isl --with-zstd=/opt/homebrew/opt/zstd
--with-pkgversion='Homebrew GCC 11.1.0_1'
--with-bugurl=https://github.com/Homebrew/homebrew-core/issues
--build=aarch64-apple-darwin20 --with-system-zlib --disable-multilib
--with-native-system-header-dir=/usr/include
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.0 (Homebrew GCC 11.1.0_1) 

MacOS Monterey 12.3.1

---

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

Ubuntu 22.04

[Bug bootstrap/105561] Nondeterministic ICE on creation of bits/stdc++.h.gch/O2g.gch and bits/extc++.h.gch/O2g.gch

[swilde--- via Gcc-bugs]

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

--- Comment #3 from Sascha Wilde  ---
(In reply to Richard Biener from comment #1)
> I wonder if you can get a backtrace from gdb for the crash?  When you add -v
> to the failing command you should see cc1plus being invoked, trace on that
> command.

Reading symbols from /home/wilde/src/gcc-12.1.0-build/./gcc/cc1plus...
run(gdb) run
Starting program: /home/wilde/src/gcc-12.1.0-build/gcc/cc1plus -quiet
-nostdinc++ -nostdinc++ -v -I
/home/wilde/src/gcc-12.1.0-build/i386-unknown-netbsdelf9.2/libstdc++-v3/include/i386-unknown-netbsdelf9.2
-I
/home/wilde/src/gcc-12.1.0-build/i386-unknown-netbsdelf9.2/libstdc++-v3/include
-I /home/wilde/src/gcc-12.1.0/libstdc++-v3/libsupc++ -iprefix
/home/wilde/src/gcc-12.1.0-build/gcc/../lib/gcc/i386-unknown-netbsdelf9.2/12.1.0/
-isystem /home/wilde/src/gcc-12.1.0-build/./gcc/include -isystem
/home/wilde/src/gcc-12.1.0-build/./gcc/include-fixed -isystem
/usr/local/i386-unknown-netbsdelf9.2/include -isystem
/usr/local/i386-unknown-netbsdelf9.2/sys-include
/home/wilde/src/gcc-12.1.0/libstdc++-v3/include/precompiled/stdc++.h -quiet
-dumpdir i386-unknown-netbsdelf9.2/bits/stdc++.h.gch/O2g.gch- -dumpbase
stdc++.h -dumpbase-ext .h -mtune=generic -march=i486 -g -g -O2 -O2 -version
-fchecking=1 -o /tmp//cccDHD3H.s --output-pch=
i386-unknown-netbsdelf9.2/bits/stdc++.h.gch/O2g.gch
GNU C++17 (GCC) version 12.1.0 (i386-unknown-netbsdelf9.2)
compiled by GNU C version 12.1.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.0, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/i386-unknown-netbsdelf9.2/include"
ignoring nonexistent directory
"/usr/local/i386-unknown-netbsdelf9.2/sys-include"
ignoring nonexistent directory
"/home/wilde/src/gcc-12.1.0-build/gcc/../lib/gcc/i386-unknown-netbsdelf9.2/12.1.0/include"
ignoring nonexistent directory
"/home/wilde/src/gcc-12.1.0-build/gcc/../lib/gcc/i386-unknown-netbsdelf9.2/12.1.0/include-fixed"
ignoring nonexistent directory
"/home/wilde/src/gcc-12.1.0-build/gcc/../lib/gcc/i386-unknown-netbsdelf9.2/12.1.0/../../../../i386-unknown-netbsdelf9.2/include"
ignoring nonexistent directory
"/usr/local/lib/gcc/i386-unknown-netbsdelf9.2/12.1.0/include"
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/local/lib/gcc/i386-unknown-netbsdelf9.2/12.1.0/include-fixed"
ignoring nonexistent directory "/usr/local/i386-unknown-netbsdelf9.2/include"
#include "..." search starts here:
#include <...> search starts here:

/home/wilde/src/gcc-12.1.0-build/i386-unknown-netbsdelf9.2/libstdc++-v3/include/i386-unknown-netbsdelf9.2

/home/wilde/src/gcc-12.1.0-build/i386-unknown-netbsdelf9.2/libstdc++-v3/include
 /home/wilde/src/gcc-12.1.0/libstdc++-v3/libsupc++
 /home/wilde/src/gcc-12.1.0-build/./gcc/include
 /home/wilde/src/gcc-12.1.0-build/./gcc/include-fixed
 /usr/include
End of search list.
GNU C++17 (GCC) version 12.1.0 (i386-unknown-netbsdelf9.2)
compiled by GNU C version 12.1.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.0, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: a1413fe37641e0518146e5d1b732cd59

Program received signal SIGBUS, Bus error.
0xb0cb4957 in __mmap () from /usr/lib/libc.so.12
(gdb) bt
#0  0xb0cb4957 in __mmap () from /usr/lib/libc.so.12
#1  0xb0cb1823 in mmap () from /usr/lib/libc.so.12
#2  0x08d7881d in netbsd_gt_pch_get_address (size=,
fd=) at ../../gcc-12.1.0/gcc/config/host-netbsd.cc:53
#3  0x086baf8d in gt_pch_save (f=) at
../../gcc-12.1.0/gcc/ggc-common.cc:529
#4  0x084d3030 in c_common_write_pch () at
../../gcc-12.1.0/gcc/c-family/c-pch.cc:175
#5  0x0832258d in c_parse_final_cleanups () at
../../gcc-12.1.0/gcc/cp/decl2.cc:5075
#6  0x084d2bf1 in c_common_parse_file () at
../../gcc-12.1.0/gcc/c-family/c-opts.cc:1262
#7  0x089bbc3e in compile_file () at ../../gcc-12.1.0/gcc/toplev.cc:452
#8  0x09a1fbf5 in do_compile (no_backend=) at
../../gcc-12.1.0/gcc/toplev.cc:2168
#9  toplev::main (this=, argc=, argv=)
at ../../gcc-12.1.0/gcc/toplev.cc:2320
#10 0x09a21b12 in main (argc=41, argv=0xbfb86ad0) at
../../gcc-12.1.0/gcc/main.cc:39
(gdb)

[Bug rtl-optimization/105559] [9/10/11/12 Regression] -g and -O3 cause timeout since r12-156-g8d4c374c4419a875

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||13.0
   Priority|P3  |P2
Summary|[12/13 Regression] -g and   |[9/10/11/12 Regression] -g
   |-O3 cause timeout since |and -O3 cause timeout since
   |r12-156-g8d4c374c4419a875   |r12-156-g8d4c374c4419a875
   Target Milestone|12.2|9.5

[Bug libstdc++/105562] std::function::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing

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

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #6)
> Created attachment 52953 [details]
> Precompiled testcase
> 
> This .ii is based on the gcc-12 code, but with some tweaks to compile with
> gcc-10.

This a-re.ii warns with:

g++ a-re.ii -O1 -fno-strict-aliasing -Wsystem-headers -Wmaybe-uninitialized

[Bug libstdc++/105562] std::function::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing

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

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

--- Comment #6 from Jonathan Wakely  ---
Created attachment 52953
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52953=edit
Precompiled testcase

This .ii is based on the gcc-12 code, but with some tweaks to compile with
gcc-10.

[Bug libstdc++/105562] std::function::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing

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

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

--- Comment #5 from Jonathan Wakely  ---
The fact that -fno-lifetime-dse silences the warning seems to confirm it's that
commit.

[Bug middle-end/105469] "execution reached an unreachable program point" with -flto since r5-7027-g0b986c6ac777aa4e

[remi.coulom at gmail dot com via Gcc-bugs]

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

--- Comment #14 from Rémi Coulom  ---
Thanks for investigating the bug.

Can you recommend a workaround at this point?

I don't want to tell users of the library to change their compilation options,
so I tried this in class Client_Data:

#ifdef __GNUC__
// Workaround for gcc bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105469
   __attribute__ ((noinline))
#endif
   void update()
   {
...
   }

It seems to be working OK for the moment, but all kinds of random changes to
the code seemed to make the bug appear or disappear in the past, so I am not
completely satisfied with this situation. Can you explain the bug better? Do
you have any recommendation?

Thanks.

[Bug libstdc++/105562] std::function::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing

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

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

--- Comment #4 from Jonathan Wakely  ---
Looks like it started with r11-2238

[Bug bootstrap/105561] Nondeterministic ICE on creation of bits/stdc++.h.gch/O2g.gch and bits/extc++.h.gch/O2g.gch

[swilde--- via Gcc-bugs]

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

--- Comment #2 from Sascha Wilde  ---
(In reply to Richard Biener from comment #1)
> I wonder if you can get a backtrace from gdb for the crash?  When you add -v
> to the failing command you should see cc1plus being invoked, trace on that
> command.
> 
> Does NetBSD have address space randomization?  That might influence whether
> the bug reproduces or not.

Yes NetBSD 9.2 has address space layout randomization active.

By "trace" you mean running the cc1plus command in gdb?

[Bug rtl-optimization/105559] [12/13 Regression] -g and -O3 cause timeout since r12-156-g8d4c374c4419a875

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:37a8220fa9188470c677abfef50c1b120c0b6c76

commit r13-323-g37a8220fa9188470c677abfef50c1b120c0b6c76
Author: Richard Biener 
Date:   Wed May 11 13:34:37 2022 +0200

rtl-optimization/105559 - avoid quadratic behavior in delete_insn_and_edges

When the insn to delete is a debug insn there's no point in figuring
out whether it might be the last real insn and thus we have to purge
dead edges.

2022-05-11  Richard Biener  

PR rtl-optimization/105559
* cfgrtl.cc (delete_insn_and_edges): Only perform search to BB_END
for non-debug insns.

[Bug driver/105564] Bad error for -ftrivial-auto-var-init without a choice argument

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
-ftrivial-auto-var-init to -Wtrivial-auto-var-init is just a single letter
change, addition of trailing = is a single letter addition, so guess the
distance is the same and we just choose one.  But perhaps we could special case
the missing trailing = if it the option is otherwise exact match.

[Bug driver/105564] Bad error for -ftrivial-auto-var-init without a choice argument

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

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

Martin Liška  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-05-11
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Yeah, taking look at it now..

[Bug other/105527] configure option --with-zstd is not documented

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

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||13.0

--- Comment #2 from Martin Liška  ---
Fixed on master so far.