[Bug analyzer/110426] New: Missing buffer overflow warning with function pointer that has the alloc_size attribute

[alexhenrie24 at gmail dot com via Gcc-bugs]

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

Bug ID: 110426
   Summary: Missing buffer overflow warning with function pointer
that has the alloc_size attribute
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: alexhenrie24 at gmail dot com
  Target Milestone: ---

I expected to get a warning when compiling this program with -fanalyzer:

#include 

extern void* (*my_alloc)(size_t) __attribute__ ((alloc_size (1)));

int main(void)
{
int *x = my_alloc(1);
x[0] = 0; // buffer overflow!
return 0;
}

There is a warning if I call malloc instead of my_alloc.

[Bug rtl-optimization/92151] Spurious register copying

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Alexander Monakov from comment #3)
> 
> Here's a manually reduced variant that exhibits a similar issue at -O1:
> 
> void foo(int num, int c) {
> asm("# %0" : "+r"(num));
> while (--c)
> asm goto("# %0" :: "r"(num) :: l2);
> l2:
> asm("# %0" :: "r"(num));
> }

Note the DEAD_REG is updated in IRA anyways so that is not the issue.

This reduced testcase seems to be fixed in GCC 11+, maybe r11-209
(https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545442.html).

The original testcase did fix on mov issue.
But 
  __asm__("\t mov   %q[w], (%q[d])\n"   // write
: "=m" (*d) : [d] "r" (d), [w] "r" (w)) ;
  __asm__("\t lea   8(%q[d]), %q[d]\n"
: [d] "+r" (d)) ;

Still causes an extra move to happen.

Note there was one improvement in GCC 11 in the original testcase too.

I think TWITCH difference is due to the way register variables are represented
in gimple ...

[Bug target/110264] internal compiler error: riscv_vector::vector_insn_info::get_avl_reg_rtx

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

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

Kito Cheng  changed:

   What|Removed |Added

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

--- Comment #7 from Kito Cheng  ---
Fixed on trunk and backported to GCC 13

[Bug rtl-optimization/98619] aarch64: ICE (verify_flow_info failed) with asm goto with output and same block and two labels

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-June/62
   ||2906.html
   Keywords||patch

--- Comment #4 from Andrew Pinski  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/622906.html

[Bug middle-end/103979] asm goto is not considered volatile with output operands

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-June/62
   ||2906.html
   Keywords||patch

--- Comment #8 from Andrew Pinski  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/622906.html

[Bug tree-optimization/110420] [12/13/14 Regression] internal compiler error: in gimple_redirect_edge_and_branch due to simple_dce_from_worklist removing `asm goto`

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-June/62
   ||2906.html

--- Comment #6 from Andrew Pinski  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/622906.html

[Bug target/110264] internal compiler error: riscv_vector::vector_insn_info::get_avl_reg_rtx

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Pan Li :

https://gcc.gnu.org/g:2f3eedccaff8b6c65869ed50a7733138740325ff

commit r13-7482-g2f3eedccaff8b6c65869ed50a7733138740325ff
Author: Juzhe-Zhong 
Date:   Fri Jun 16 16:02:31 2023 +0800

RISC-V: Fix VL operand bug in VSETVL PASS[PR110264]

This patch fixes this issue happens on both GCC-13 and GCC-14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110264

The testcase is too big and I failed to reduce it so I didn't append
test into this patch.

This patch should not only land into GCC-14 but also should backport to
GCC-13.

PR target/110264

gcc/ChangeLog:

* config/riscv/riscv-vsetvl.cc (insert_vsetvl): Fix bug.

(cherry picked from commit dd6e1cbac8682106c5167c105f2807014288b852)

[Bug c/110425] Docbug: missing name for builtin function (__builtin_alloca_with_align_and_max?)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Fixed, I forgot to put the PR # in the commit message.
r14-2113-gfb909bc101f2dc7453e0ed187933e39acbab1b21
r13-7481-g87b1fcb2cdccb88fecef9ca57573a0a33b500b8d

[Bug c/110425] Docbug: missing name for builtin function (__builtin_alloca_with_align_and_max?)

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

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

--- Comment #2 from Andrew Pinski  ---
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index c01cd3fe90c..53a1b12f88a 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -13731,7 +13731,7 @@ an extension.  @xref{Variable Length}, for details.

 @enddefbuiltin

-@defbuiltin{{void *}__builtin_alloca_with_align_and_max (size_t size, size_t
alignment, size_t max_size)}
+@defbuiltin{{void *} __builtin_alloca_with_align_and_max (size_t size, size_t
alignment, size_t max_size)}
 Similar to @code{__builtin_alloca_with_align} but takes an extra argument
 specifying an upper bound for @var{size} in case its value cannot be computed
 at compile time, for use by @option{-fstack-usage}, @option{-Wstack-usage}

[Bug c/110425] Docbug: missing name for builtin function (__builtin_alloca_with_align_and_max?)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
   Last reconfirmed||2023-06-27
   Target Milestone|--- |13.2

--- Comment #1 from Andrew Pinski  ---
Literally the fix is just a missing space.

Mine.

[Bug c/110425] New: Docbug: missing name for builtin function (__builtin_alloca_with_align_and_max?)

[hv at crypt dot org via Gcc-bugs]

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

Bug ID: 110425
   Summary: Docbug: missing name for builtin function
(__builtin_alloca_with_align_and_max?)
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hv at crypt dot org
  Target Milestone: ---

In https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html and
https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/Other-Builtins.html the section
after the entry for __builtin_alloca_with_align() starts:

  Built-in Function: void * (size_t size, size_t alignment, size_t max_size)

Similar to __builtin_alloca_with_align but takes an extra argument
specifying an upper bound for size ...

The name of the function is missing. Judging by the corresponding page for
v12.3.0, it should be "__builtin_alloca_with_align_and_max".

[Bug ada/110398] Program_Error sem_eval.adb:4635 explicit raise

[aj at ianozi dot com via Gcc-bugs]

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

--- Comment #3 from aj at ianozi dot com ---
Sorry about that.

Here's the results on my Macbook (Darwin macbook 21.6.0 Darwin Kernel Version
21.6.0: Thu Mar  9 20:12:18 PST 2023;
root:xnu-8020.240.18.700.8~1/RELEASE_ARM64_T8110 arm64):
```
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/gcc-12.1.0-aarch64/libexec/gcc/aarch64-apple-darwin21/12.1.0/lto-wrapper
Target: aarch64-apple-darwin21
Configured with: /Volumes/Miscellaneous1/src/gcc-12-aarch64/configure
--prefix=/opt/gcc-12.1.0-aarch64 --without-libiconv-prefix --disable-libmudflap
--disable-libstdcxx-pch --disable-libsanitizer --disable-libcc1
--disable-libcilkrts --disable-multilib --disable-nls
--enable-languages=c,c++,ada --host=aarch64-apple-darwin21
--target=aarch64-apple-darwin21 --build=aarch64-apple-darwin21 --without-isl
--with-build-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
--with-sysroot=
--with-specs='%{!sysroot=*:--sysroot=%:if-exists-else(/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk)}' --with-as=/usr/bin/as
--with-ld=/usr/bin/ld --with-ranlib=/usr/bin/ranlib
--with-dsymutil=/usr/bin/dsymutil --with-build-config=no --enable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.1.0 (GCC) 
```
The command is:
`gcc -c example.adb`

The result is:
```
+===GNAT BUG DETECTED==+
| 12.1.0 (aarch64-apple-darwin21) Program_Error sem_eval.adb:4631 explicit
raise|
| Error detected at example.adb:3:42   |
| Compiling example.adb|
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

example.adb
foobar.ads
foo.ads
foobar-nested.ads
```

Here's `gcc -v` on debian (Linux scratch 5.10.0-23-amd64 #1 SMP Debian
5.10.179-1 (2023-05-12) x86_64 GNU/Linux) using alire:
```
Using built-in specs.
COLLECT_GCC=/home/aj/.config/alire/cache/dependencies/gnat_native_12.2.1_11f3b811/bin/gcc
COLLECT_LTO_WRAPPER=/home/aj/.config/alire/cache/dependencies/gnat_native_12.2.1_11f3b811/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../src/configure
--prefix=/home/runner/work/GNAT-FSF-builds/GNAT-FSF-builds/sbx/x86_64-linux/gcc/install
--with-build-time-tools=/home/runner/work/GNAT-FSF-builds/GNAT-FSF-builds/sbx/x86_64-linux/binutils/install/bin
--enable-languages=c,ada,c++ --enable-libstdcxx --enable-libstdcxx-threads
--enable-libada --disable-nls --without-libiconv-prefix --disable-libstdcxx-pch
--enable-lto --disable-multilib --enable-threads=posix --with-gnu-ld
--with-gnu-as
--with-mpfr=/home/runner/work/GNAT-FSF-builds/GNAT-FSF-builds/sbx/x86_64-linux/mpfr/install
--with-gmp=/home/runner/work/GNAT-FSF-builds/GNAT-FSF-builds/sbx/x86_64-linux/gmp/install
--with-mpc=/home/runner/work/GNAT-FSF-builds/GNAT-FSF-builds/sbx/x86_64-linux/mpc/install
--with-isl=/home/runner/work/GNAT-FSF-builds/GNAT-FSF-builds/sbx/x86_64-linux/isl/install
--build=x86_64-pc-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.2.0 (GCC) 
```

Command `~/.config/alire/cache/dependencies/gnat_native_12.2.1_11f3b811/bin/gcc
-c example.adb` gives me:
```
+===GNAT BUG DETECTED==+
| 12.2.0 (x86_64-pc-linux-gnu) Program_Error sem_eval.adb:4631 explicit raise|
| Error detected at example.adb:3:42   |
| Compiling example.adb|
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.

[Bug ada/110398] Program_Error sem_eval.adb:4635 explicit raise

[aj at ianozi dot com via Gcc-bugs]

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

--- Comment #2 from aj at ianozi dot com ---
Created attachment 55403
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55403=edit
files for bug

[Bug lto/110424] New: Bogus ODR warning for FMV member function with -flto

[wwwhhhyyy333 at gmail dot com via Gcc-bugs]

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

Bug ID: 110424
   Summary: Bogus ODR warning for FMV member function with -flto
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wwwhhhyyy333 at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

cat m1.h

---
#pragma once 

class A  
{
public:  
  int foo1();
};   
---

cat m1.cpp

---
#include "m1.h"

__attribute__((target_clones("default","arch=icelake-server"))) 
int A::foo1()  
{  
return 0;  
}  

---

cat m2.cpp

---
#include "m1.h"   

int main()
{ 
  A a;
  return a.foo1();
} 
---

g++ -flto -Werror m1.cpp m2.cpp -o m2

m1.h:6:7: error: ‘foo1’ violates the C++ One Definition Rule [-Werror=odr]
6 |   int foo1(); 
  |   ^   
m1.cpp:9:1: note: ‘_ZN1A4foo1Ev’ was previously declared here 
9 | } 
  | ^ 
lto1: all warnings being treated as errors

The output binary should quite same as the one without lto, so the warning
seems to be bogus.

[Bug rtl-optimization/110423] Redundant constants not getting eliminated on RISCV.

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

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

--- Comment #1 from Vineet Gupta  ---
Created attachment 55402
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55402=edit
test case (but needs reverting upstream 6508d5e5a1a)

[Bug rtl-optimization/110423] New: Redundant constants not gettign eliminated on RISCV.

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

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

Bug ID: 110423
   Summary: Redundant constants not gettign eliminated on RISCV.
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vineetg at gcc dot gnu.org
  Target Milestone: ---

Redundant constants, across basic blocks, don't seem to be eliminated robustly
by gcc. I'd reported this last year [1] and this is just recapturing that info
as a bugzilla PR.

[1] https://gcc.gnu.org/pipermail/gcc/2022-October/239645.html

When analyzing coremark build for RISC-V, noticed redundant constants 
not being eliminated. While this is a recurrent issue with RV, this 
specific instance is not unique to RV as I can trigger similar output on 
aarch64 with -fno-if-conversion, hence something which could be 
addressed in common passes.

-O3 -march=rv64gc_zba_zbb

crcu8:
xor a3,a0,a1
andia3,a3,1
srlia4,a0,1
srlia5,a1,1
beq a3,zero,.L2

li  a3,-24576   # 0x_A000
addia3,a3,1 # 0x_A001
xor a5,a5,a3
zext.h  a5,a5

.L2:
xor a4,a4,a5
andia4,a4,1 
srlia3,a0,2 
srlia5,a5,1 
beq a4,zero,.L3 

li  a4,-24576   # 0x_A000
addia4,a4,1 # 0x_A001
xor a5,a5,a4
zext.h  a5,a5   

.L3:
xor a3,a3,a5
andia3,a3,1 
srlia4,a0,3 
srlia5,a5,1 
beq a3,zero,.L4

li  a3,-24576   # 0x_A000
addia3,a3,1 # 0x_A001
[...]

.L8
andia3,a5,1
srlia0,a5,1
beq a3,a4,.L9
li  a5,-24576   # 0x_A000
addia5,a5,1 # 0x_A001
xor a0,a0,a5
sllia0,a0,48
srlia0,a0,48
.L9:
ret


cse can't handle this: as explained by Jeff in [2] EBB can have jumps out but
not jumps in, which misses the cfg paths needed to be traversed to find the
equivalents.

[2] https://gcc.gnu.org/pipermail/gcc/2022-October/239646.html

Note that since gcc 13.1, this specific test generates different code since the
match.pd change 6508d5e5a1a ("match.pd: rewrite select to branchless
expression") now removes the branches and the arithmatic needing the large
const. 
But this test is very convenient, so I'm continuing to use it and just revert
the match.pd change in my local gcc build.

[Bug middle-end/103979] asm goto is not considered volatile with output operands

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #7 from Andrew Pinski  ---
MIne, I filed PR 110422  for the SRA issue.

[Bug tree-optimization/110420] [12/13/14 Regression] internal compiler error: in gimple_redirect_edge_and_branch due to simple_dce_from_worklist removing `asm goto`

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/98619] aarch64: ICE (verify_flow_info failed) with asm goto with output and same block and two labels

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
if asm goto is marked as volatile, it is fixed ...

so mine.

[Bug tree-optimization/110422] New: asm goto vs SRA

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

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

Bug ID: 110422
   Summary: asm goto vs SRA
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Testcase from originally from PR 103979:

```
struct S { char a[64]; };

int
foo (void)
{
  struct S s, t;
  asm goto ("" : "=g" (s) : : : l);
  t = s;
  asm goto ("" : "=g" (s) : : : l);
  return s.a[0] + t.a[63];
l:
  return -1;
}
```

This is not related to asm goto not being volatile but rather SRA (just like
complex lowering, PR 105165) does not know how to handle `asm goto` with
outputs.

[Bug tree-optimization/110420] [12/13/14 Regression] internal compiler error: in gimple_redirect_edge_and_branch due to simple_dce_from_worklist removing `asm goto`

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

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

--- Comment #4 from Andrew Pinski  ---
Created attachment 55401
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55401=edit
Patch

So this is another `asm goto` not being considered as volatile.
Anyways that fixes that issue.

[Bug middle-end/103979] asm goto is not considered volatile with output operands

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #3)
> struct S { char a[64]; };
> 
> int
> foo (void)
> {
>   struct S s, t;
>   asm goto ("" : "=g" (s) : : : l);
>   t = s;
>   asm goto ("" : "=g" (s) : : : l);
>   return s.a[0] + t.a[63];
> l:
>   return -1;
> }
> 

That is going to be turned into a different issue ...

[Bug middle-end/103979] asm goto is not considered volatile with output operands

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #3)
> I think we shouldn't just follow blindly the docs, but see what e.g. Linux
> kernel as heavy user of asm goto with outputs (and I think mostly without
> volatile) wants.

They will need volatile, at least on powerpc. The reason is they use asm goto
now for loading/storing from/to userspace. PR 110420 is another case where asm
goto is removed on accident due not to being volatile.

[Bug tree-optimization/110420] [12/13/14 Regression] internal compiler error: in gimple_redirect_edge_and_branch due to simple_dce_from_worklist removing `asm goto`

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[12/13/14 Regression]   |[12/13/14 Regression]
   |internal compiler error: in |internal compiler error: in
   |gimple_redirect_edge_and_br |gimple_redirect_edge_and_br
   |anch, at tree-cfg.cc:6262   |anch due to
   ||simple_dce_from_worklist
   ||removing `asm goto`

--- Comment #3 from Andrew Pinski  ---
Note

[Bug fortran/110421] internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.cc:1548

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
Looks like a duplicate of PR110415

[Bug tree-optimization/110420] [12/13/14 Regression] internal compiler error: in gimple_redirect_edge_and_branch, at tree-cfg.cc:6262

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||11.1.0, 11.4.0
  Known to fail||12.1.0
 Ever confirmed|0   |1
Summary|[14 Regression] internal|[12/13/14 Regression]
   |compiler error: in  |internal compiler error: in
   |gimple_redirect_edge_and_br |gimple_redirect_edge_and_br
   |anch, at tree-cfg.cc:6262   |anch, at tree-cfg.cc:6262
   Last reconfirmed||2023-06-26
   Target Milestone|14.0|13.2
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
Reduced testcase that shows this is a regression in GCC 12+:
```
static int t;
void g(void);

void f(void)
{
  int  __gu_val;
  asm goto(""
 : "="(__gu_val)
 :
 :
 : Efault);
  t = __gu_val;
  g();
Efault:
}

```
simple_dce_from_worklist is removing the statement (in this case during inline
but in the original case it was during ccp1 but it was the same issue).

```
Removing statement, writes to write only var:
# .MEM_4 = VDEF <.MEM_3(D)>
t = __gu_val_2;
Removing dead stmt:__asm__ goto("" : "=" __gu_val_2 :  :  : "Efault" Efault);
```

[Bug fortran/110421] internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.cc:1548

[gronki at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Dominik Gronkiewicz  ---
Actually the minimal example can be cut down even further, to not introduce
confusion:

program main

implicit none

type :: typ1
end type

type, extends(typ1) :: typ1a
end type

type :: typ2
class(typ1), allocatable :: t1
end type

type(typ2) :: t2

! works
t2 = typ2(t1=typ1())

! crash
t2 = typ2(t1=typ1a())

end program

[Bug tree-optimization/110420] [14 Regression] internal compiler error: in gimple_redirect_edge_and_branch, at tree-cfg.cc:6262

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
Summary|internal compiler error: in |[14 Regression] internal
   |gimple_redirect_edge_and_br |compiler error: in
   |anch, at tree-cfg.cc:6262   |gimple_redirect_edge_and_br
   ||anch, at tree-cfg.cc:6262
   Keywords||ice-on-valid-code

--- Comment #1 from Andrew Pinski  ---
Reducing and trying to figure out what is going wrong .

[Bug fortran/110421] New: internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.cc:1548

[gronki at gmail dot com via Gcc-bugs]

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

Bug ID: 110421
   Summary: internal compiler error: in gfc_get_symbol_decl, at
fortran/trans-decl.cc:1548
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gronki at gmail dot com
  Target Milestone: ---

Reporting an ICE I encounter.

Test code:

program main

implicit none

type :: typ1
integer :: i
end type

type, extends(typ1) :: typ1a
end type

type :: typ2
class(typ1), allocatable :: t1
end type

type(typ2) :: t2

! works
t2 = typ2(t1=typ1(1))

! crash
t2 = typ2(t1=typ1a(1))

end program

Error:

gfortran -v -save-temps test.f90 
Driving: gfortran -v -save-temps test.f90 -l gfortran -l m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/13/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,m2,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --enable-libstdcxx-backtrace
--with-libstdcxx-zoneinfo=/usr/share/zoneinfo --with-linker-hash-style=gnu
--enable-plugin --enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-13.1.1-20230614/obj-x86_64-redhat-linux/isl-install
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-offload-defaulted --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
--with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.1.1 20230614 (Red Hat 13.1.1-4) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64' '-dumpdir' 'a-'
 /usr/libexec/gcc/x86_64-redhat-linux/13/f951 test.f90 -quiet -dumpdir a-
-dumpbase test.f90 -dumpbase-ext .f90 -mtune=generic -march=x86-64 -version
-fintrinsic-modules-path /usr/lib/gcc/x86_64-redhat-linux/13/finclude
-fpre-include=/usr/include/finclude/math-vector-fortran.h -o a-test.s
GNU Fortran (GCC) version 13.1.1 20230614 (Red Hat 13.1.1-4)
(x86_64-redhat-linux)
compiled by GNU C version 13.1.1 20230614 (Red Hat 13.1.1-4), GMP
version 6.2.1, MPFR version 4.1.1-p1, MPC version 1.3.1, isl version
isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
test.f90:22:26:

   22 | t2 = typ2(t1=typ1a(1))
  |  1
internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.cc:1548
Please submit a full bug report, with preprocessed source.
See  for instructions.

Thank you very much!
Dominik

[Bug tree-optimization/110420] New: internal compiler error: in gimple_redirect_edge_and_branch, at tree-cfg.cc:6262

[jbglaw--- via Gcc-bugs]

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

Bug ID: 110420
   Summary: internal compiler error: in
gimple_redirect_edge_and_branch, at tree-cfg.cc:6262
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jbg...@lug-owl.de
  Target Milestone: ---

Created attachment 55400
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55400=edit
Preprocessed input.

Starting with g:21e2ef2dc, I see a new ICE building a PPC Linux kernel for the
adder875_defconfig config (see eg.
http://toolchain.lug-owl.de/laminar/jobs/linux-powerpc-adder875_defconfig/100):

[mk all 2023-06-26 02:31:11] # CC  arch/powerpc/kernel/ptrace/ptrace-view.o
[mk all 2023-06-26 02:31:11]   powerpc-linux-gcc
-Wp,-MMD,arch/powerpc/kernel/ptrace/.ptrace-view.o.d -nostdinc
-I./arch/powerpc/include -I./arch/powerpc/include/generated  -I./include
-I./arch/powerpc/include/uapi -I./arch/powerpc/include/generated/uapi
-I./include/uapi -I./include/generated/uapi -include
./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include
./include/linux/compiler_types.h -D__KERNEL__ -I ./arch/powerpc
-fmacro-prefix-map=./= -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE
-Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type
-Wno-format-security -funsigned-char -std=gnu11 -mbig-endian -m32 -msoft-float
-pipe -ffixed-r2 -mmultiple -mno-readonly-in-sdata -mcpu=860 -mno-prefixed
-mno-pcrel -mno-altivec -mno-vsx -mno-mma -fno-asynchronous-unwind-tables
-mno-string -mbig-endian -mstack-protector-guard=tls
-mstack-protector-guard-reg=r2 -fno-delete-null-pointer-checks
-Wno-frame-address -Wno-format-truncation -Wno-format-overflow
-Wno-address-of-packed-member -O2 -fno-allow-store-data-races
-Wframe-larger-than=1024 -fstack-protector-strong -Wno-main
-Wno-unused-but-set-variable -Wno-unused-const-variable -Wno-dangling-pointer
-fomit-frame-pointer -ftrivial-auto-var-init=zero -fno-stack-clash-protection
-Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wcast-function-type
-Wno-stringop-truncation -Wno-stringop-overflow -Wno-restrict
-Wno-maybe-uninitialized -Wno-array-bounds -Wno-alloc-size-larger-than
-Wimplicit-fallthrough=5 -fno-strict-overflow -fno-stack-check -fconserve-stack
-Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init
-Wno-packed-not-aligned -g -mstack-protector-guard-offset=544 -Werror
-DUTS_MACHINE='"ppc"'   
-DKBUILD_MODFILE='"arch/powerpc/kernel/ptrace/ptrace-view"'
-DKBUILD_BASENAME='"ptrace_view"' -DKBUILD_MODNAME='"ptrace_view"'
-D__KBUILD_MODNAME=kmod_ptrace_view -c -o
arch/powerpc/kernel/ptrace/ptrace-view.o
arch/powerpc/kernel/ptrace/ptrace-view.c  
[mk all 2023-06-26 02:31:13] during GIMPLE pass: pre
[mk all 2023-06-26 02:31:13] arch/powerpc/kernel/ptrace/ptrace-view.c: In
function 'gpr32_set_common':
[mk all 2023-06-26 02:31:13] arch/powerpc/kernel/ptrace/ptrace-view.c:649:5:
internal compiler error: in gimple_redirect_edge_and_branch, at
tree-cfg.cc:6262
[mk all 2023-06-26 02:31:13]   649 | int gpr32_set_common(struct task_struct
*target,
[mk all 2023-06-26 02:31:13]   | ^~~~
[mk all 2023-06-26 02:31:13] 0x1a562a6 internal_error(char const*, ...)
[mk all 2023-06-26 02:31:13]???:0
[mk all 2023-06-26 02:31:13] 0x826ea1 fancy_abort(char const*, int, char
const*)
[mk all 2023-06-26 02:31:13]???:0
[mk all 2023-06-26 02:31:13] 0x9b77c9 redirect_edge_and_branch(edge_def*,
basic_block_def*)
[mk all 2023-06-26 02:31:13]???:0
[mk all 2023-06-26 02:31:13] 0x9b7e43 split_edge(edge_def*)
[mk all 2023-06-26 02:31:13]???:0
[mk all 2023-06-26 02:31:13] 0xee1cc7 split_critical_edges(bool)
[mk all 2023-06-26 02:31:13]???:0
[mk all 2023-06-26 02:31:13] Please submit a full bug report, with preprocessed
source (by using -freport-bug).
[mk all 2023-06-26 02:31:13] Please include the complete backtrace with any bug
report.
[mk all 2023-06-26 02:31:13] See  for instructions.
[mk all 2023-06-26 02:31:13] make[4]: *** [scripts/Makefile.build:252:
arch/powerpc/kernel/ptrace/ptrace-view.o] Error 1
[mk all 2023-06-26 02:31:13] make[3]: *** [scripts/Makefile.build:494:
arch/powerpc/kernel/ptrace] Error 2
[mk all 2023-06-26 02:31:13] make[2]: *** [scripts/Makefile.build:494:
arch/powerpc/kernel] Error 2
[mk all 2023-06-26 02:31:13] make[1]: *** [scripts/Makefile.build:494:
arch/powerpc] Error 2
[mk all 2023-06-26 02:31:13] make: *** [Makefile:2026: .] Error 2



The full command line is seen above, I'll also attach preprocessed input.
(-freport-bug didn't generate something?)

[Bug target/108678] Windows on ARM64 platform target aarch64-w64-mingw32

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

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

--- Comment #7 from Jonathan Wakely  ---
The change to libstdc++-v3/src/c++17/fast_float/fast_float.h should be done
upstream: https://github.com/fastfloat/fast_float

[Bug tree-optimization/110410] [14 Regression] Different results between -O0 and -O2

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Jw Zeng from comment #3)
> (In reply to Richard Biener from comment #2)
> > phi-opt again?
> 
> Link to the Compiler Explorer:https://godbolt.org/z/EeEqMGnWo
> 
> I reduced the code again, I hope it helps. The reduced code is as follows:

This reduced testcase is the same issue except it is dom2 which has the missed
optimization:
Exported global range table:

_3  : [irange] int [0, 65535] NONZERO 0x
_7  : [irange] int [0, 65535] NONZERO 0x
iftmp.0_16  : [irange] unsigned int [0, 1][2147483648, +INF]
iftmp.7_21  : [irange] unsigned int [0, 0][2147483648, +INF]
iftmp.7_22  : [irange] unsigned int [0, 0] NONZERO 0x0

Note the reason why dom3 is able to figure out:
  # VUSE <.MEM_18(D)>
  var_3.9_9 = var_3;
is the same as var_3.3_2
and not fre3 is because a jump threading is needed to happen before. Once dom3
is already to figure that out, it becomes obvious that is _22 is 0 and such.

[Bug other/110419] New: [14 regression] new test case gfortran.dg/value_9.f90 in r14-2050-gd130ae8499e0c6 fails

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

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

Bug ID: 110419
   Summary: [14 regression] new test case gfortran.dg/value_9.f90
in r14-2050-gd130ae8499e0c6 fails
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:d130ae8499e0c615e1636258d6901372316dfd93, r14-2050-gd130ae8499e0c6 

This is failing on big endian.

make  -k check-gcc-fortran RUNTESTFLAGS="--target_board=unix'{-m32,m64}'
dg.exp=gcc/testsuite/gfortran.dg/value_9.f90"

FAIL: gfortran.dg/value_9.f90   -O0  execution test
FAIL: gfortran.dg/value_9.f90   -O1  execution test
FAIL: gfortran.dg/value_9.f90   -O2  execution test
FAIL: gfortran.dg/value_9.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/value_9.f90   -O3 -g  execution test
FAIL: gfortran.dg/value_9.f90   -Os  execution test
# of expected passes6
# of unexpected failures6


spawn [open ...]
 by value(kind=1): B
 by value(kind=1): A

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0xf7ba03f3 in ???
#1  0x1d34 in val
at
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/value_9.f90:47
#2  0x19db in p
at
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/value_9.f90:20
#3  0x19db in main
at
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/value_9.f90:45
FAIL: gfortran.dg/value_9.f90   -O3 -g  execution test

commit d130ae8499e0c615e1636258d6901372316dfd93 (HEAD)
Author: Harald Anlauf 
Date:   Thu Jun 22 22:07:41 2023 +0200

Fortran: ABI for scalar CHARACTER(LEN=1),VALUE dummy argument [PR110360]

[Bug target/110406] d: Wrong code-gen returning POD structs by value

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

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

--- Comment #10 from ibuclaw at gcc dot gnu.org ---
Looking at an ICE in stage2 D compiler for i686-darwin17, I realized that it's
another facet of this issue.

// aggregate.d
import dsymbol;
extern (C++) class AggregateDeclaration : ScopeDsymbol
{
Visibility visibility;
override Visibility visible() { return visibility; }
}



// dsymbol.d
struct Visibility
{
enum Kind { undefined }
Kind kind;
}
extern(C++) class ScopeDsymbol
{
Visibility visible();
Visibility.Kind* visibilities; 
}


When compiling dsymbol.d, `struct Visibility` is set SImode.  However when
compiling aggregate.d it's instead given BLKmode.  This causes all the
difference in how it is returned.  Any C++ code interfacing with this will
crash due to the mismatch too.

[Bug c++/110409] ICE on explicit instantiation of undefined template

[stevenxia990430 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Steven Xia  ---
Noted, thanks!

[Bug target/108678] Windows on ARM64 platform target aarch64-w64-mingw32

[zac.walker at linaro dot org via Gcc-bugs]

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

--- Comment #6 from Zac Walker  ---
I have been rebasing regularly to keep all my changes on top of the commit log.
You can use github's compare url to combine my changes into a single diff
(based on commit hash). For example:

https://github.com/ZacWalk/gcc-woarm64/compare/06a0f07..0248264

[Bug c++/110416] Error initializing of const union variable with a mutable field

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

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

--- Comment #3 from Andrew Pinski  ---
[dcl.init.general]/8 (specifically 8.2) is what makes the union case valid.

Though I wonder what mutable field means in an union if not the whole union is
not mutable ...

[Bug rtl-optimization/110418] New: ICE on valid code at -O2 and -O3 with -fselective-scheduling2: Segmentation fault

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

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

Bug ID: 110418
   Summary: ICE on valid code at -O2 and -O3 with
-fselective-scheduling2: Segmentation fault
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

This appears to be a long-latent issue, affecting 6.* and later. 

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

[506] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230625 (experimental) [master r14-924-gd709841ae0f] (GCC) 
[507] % 
[507] % gcctk -O2 -fselective-scheduling2 small.c
during RTL pass: sched2
small.c: In function ‘main’:
small.c:20:1: internal compiler error: Segmentation fault
   20 | }
  | ^
0xfc7c03 crash_signal
../../gcc-trunk/gcc/toplev.cc:314
0x7fdf8a71151f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0xf726a0 init_expr
../../gcc-trunk/gcc/sel-sched-ir.cc:1627
0xf726a0 copy_expr_onside(_expr*, _expr*)
../../gcc-trunk/gcc/sel-sched-ir.cc:1685
0xf80619 move_op_orig_expr_found
../../gcc-trunk/gcc/sel-sched.cc:5989
0xf856d9 code_motion_path_driver
../../gcc-trunk/gcc/sel-sched.cc:6543
0xf85c49 code_motion_process_successors
../../gcc-trunk/gcc/sel-sched.cc:6342
0xf85c49 code_motion_path_driver
../../gcc-trunk/gcc/sel-sched.cc:6608
0xf85c49 code_motion_process_successors
../../gcc-trunk/gcc/sel-sched.cc:6342
0xf85c49 code_motion_path_driver
../../gcc-trunk/gcc/sel-sched.cc:6608
0xf85c49 code_motion_process_successors
../../gcc-trunk/gcc/sel-sched.cc:6342
0xf85c49 code_motion_path_driver
../../gcc-trunk/gcc/sel-sched.cc:6608
0xf85c49 code_motion_process_successors
../../gcc-trunk/gcc/sel-sched.cc:6342
0xf85c49 code_motion_path_driver
../../gcc-trunk/gcc/sel-sched.cc:6608
0xf86279 move_op
../../gcc-trunk/gcc/sel-sched.cc:6702
0xf86279 move_exprs_to_boundary
../../gcc-trunk/gcc/sel-sched.cc:5223
0xf86279 schedule_expr_on_boundary
../../gcc-trunk/gcc/sel-sched.cc:5436
0xf887ef fill_insns
../../gcc-trunk/gcc/sel-sched.cc:5578
0xf887ef schedule_on_fences
../../gcc-trunk/gcc/sel-sched.cc:7353
0xf887ef sel_sched_region_2
../../gcc-trunk/gcc/sel-sched.cc:7491
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.
[508] % 
[508] % cat small.c
int printf (const char *, ...);
volatile int a, c, e;
int b = 1, d, f = 1;
int main ()
{
  int h, i = b - c, k;
  char j;
L:
  j = k = ~(-(b * a) / f);
  c = -((1 - d / b) | ((c | 1 / j) - b));
  e = ~((1 & b) ^ e) / ~f;
  if (a)
printf ("%d", h);
  if (!(a || k < 2 || a))
e = j;
  if (a < d || e)
goto L;
  d = f && i;
  return 0;
}

[Bug c++/110416] Error initializing of const union variable with a mutable field

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
Summary|Error initializing of const |Error initializing of const
   |aggregate variable with a   |union variable with a
   |mutable field   |mutable field
 Ever confirmed|0   |1
   Last reconfirmed||2023-06-26

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> struct also fails ...

Well clang does not reject that case but MSVC does.
So I don't think the struct case is a GCC bug; just clang does not have a
check.

[Bug c++/110416] Error initializing of const aggregate variable with a mutable field

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Error initializing of const |Error initializing of const
   |union variable with a   |aggregate variable with a
   |mutable field   |mutable field

--- Comment #1 from Andrew Pinski  ---
struct also fails ...

[Bug c++/110409] ICE on explicit instantiation of undefined template

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Confirmed. There are a few related issues (which I linked already) but I am not
sure if any are an exact dup of this one though fixing one of them might fix
this one too ...

[Bug fortran/110360] ABI issue with character,value dummy argument

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

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

--- Comment #15 from Mikael Morin  ---
(In reply to anlauf from comment #14)> 
> Let's hope that somebody with access to such a system can run the testcase
> manually and append the output to this PR.

I have asked for an account on the compile farm (see
https://gcc.gnu.org/wiki/CompileFarm) to have access to a powerpc machine.
You may want to do the same, can prove handy sometimes.

I'll investigate tomorrow and post the missing information here.

[Bug middle-end/110377] Early VRP and IPA-PROP should work out value ranges from __builtin_unreachable

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #4 from Andrew Macleod  ---
If I were to guess, I'd guess that its using the default query which simply
picks up global ranges from the global_range_query.

If enable_range() was called at the start, and disable_ranger() at the end of
the pass, it would switch to a  context sensitive query.. as long as the IL
isnt going thru too much funny stuff.

My guess is Aldy has been converting the OLD API to rangers API, and simply
hasn't enabled a context ranger yet... Or if he even had plans for that..  
Aldy?

[Bug c/102989] Implement C2x's n2763 (_BitInt)

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

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

--- Comment #70 from Jakub Jelinek  ---
For right shifts, I wonder if we shouldn't emit inline (perhaps with exception
of -Os) something like:
__attribute__((noipa)) void
ashiftrt575 (unsigned long *p, unsigned long *q, int n)
{
  int prec = 575;
  int n1 = n & 63;
  int n2 = n / 64;
  int n3 = n1 != 0;
  int n4 = (-n1) & 63;
  unsigned long ext;
  int i;
  for (i = n2; i < prec / 64 - n3; ++i)
p[i - n2] = (q[i] >> n1) | (q[i + n3] << n4);
  ext = ((signed long) (q[prec / 64] << (64 - (prec & 63 >> (64 - (prec &
63));
  if (n1 && i == prec / 64 - n3)
{
  p[i - n2] = (q[i] >> n1) | (ext << n4);
  ++i;
}
  i -= n2;
  p[i] = ((signed long) ext) >> n1;
  ext = ((signed long) ext) >> 63;
  for (++i; i < prec / 64 + 1; ++i)
p[i] = ext;
}

__attribute__((noipa)) void
lshiftrt575 (unsigned long *p, unsigned long *q, int n)
{
  int prec = 575;
  int n1 = n & 63;
  int n2 = n / 64;
  int n3 = n1 != 0;
  int n4 = (-n1) & 63;
  unsigned long ext;
  int i;
  for (i = n2; i < prec / 64 - n3; ++i)
p[i - n2] = (q[i] >> n1) | (q[i + n3] << n4);
  ext = q[prec / 64] & ((1UL << (prec % 64)) - 1);
  if (n1 && i == prec / 64 - n3)
{
  p[i - n2] = (q[i] >> n1) | (ext << n4);
  ++i;
}
  i -= n2;
  p[i] = ext >> n1;
  ext = 0;
  for (++i; i < prec / 64 + 1; ++i)
p[i] = 0;
}
(for _BitInt(575) and 64-bit limb little endian).  If the shift count is
constant, it will allow further optimizations,
and if e.g. get_nonzero_bits tells us that n is variable but multiple of limb
precision, we can optimize some more as well.
Looking at what LLVM does, they seem to sign extend in memory to twice as many
bits and then just use an unrolled loop without any conditionals, but that
doesn't look well for memory usage etc.

[Bug tree-optimization/110412] [14 Regression] GCN 'gcc.dg/vect/pr65494.c' ICE, 'error: invalid types in nop conversion'

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

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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #2 from Thomas Schwinge  ---
(In reply to Andrew Pinski from comment #1)
> I think this was just fixed by r14-2085 or r14-2086 (both aka PR 110371).

Thanks!  Indeed commit r14-2086-g1bfe7e5352d1f4ac525317454aca45aa80a517ba 'Use
cvt_op to save intermediate type operand instead of "subtle" vec_dest' does
resolve this ICE:

PASS: gcc.dg/vect/pr65494.c (test for excess errors)
PASS: gcc.dg/vect/pr65494.c scan-tree-dump vect "vectorized 1 loops in
function"

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

[Bug tree-optimization/110371] [14 Regression] gfortran ICE "verify_gimple failed" in gfortran.dg/vect/pr51058-2.f90 since r14-2007

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #11 from Thomas Schwinge  ---
*** Bug 110412 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/110237] gcc.dg/torture/pr58955-2.c is miscompiled by RTL scheduling after reload

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

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

--- Comment #18 from Alexander Monakov  ---
(In reply to rguent...@suse.de from comment #17)
> Yes, we do the same to loads.  I hope that's not a common technique
> though but I have to admit the vectorizer itself assesses whether it's
> safe to access "gaps" by looking at alignment so its code generation
> is prone to this same "mistake".
> 
> Now, is "alignment to 16 is ensured externally" good enough here?
> If we consider
> 
> static int a[2];
> 
> and code doing
> 
>  if (is_aligned (a))
>{
>  __v4si v = (__attribute__((may_alias)) __v4si *) 
>}
> 
> then we cannot even use a DECL_ALIGN that's insufficient for decls
> that bind locally.

I agree. I went with the 'extern' example because there it should be more
obvious the construction ought to work.


> Note we have similar arguments with aggregate type sizes (and TBAA)
> where when we infer a dynamic type from one access we check if
> the other access would fit.  Wouldn't the above then extend to that
> as well given we could also do aggregate copies of "padding" and
> ignore the bits if we'd have ensured the larger access wouldn't trap?

I think a read via a may_alias type just tells you that N bytes are accessible
for reading, not necessarily for writing. So I don't see a problem, but maybe I
didn't quite catch what you are saying.


> So supporting the above might be a bit of a stretch (though I think
> we have to fix the vectorizer here).

What would the solution be? Using a may_alias type for such accesses?


> > > If the v4si store is masked we cannot do this anymore, but the IL
> > > we seed the alias oracle with doesn't know the store is partial.
> > > The only way to "fix" it is to take away all of the information from it.
> > 
> > But that won't fix the trapping issue? I think we need a distinct RTX for
> > memory accesses where hardware does fault suppression for masked-out 
> > elements.
> 
> Yes, it doesn't fix that part.  The idea of using BLKmode instead of
> a vector mode for the MEMs would, I guess, together with specifying
> MEM_SIZE as not known.

Unfortunate if that works for the trapping side, but not for the aliasing side.

[Bug target/108678] Windows on ARM64 platform target aarch64-w64-mingw32

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

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

--- Comment #5 from Brecht Sanders  
---
Thanks Zac, how can I see what you actually changed?
Is there a particular GCC version I can diff
https://github.com/ZacWalk/gcc-woarm64 against?

[Bug ipa/110334] [13/14 Regresssion] unused functions not eliminated before LTO streaming

[hubicka at ucw dot cz via Gcc-bugs]

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

--- Comment #11 from Jan Hubicka  ---
Hi,
what about this. It should make at least quite basic inlining to happen
to always_inline. I do not think many critical always_inlines have
indirect calls in them.  The test for lto is quite bad and I can
work on solving this incrementally (it would be nice to have this
tested and possibly backport it).

diff --git a/gcc/ipa-inline.cc b/gcc/ipa-inline.cc
index efc8df7d4e0..dcec07e49e1 100644
--- a/gcc/ipa-inline.cc
+++ b/gcc/ipa-inline.cc
@@ -702,6 +702,38 @@ can_early_inline_edge_p (struct cgraph_edge *e)
   if (!can_inline_edge_p (e, true, true)
   || !can_inline_edge_by_limits_p (e, true, false, true))
 return false;
+  /* When inlining regular functions into always-inline functions
+ during early inlining watch for possible inline cycles.  */
+  if (DECL_DISREGARD_INLINE_LIMITS (caller->decl)
+  && lookup_attribute ("always_inline", DECL_ATTRIBUTES (caller->decl))
+  && (!DECL_DISREGARD_INLINE_LIMITS (callee->decl)
+ || !lookup_attribute ("always_inline", DECL_ATTRIBUTES
(callee->decl
+{
+  /* If there are indirect calls, inlining may produce direct call.
+TODO: We may lift this restriction if we avoid errors on formely
+indirect calls to always_inline functions.  Taking address
+of always_inline function is generally bad idea and should
+have been declared as undefined, but sadly we allow this.  */
+  if (caller->indirect_calls || e->callee->indirect_calls)
+   return false;
+  for (cgraph_edge *e2 = callee->callees; e2; e2 = e2->next_callee)
+   {
+ struct cgraph_node *callee2 = e2->callee->ultimate_alias_target ();
+ /* As early inliner runs in RPO order, we will see uninlined
+always_inline calls only in the case of cyclic graphs.  */
+ if (DECL_DISREGARD_INLINE_LIMITS (callee2->decl)
+ || lookup_attribute ("always_inline", callee2->decl))
+   return false;
+ /* With LTO watch for case where function is later replaced
+by always_inline definition.
+TODO: We may either stop treating noninlined cross-module always
+inlines as errors, or we can extend decl merging to produce
+syntacic alias and honor always inline only in units it has
+been declared as such.  */
+ if (flag_lto && callee2->externally_visible)
+   return false;
+   }
+}
   return true;
 }

@@ -3034,18 +3066,7 @@ early_inliner (function *fun)

   if (!optimize
   || flag_no_inline
-  || !flag_early_inlining
-  /* Never inline regular functions into always-inline functions
-during incremental inlining.  This sucks as functions calling
-always inline functions will get less optimized, but at the
-same time inlining of functions calling always inline
-function into an always inline function might introduce
-cycles of edges to be always inlined in the callgraph.
-
-We might want to be smarter and just avoid this type of inlining.  */
-  || (DECL_DISREGARD_INLINE_LIMITS (node->decl)
- && lookup_attribute ("always_inline",
-  DECL_ATTRIBUTES (node->decl
+  || !flag_early_inlining)
 ;
   else if (lookup_attribute ("flatten",
 DECL_ATTRIBUTES (node->decl)) != NULL)

[Bug c++/110417] New: [modules] Segfault compiling iostream as header unit on FreeBSD

[boris at kolpackov dot net via Gcc-bugs]

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

Bug ID: 110417
   Summary: [modules] Segfault compiling iostream as header unit
on FreeBSD
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris at kolpackov dot net
  Target Milestone: ---

[Submitting this on behalf of a build2 user who is still waiting for the
bugzilla login[1].]

GCC 12,13,14 all have compilation errors on FreeBSD when trying to compile C++
modules on FreeBSD.

When trying to compile iostream using the command: 

g++ -v -save-temps -std=c++20 -fmodules-ts -xc++-system-header iostream

GCC throws internal compiler error in exact form:

header iostream
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc12/gcc/x86_64-portbld-freebsd13.1/12.2.0/lto-wrapper
Target: x86_64-portbld-freebsd13.1
Configured with: /wrkdirs/usr/ports/lang/gcc12/work/gcc-12.2.0/configure
--enable-multilib --with-build-config=bootstrap-lto-noplugin --disable-nls
--enable-gnu-indirect-function --enable-host-shared --enable-plugin
--libdir=/usr/local/lib/gcc12 --libexecdir=/usr/local/libexec/gcc12
--program-suffix=12 --with-as=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc12/include/c++/
--with-gxx-libcxx-include-dir=/usr/include/c++/v1 --with-ld=/usr/local/bin/ld
--with-pkgversion='FreeBSD Ports Collection' --with-system-zlib --without-zstd
--enable-languages=c,c++,objc,fortran,jit --prefix=/usr/local
--localstatedir=/var --mandir=/usr/local/man
--infodir=/usr/local/share/info/gcc12 --build=x86_64-portbld-freebsd13.1
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.2.0 (FreeBSD Ports Collection)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++20' '-fmodules-ts'
'-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
 /usr/local/libexec/gcc12/gcc/x86_64-portbld-freebsd13.1/12.2.0/cc1plus -E
-fdirectives-only -fmodule-header=system -quiet -v iostream -mtune=generic
-march=x86-64 -std=c++20 -fmodules-ts -fpch-preprocess -o a-iostream.ii
ignoring nonexistent directory
"/usr/local/lib/gcc12/gcc/x86_64-portbld-freebsd13.1/12.2.0/include-fixed"
ignoring nonexistent directory
"/usr/local/lib/gcc12/gcc/x86_64-portbld-freebsd13.1/12.2.0/../../../../../x86_64-portbld-freebsd13.1/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/lib/gcc12/include/c++/
 /usr/local/lib/gcc12/include/c++//x86_64-portbld-freebsd13.1
 /usr/local/lib/gcc12/include/c++//backward
 /usr/local/lib/gcc12/gcc/x86_64-portbld-freebsd13.1/12.2.0/include
 /usr/local/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++20' '-fmodules-ts'
'-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
 /usr/local/libexec/gcc12/gcc/x86_64-portbld-freebsd13.1/12.2.0/cc1plus
-fpreprocessed -fdirectives-only a-iostream.ii -fmodule-header=system -quiet
-dumpdir a- -dumpbase iostream -mtune=generic -march=x86-64 -std=c++20 -version
-fmodules-ts -o a-iostream.s
GNU C++20 (FreeBSD Ports Collection) version 12.2.0
(x86_64-portbld-freebsd13.1)
compiled by GNU C version 12.2.0, GMP version 6.2.1, MPFR version
4.2.0-p9, MPC version 1.3.1, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++20 (FreeBSD Ports Collection) version 12.2.0
(x86_64-portbld-freebsd13.1)
compiled by GNU C version 12.2.0, GMP version 6.2.1, MPFR version
4.2.0-p9, MPC version 1.3.1, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 8fd6eb50279aca98d331f0f2293361fa
/usr/local/lib/gcc12/include/c++/iostream:77:1: internal compiler error:
Segmentation fault
   77 | } // namespace
  | ^
0x8270edff3 ???
/usr/src/lib/libc/amd64/string/memmove.S:306
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.

steps to reproduce:
1. Use Freebsd 13.2 or 14.0
2. pkg install gcc-12_5
3. mkdir example && cd example && g++ -v -save-temps -std=c++20 -fmodules-ts
-xc++-system-header iostream

You should now see a similar segmentation fault error.

[1] https://github.com/build2/build2/issues/284

[Bug fortran/110415] (Re)allocation on assignment to allocatable polymorphic variable from allocatable polymorphic function result

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2023-06-26
 Status|UNCONFIRMED |NEW
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1

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

Thanks, Brad.  I vaguely recall a similar bug report, perhaps, PR107489.

Here's the code in question

type, abstract :: p
end type

type, extends(p) :: c
end type

class(p), allocatable :: a

a = func()
contains
  function func() result(a)
class(p), allocatable :: a

a = c()
  end function
end

[Bug c++/110416] New: Error initializing of const union variable with a mutable field

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 110416
   Summary: Error initializing of const union variable with a
mutable field
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

This program

union U {
mutable int x;
float y = 2;
};

int main() {
const U u;
u.x = 1;
}

is accepted in Clang and MSVC, but GCC complains:

: In function 'int main()':
:7:13: error: uninitialized 'const u' [-fpermissive]
7 | const U u;
  | ^
:1:7: note: 'const union U' has no user-provided default constructor
1 | union U {
  |   ^
:2:17: note: and the implicitly-defined constructor does not initialize
'int U::x'
2 | mutable int x;

Online demo: https://gcc.godbolt.org/z/T8bqYTG5f

[Bug middle-end/110377] Early VRP and IPA-PROP should work out value ranges from __builtin_unreachable

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

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

--- Comment #3 from Jan Hubicka  ---
IPA code takes value ranges from jump functions that are computed by
ipa-prop::ipa_compute_jump_functions_for_edge which seems to do:
  if (TREE_CODE (arg) == SSA_NAME
  && param_type
  /* Limit the ranger query to integral types as the rest
 of this file uses value_range's, which only hold
 integers and pointers.  */
  && irange::supports_p (TREE_TYPE (arg))
  && irange::supports_p (param_type)
  && get_range_query (cfun)->range_of_expr (vr, arg)
  && !vr.undefined_p ())
Which looks like a ragner query. I wonder why it does not return the limited
range?

[Bug libstdc++/110239] [14 regression] std/format/functions/format.cc fails after r14-1648-g628ba410b9265d

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Fixed on trunk.

This needs to be backported because the formatter is wrong in gcc-13, we just
don't have a test on the branch to reveal the bug.

[Bug c++/110404] Feature request: add a new option which is like -ftrivial-auto-var-init=zero but zero-initialize instead of zero-fill

[dangelog at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Giuseppe D'Angelo  ---
(In reply to Richard Biener from comment #1)
> But your testcase is invoking undefined behavior when inspecting 'ptr'? 
> That doesn't change with -ftrivial-auto-var-init=zero, so getting a trap is
> good
> here and you need to fix your code instead.

Hi,

Well, the point of -ftrivial-auto-var-init=zero is to turn that UB in a
specific  behavior, that is, to read 0. From a formal point of view, this is a
perfectly valid expression of UB.

The problem I'm raising above is that I'd like reads of uninitialized pointers
to yield nullptr, which is currently not the case of pointers to data members
on Itanium.

--

Then there's the question regarding whether GCC can "see the UB" and e.g.
optimize the whole thing away, based on reasonings like "this code exhibits UB,
therefore it can never be called, therefore it's dead, therefore I can remove
it".

I don't know if this is actually the case at the moment, but if it is, I'd
consider it a *different* bug report. The whole point of
-ftrivial-auto-var-init=zero is to prevent that sort of UB from manifesting
itself (by zero-filling the storage); to prevent leaking "secrets" (leaks that
imply an uninitialized read anyhow, so UB);  etc.

I am not able at the moment to prove or disprove this using GCC. Clang however
disables such UB-optimizations when using -ftrivial-auto-var-init=zero :

https://gcc.godbolt.org/z/qhMxM11jE

[Bug libstdc++/110239] [14 regression] std/format/functions/format.cc fails after r14-1648-g628ba410b9265d

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r14-2105-g3bb9f9329c378934541ae4cff9977b7487e97cf0
Author: Jonathan Wakely 
Date:   Mon Jun 26 14:46:46 2023 +0100

libstdc++: Fix std::format for pointers [PR110239]

The formatter for pointers was casting to uint64_t which sign extends a
32-bit pointer and produces a value that won't fit in the provided
buffer. Cast to uintptr_t instead.

There was also a bug in the __parse_integer helper when converting a
wide string to a narrow string in order to use std::from_chars on it.
The function would always try to read 32 characters, even if the format
string was shorter than that. Fix that bug, and remove the constexpr
implementation of __parse_integer by just using __from_chars_alnum
instead of from_chars, because that's usable in constexpr even in
C++20.

libstdc++-v3/ChangeLog:

PR libstdc++/110239
* include/std/format (__format::__parse_integer): Fix buffer
overflow for wide chars.
(formatter::format): Cast to uintptr_t instead
of uint64_t.
* testsuite/std/format/string.cc: Test too-large widths.

[Bug middle-end/109849] suboptimal code for vector walking loop

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

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

--- Comment #17 from CVS Commits  ---
The master branch has been updated by Jan Hubicka :

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

commit r14-2101-gc2ebccc97190a978a44e341516b488f02a78c598
Author: Jan Hubicka 
Date:   Mon Jun 26 18:29:39 2023 +0200

Fix profile of forwarders produced by cd-dce

compiling the testcase from PR109849 (which uses std:vector based stack to
drive a loop) with profile feedbakc leads to profile mismatches introduced
by
tree-ssa-dce.  This is the new code to produce unified forwarder blocks for
PHIs.

I am not including the testcase itself since
checking it for Invalid sum is probably going to be too fragile and this
should
show in our LNT testers. The patch however fixes the mismatch.

Bootstrapped/regtested x86_64-linux and plan to commit it shortly.

gcc/ChangeLog:

PR tree-optimization/109849
* tree-ssa-dce.cc (make_forwarders_with_degenerate_phis): Fix
profile
count of newly constructed forwarder block.

[Bug target/110411] ICE on simple memcpy test case when allowing generation of vector pair load/store insns

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

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #3 from Peter Bergner  ---
Jeevitha is going to look at fixing this for us.

[Bug tree-optimization/110412] [14 Regression] GCN 'gcc.dg/vect/pr65494.c' ICE, 'error: invalid types in nop conversion'

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=110371
  Component|target  |tree-optimization
   Target Milestone|--- |14.0

--- Comment #1 from Andrew Pinski  ---
I think this was just fixed by r14-2085 or r14-2086 (both aka PR 110371).

[Bug tree-optimization/110410] [14 Regression] Different results between -O0 and -O2

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||110252
 Status|UNCONFIRMED |NEW
   Keywords|needs-bisection |missed-optimization
 Ever confirmed|0   |1
   Last reconfirmed||2023-06-26

--- Comment #5 from Andrew Pinski  ---
This is basically a dup of bug 110252 as the range of iftmp.7_27 is flow
sensitive here.

BUT there is a missed optimization before hand though:
  # RANGE [irange] unsigned int [0, 0] NONZERO 0x0
  iftmp.7_27 = (unsigned intD.9) _7;

This shows up in dom3. So keeping it open for that case too ...


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110252
[Bug 110252] [14 Regression] Wrong code at -O2/3/s on x86_64-linux-gnu

[Bug tree-optimization/110410] [14 Regression] Different results between -O0 and -O2

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

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

--- Comment #4 from Andrew Pinski  ---
Yes phiopt again:

  _7 = _3 >> _6;
  iftmp.7_27 = (unsigned int) _7;
  _13 = _7 > 0;
  _12 = (unsigned int) _13;
  _11 = _12 | iftmp.7_27;

[Bug fortran/110415] New: (Re)allocation on assignment to allocatable polymorphic variable from allocatable polymorphic function result

[everythingfunctional at protonmail dot com via Gcc-bugs]

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

Bug ID: 110415
   Summary: (Re)allocation on assignment to allocatable
polymorphic variable from allocatable polymorphic
function result
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: everythingfunctional at protonmail dot com
  Target Milestone: ---

A reproducer and explanation can be found at:
https://github.com/HPC-Bugs/reproducers/tree/main/compiler/Fortran/gfortran/polymorphic-function-assignment

[Bug ada/110398] Program_Error sem_eval.adb:4635 explicit raise

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||ebotcazou at gcc dot gnu.org
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2023-06-26

--- Comment #1 from Eric Botcazou  ---
Please read the instructions at https://gcc.gnu.org/bugs/#gnat

[Bug ada/110336] Ada doesn't build with coverage enabled on Arm

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Botcazou  ---
Yes, there are no traces of coverage support in the Ada Makefiles.

[Bug tree-optimization/110414] New: [14 Regression] Dead Code Elimination Regression since r14-1127-g9e2017ae6ac

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

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

Bug ID: 110414
   Summary: [14 Regression] Dead Code Elimination Regression
since  r14-1127-g9e2017ae6ac
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: theodort at inf dot ethz.ch
  Target Milestone: ---

https://godbolt.org/z/5E795dPvY

Given the following code:

void foo(void);
static int a, b, e, l, m, n;
static int *c = , *j;
static int **d = 
static int ***f;
void __assert_fail(char *, char *, int, char *) __attribute__((__noreturn__));
static void g(char) {
if (c ==  || c == )
;
else
__assert_fail("", "", 3, __PRETTY_FUNCTION__);
}
static void h();
static int *i();
static short k() {
j = i();
h();
**f = 
if (c ==  || c ==  || c == 0)
__assert_fail("", "", 6, __PRETTY_FUNCTION__);
return 0;
}
static void h() {
if (l) {
for (; l; l = l - 8) *d = 
if (c == )
;
else
__assert_fail("", "", 9, __PRETTY_FUNCTION__);
}
if (c ==  || c ==  || c == 0)
;
else {
foo();
__assert_fail("", "", 8, __PRETTY_FUNCTION__);
}
}
static int *i() {
if (c ==  || c == )
;
else {
__builtin_unreachable();
__assert_fail("", "", 6, __PRETTY_FUNCTION__);
}
return 
}
int main() { g(a && k()); }

gcc-trunk -Os does not eliminate the call to foo:

main:
pushq   %rcx
cmpl$0, a(%rip)
je  .L2
movll(%rip), %edx
testl   %edx, %edx
je  .L3
movl%edx, %eax
movl$__PRETTY_FUNCTION__.1, %ecx
movq$m, c(%rip)
shrl$3, %eax
imull   $-8, %eax, %eax
addl%edx, %eax
movl$9, %edx
movl%eax, l(%rip)
jmp .L7
.L3:
movqc(%rip), %rax
cmpq$a, %rax
sete%dl
cmpq$b, %rax
sete%cl
orb %cl, %dl
jne .L4
testq   %rax, %rax
je  .L4
callfoo
movl$__PRETTY_FUNCTION__.1, %ecx
movl$8, %edx
.L7:
movl$.LC0, %esi
movq%rsi, %rdi
call__assert_fail
.L4:
movl$__PRETTY_FUNCTION__.2, %ecx
movl$6, %edx
jmp .L7
.L2:
movqc(%rip), %rax
cmpq$a, %rax
je  .L5
cmpq$b, %rax
je  .L5
movl$__PRETTY_FUNCTION__.0, %ecx
movl$3, %edx
jmp .L7
.L5:
xorl%eax, %eax
popq%rdx
ret

gcc-13.1.0 -Os eliminates the call to foo:

main:
pushq   %rcx
movqc(%rip), %rdx
cmpq$a, %rdx
sete%al
cmpq$b, %rdx
sete%dl
orl %edx, %eax
cmpl$0, a(%rip)
je  .L2
movll(%rip), %edx
testl   %edx, %edx
je  .L3
movl%edx, %eax
movl$__PRETTY_FUNCTION__.1, %ecx
movq$m, c(%rip)
shrl$3, %eax
imull   $-8, %eax, %eax
addl%edx, %eax
movl$9, %edx
movl%eax, l(%rip)
jmp .L7
.L2:
testb   %al, %al
jne .L5
movl$__PRETTY_FUNCTION__.0, %ecx
movl$3, %edx
.L7:
movl$.LC0, %esi
movq%rsi, %rdi
call__assert_fail
.L3:
movl$__PRETTY_FUNCTION__.2, %ecx
movl$6, %edx
jmp .L7
.L5:
xorl%eax, %eax
popq%rdx
ret

Bisects to r14-1127-g9e2017ae6ac

[Bug target/110411] ICE on simple memcpy test case when allowing generation of vector pair load/store insns

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

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

Peter Bergner  changed:

   What|Removed |Added

  Known to fail||11.0, 12.0, 13.0, 14.0

--- Comment #2 from Peter Bergner  ---
Failure goes back to GCC 11, which is the start of P10 code generation, so not
a regression.  The work around is to use the -mno-block-ops-vector-pair option,
which is the default.

[Bug tree-optimization/110413] New: [14 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r14-1880-g827e208fa64

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

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

Bug ID: 110413
   Summary: [14 Regression] Missed Dead Code Elimination when
using __builtin_unreachable since
r14-1880-g827e208fa64
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: theodort at inf dot ethz.ch
  Target Milestone: ---

https://godbolt.org/z/75vvarEvs

Given the following code:

void foo(void);
static int a, b, d, e, g, h;
static short f;
static int *i, *k;
static int **l = 
void __assert_fail(char *, char *, int, char *) __attribute__((__noreturn__));
static int(c)() { return a + b; }
static int *j() {
f | e & 4073709551611 && c();
return 
}
int main() {
*l = j();
h = 5;
for (; h; h--) {
k = j();
if (k && k <= )
;
else {
__builtin_unreachable();
__assert_fail("", "", 0, __PRETTY_FUNCTION__);
}
}
if (k || k == )
;
else
foo();
;
}

gcc-trunk -O1 does not eliminate the call to foo:

j:
movl$d, %eax
ret


main:
subq$8, %rsp
movl$0, %eax
callj
movq%rax, i(%rip)
movq%rax, k(%rip)
movl$0, h(%rip)
cmpq$g, %rax
je  .L3
testq   %rax, %rax
je  .L5
.L3:
movl$0, %eax
addq$8, %rsp
ret
.L5:
callfoo
jmp .L3

gcc-13.1.0 -O1 eliminates the call to foo:

j:
movl$d, %eax
ret


main:
movl$0, %eax
callj
movq%rax, i(%rip)
movq%rax, k(%rip)
movl$0, h(%rip)
movl$0, %eax
ret

Bisects to r14-1880-g827e208fa64

[Bug target/110411] ICE on simple memcpy test case when allowing generation of vector pair load/store insns

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

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

Peter Bergner  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||linkw at gcc dot gnu.org,
   ||meissner at gcc dot gnu.org,
   ||segher at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-06-26
 Target||powerpc*-*-*

--- Comment #1 from Peter Bergner  ---
I'll note this was reported by our Linux kernel team.

The problem here is the expression we assign to src ends up looking like an
altivec and:DI memory address and that type of address is invalid for a
lxvp/stxvp instruction.  fwprop seems to be creating it:

propagating insn 7 into insn 9, replacing:
(set (reg:DI 123 [ src ])
(and:DI (reg:DI 122)
(reg:DI 124 [ ptr ])))
successfully matched this instruction to anddi3_mask:
(set (reg:DI 123 [ src ])
(and:DI (reg:DI 124 [ ptr ])
(const_int -16 [0xfff0])))
rescanning insn with uid = 9.
updating insn 9 in-place
verify found no changes in insn with uid = 9.

propagating insn 9 into insn 10, replacing:
(set (reg:OO 125 [ MEM  [(void *)src_4] ])
(mem:OO (reg:DI 123 [ src ]) [0 MEM  [(void *)src_4]+0 S32
A128]))
successfully matched this instruction to *movoo:
(set (reg:OO 125 [ MEM  [(void *)src_4] ])
(mem:OO (and:DI (reg:DI 124 [ ptr ])
(const_int -16 [0xfff0])) [0 MEM  [(void
*)src_4]+0 S32 A128]))


Clearly, movoo shouldn't allow these types of addresses.

[Bug target/110412] New: [14 Regression] GCN 'gcc.dg/vect/pr65494.c' ICE, 'error: invalid types in nop conversion'

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

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

Bug ID: 110412
   Summary: [14 Regression] GCN 'gcc.dg/vect/pr65494.c' ICE,
'error: invalid types in nop conversion'
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org
  Target Milestone: ---
Target: GCN

In GCC commit
bc6bd0d608da1609c1caeb04ab795a83720add55..ad5ab848cc487b3f7fd82c7cb3c408747bd10422
appeared a new GCN ICE:

[-PASS:-]{+FAIL: gcc.dg/vect/pr65494.c (internal compiler error:
verify_gimple failed)+}
{+FAIL:+} gcc.dg/vect/pr65494.c (test for excess errors)
[-FAIL:-]{+PASS:+} gcc.dg/vect/pr65494.c scan-tree-dump vect "vectorized 1
loops in function"

[...]/gcc/testsuite/gcc.dg/vect/pr65494.c: In function 'foo':
[...]/gcc/testsuite/gcc.dg/vect/pr65494.c:9:6: error: invalid types in nop
conversion
float
unsigned char
vect__37.29_187 = (vector(64) float) vect__36.27_201;
[...]/gcc/testsuite/gcc.dg/vect/pr65494.c:9:6: error: invalid types in nop
conversion
float
unsigned char
vect__37.29_185 = (vector(64) float) vect__36.28_199;
[...]/gcc/testsuite/gcc.dg/vect/pr65494.c:9:6: error: invalid types in nop
conversion
float
unsigned char
vect__56.38_164 = (vector(64) float) vect__55.36_169;
[...]/gcc/testsuite/gcc.dg/vect/pr65494.c:9:6: error: invalid types in nop
conversion
float
unsigned char
vect__56.38_162 = (vector(64) float) vect__55.37_167;
[...]/gcc/testsuite/gcc.dg/vect/pr65494.c:9:6: error: invalid types in nop
conversion
float
unsigned char
vect__75.47_141 = (vector(64) float) vect__74.45_146;
[...]/gcc/testsuite/gcc.dg/vect/pr65494.c:9:6: error: invalid types in nop
conversion
float
unsigned char
vect__75.47_139 = (vector(64) float) vect__74.46_144;
[...]/gcc/testsuite/gcc.dg/vect/pr65494.c:9:6: error: invalid types in nop
conversion
float
unsigned char
vect__94.20_218 = (vector(64) float) vect__93.18_223;
[...]/gcc/testsuite/gcc.dg/vect/pr65494.c:9:6: error: invalid types in nop
conversion
float
unsigned char
vect__94.20_216 = (vector(64) float) vect__93.19_221;
[...]/gcc/testsuite/gcc.dg/vect/pr65494.c:9:6: error: invalid types in nop
conversion
float
unsigned char
vect__113.12_238 = (vector(64) float) vect__112.10_243;
[...]/gcc/testsuite/gcc.dg/vect/pr65494.c:9:6: error: invalid types in nop
conversion
float
unsigned char
vect__113.12_236 = (vector(64) float) vect__112.11_241;
during GIMPLE pass: vect
dump file: pr65494.c.173t.vect
[...]/gcc/testsuite/gcc.dg/vect/pr65494.c:9:6: internal compiler error:
verify_gimple failed
0xfcd424 verify_gimple_in_cfg(function*, bool, bool)
[...]/gcc/tree-cfg.cc:5646
0xe2b117 execute_function_todo
[...]/gcc/passes.cc:2098
0xe2ba45 execute_todo
[...]/gcc/passes.cc:2152

[Bug target/110411] New: ICE on simple memcpy test case when allowing generation of vector pair load/store insns

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

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

Bug ID: 110411
   Summary: ICE on simple memcpy test case when allowing
generation of vector pair load/store insns
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bergner at gcc dot gnu.org
  Target Milestone: ---

bergner@ltcden2-lp1:~$ cat bug.c
#include 

struct s {
  long a;
  long b;
  long c;
  long d: 1;
};
unsigned long ptr;

void
bug (struct s *dst)
{
  struct s *src = (struct s *)(ptr & ~0xFUL);
  memcpy (dst, src, sizeof(struct s));
}

bergner@ltcden2-lp1:~$ gcc -S -O2 -mcpu=power10 -mblock-ops-vector-pair bug.c
during RTL pass: final
bug.c: In function 'bug':
bug.c:16:1: internal compiler error: output_operand: invalid expression as
operand
   16 | }
  | ^
0x10dea57b output_operand_lossage(char const*, ...)
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/final.cc:3190
0x10dee2bb output_addr_const(_IO_FILE*, rtx_def*)
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/final.cc:3787
...

[Bug middle-end/110377] Early VRP and IPA-PROP should work out value ranges from __builtin_unreachable

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #2 from Andrew Macleod  ---
(In reply to Jan Hubicka from comment #0)
> In the following testcase
> void test2(int);
> void
> test(int n)
> {
> if (n > 5)
>   __builtin_unreachable ();
> test2(n);
> }
> we should work out that value range of n passed to test2 is [INT_MIN,4].
> This would help optimizing some code in libstdc++, which now uses similar
> constructs to ensure known value ranges.

Ranger does already know this at the call site (this is output from what it
know during EVRP for instance):

=== BB 4 
n_1(D)  [irange] int [-INF, 5]
 :
test2 (n_1(D));
return;

All you need to do is either query a ranger during processing of the parameter,
or tag the parameter on the call at some point..  It would be far more
effective than trying to use global ranges to communicate the information.

I had always presumed we would eventually get to the place where we can use
context sensitive range information at each call site during IPA analysis.  And
that likewise, we'd communicate back at call sites what the return range might
be when available.  (That would be a range query at the return locations of the
value on the return)

[Bug tree-optimization/110251] [13/14 Regression] Hang at -O3 on x86_64-linux-gnu

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #7 from Andrew Macleod  ---
(In reply to Andrew Macleod from comment #6)
> bah.
> 
> Ranger hang is resolved with:
>  
> commit 4dfeb1cd8dfca234186216d891ec8f46235c3a14 
> Date:   Thu Jun 22 10:00:12 2023 -0400
> 
> Avoid redundant GORI calcualtions.

When GORI evaluates a statement, if operand 1 and 2 are both in the
dependency chain, GORI evaluates the name through both operands
sequentially
and combines the results.

If either operand is in the dependency chain of the other, this
evaluation will do the same work twice, for questionable gain.
Instead, simple evaluate only the operand which depends on the other
and keep the evaluation linear in time.

[Bug tree-optimization/110251] [13/14 Regression] Hang at -O3 on x86_64-linux-gnu

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #6 from Andrew Macleod  ---
bah.

Ranger hang is resolved with:

commit 4dfeb1cd8dfca234186216d891ec8f46235c3a14 
Date:   Thu Jun 22 10:00:12 2023 -0400

Avoid redundant GORI calcualtions.

[Bug c++/110403] dependent function constexpr inside vector_size __attribute__ does not compile

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

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

Patrick Palka  changed:

   What|Removed |Added

   Keywords||rejects-valid
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=105233
 Ever confirmed|0   |1
 CC||ppalka at gcc dot gnu.org
   Last reconfirmed||2023-06-26
 Status|UNCONFIRMED |NEW

--- Comment #2 from Patrick Palka  ---
Confirmed, closely related to PR105233 which was the same issue for the aligned
attribute (and alignas), and was fixed by performing manifestly constant
evaluation of their argument.  I guess the same could be done for vector_size?

[Bug other/110239] [14 regression] std/format/functions/format.cc fails after r14-1648-g628ba410b9265d

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

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> ==55393==ERROR: AddressSanitizer: global-buffer-overflow on address
> 0x004c9324 at pc 0x00432970 bp 0x7ffe2c7fcf80 sp 0x7ffe2c7fcf78
> READ of size 4 at 0x004c9324 thread T0
> #0 0x43296f in std::pair
> std::__format::__parse_integer(wchar_t const*, wchar_t const*)
> /home/jwakely/gcc/14/include/c++/14.0.0/format:301

That's actually a separate bug that only affects formatting wide strings. I
have a fix for that, but the bug for 32-bit targets is simply:

@@ -2118,7 +2105,7 @@ namespace __format
typename basic_format_context<_Out, _CharT>::iterator
format(const void* __v, basic_format_context<_Out, _CharT>& __fc) const
{
- auto __u = reinterpret_cast<__UINT64_TYPE__>(__v);
+ auto __u = reinterpret_cast<__UINTPTR_TYPE__>(__v);
  char __buf[2 + sizeof(__v) * 2];
  auto [__ptr, __ec] = std::to_chars(__buf + 2, std::end(__buf),
 __u, 16);

Casting the pointer to uint64_t sign extends it, which produces a very large
64-bit integer that doesn't fit in __buf.

[Bug target/109780] [12/13/14 Regression] csmith: runtime crash with -O2 -march=znver1

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

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

--- Comment #14 from Xi Ruoyao  ---
Any clue about how to fix this?

[Bug tree-optimization/105816] SLP vectorize permutes from different groups

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

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

--- Comment #1 from Richard Biener  ---
For example for

void __attribute__((noipa)) test_lo (short * __restrict dst, short *src1, short
*src2, int n)
{
  for (int i = 0; i < n; ++i)
{
  dst[0] = src1[0];
  dst[1] = src1[1];
  dst[2] = src1[2];
  dst[3] = src1[3];
  dst[4] = src2[0];
  dst[5] = src2[1];
  dst[6] = src2[2];
  dst[7] = src2[3];
  dst+=8;
  src1+=4;
  src2+=4;
}
}

we generate

.L4:
movdqu  (%rsi,%rax), %xmm0
movq%xmm0, (%rdi,%rax,2)
movhps  %xmm0, 16(%rdi,%rax,2)
movdqu  (%rdx,%rax), %xmm0
movq%xmm0, 8(%rdi,%rax,2)
movhps  %xmm0, 24(%rdi,%rax,2)
addq$16, %rax
cmpq%r8, %rax
jne .L4

but ideally we'd interleave two V2DImode vectors and perform two SSE vector
stores.  With AVX2 the above gets

.L4:
vmovdqu (%r10,%rdx), %ymm0
addq$64, %rax
vmovq   %xmm0, -64(%rax)
vpextrq $1, %xmm0, -48(%rax)
vextracti128$0x1, %ymm0, %xmm0
vmovq   %xmm0, -32(%rax)
vpextrq $1, %xmm0, -16(%rax)
vmovdqu (%r9,%rdx), %ymm0
addq$32, %rdx
vmovq   %xmm0, -56(%rax)
vpextrq $1, %xmm0, -40(%rax)
vextracti128$0x1, %ymm0, %xmm0
vmovq   %xmm0, -24(%rax)
vpextrq $1, %xmm0, -8(%rax)
cmpq%rcx, %rdx
jne .L4

the unpacks would be there in the SLP tree if we would not split the
instance.

[Bug tree-optimization/110410] [14 Regression] Different results between -O0 and -O2

[jwzeng at nuaa dot edu.cn via Gcc-bugs]

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

--- Comment #3 from Jw Zeng  ---
(In reply to Richard Biener from comment #2)
> phi-opt again?

Link to the Compiler Explorer:https://godbolt.org/z/EeEqMGnWo

I reduced the code again, I hope it helps. The reduced code is as follows:

#include 

int var_1 = 1;
int var_2 = 0;
unsigned short var_3 = 7472;
int var_4 = 518868156U;
unsigned var_5;
#define min(a, b) ((a) < (b) ? (a) : (b))

int main() {
var_5 = min(var_1 ? var_3 >> (var_4 - 518868145U) : var_2, 1);
printf("%d\n", var_5);
return 0;
}

[Bug tree-optimization/110381] [11/12/13 Regression] double counting for sum of structs of floating point types

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[11/12/13/14 Regression]|[11/12/13 Regression]
   |double counting for sum of  |double counting for sum of
   |structs of floating point   |structs of floating point
   |types   |types
  Known to work||14.0

--- Comment #11 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/110381] [11/12/13/14 Regression] double counting for sum of structs of floating point types

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

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

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

https://gcc.gnu.org/g:53d6f57c1b20c6da52aefce737fb7d5263686ba3

commit r14-2095-g53d6f57c1b20c6da52aefce737fb7d5263686ba3
Author: Richard Biener 
Date:   Mon Jun 26 12:51:37 2023 +0200

tree-optimization/110381 - preserve SLP permutation with in-order
reductions

The following fixes a bug that manifests itself during fold-left
reduction transform in picking not the last scalar def to replace
and thus double-counting some elements.  But the underlying issue
is that we merge a load permutation into the in-order reduction
which is of course wrong.

Now, reduction analysis has not yet been performend when optimizing
permutations so we have to resort to check that ourselves.

PR tree-optimization/110381
* tree-vect-slp.cc
(vect_optimize_slp_pass::start_choosing_layouts):
Materialize permutes before fold-left reductions.

* gcc.dg/vect/pr110381.c: New testcase.

[Bug tree-optimization/110410] [14 Regression] Different results between -O0 and -O2

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-bisection, wrong-code
   Target Milestone|--- |14.0

--- Comment #2 from Richard Biener  ---
phi-opt again?

[Bug c++/110380] [feature request] "-pg-constexpr=coverage-output" emit coverage metrics for constexpr code evaluated at compile time

[anthony.ajw at gmail dot com via Gcc-bugs]

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

Anthony Williams  changed:

   What|Removed |Added

 CC||anthony.ajw at gmail dot com

--- Comment #5 from Anthony Williams  ---
Yes, we have this problem too. In some cases we've explicitly duplicated tests
in static_assert and runtime-assert in order to convince gcov that the
functions are tested, but things like "std::is_constant_evaluated()" mean that
there might be different branches in runtime vs compile time cases, so
"-fprofile-constexpr" would be really useful

[Bug rtl-optimization/110237] gcc.dg/torture/pr58955-2.c is miscompiled by RTL scheduling after reload

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #17 from rguenther at suse dot de  ---
On Mon, 26 Jun 2023, amonakov at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237
> 
> --- Comment #16 from Alexander Monakov  ---
> (In reply to rguent...@suse.de from comment #14)
> > vectors of T and scalar T interoperate TBAA wise.  What we disambiguate is
> > 
> > int a[2];
> > 
> > int foo(int *p)
> > {
> >   a[0] = 1;
> >   *(v4si *)p = {0,0,0,0};
> >   return a[0];
> > }
> > 
> > because the V4SI vector store is too large for the a[] object.  That
> > doesn't even use TBAA (it works with -fno-strict-aliasing just fine).
> 
> Thank you for the example. If we do the same for vector loads, that's a 
> footgun
> for users who use vector loads to access small objects:
> 
> // alignment to 16 is ensured externally
> extern int a[2];
> 
> int foo()
> {
>   a[0] = 1;
> 
>   __v4si v = (__attribute__((may_alias)) __v4si *) 
>   // mask out extra elements in v and continue
>  ...
> }
> 
> This is a benign data race on data that follows 'a' in the address space, but
> otherwise should be a valid and useful technique.

Yes, we do the same to loads.  I hope that's not a common technique
though but I have to admit the vectorizer itself assesses whether it's
safe to access "gaps" by looking at alignment so its code generation
is prone to this same "mistake".

Now, is "alignment to 16 is ensured externally" good enough here?
If we consider

static int a[2];

and code doing

 if (is_aligned (a))
   {
 __v4si v = (__attribute__((may_alias)) __v4si *) 
   }

then we cannot even use a DECL_ALIGN that's insufficient for decls
that bind locally.

Note we have similar arguments with aggregate type sizes (and TBAA)
where when we infer a dynamic type from one access we check if
the other access would fit.  Wouldn't the above then extend to that
as well given we could also do aggregate copies of "padding" and
ignore the bits if we'd have ensured the larger access wouldn't trap?

So supporting the above might be a bit of a stretch (though I think
we have to fix the vectorizer here).

> > If the v4si store is masked we cannot do this anymore, but the IL
> > we seed the alias oracle with doesn't know the store is partial.
> > The only way to "fix" it is to take away all of the information from it.
> 
> But that won't fix the trapping issue? I think we need a distinct RTX for
> memory accesses where hardware does fault suppression for masked-out elements.

Yes, it doesn't fix that part.  The idea of using BLKmode instead of
a vector mode for the MEMs would, I guess, together with specifying
MEM_SIZE as not known.

[Bug tree-optimization/110392] [13 Regression] ICE at -O3 with "-O3 -Wall -fno-tree-vrp -fno-tree-dominator-opts -fno-tree-copy-prop -fno-tree-fre -fno-tree-ccp -fno-tree-forwprop": in find_var_cmp_co

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[13/14 Regression] ICE at   |[13 Regression] ICE at -O3
   |-O3 with "-O3 -Wall |with "-O3 -Wall
   |-fno-tree-vrp   |-fno-tree-vrp
   |-fno-tree-dominator-opts|-fno-tree-dominator-opts
   |-fno-tree-copy-prop |-fno-tree-copy-prop
   |-fno-tree-fre -fno-tree-ccp |-fno-tree-fre -fno-tree-ccp
   |-fno-tree-forwprop": in |-fno-tree-forwprop": in
   |find_var_cmp_const, at  |find_var_cmp_const, at
   |gimple-predicate-analysis.c |gimple-predicate-analysis.c
   |c:257   |c:257
   Priority|P3  |P2
  Known to work||14.0

[Bug tree-optimization/110392] [13/14 Regression] ICE at -O3 with "-O3 -Wall -fno-tree-vrp -fno-tree-dominator-opts -fno-tree-copy-prop -fno-tree-fre -fno-tree-ccp -fno-tree-forwprop": in find_var_cmp

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

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

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

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

commit r14-2089-gab6eac20f00761695c69b555f6b0a026bc25770d
Author: Richard Biener 
Date:   Mon Jun 26 11:21:43 2023 +0200

tree-optimization/110392 - ICE with predicate analysis

Feeding not optimized IL can result in predicate normalization
to simplify things so a predicate can get true or false.  The
following re-orders the early exit in that case to come after
simplification and normalization to take care of that.

PR tree-optimization/110392
* gimple-predicate-analysis.cc (uninit_analysis::is_use_guarded):
Do early exits on true/false predicate only after normalization.

[Bug tree-optimization/110381] [11/12/13/14 Regression] double counting for sum of structs of floating point types

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #9 from Richard Biener  ---
I think the transform phase is correct but the analysis phase fails to reject
this case because there's a permutation we elide even though that will not
preserve the fold-left reduction semantics.  We analyze the SLP node to

t.c:12:23: note:   Final SLP tree for instance 0x4c90840:
t.c:12:23: note:   node 0x4d57380 (max_nunits=2, refcnt=3) vector(2) double
t.c:12:23: note:   op template: sum_13 = foo$c_8 + sum_22;
t.c:12:23: note:stmt 0 sum_13 = foo$c_8 + sum_22;
t.c:12:23: note:stmt 1 sum_14 = foo$b_9 + sum_13;
t.c:12:23: note:stmt 2 sum_15 = foo$a_11 + sum_14;
t.c:12:23: note:children 0x4d57408 0x4d57490
t.c:12:23: note:   node 0x4d57408 (max_nunits=2, refcnt=2) vector(2) double
t.c:12:23: note:   op template: foo$c_8 = _3->c;
t.c:12:23: note:stmt 0 foo$c_8 = _3->c;
t.c:12:23: note:stmt 1 foo$b_9 = _3->b;
t.c:12:23: note:stmt 2 foo$a_11 = _3->a;
t.c:12:23: note:load permutation { 2 1 0 }
t.c:12:23: note:   node 0x4d57490 (max_nunits=2, refcnt=2) vector(2) double
t.c:12:23: note:   op template: sum_22 = PHI 
t.c:12:23: note:stmt 0 sum_22 = PHI 
t.c:12:23: note:stmt 1 sum_22 = PHI 
t.c:12:23: note:stmt 2 sum_22 = PHI 
t.c:12:23: note:children 0x4d57380 (nil)

but optimize_slp mangles things here.

We have

  /* We have to mark outgoing permutations facing non-reduction graph
 entries that are not represented as to be materialized.  */
  for (slp_instance instance : m_vinfo->slp_instances)
if (SLP_INSTANCE_KIND (instance) == slp_inst_kind_ctor)
  {   
unsigned int node_i = SLP_INSTANCE_TREE (instance)->vertex;
m_partitions[m_vertices[node_i].partition].layout = 0;
  }

unfortunately this all happens before we determine the reduction is
in-order.  The only thing we can do here is check
needs_fold_left_reduction_p directly.

I'm testing a patch.

[Bug c++/110380] [feature request] "-pg-constexpr=coverage-output" emit coverage metrics for constexpr code evaluated at compile time

[gasper.azman at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Gašper Ažman  ---
John McFarlane noted that pre-initializing coverage datastructures with the
results of the constexpr-evaluated traces would also be a possible direction.
It does mean the linker needs to then correctly merge those, otherwise you lose
constexpr coverage at link time.

[Bug c++/110380] [feature request] "-pg-constexpr=coverage-output" emit coverage metrics for constexpr code evaluated at compile time

[hanicka at hanicka dot net via Gcc-bugs]

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

Hana Dusíková  changed:

   What|Removed |Added

 CC||hanicka at hanicka dot net

--- Comment #3 from Hana Dusíková  ---
This would be really useful for many constexpr only libraries (like CTRE).

[Bug tree-optimization/110371] [14 Regression] gfortran ICE "verify_gimple failed" in gfortran.dg/vect/pr51058-2.f90 since r14-2007

[thiago.bauermann at linaro dot org via Gcc-bugs]

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

Thiago Jung Bauermann  changed:

   What|Removed |Added

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

--- Comment #10 from Thiago Jung Bauermann  
---
Your commit fixed the gfortran failures I reported, thank you!

The aarch64-sve.exp failures are still there, but it's a separate issue.

[Bug tree-optimization/110410] [14 Regression] Different results between -O0 and -O2

[jwzeng at nuaa dot edu.cn via Gcc-bugs]

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

--- Comment #1 from Jw Zeng  ---
Link to the Compiler Explorer: https://godbolt.org/z/d5v5scnP4

[Bug tree-optimization/110381] [11/12/13/14 Regression] double counting for sum of structs of floating point types

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

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

--- Comment #8 from Richard Biener  ---
OK, so we transform the in-order FOLD_LEFT_REDUCTION as

  # sum_22 = PHI 
  # vectp_foos.7_25 = PHI 
...
  vect_foo_c_8.9_21 = MEM  [(double *)vectp_foos.7_25];
  vectp_foos.7_20 = vectp_foos.7_25 + 16;
  vect_foo_c_8.10_7 = MEM  [(double *)vectp_foos.7_20];
  vectp_foos.7_6 = vectp_foos.7_25 + 32;
  vect_foo_c_8.11_5 = MEM  [(double *)vectp_foos.7_6];
  stmp_sum_13.12_4 = BIT_FIELD_REF ;
  stmp_sum_13.12_31 = sum_22 + stmp_sum_13.12_4;
  stmp_sum_13.12_32 = BIT_FIELD_REF ;
  stmp_sum_13.12_33 = stmp_sum_13.12_31 + stmp_sum_13.12_32;
  stmp_sum_13.12_34 = BIT_FIELD_REF ;
  stmp_sum_13.12_35 = stmp_sum_13.12_33 + stmp_sum_13.12_34;
  stmp_sum_13.12_36 = BIT_FIELD_REF ;
  stmp_sum_13.12_37 = stmp_sum_13.12_35 + stmp_sum_13.12_36;
  stmp_sum_13.12_38 = BIT_FIELD_REF ;
  stmp_sum_13.12_39 = stmp_sum_13.12_37 + stmp_sum_13.12_38;
  stmp_sum_13.12_40 = BIT_FIELD_REF ;
  foo$a_11 = _3->a;
  foo$b_9 = _3->b;
  foo$c_8 = _3->c;
  sum_13 = stmp_sum_13.12_39 + stmp_sum_13.12_40;
  sum_14 = foo$b_9 + sum_13;
  sum_15 = foo$a_11 + sum_14;

where you can see the final step updates one but not the last scalar stmt
in the SLP reduction group.  That causes us to keep the scalar reads live
and apply some elements multiple times.

[Bug tree-optimization/110410] New: [14 Regression] Different results between -O0 and -O2

[jwzeng at nuaa dot edu.cn via Gcc-bugs]

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

Bug ID: 110410
   Summary: [14 Regression] Different results between -O0 and -O2
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jwzeng at nuaa dot edu.cn
  Target Milestone: ---

The following code snippet:

#include 
int seed;
void hash(int *seed, int v) { *seed ^= v; }
unsigned int var_6 = 1341494070U;
int var_7 = 0;
unsigned short var_8 = 7472;
int var_13 = 518868156U;
unsigned var_17;
#define min(a, b) ((a) < (b) ? (a) : (b))
void test() {
for (int ii_0 = 0; ii_0 < 20; ++ii_0)
for (int ii_1 = 0; ii_1 < 10; ++ii_1)
var_17 = min(var_6 ? var_8 >> (var_13 - 518868145U) : var_7,
1887837879 || 0);
}
int main() {
test(2062689408U);
hash(, var_17);
printf("%d\n", seed);
return 0;
}

> $ /usr/gcc-trunk/bin/gcc -O0 bug.c; ./a.out
> 1
> $ /usr/gcc-trunk/bin/gcc -O2 bug.c; ./a.out
> 3

When compiled with -O2 or -O3, it prints 3 instead of 1. Earlier GCCs do not
have this bug.

> $ /usr/gcc-trunk/bin/gcc --version
gcc (GCC) 14.0.0 20230619 (experimental) [master r14-1917-gf8e0270272]
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE

[Bug target/110406] d: Wrong code-gen returning POD structs by value

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

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

--- Comment #9 from ibuclaw at gcc dot gnu.org ---
(In reply to ibuclaw from comment #8)
> So long as C and D agree with each other when it comes to POD types, it
> almost doesn't matter to me weather the back-end is following the wrong ABI.
Or whether.

[Bug target/110406] d: Wrong code-gen returning POD structs by value

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

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

--- Comment #8 from ibuclaw at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #7)
> (In reply to Andrew Pinski from comment #6)
> > Which itself is GCC 12+ regression too ...
> 
> I filed that as PR 110407, let's see what the x86 backend folks say ...
OK, in the meantime I will proceed with seeing what I did to change the return
behaviour on my end.

So long as C and D agree with each other when it comes to POD types, it almost
doesn't matter to me weather the back-end is following the wrong ABI.

[Bug tree-optimization/110381] [11/12/13/14 Regression] double counting for sum of structs of floating point types

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

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

--- Comment #7 from Richard Biener  ---
C testcase:

struct FOO {
   double a;
   double b;
   double c;
};

double __attribute__((noipa))
sum_8_foos(const struct FOO* foos)
{
double sum = 0;

for (int i = 0; i < 8; ++i) {
struct FOO foo = foos[i];

sum += foo.c;
sum += foo.b;
sum += foo.a;
}

return sum;
}

int main()
{
  struct FOO foos[8];

  __builtin_memset (foos, 0, sizeof (foos));
  foos[0].b = 5;

  if (sum_8_foos (foos) != 5)
__builtin_abort ();
  return 0;
}

[Bug rtl-optimization/110391] [12/13/14 Regression] wrong code at -O2 and -O3 with "-fsel-sched-pipelining -fselective-scheduling2" on x86_64-linux-gnu

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

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

--- Comment #2 from Zhendong Su  ---
A likely related reproducer that affects 10.* and later. 

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

[579] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230625 (experimental) [master r14-924-gd709841ae0f] (GCC) 
[580] % 
[580] % gcctk -O2 -fsel-sched-pipelining -fschedule-insns
-fselective-scheduling2 small.c
[581] % ./a.out
Floating point exception
[582] % 
[582] % gcctk -O2 small.c; ./a.out
[583] % 
[583] % cat small.c
int printf(const char *, ...);
int a, d, e = -2;
char b;
long c = -2;
int main() {
  int g, h;
  d = e;
  g = c;
 L:
  h = d;
  c = 1;
  d = c % ~e;
  e = e >> ~g;
  if (e > b)
printf("%ld", c);
  if (g > c)
printf("%d", a);
  if (b)
goto L;
  e = h;
  return 0;
}

[Bug c++/110404] Feature request: add a new option which is like -ftrivial-auto-var-init=zero but zero-initialize instead of zero-fill

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-06-26
 CC||rguenth at gcc dot gnu.org
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Richard Biener  ---
But your testcase is invoking undefined behavior when inspecting 'ptr'?  That
doesn't change with -ftrivial-auto-var-init=zero, so getting a trap is good
here and you need to fix your code instead.

[Bug tree-optimization/110392] [13/14 Regression] ICE at -O3 with "-O3 -Wall -fno-tree-vrp -fno-tree-dominator-opts -fno-tree-copy-prop -fno-tree-fre -fno-tree-ccp -fno-tree-forwprop": in find_var_cmp

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
I will have a look.

[Bug tree-optimization/110389] [12/13/14 Regression] wrong code at -Os and -O2 with "-fno-tree-ch -fno-expensive-optimizations -fno-ivopts -fno-tree-loop-ivcanon" on x86_64-linux-gnu

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug analyzer/110387] [14 Regression] ICE: in key_t, at analyzer/region.h:1110 with -fanalyzer

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0