[Bug c++/119525] ICE when using template alias parameter deduction on alias for std::variant

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #2 from Patrick Palka  ---
This is a simpler version of PR118626

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

[Bug c++/118626] C++20 std::variant causes a segmentation fault

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

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

Patrick Palka  changed:

   What|Removed |Added

   See Also|https://gcc.gnu.org/bugzill |
   |a/show_bug.cgi?id=119525|
 CC||whiteredredcat at gmail dot com

--- Comment #10 from Patrick Palka  ---
*** Bug 119525 has been marked as a duplicate of this bug. ***

[Bug c++/119387] [14/15 Regression] Regression in performance by a factor of 6 when building with debugging symbols since r14-5979

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

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

--- Comment #14 from Patrick Palka  ---
Created attachment 60941
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60941&action=edit
reduced memory-hog testcase

I managed to distill a large chunk of the front end memory-hog into the
attached testcase (compile with -std=c++20 -O -fsyntax-only) which initializes
a 512-tuple.  The initialization is clearly non-constant, but after P2280
during speculative constexpr folding we no longer immediately give up
evaluating the hefty recursive initialization, and in the meantime create a lot
of garbage evaluating all the recursive constexpr calls in vain (and seemingly
quadratically).  The constexpr call cache doesn't help here because the
constructor arguments are non-constant.

r14-5978 (unoptimized checking):

Time variable   usr   sys  wall
  GGC
 phase setup:   0.04 (  0%)   0.01 (  8%)   0.09 (  1%)
 1773k (  3%)
 phase parsing  :   9.39 ( 99%)   0.12 ( 92%)   9.53 ( 98%)
   66M ( 97%)
 phase lang. deferred   :   0.08 (  1%)   0.00 (  0%)   0.09 (  1%)
  128  (  0%)
 |name lookup   :   7.75 ( 81%)   0.05 ( 38%)   7.85 ( 81%)
  305k (  0%)
 |overload resolution   :   0.07 (  1%)   0.01 (  8%)   0.18 (  2%)
 3802k (  5%)
 garbage collection :   0.08 (  1%)   0.00 (  0%)   0.09 (  1%)
0  (  0%)
 parser (global):   0.00 (  0%)   0.01 (  8%)   0.01 (  0%)
  585k (  1%)
 parser struct body :   0.01 (  0%)   0.00 (  0%)   0.00 (  0%)
   31k (  0%)
 parser function body   :   0.03 (  0%)   0.00 (  0%)   0.04 (  0%)
 2623k (  4%)
 template instantiation :   9.08 ( 95%)   0.10 ( 77%)   9.22 ( 95%)
   57M ( 84%)
 constant expression evaluation :   0.27 (  3%)   0.01 (  8%)   0.25 (  3%)
 6087k (  9%)
 varconst   :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
0  (  0%)
 TOTAL  :   9.51  0.13  9.71   
   67M

r14-5979 (unoptimized checking):

Time variable   usr   sys  wall
  GGC
 phase setup:   0.01 (  0%)   0.00 (  0%)   0.02 (  0%)
 1773k (  0%)
 phase parsing  :  35.94 (100%)   0.52 (100%)  36.53 (100%)
  457M (100%)
 phase lang. deferred   :   0.15 (  0%)   0.00 (  0%)   0.15 (  0%)
  128  (  0%)
 |name lookup   :   7.59 ( 21%)   0.04 (  8%)   7.86 ( 21%)
  324k (  0%)
 |overload resolution   :   0.11 (  0%)   0.00 (  0%)   0.10 (  0%)
 3809k (  1%)
 garbage collection :   0.15 (  0%)   0.00 (  0%)   0.15 (  0%)
0  (  0%)
 parser function body   :   0.03 (  0%)   0.01 (  2%)   0.03 (  0%)
 2623k (  1%)
 template instantiation :   9.10 ( 25%)   0.10 ( 19%)   9.18 ( 25%)
   57M ( 12%)
 constant expression evaluation :  26.81 ( 74%)   0.41 ( 79%)  27.32 ( 74%)
  397M ( 86%)
 TOTAL  :  36.10  0.52 36.70   
  459M

trunk (optimized release):

Time variable  wall   GGC
 phase setup:   0.01 (  1%)  1813k (  1%)
 phase parsing  :   1.42 ( 99%)   328M ( 99%)
 |name lookup   :   0.01 (  0%)   328k (  0%)
 |overload resolution   :   0.01 (  1%)  3810k (  1%)
 parser function body   :   0.00 (  0%)  2345k (  1%)
 template instantiation :   0.13 (  9%)58M ( 18%)
 constant expression evaluation :   1.28 ( 90%)   267M ( 81%)
 TOTAL  :   1.43  330M

[Bug ipa/119530] [15 regression] wrong code at -O{s,2,3} with "-fno-tree-vrp -fno-inline" on x86_64-linux-gnu since r15-6294-g96fb71883d438b

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

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Jambor  ---
Thanks for reporting, but this is a duplicate of PR 119318.

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

[Bug c++/119561] New: GCC hasn't completely forbidden user-declared specializations of std::initializer_list

[de34 at live dot cn via Gcc-bugs]

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

Bug ID: 119561
   Summary: GCC hasn't completely forbidden user-declared
specializations of std::initializer_list
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: de34 at live dot cn
  Target Milestone: ---

Per [initializer.list.syn]/2 (https://eel.is/c++draft/initializer.list.syn#2)
(added via LWG 2129 (https://cplusplus.github.io/LWG/issue2129)), the following
code snippet is ill-formed (neither UB nor IFNDR) and thus should be rejected.

(Although this is an LWG issue, compiler change is necessary.)
```
#include 

template
class std::initializer_list {
private:
  void*   m_array_;
  decltype(sizeof(0)) m_len_;
};
```

But currently GCC (/w libstdc++) silently accepts it
(https://godbolt.org/z/q6TMo91Ef).

GCC should either directly detect such specializations (like MSVC and EDG) or
provide some more general mechanism like Clang's [[clang::no_specializations]].

[Bug tree-optimization/116835] [12/13/14/15 Regression] phiprop will prop back into a loop

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

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

Sam James  changed:

   What|Removed |Added

   Severity|enhancement |normal

--- Comment #12 from Sam James  ---
wrong-code means we can promote it from enhancement

[Bug ipa/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it

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

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

Sam James  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2025-04-01

[Bug testsuite/66403] gcc.dg/torture/builtin-self.c FAILs with PIE

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

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

Sam James  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |13.0

--- Comment #4 from Sam James  ---
Should be fixed by r13-2043-g4ad200addc3eaf.

[Bug testsuite/66399] g++.dg/abi/anon4.C FAILs with PIE

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

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

Sam James  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |13.0
 Resolution|--- |FIXED

--- Comment #4 from Sam James  ---
Should be fixed by r13-2043-g4ad200addc3eaf.

[Bug testsuite/70150] Additonal test failures with --enable-default-pie

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

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

Bug 66403 Summary: gcc.dg/torture/builtin-self.c FAILs with PIE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66403

   What|Removed |Added

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

[Bug testsuite/70150] Additonal test failures with --enable-default-pie

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

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

Bug 66399 Summary: g++.dg/abi/anon4.C FAILs with PIE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66399

   What|Removed |Added

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

[Bug testsuite/70150] Additonal test failures with --enable-default-pie

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

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

Bug 66398 Summary: g++.dg/abi/anon1.C FAILs with PIE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66398

   What|Removed |Added

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

[Bug testsuite/66398] g++.dg/abi/anon1.C FAILs with PIE

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Sam James  ---
Should be fixed by r13-2043-g4ad200addc3eaf.

[Bug sanitizer/66401] g++.dg/ubsan/vla-1.C FAILs with PIE

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

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

Sam James  changed:

   What|Removed |Added

   Last reconfirmed||2025-04-01
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #5 from Sam James  ---
Maybe fixed by r6-7842-g342fac9537c6a7.

[Bug target/119547] RISC-V: VSETVL mistakenly modified other data

[zhijin.zeng at spacemit dot com via Gcc-bugs]

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

曾治金  changed:

   What|Removed |Added

 CC||zhijin.zeng at spacemit dot com

--- Comment #4 from 曾治金  ---
Created attachment 60944
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60944&action=edit
RISC-V: Fix vsetvl bug (Bug 119547)

Perhaps I am unable to solve this issue, but I would like to offer this patch
as a reference.

[Bug lto/119557] malloc attribute on function decls and merging interaction with LTO

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

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

--- Comment #3 from Andrew Pinski  ---
I should mention, malloc inlining is not the issue but rather it is the inline
of the free. So handling this is even constrained. So maybe this is a
documentation fix to warn about it and make a mention that the free side makes
the requirement of the malloc attribute to wrong and you need to remove the
malloc attribute.

[Bug ipa/119558] [meta-bug] Improve Link Time Optimization on Windows

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||mingw

--- Comment #2 from Andrew Pinski  ---
Is this about windows as a host or windows as a target. Because I think e.g.
LTO plugin does not work with windows as a host but might work with windows as
a targert with Linux as the host.

[Bug target/119556] New: gcc.target/arm/short-vfp-1.c fails

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

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

Bug ID: 119556
   Summary: gcc.target/arm/short-vfp-1.c fails
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---
Target: arm

g:78e0cf06c818e6293d36e52ad7a96bd9e7953c06 enabled gcc.target/arm/short-vfp-1.c
but all the scan-assembler directives fail.

In fact, it has (would have) always been the case: I rebuilt the compiler from
g:50df9464b86a58d5c959b10c33c1870c0c4c5e48 (r7-3249-g50df9464b86) and after
fixing the dg directives, the test was also failing. (the same applies after
patch 17/17 r7-3273-gcab9e1df4d3).


At that point, the generated code looked like:

test_sisf:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 1, uses_anonymous_args = 0
push{fp, lr}
add fp, sp, #4
sub sp, sp, #8
str r0, [fp, #-8]   @ float
ldr r0, [fp, #-8]   @ float
bl  __aeabi_f2iz
mov r3, r0
mov r0, r3
sub sp, fp, #4
@ sp needed
pop {fp, lr}
bx  lr


Or, with -O2:
test_sisf:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
push{r4, lr}
bl  __aeabi_f2iz
pop {r4, lr}
bx  lr


So there's no chance any of the scan-assembler-times directives could pass...



With today's trunk at -O2, we get:
test_sisf:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
vcvt.s32.f32s15, s0
vmovr0, s15 @ int
bx  lr
.size   test_sisf, .-test_sisf
.align  1
.p2align 2,,3
.global test_hisf
.syntax unified
.thumb
.thumb_func
.type   test_hisf, %function
test_hisf:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
vcvt.s32.f32s0, s0
vmovr3, s0  @ int
sxthr0, r3
bx  lr
.size   test_hisf, .-test_hisf
.align  1
.p2align 2,,3
.global test_sfsi
.syntax unified
.thumb
.thumb_func
.type   test_sfsi, %function
test_sfsi:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
vmovs0, r0  @ int
vcvt.f32.s32s0, s0
bx  lr
.size   test_sfsi, .-test_sfsi
.align  1
.p2align 2,,3
.global test_sfhi
.syntax unified
.thumb
.thumb_func
.type   test_sfhi, %function
test_sfhi:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
vmovs0, r0  @ int
vcvt.f32.s32s0, s0
bx  lr
.size   test_sfhi, .-test_sfhi
.align  1
.p2align 2,,3
.global test_hisi
.syntax unified
.thumb
.thumb_func
.type   test_hisi, %function
test_hisi:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
sxthr0, r0
bx  lr
.size   test_hisi, .-test_hisi
.align  1
.p2align 2,,3
.global test_sihi
.syntax unified
.thumb
.thumb_func
.type   test_sihi, %function
test_sihi:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
bx  lr


which looks good

[Bug c++/119560] New: cc1 posix_spawnp compilation error with gcc 14.2.0 on Ubuntu 24.04

[scott at smedleyfamily dot com via Gcc-bugs]

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

Bug ID: 119560
   Summary: cc1 posix_spawnp compilation error with gcc 14.2.0 on
Ubuntu 24.04
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: scott at smedleyfamily dot com
  Target Milestone: ---

Created attachment 60943
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60943&action=edit
config.log

Hi,

I'm encountering a compilation error when I build gcc 14.2.0 with gcc 13.3.0 on
Ubuntu 24.04. I'm not quite sure how to diagnose it, can someone please point
me in the right direction?

The error message:

/home/ssmedley/gcc/build-14.2.0/./gcc/xgcc
-B/home/ssmedley/gcc/build-14.2.0/./gcc/ -fno-checking -xc -nostdinc /dev/null
-S -o /dev/null -fself-test=../../gcc-14.2.0/gcc/testsuite/selftests
xgcc: fatal error: cannot execute 'cc1': posix_spawnp: No such file or
directory
compilation terminated.

config.log (gzipped) is attached.

Here's the steps I use to download/build gcc (which has worked many times in
the past, for earlier versions):

ver=14.2.0
wget
http://ftp.tsukuba.wide.ad.jp/software/gcc/releases/gcc-$ver/gcc-$ver.tar.gz
tar xvf gcc-$ver.tar.gz
cd gcc-$ver/
./contrib/download_prerequisites
mkdir ../build-$ver
cd ../build-$ver
../gcc-$ver/configure --enable-languages=c,c++ --prefix=/usr/local/gcc-$ver
--disable-multilib
make -j 4
make install

gcc -v output:

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

Any pointers would be appreciated.

Scott.

[Bug target/119473] [15 Regression] __builtin_ia32_vaesdec_v32qi() emits wrong base register with -mvaes -O2 -mapxf -m64

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Hu :

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

commit r15-9117-ge5cfa7f797b79613e5483786484567b9ca72db06
Author: Hu, Lin1 
Date:   Wed Mar 26 16:15:52 2025 +0800

i386: Add attr_isa for vaes patterns to sync with attr gpr16. [pr119473]

For vaes patterns with jm constraint and gpr16 attr, it requires "isa"
attr to distinct avx/avx512 alternatives in ix86_memory_address_reg_class.
Also adds missing type and mode attributes for those vaes patterns.

gcc/ChangeLog:

PR target/119473
* config/i386/sse.md
(vaesdec_): Set attr "isa" as "avx,vaes_avx512vl", "type" as
"sselog1", "mode" as "TI".
(vaesdeclast_): Ditto.
(vaesenc_): Ditto.
(vaesenclast_): Ditto.

gcc/testsuite/ChangeLog:

PR target/119473
* gcc.target/i386/pr119473.c: New test.

Co-authored-by: Hongyu Wang 

[Bug target/119473] [15 Regression] __builtin_ia32_vaesdec_v32qi() emits wrong base register with -mvaes -O2 -mapxf -m64

[lin1.hu at intel dot com via Gcc-bugs]

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

Hu Lin  changed:

   What|Removed |Added

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

--- Comment #3 from Hu Lin  ---
Fix on trunk.

[Bug fortran/119540] [15 Regression] FAIL: gfortran.dg/reduce_1.f90 -O0 execution test

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

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Created attachment 60936
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60936&action=edit
Patch for reduce.c

This patch fixes the stride calculation for the result array of the reduce
intrinsic for numeric types, but fails on reduce_1.f90 for character tests
when compiling with -fcheck=bounds.

I might be missing to set some elem_len or span or ...

[Bug libgomp/119559] New: [15 regression] GOMP: ICE in modify_call_for_omp_dispatch

[ewlu at rivosinc dot com via Gcc-bugs]

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

Bug ID: 119559
   Summary: [15 regression] GOMP: ICE in
modify_call_for_omp_dispatch
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ewlu at rivosinc dot com
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 60937
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60937&action=edit
freport-bug output

Postcommit is finding the following errors:
FAIL: c-c++-common/gomp/append-args-1.c  (test for errors, line 82)
FAIL: c-c++-common/gomp/append-args-1.c  -std=c++17  (test for errors, line 82)
FAIL: c-c++-common/gomp/append-args-1.c  -std=c++17 (internal compiler error:
in modify_call_for_omp_dispatch, at gimplify.cc:3957)
FAIL: c-c++-common/gomp/append-args-1.c  -std=c++17 (test for excess errors)
FAIL: c-c++-common/gomp/append-args-1.c  -std=c++26  (test for errors, line 82)
FAIL: c-c++-common/gomp/append-args-1.c  -std=c++26 (internal compiler error:
in modify_call_for_omp_dispatch, at gimplify.cc:3957)
FAIL: c-c++-common/gomp/append-args-1.c  -std=c++26 (test for excess errors)
FAIL: c-c++-common/gomp/append-args-1.c  -std=c++98  (test for errors, line 82)
FAIL: c-c++-common/gomp/append-args-1.c  -std=c++98 (internal compiler error:
in modify_call_for_omp_dispatch, at gimplify.cc:3957)
FAIL: c-c++-common/gomp/append-args-1.c  -std=c++98 (test for excess errors)
FAIL: c-c++-common/gomp/append-args-1.c (internal compiler error: in
modify_call_for_omp_dispatch, at gimplify.cc:3957)
FAIL: c-c++-common/gomp/append-args-1.c (test for excess errors)

https://github.com/patrick-rivos/gcc-postcommit-ci/issues/2894

Likely caused by r15-9063-gf3899e0fd3f

Tested on r15-9108-gc5d96fd5279

Command/backtrace
$
/scratch/ewlu/ci/triage/baseline/build-gomp-ice/build-gcc-linux-stage2/gcc/xgcc
-B/scratch/ewlu/ci/triage/baseline/build-gomp-ice/build-gcc-linux-stage2/gcc/ 
/scratch/ewlu/ci/triage/baseline/gcc/gcc/testsuite/c-c++-common/gomp/append-args-1.c
 -march=rv64gcv -mabi=lp64d -mcmodel=medlow   -fdiagnostics-plain-output  
-fopenmp -S   -o append-args-1.s -freport-bug
/scratch/ewlu/ci/triage/baseline/gcc/gcc/testsuite/c-c++-common/gomp/append-args-1.c:16:7:
error: argument 1 of 'repl0' must be of 'omp_interop_t'
/scratch/ewlu/ci/triage/baseline/gcc/gcc/testsuite/c-c++-common/gomp/append-args-1.c:17:64:
note: 'append_args' specified here
/scratch/ewlu/ci/triage/baseline/gcc/gcc/testsuite/c-c++-common/gomp/append-args-1.c:41:93:
error: too many 'append_args' clauses
/scratch/ewlu/ci/triage/baseline/gcc/gcc/testsuite/c-c++-common/gomp/append-args-1.c:41:29:
error: variant 'repl4' and base 'base4' have incompatible types
/scratch/ewlu/ci/triage/baseline/gcc/gcc/testsuite/c-c++-common/gomp/append-args-1.c:48:7:
error: argument 4 of 'repl5' must be of 'omp_interop_t'
/scratch/ewlu/ci/triage/baseline/gcc/gcc/testsuite/c-c++-common/gomp/append-args-1.c:49:64:
note: 'append_args' specified here
/scratch/ewlu/ci/triage/baseline/gcc/gcc/testsuite/c-c++-common/gomp/append-args-1.c:57:29:
error: variant 'repl6' and base 'base6' have incompatible types
/scratch/ewlu/ci/triage/baseline/gcc/gcc/testsuite/c-c++-common/gomp/append-args-1.c:
In function 'test':
/scratch/ewlu/ci/triage/baseline/gcc/gcc/testsuite/c-c++-common/gomp/append-args-1.c:82:32:
error: number of list items in 'interop' clause (2) exceeds the number of
'append_args' items (1) for 'declare variant' candidate 'repl3'
/scratch/ewlu/ci/triage/baseline/gcc/gcc/testsuite/c-c++-common/gomp/append-args-1.c:35:21:
note: 'declare variant' candidate 'repl3' declared here
/scratch/ewlu/ci/triage/baseline/gcc/gcc/testsuite/c-c++-common/gomp/append-args-1.c:83:5:
internal compiler error: in modify_call_for_omp_dispatch, at gimplify.cc:3957
0x30eac66 internal_error(char const*, ...)
../../../gcc/gcc/diagnostic-global-context.cc:517
0xd050a5 fancy_abort(char const*, int, char const*)
../../../gcc/gcc/diagnostic.cc:1749
0xb34569 modify_call_for_omp_dispatch
../../../gcc/gcc/gimplify.cc:3957
0x113604b expand_variant_call_expr
../../../gcc/gcc/gimplify.cc:4401
0x113604b gimplify_variant_call_expr
../../../gcc/gcc/gimplify.cc:4503
0x113604b gimplify_call_expr
../../../gcc/gcc/gimplify.cc:4708
0x112116f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../../gcc/gcc/gimplify.cc:19440
0x112304a gimplify_stmt(tree_node**, gimple**)
../../../gcc/gcc/gimplify.cc:8437
0x114a241 gimplify_and_add(tree_node*, gimple**)
../../../gcc/gcc/gimplify.cc:547
0x114a241 gimplify_omp_dispatch
../../../gcc/gcc/gimplify.cc:18932
0x11220b5 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../../gcc/gcc/gimplify.cc:20143
0x112304a gimplify_stmt(tree_node**, gi

[Bug rtl-optimization/119554] [risc-v][bug] Unusual Behavior Observed with RISC-V Vector Extension (RVV)

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #2 from Jeffrey A. Law  ---
Yea, this was fixed during gcc-15 development.

[Bug libstdc++/110498] [12/13/14 Regression] Spurious warnings stringop-overflow and array-bounds copying data as bytes into vector::reserve

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

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to fail||13.3.0, 14.2.0
Summary|[12/13/14/15 Regression]|[12/13/14 Regression]
   |Spurious warnings   |Spurious warnings
   |stringop-overflow and   |stringop-overflow and
   |array-bounds copying data   |array-bounds copying data
   |as bytes into   |as bytes into
   |vector::reserve |vector::reserve
  Known to work||15.0

--- Comment #8 from Jonathan Wakely  ---
Fixed on trunk so far.

[Bug ipa/119318] [15 Regression] wrong code with vector arithmetics at -O2 since r15-6294-g96fb71883d438b

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #6 from Sam James  ---
Maybe add the PR119530 testcase as well? It is structurally similar, but it
lacks vectors so may be more useful food for the fuzzers.

[Bug tree-optimization/116835] [12/13/14/15 Regression] phiprop will prop back into a loop

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

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

--- Comment #10 from Andrew Pinski  ---
Created attachment 60940
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60940&action=edit
Testcase that fails even at -O2

Here is a testcase which fails even at -O2. The reason is aggregates copies are
harder to move.

[Bug fortran/119540] [15 Regression] FAIL: gfortran.dg/reduce_1.f90 -O0 execution test

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org,
   ||pault at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
The following testcase shows that the descriptor of the result array
is wrong:

program p
  implicit none
  integer, parameter :: mm(1,2,3) = 1
  print *, shape (reduce (mm, add, 1))
  print *, shape (reduce (mm, add, 2))
  print *, shape (reduce (mm, add, 3))
  print *, reduce (mm, add, 1)
  print *, reduce (mm, add, 2)
  print *, reduce (mm, add, 3)
contains
  pure function add(i,j) result(sum_ij)
integer, intent(in) :: i, j
integer :: sum_ij
sum_ij = i + j
  end function add
end

I get:

   1   2
   1   2
   1   2
   1   1
   2   2
   3   3

Expected (e.g. Intel):

   2   3
   1   3
   1   2
   1   1   1   1   1   1
   2   2   2
   3   3

The reason for the wrong extents in the descriptor is likely in the
runtime code.  My attempt to fix this was as follows:

diff --git a/libgfortran/intrinsics/reduce.c b/libgfortran/intrinsics/reduce.c
index c8950e41fd0..fec05d5df88 100644
--- a/libgfortran/intrinsics/reduce.c
+++ b/libgfortran/intrinsics/reduce.c
@@ -117,15 +117,20 @@ reduce (parray *ret,
   else if (i < dimen_m1)
ext0 *= ext;
   else if (i == dimen_m1)
-   ext1 = ext;
+   {
+ ext1 = ext;
+ continue;
+   }
   else
ext2 *= ext;

   /* The dimensions of the return array.  */
   if (i < (int)(dimen - 1))
GFC_DIMENSION_SET (ret->dim[i], 0, ext - 1, str);
-  else if (i < array_rank - 1)
-   GFC_DIMENSION_SET (ret->dim[i], 0, ext - 1, str);
+  /* else if (i < array_rank - 1) */
+  /*   GFC_DIMENSION_SET (ret->dim[i], 0, ext - 1, str); */
+  else
+   GFC_DIMENSION_SET (ret->dim[i-1], 0, ext - 1, str);
 }

   if (!scalar_result)

This now leads to:

   2   3
   1   3
   1   2
   1   1   1   1   1   1
   2   2   0
   3   3

This is only almost correct (see dim=2 case).

CC'ing Paul for help.

[Bug c/97831] Lack of disable_tail_calls attribute

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org

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

[Bug libstdc++/110498] [12/13/14/15 Regression] Spurious warnings stringop-overflow and array-bounds copying data as bytes into vector::reserve

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r15-9112-gaa3aaf2bfb8fcc17076993df4297597b68bc5f60
Author: Jonathan Wakely 
Date:   Fri Mar 28 15:41:41 2025 +

libstdc++: Fix -Warray-bounds warning in std::vector [PR110498]

In this case, we need to tell the compiler that the current size is not
larger than the new size so that all the existing elements can be copied
to the new storage. This avoids bogus warnings about overflowing the new
storage when the compiler can't tell that that cannot happen.

We might as well also hoist the loads of begin() and end() before the
allocation too. All callers will have loaded at least begin() before
calling _M_reallocate.

libstdc++-v3/ChangeLog:

PR libstdc++/110498
* include/bits/vector.tcc (vector::_M_reallocate):
Hoist loads of begin() and end() before allocation and use them
to state an unreachable condition.
* testsuite/23_containers/vector/bool/capacity/110498.cc: New
test.

Reviewed-by: Tomasz KamiÅski 

[Bug libstdc++/114758] [13/14/15 Regression] The layout of a std::vector reports a warning

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:1f6c19f307c8de9830130a0ba071c24e3835beb3

commit r15-9111-g1f6c19f307c8de9830130a0ba071c24e3835beb3
Author: Jonathan Wakely 
Date:   Fri Mar 28 15:41:41 2025 +

libstdc++: Fix -Wstringop-overread warning in std::vector [PR114758]

As in r13-4393-gcca06f0d6d76b0 and a few other commits, we can avoid
bogus warnings in std::vector by hoisting some loads to before the
allocation that calls operator new. This means that the compiler has
enough info to remove the dead branches that trigger bogus warnings.

On trunk this is only needed with -fno-assume-sane-operators-new-delete
but it will help on the branches where that option doesn't exist.

libstdc++-v3/ChangeLog:

PR libstdc++/114758
* include/bits/vector.tcc (vector::_M_fill_insert):
Hoist loads of begin() and end() before allocation.
* testsuite/23_containers/vector/bool/capacity/114758.cc: New
test.

Reviewed-by: Tomasz KamiÅski 

[Bug libstdc++/119550] [15 Regression] cross compilation of libstdc++ fail for arm-none-eabi due to tzname tests since g:778c28c70f85

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

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

--- Comment #14 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:97cbe3cd5f36470884e940bda4469dc9b5b93cfd

commit r15-9110-g97cbe3cd5f36470884e940bda4469dc9b5b93cfd
Author: Jonathan Wakely 
Date:   Mon Mar 31 15:07:12 2025 +0100

Libstdc++: Fix bootstrap failure for cross without tm.tm_zone [PR119550]

In r15-8491-g778c28c70f8573 I added a use of the Autoconf macro
AC_STRUCT_TIMEZONE, but that requires a link-test for the global tzname
object if tm.tm_zone isn't supported. That link-test isn't allowed for
cross-compilation, so bootstrap fails if tm.tm_zone isn't supported.

Since libstdc++ only cares about tm.tm_zone and won't use tzname anyway,
we don't need the link-test. Replace AC_STRUCT_TIMEZONE with a custom
macro that only checks for tm.tm_zone. We can improve on the Autoconf
macro by checking it's a suitable type, which isn't actually checked by
AC_STRUCT_TIMEZONE.

libstdc++-v3/ChangeLog:

PR libstdc++/119550
* acinclude.m4 (GLIBCXX_STRUCT_TM_TM_ZONE): New macro.
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Use GLIBCXX_STRUCT_TM_TM_ZONE.
* include/bits/chrono_io.h (__formatter_chrono::_M_c): Check
_GLIBCXX_USE_STRUCT_TM_TM_ZONE instead of
_GLIBCXX_HAVE_STRUCT_TM_TM_ZONE.

[Bug middle-end/119559] [15 regression] GOMP: ICE in modify_call_for_omp_dispatch

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

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2025-03-31
   Assignee|unassigned at gcc dot gnu.org  |burnus at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Tobias Burnus  ---
Created attachment 60938
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60938&action=edit
Draft patch: OpenMP: Reorder diagnostic in modify_call_for_omp_dispatch
[PR119559]

Lightly tested.

[Bug tree-optimization/116835] [12/13/14/15 Regression] phiprop will prop back into a loop

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

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

--- Comment #11 from Andrew Pinski  ---
Created attachment 60942
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60942&action=edit
Finally figured out how best to handle this

patch which I am testing.

[Bug target/119533] RISC-V: libgo build failures (ICE) with Vector enabled

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Eric Botcazou from comment #7)
> > Does go use sjlj EH "manually"?  EH shouldn't result in EDGE_ABNORMAL ...
> 
> /* Strange flow, like a computed jump or exception handling.  Usually
>this means that the edge cannot be split.  */
> DEF_EDGE_FLAG(ABNORMAL, 1)
> 
> rtl_make_eh_edge does set it for EH.

And even more, see EDGE_EH:
```
/* Exception edge.  Exception handling edges represent possible control
   transfers from a trapping instruction to an exception handler.
   EH edges also have ABNORMAL set for the RTL CFG.  */
DEF_EDGE_FLAG(EH, 3)

```
Specifically: "EH edges also have ABNORMAL set for the RTL CFG" :).

[Bug ipa/119318] [15 Regression] wrong code with vector arithmetics at -O2 since r15-6294-g96fb71883d438b

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

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

--- Comment #5 from Martin Jambor  ---
Created attachment 60939
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60939&action=edit
Simple fix

This patch is a simple fix.  I'll submit one streaming the necessary type to
the mailing list though in order not to need to fiddle with
expr_type_first_operand_type_p.

[Bug libstdc++/119550] [15 Regression] cross compilation of libstdc++ fail for arm-none-eabi due to tzname tests since g:778c28c70f85

[Alexandre.BUSTICO at enac dot fr via Gcc-bugs]

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

--- Comment #16 from Alexandre Bustico  ---
Tested, works perfectly, thanks for the outstanding reactivity.

[Bug ipa/119558] [meta-bug] Improve Link Time Optimization on Windows

[peter0x44 at disroot dot org via Gcc-bugs]

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

--- Comment #3 from Peter Damianov  ---
the -fdeclone-ctor-dtor ICE is PR108383
I put a reduced testcase there but unfortunately no one confirmed it

[Bug middle-end/119482] slow compilation on ladybird interpreter

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

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

--- Comment #6 from Andrew Pinski  ---
With flatten enabled at -O2 I get an ICE:
during IPA pass: inline
Interpreter.cpp:3841:1: internal compiler error: in redirect_callee, at
cgraph.cc:1391
0x293749f internal_error(char const*, ...)
   
/home/apinski/src/upstream-gcc-match/gcc/gcc/diagnostic-global-context.cc:517
0xab270f fancy_abort(char const*, int, char const*)
/home/apinski/src/upstream-gcc-match/gcc/gcc/diagnostic.cc:1749
0x8b200f cgraph_edge::redirect_callee(cgraph_node*)
/home/apinski/src/upstream-gcc-match/gcc/gcc/cgraph.cc:1391
0x116c808 redirect_to_unreachable
/home/apinski/src/upstream-gcc-match/gcc/gcc/ipa-fnsummary.cc:266
0x116c808 edge_set_predicate
/home/apinski/src/upstream-gcc-match/gcc/gcc/ipa-fnsummary.cc:290
0x116cc3f remap_edge_summaries
/home/apinski/src/upstream-gcc-match/gcc/gcc/ipa-fnsummary.cc:4355
0x116ff50 ipa_merge_fn_summary_after_inlining(cgraph_edge*)
/home/apinski/src/upstream-gcc-match/gcc/gcc/ipa-fnsummary.cc:4519
0x1187605 inline_call(cgraph_edge*, bool, vec*,
int*, bool, bool*)
   
/home/apinski/src/upstream-gcc-match/gcc/gcc/ipa-inline-transform.cc:522
0x278d2b3 flatten_function
/home/apinski/src/upstream-gcc-match/gcc/gcc/ipa-inline.cc:2557
0x279075a ipa_inline
/home/apinski/src/upstream-gcc-match/gcc/gcc/ipa-inline.cc:2880



Note without flatten, the total time at -O2 was 18s (with -fno-checking) and
40s (with checking).  So if anything I think the timing reported here is due to
that.

[Bug middle-end/119482] slow compilation on ladybird interpreter

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #6)
> With flatten enabled at -O2 I get an ICE:
> during IPA pass: inline
> Interpreter.cpp:3841:1: internal compiler error: in redirect_callee, at
> cgraph.cc:1391
> 0x293749f internal_error(char const*, ...)
>
> /home/apinski/src/upstream-gcc-match/gcc/gcc/diagnostic-global-context.cc:517
> 0xab270f fancy_abort(char const*, int, char const*)
> /home/apinski/src/upstream-gcc-match/gcc/gcc/diagnostic.cc:1749
> 0x8b200f cgraph_edge::redirect_callee(cgraph_node*)
> /home/apinski/src/upstream-gcc-match/gcc/gcc/cgraph.cc:1391
> 0x116c808 redirect_to_unreachable
> /home/apinski/src/upstream-gcc-match/gcc/gcc/ipa-fnsummary.cc:266
> 0x116c808 edge_set_predicate
> /home/apinski/src/upstream-gcc-match/gcc/gcc/ipa-fnsummary.cc:290
> 0x116cc3f remap_edge_summaries
> /home/apinski/src/upstream-gcc-match/gcc/gcc/ipa-fnsummary.cc:4355
> 0x116ff50 ipa_merge_fn_summary_after_inlining(cgraph_edge*)
> /home/apinski/src/upstream-gcc-match/gcc/gcc/ipa-fnsummary.cc:4519
> 0x1187605 inline_call(cgraph_edge*, bool, vec vl_ptr>*, int*, bool, bool*)
>
> /home/apinski/src/upstream-gcc-match/gcc/gcc/ipa-inline-transform.cc:522
> 0x278d2b3 flatten_function
> /home/apinski/src/upstream-gcc-match/gcc/gcc/ipa-inline.cc:2557
> 0x279075a ipa_inline
> /home/apinski/src/upstream-gcc-match/gcc/gcc/ipa-inline.cc:2880
> 

Which is PR 103819.

[Bug c/117689] enum with underying type "extension" to GNU 17 is not documented

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |sandra at gcc dot 
gnu.org
 CC||sandra at gcc dot gnu.org

--- Comment #1 from sandra at gcc dot gnu.org ---
I'm looking at this.

It appears that the existing text in "Incomplete enums" is wrong about e.g.

enum e;

producing an incomplete type, as gcc is allowing me to declare e.g.

static enum e thing;

at file scope without complaint as long as there is a subsequent full
declaration of the enum in the compilation unit, after the point of use.  It
seems to be defaulting to using int as the underlying type, or char if I use
-fshort-enums, but I'm having trouble finding the place where that happens.  Is
that a bug in the docs or a bug in the implementation that it isn't rejecting
that?  It does complain about the use if there is no redeclaration of the enum.

Of course there is no problem if the underlying type is specified explicitly. 
That is the C++11 requirement too.  The C++ spec refers to the resulting type
as "opaque" rather than "incomplete" for this reason.

Anyway, my plan is to merge the information about specifying the underlying
type into the existing section about forward declarations since they are
closely related in terms of what you can and can't do.

[Bug tree-optimization/119534] [12/13/14/15 regression] ICE when building libaom-3.10.0 since r12-5392

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

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

--- Comment #7 from Jakub Jelinek  ---
r12-2836-g08aa0e3d4f781fd6a6e293bb06d280365a0bdc1d

[Bug tree-optimization/119534] [12/13/14/15 regression] ICE when building libaom-3.10.0 since r12-5392

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

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

--- Comment #8 from Jakub Jelinek  ---
  vector(8)  mask__2.12;
   _72;
   _78;

_72 = BIT_FIELD_REF ;
pr119534.c:1:6: error: integral result type precision does not match field size
of ‘bit_field_ref’
_78 = BIT_FIELD_REF ;

[Bug c++/119551] [modules] ICE when reading inline var referencing TU-local entity

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

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

--- Comment #3 from Jason Merrill  ---
It occurs to me that if an inline variable in an MIU has non-trivial [cd]tion,
we have to emit it (and [cd]truct it) in the MIU already, so we could take
option #1 for that case even without ABI blessing.

[Bug tree-optimization/119534] [12/13/14/15 regression] ICE when building libaom-3.10.0 since r12-5392

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Jakub Jelinek from comment #4)
> > Started with r12-5392-g527e54a431473cc497204226a21f2831d2375e66

> Can someone redo the bisect with the addition option of -fdbg-cnt=match:0 ?
> With that option we get the same IR coming into the vectorizer for GCC 11.x
> and GCC 12.x and GCC 11.x still works.
I should say GCC 12.x still ICEs too with that option. Basically we disable the
match pattern which was is now disable until later on due to that patch.

[Bug tree-optimization/119534] [12/13/14/15 regression] ICE when building libaom-3.10.0 since r12-5392

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #4)
> Started with r12-5392-g527e54a431473cc497204226a21f2831d2375e66

This just changed the IR coming into the vectorizer.

Before we had:
```
  _7 = _1 <= j_21 ? 8 : 0;
  _8 = d_17(D) + _7;
```

After we have:
```
  _2 = _1 <= j_23;
...
  i.1_8 = (unsigned int) _2;
  _9 = i.1_8 * 8;
```

Can someone redo the bisect with the addition option of -fdbg-cnt=match:0 ?
With that option we get the same IR coming into the vectorizer for GCC 11.x and
GCC 12.x and GCC 11.x still works.

[Bug c++/119562] New: ICE on trunk when trying to token-paste a raw string

[rl.alt.accnt at gmail dot com via Gcc-bugs]

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

Bug ID: 119562
   Summary: ICE on trunk when trying to token-paste a raw string
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rl.alt.accnt at gmail dot com
  Target Milestone: ---

This code currently crashes GCC trunk (https://godbolt.org/z/eT3Mn9PxM):

#define X R##"x()"
X

Crash:
:2:1: error: unterminated raw string
2 | X
  | ^
:2:1: internal compiler error: Segmentation fault
0x29226a5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2939676 internal_error(char const*, ...)
???:0
0xe56bdc preprocess_file(cpp_reader*)
???:0
0xe54a05 c_common_init()
???:0
0xc0e35e cxx_init()
???:0

[Bug preprocessor/119562] ICE when trying to token-paste an unterminated raw string

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-04-01
  Known to fail||4.5.3

--- Comment #2 from Andrew Pinski  ---
Confirmed. Looks not to be a regression has been ICEing since Raw string
support was added in GCC 4.5.0.

[Bug preprocessor/119562] ICE on trunk when trying to token-paste an unterminated raw string

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

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

--- Comment #1 from Andrew Pinski  ---
[apinski@xeond2 gcc]$ ./cc1 t.c
t.c:2:1: error: unterminated raw string
2 | X
  | ^
t.c:2:1: internal compiler error: Segmentation fault
0x2610edf internal_error(char const*, ...)
   
/home/apinski/src/upstream-gcc-match/gcc/gcc/diagnostic-global-context.cc:517
0x112912f crash_signal
/home/apinski/src/upstream-gcc-match/gcc/gcc/toplev.cc:322
0x26a1b2d paste_tokens
/home/apinski/src/upstream-gcc-match/gcc/libcpp/macro.cc:1051
0x26a4d74 paste_all_tokens
/home/apinski/src/upstream-gcc-match/gcc/libcpp/macro.cc:1150
0x26a4d74 cpp_get_token_1
/home/apinski/src/upstream-gcc-match/gcc/libcpp/macro.cc:3028
0xaf5bfa get_token
/home/apinski/src/upstream-gcc-match/gcc/gcc/c-family/c-lex.cc:311
0xaf5bfa c_lex_with_flags(tree_node**, unsigned long*, unsigned char*, int)
/home/apinski/src/upstream-gcc-match/gcc/gcc/c-family/c-lex.cc:574
0xa3e7f9 c_lex_one_token
/home/apinski/src/upstream-gcc-match/gcc/gcc/c/c-parser.cc:329
0xa8ad20 c_parser_peek_token(c_parser*)
/home/apinski/src/upstream-gcc-match/gcc/gcc/c/c-parser.cc:533
0xa8ad20 c_parse_file()
/home/apinski/src/upstream-gcc-match/gcc/gcc/c/c-parser.cc:29794
0xb0b641 c_common_parse_file()
/home/apinski/src/upstream-gcc-match/gcc/gcc/c-family/c-opts.cc:1379
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug ipa/119318] [15 Regression] wrong code with vector arithmetics at -O2 since r15-6294-g96fb71883d438b

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

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

Martin Jambor  changed:

   What|Removed |Added

 CC||zhendong.su at inf dot ethz.ch

--- Comment #4 from Martin Jambor  ---
*** Bug 119530 has been marked as a duplicate of this bug. ***

[Bug middle-end/119522] Notail attribute like musttail attribute

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Richard Biener from comment #2)
> IMO having the behavior on abort() be explicit as noreturn,notail would be
> nice. Placing instructions after a noreturn call is difficult.

Then this is a dup of bug 97831 . So closing as such.

Note clang has not_tail_called, I think we should follow clang's naming here.
There are open questions about LTO.

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

[Bug lto/119557] New: malloc attribute on function decls and merging interaction with LTO

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

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

Bug ID: 119557
   Summary: malloc attribute on function decls and merging
interaction with LTO
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: documentation, lto
  Severity: enhancement
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

I am not 100% sure this is just a documentation issue or there needs some
changes to be done with respect to maybe adding noinline when malloc attribute
different between 2 TUs.

An exmple is PR 117315. Even though the malloc attribute is included on the TU
that has the malloc attribute on it but even if we remove it from the TU which
has the definition of the function that might become well defined?

This came up when I was thinking about clang's not_tail_called attribute and
how to handle merging the decl for LTO.

[Bug libstdc++/119550] [15 Regression] cross compilation of libstdc++ fail for arm-none-eabi due to tzname tests since g:778c28c70f85

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #15 from Jonathan Wakely  ---
It should be fixed now, please reopen if not. Thanks for the report.

[Bug c++/119150] [14 Regression] Optimization causes function call arguments to consteval functions to not be manifestly constant-evaluated since r14-4140

[aapomeranz at yahoo dot com via Gcc-bugs]

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

--- Comment #10 from Alex Pomeranz  ---
Now that's service! :)  Thanks Jakub and everyone else who contributed.

[Bug libgdiagnostics/117879] libgdiagnostics and libgccjit installed into */lib directory rather than */lib64 on multilib non-multiarch hosts

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

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

Sam James  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=101491
   Keywords||build
 CC||sjames at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2025-04-01
 Status|UNCONFIRMED |NEW

[Bug rust/117869] rust fails to build with cargo command error

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

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

--- Comment #3 from Sam James  ---
Since r15-9083-gd560f3f9594339, 1.49 should work again, but it needs
documenting still.

[Bug bootstrap/119560] cc1 posix_spawnp compilation error with gcc 14.2.0 on Ubuntu 24.04

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|driver  |bootstrap

--- Comment #1 from Andrew Pinski  ---
Do you have the full build log?

[Bug bootstrap/119560] cc1 posix_spawnp compilation error with gcc 14.2.0 on Ubuntu 24.04

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

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

--- Comment #2 from Andrew Pinski  ---
Also can you go into /home/ssmedley/gcc/build-14.2.0/./gcc and invoke:
/home/ssmedley/gcc/build-14.2.0/./gcc/xgcc
-B/home/ssmedley/gcc/build-14.2.0/./gcc/ -fno-checking -xc -nostdinc /dev/null
-S -o /dev/null -fself-test=../../gcc-14.2.0/gcc/testsuite/selftests -v

And provide the full output of that?

Also is there a `/home/ssmedley/gcc/build-14.2.0/./gcc/cc1` ?

[Bug target/119547] RISC-V: VSETVL mistakenly modified other data

[pan2.li at intel dot com via Gcc-bugs]

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

Li Pan  changed:

   What|Removed |Added

 CC||jeffreyalaw at gmail dot com,
   ||juzhe.zhong at rivai dot ai,
   ||kito.cheng at gmail dot com,
   ||pan2.li at intel dot com,
   ||rdapp at gcc dot gnu.org

--- Comment #2 from Li Pan  ---
Any information about gcc version? Seems asm layout is different from today's
upstream. CC RISC-V relatives.

 123   │ .L41:
 124   │ addiw   t2,t2,1
 125   │ vsetvli a3,zero,e8,mf2,ta,ma
 126   │ bne s0,t2,.L44
 127   │ .L33:
 128   │ ld  s1,64(sp)
 129   │ .cfi_restore 9
 130   │ ld  s2,56(sp)
 131   │ .cfi_restore 18
 132   │ ld  s3,48(sp)
 133   │ .cfi_restore 19
 134   │ ld  s4,40(sp)
 135   │ .cfi_restore 20
 136   │ ld  s5,32(sp)
 137   │ .cfi_restore 21
 138   │ ld  s6,24(sp)
 139   │ .cfi_restore 22
 140   │ .L31:
 141   │ ld  s0,72(sp)
 142   │ .cfi_restore 8
 143   │ addisp,sp,80
 144   │ .cfi_def_cfa_offset 0
 145   │ jr  ra
 146   │ .L43:
 147   │ .cfi_def_cfa_offset 80
 148   │ .cfi_offset 8, -8
 149   │ .cfi_offset 9, -16
 150   │ .cfi_offset 18, -24
 151   │ .cfi_offset 19, -32
 152   │ .cfi_offset 20, -40
 153   │ .cfi_offset 21, -48
 154   │ .cfi_offset 22, -56
 155   │ sllis4,a4,3
 156   │ add a5,a0,a4
 157   │ .L11:
 158   │ sllia7,s5,32
 159   │ srlia7,a7,32
 160   │ add a4,a2,s4
 161   │ add a7,a7,a5
 162   │ .L15:
 163   │ lb  t1,0(a5)
 164   │ addia5,a5,1
 165   │ addia4,a4,8
 166   │ fcvt.d.wfa5,t1
 167   │ fmadd.d fa5,fa5,fa0,fa1
 168   │ fsd fa5,-8(a4)
 169   │ bne a5,a7,.L15
 170   │ j   .L34

[Bug fortran/119540] [15 Regression] FAIL: gfortran.dg/reduce_1.f90 -O0 execution test

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

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #3)
> I might be missing to set some elem_len or span or ...

Testcase:

module operations
  implicit none
contains
  pure function c_op (i, j) result (ij)
character(8), intent(in) :: i, j
character(8) :: ij
integer :: n
ij = i
do n = 1, 8
   if (i(n:n) .ne. j(n:n)) ij(n:n) = '!'
end do
  end function c_op
end module operations

program test_reduce
   use operations
   implicit none
   character(*), parameter :: carray (4) = ['abctefgh', 'atcdefgh', &
'abcdefth', 'abcdtfgh']
   print *, reduce (carray, c_op)
end


The dump-tree has:

  _gfortran_reduce_scalar_c ((character(kind=1)[1:8] *) &str.3, 8, &parm.2,
__reduce_wrapper_c_op_test_reduce, 0B, 0B, 0B, 0B, 8);


but the prototype in reduce.c:

extern void reduce_scalar_c (void *, index_type, parray *,
  void (*operation) (void *, void *, void *),
  GFC_INTEGER_4 *, gfc_array_l4 *, void *, void *,
  index_type, index_type);

The last two arguments are string lengths, but only one is provided...

[Bug middle-end/119559] [15 regression] GOMP: ICE in modify_call_for_omp_dispatch

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug c/119526] standard attributes should be preserved in redeclarations

[foom at fuhm dot net via Gcc-bugs]

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

James Y Knight  changed:

   What|Removed |Added

 CC||foom at fuhm dot net

--- Comment #2 from James Y Knight  ---
Presumably also in this example, "i" should remain deprecated:

struct S {
  char c;
  [[deprecated]] int i;
};

struct S {
  char c;
  int i;
};

[Bug ipa/119558] [meta-bug] Improve Link Time Optimization on Windows

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

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

Eric Botcazou  changed:

   What|Removed |Added

   Last reconfirmed||2025-03-31
 CC||ebotcazou at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #4 from Eric Botcazou  ---
> Is this about windows as a host or windows as a target. Because I think e.g.
> LTO plugin does not work with windows as a host but might work with windows
> as a targert with Linux as the host.

It works in both cases.

[Bug target/119533] RISC-V: libgo build failures (ICE) with Vector enabled

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

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

Eric Botcazou  changed:

   What|Removed |Added

   Last reconfirmed||2025-03-31
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||ebotcazou at gcc dot gnu.org

--- Comment #7 from Eric Botcazou  ---
> Does go use sjlj EH "manually"?  EH shouldn't result in EDGE_ABNORMAL ...

/* Strange flow, like a computed jump or exception handling.  Usually
   this means that the edge cannot be split.  */
DEF_EDGE_FLAG(ABNORMAL, 1)

rtl_make_eh_edge does set it for EH.

[Bug libstdc++/114758] [13/14 Regression] The layout of a std::vector reports a warning

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

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to fail||13.3.0, 14.2.0
Summary|[13/14/15 Regression] The   |[13/14 Regression] The
   |layout of a |layout of a
   |std::vector reports a |std::vector reports a
   |warning |warning
  Known to work||15.0

--- Comment #8 from Jonathan Wakely  ---
Fixed on trunk so far.

[Bug cobol/119524] cobol: gg_printf assumes target characteristics

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

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

--- Comment #1 from Richard Biener  ---
Move it to the runtime is the only viable solution here.

[Bug middle-end/119522] Notail attribute like musttail attribute

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

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

--- Comment #2 from Richard Biener  ---
IMO having the behavior on abort() be explicit as noreturn,notail would be
nice. Placing instructions after a noreturn call is difficult.

[Bug target/119547] New: RISC-V: VSETVL mistakenly modified other data

[zhijin.zeng at spacemit dot com via Gcc-bugs]

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

Bug ID: 119547
   Summary: RISC-V: VSETVL mistakenly modified other data
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhijin.zeng at spacemit dot com
  Target Milestone: ---

This code extract from opencv/modules/core/src/convert_scale.simd.hpp.

-march=rv64gcv -mabi=lp64d --param logical-op-non-short-circuit=1


```
#include 

using v_uint8 = vuint8m2_t;
using v_int8 = vint8m2_t;
using v_uint16 = vuint16m2_t;
using v_int16 = vint16m2_t;
using v_uint32 = vuint32m2_t;
using v_int32 = vint32m2_t;
using v_uint64 = vuint64m2_t;
using v_int64 = vint64m2_t;
using v_float32 = vfloat32m2_t;
using v_float64 = vfloat64m2_t;

using uchar = unsigned char;
using schar = signed char;
using ushort = unsigned short;
using uint = unsigned int;
using uint64 = unsigned long int;
using int64 = long int;

struct Size {
  int width;
  int height;
};

template 
struct VTraits;

template <> struct VTraits { static inline int vlanes() { return
__riscv_vsetvlmax_e32m1(); } using lane_type = int32_t; static const int
max_nlanes = 1024/32*2; };
template <> struct VTraits { static inline int vlanes() { return
__riscv_vsetvlmax_e32m2(); } using lane_type = int32_t; static const int
max_nlanes = 1024/32*2; };
template <> struct VTraits { static inline int vlanes() { return
__riscv_vsetvlmax_e32m4(); } using lane_type = int32_t; static const int
max_nlanes = 1024/32*2; };
template <> struct VTraits { static inline int vlanes() { return
__riscv_vsetvlmax_e32m8(); } using lane_type = int32_t; static const int
max_nlanes = 1024/32*2; };

template <> struct VTraits { static inline int vlanes() { return
__riscv_vsetvlmax_e64m1(); } using lane_type = double; static const int
max_nlanes = 1024/64*2; };
template <> struct VTraits { static inline int vlanes() { return
__riscv_vsetvlmax_e64m2(); } using lane_type = double; static const int
max_nlanes = 1024/64*2; };
template <> struct VTraits { static inline int vlanes() { return
__riscv_vsetvlmax_e64m4(); } using lane_type = double; static const int
max_nlanes = 1024/64*2; };
template <> struct VTraits { static inline int vlanes() { return
__riscv_vsetvlmax_e64m8(); } using lane_type = double; static const int
max_nlanes = 1024/64*2; };

static inline v_float64 v_setall_f64(double v) { return
__riscv_vfmv_v_f_f64m2(v, VTraits::vlanes()); }
static inline v_float64 vx_setall_f64(double v) { return v_setall_f64(v); }

inline v_int32 v_load_expand_q(const schar* ptr)
{
return __riscv_vwcvt_x(__riscv_vwcvt_x(__riscv_vle8_v_i8mf2(ptr,
VTraits::vlanes()), VTraits::vlanes()),
VTraits::vlanes());
}

static inline v_int32 vx_load_expand_q(const schar * ptr) { return
v_load_expand_q(ptr); }

inline v_float64 v_cvt_f64(const v_int32& a)
{
return __riscv_vget_f64m2(__riscv_vfwcvt_f(a, VTraits::vlanes()),
0);
}

inline v_float64 v_cvt_f64_high(const v_int32& a)
{
return __riscv_vget_f64m2(__riscv_vfwcvt_f(a, VTraits::vlanes()),
1);
}

inline void v_store(double* ptr, const v_float64& a) { __riscv_vse64(ptr, a,
VTraits::vlanes()); }

static inline void v_store_pair_as(double* ptr, const v_float64& a, const
v_float64& b)
{
v_store(ptr, a);
v_store(ptr + VTraits::vlanes(), b);
}

static inline void vx_load_pair_as(const schar* ptr, v_float64& a, v_float64&
b)
{
v_int32 v0 = vx_load_expand_q(ptr);
a = v_cvt_f64(v0);
b = v_cvt_f64_high(v0);
}

inline v_float64 v_fma(const v_float64& a, const v_float64& b, const v_float64&
c)
{
return __riscv_vfmacc_vv_f64m2(c, a, b, VTraits::vlanes());
}

template static inline _Tp saturate_cast(double v) { return
_Tp(v); }

template __attribute__((noinline)) void
cvt_64f( const _Ts* src, size_t sstep, _Td* dst, size_t dstep,
 Size size, double a, double b )
{

v_float64 va = vx_setall_f64(a), vb = vx_setall_f64(b);
const int VECSZ = VTraits::vlanes()*2;

sstep /= sizeof(src[0]);
dstep /= sizeof(dst[0]);

for( int i = 0; i < size.height; i++, src += sstep, dst += dstep )
{
int j = 0;


for( ; j < size.width; j += VECSZ )
{
if( j > size.width - VECSZ )
{
if( j == 0 || src == (_Ts*)dst )
break;
j = size.width - VECSZ;
}
v_float64 v0, v1;
vx_load_pair_as(src + j, v0, v1);
v0 = v_fma(v0, va, vb);
v1 = v_fma(v1, va, vb);
v_store_pair_as(dst + j, v0, v1);
}

for( ; j < size.width; j++ )
dst[j] = saturate_cast<_Td>(src[j]*a + b);
}
}

void cvtScale8s64f( const uchar* src_, size_t sstep, const uchar*, size_t,
uchar* dst_, size_t dstep, Size size, void* scale_) { const schar* src = (const
schar*)src_; double* dst = (double*)dst_; double* scale = (double*)scale_;
cvt_64f(sr

[Bug tree-optimization/119532] [avr] ICE: in build_minus_one_cst with _Accum/_Fract types , at tree.cc:2698

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

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

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

https://gcc.gnu.org/g:95c25cb09f58810bc520c3db469945c6a751aa32

commit r15-9065-g95c25cb09f58810bc520c3db469945c6a751aa32
Author: Richard Biener 
Date:   Mon Mar 31 10:02:27 2025 +0200

tree-optimization/119532 - ICE with fixed-point tail recursion

The following disables tail recursion optimization when fixed-point
types are involved as we cannot generate -1 for all fixed-point
types.

PR tree-optimization/119532
* tree-tailcall.cc (process_assignment): FAIL for fixed-point
typed functions.

* gcc.dg/torture/pr119532.c: New testcase.

[Bug target/119474] GCN 'libgomp.oacc-c++/pr96835-1.C' ICE 'during GIMPLE pass: ivopts'

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

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

--- Comment #9 from Andrew Stubbs  ---
This patch fixes the -O1 failure, for *this* testcase:

diff --git a/gcc/tree.cc b/gcc/tree.cc
index eccfcc89da40..4bfdb7a938e7 100644
--- a/gcc/tree.cc
+++ b/gcc/tree.cc
@@ -7085,11 +7085,8 @@ build_pointer_type_for_mode (tree to_type, machine_mode
mode,
   if (to_type == error_mark_node)
 return error_mark_node;

-  if (mode == VOIDmode)
-{
-  addr_space_t as = TYPE_ADDR_SPACE (to_type);
-  mode = targetm.addr_space.pointer_mode (as);
-}
+  addr_space_t as = TYPE_ADDR_SPACE (to_type);
+  mode = targetm.addr_space.pointer_mode (as);

   /* If the pointed-to type has the may_alias attribute set, force
  a TYPE_REF_CAN_ALIAS_ALL pointer to be generated.  */
@@ -7121,6 +7118,7 @@ build_pointer_type_for_mode (tree to_type, machine_mode
mode,
   TYPE_REF_CAN_ALIAS_ALL (t) = can_alias_all;
   TYPE_NEXT_PTR_TO (t) = TYPE_POINTER_TO (to_type);
   TYPE_POINTER_TO (to_type) = t;
+  TYPE_ADDR_SPACE (t) = TYPE_ADDR_SPACE (to_type);

   /* During LTO we do not set TYPE_CANONICAL of pointers and references.  */
   if (TYPE_STRUCTURAL_EQUALITY_P (to_type) || in_lto_p)


This is clearly wrong though, because the address space that the pointer is
*in* doesn't have to be the same as the one it *points to*, so I need a better
solution.

Any suggestions where to start?

[Bug tree-optimization/119532] [avr] ICE: in build_minus_one_cst with _Accum/_Fract types , at tree.cc:2698

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Fixed for GCC 15.

[Bug tree-optimization/119532] [avr] ICE: in build_minus_one_cst with _Accum/_Fract types , at tree.cc:2698

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

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

--- Comment #5 from Georg-Johann Lay  ---
It also occurs for current v13 and v14 at least.

[Bug c++/119401] [15 regression] ICE when lambda is used as template argument in member function parameter type since r15-7202

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

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

--- Comment #7 from GCC Commits  ---
The trunk branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:1949beb7dbe66687542f4a19d316914dd73fe84d

commit r15-9066-g1949beb7dbe66687542f4a19d316914dd73fe84d
Author: Jason Merrill 
Date:   Sat Mar 29 14:00:55 2025 -0400

c++: lambda in function template signature [PR119401]

Here we instantiate the lambda three times in producing A<0>::f:
1) in tsubst_function_type, substituting the type of A<>::f
2) in tsubst_function_decl, substituting the parameters of A<>::f
3) in regenerate_decl_from_template when instantiating A<>::f

The first one gets thrown away by maybe_rebuild_function_decl_type.  Before
r15-7202, we happily built all of them and mangled the result wrongly as
lambda #3.  After r15-7202, we try to mangle #3 as #1, which breaks because
 #1 is already mangled as #1.

This patch avoids building #3 by suppressing regenerate_decl_from_template
if the template signature includes a lambda, fixing the ICE.

We now mangle the lambda as #2, which is still wrong.  Addressing that
should involve not calling tsubst_function_type from tsubst_function_decl,
and building the type from the parms types in the first place rather than
fixing it up in maybe_rebuild_function_decl_type.

PR c++/119401

gcc/cp/ChangeLog:

* pt.cc (regenerate_decl_from_template): Don't regenerate if the
signature involves a lambda.

gcc/testsuite/ChangeLog:

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

[Bug libstdc++/118158] std::filesystem::equivalent unsupported on socket files

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

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

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

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

commit r13-9465-ge346a33381df08988f2b1c1f09f1ba573bb1f80b
Author: Jonathan Wakely 
Date:   Mon Dec 30 13:08:41 2024 +

libstdc++: Implement LWG 2937 for std::filesystem::equivalent [PR118158]

Do not report an error for (is_other(s1) && is_other(s2)) as the
standard originally said, nor for (is_other(s1) || is_other(s2)) as
libstdc++ was doing. We can compare inode numbers for special files and
so give sensible answers.

libstdc++-v3/ChangeLog:

PR libstdc++/118158
* src/c++17/fs_ops.cc (fs::equivalent): Remove error reporting
for is_other(s1) && is_other(s2) case, as per LWG 2937.
* testsuite/27_io/filesystem/operations/pr118158.cc: New test.

(cherry picked from commit 301a961ffd0567eece55ece42e80a7ba9e855ba0)

[Bug libstdc++/101527] The implementation of std::common_iterator and std::counted_iterator's operator== seems to be wrong

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

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

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

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

commit r13-9464-gb19afd649fcc0b747c4834d43d969f4233aeaee2
Author: Jonathan Wakely 
Date:   Mon Mar 24 21:36:16 2025 +

libstdc++: Add testcases for resolved bug [PR101527]

These tests were fixed by a front-end change r13-465-g4df735e01e3199 so
this just adds them to the testsuite to be sure we don't regress.

libstdc++-v3/ChangeLog:

PR libstdc++/101527
* testsuite/24_iterators/common_iterator/101527.cc: New test.
* testsuite/24_iterators/counted_iterator/101527.cc: New test.

(cherry picked from commit f7c0b0fc4fdeaf034dc38356830625f7280d325d)

[Bug c++/117966] [12/13/14/15 regression] constexpr std::span construction fails to compile with D_GLIBCXX_DEBUG

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

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

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

https://gcc.gnu.org/g:031cb46341690a66f5b31486942f69105db15297

commit r13-9470-g031cb46341690a66f5b31486942f69105db15297
Author: Jonathan Wakely 
Date:   Tue Dec 10 10:56:41 2024 +

libstdc++: Disable __gnu_debug::__is_singular(T*) in constexpr [PR109517]

Because of PR c++/85944 we have several bugs where _GLIBCXX_DEBUG causes
errors for constexpr code. Although Bug 117966 could be fixed by
avoiding redundant debug checks in std::span, and Bug 106212 could be
fixed by avoiding redundant debug checks in std::array, there are many
more cases where similar __glibcxx_requires_valid_range checks fail to
compile and removing the checks everywhere isn't desirable.

This just disables the __gnu_debug::__check_singular(T*) check during
constant evaluation. Attempting to dereference a null pointer will
certainly fail during constant evaluation (if it doesn't fail then it's
a compiler bug and not the library's problem). Disabling this check
during constant evaluation shouldn't do any harm.

libstdc++-v3/ChangeLog:

PR libstdc++/109517
PR libstdc++/109976
* include/debug/helper_functions.h (__valid_range_aux): Treat
all input iterator ranges as valid during constant evaluation.

(cherry picked from commit 9616deb23a17ebe81ad89ede191d7f9f752abdec)

[Bug libstdc++/118035] [12/13 Regression] deque bug when inserting an empty iterator interval

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

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

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

https://gcc.gnu.org/g:4655e9c9eef67fde3e7e0b95a218a13ff5b33c1d

commit r13-9466-g4655e9c9eef67fde3e7e0b95a218a13ff5b33c1d
Author: Jonathan Wakely 
Date:   Mon Dec 16 17:42:24 2024 +

libstdc++: Fix std::deque::insert(pos, first, last) undefined behaviour
[PR118035]

Inserting an empty range into a std::deque results in undefined calls to
either std::copy, std::copy_backward, std::move, or std::move_backward.
We call those algos with invalid arguments where the output range is the
same as the input range, e.g.  std::copy(first, last, first) which
violates the preconditions for the algorithms.

This fix simply returns early if there's nothing to insert. Most callers
already ensure that we don't even call _M_range_insert_aux with an empty
range, but some callers don't. Rather than checking for n == 0 in each
of the callers, this just does the check once and uses __builtin_expect
to treat empty insertions as unlikely.

libstdc++-v3/ChangeLog:

PR libstdc++/118035
* include/bits/deque.tcc (_M_range_insert_aux): Return
immediately if inserting an empty range.
* testsuite/23_containers/deque/modifiers/insert/118035.cc: New
test.

(cherry picked from commit b273e25e11c842a5729d0e03c85088cf5ba8e06c)

[Bug c++/85944] Address of temporary at global scope not considered constexpr

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

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

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

https://gcc.gnu.org/g:031cb46341690a66f5b31486942f69105db15297

commit r13-9470-g031cb46341690a66f5b31486942f69105db15297
Author: Jonathan Wakely 
Date:   Tue Dec 10 10:56:41 2024 +

libstdc++: Disable __gnu_debug::__is_singular(T*) in constexpr [PR109517]

Because of PR c++/85944 we have several bugs where _GLIBCXX_DEBUG causes
errors for constexpr code. Although Bug 117966 could be fixed by
avoiding redundant debug checks in std::span, and Bug 106212 could be
fixed by avoiding redundant debug checks in std::array, there are many
more cases where similar __glibcxx_requires_valid_range checks fail to
compile and removing the checks everywhere isn't desirable.

This just disables the __gnu_debug::__check_singular(T*) check during
constant evaluation. Attempting to dereference a null pointer will
certainly fail during constant evaluation (if it doesn't fail then it's
a compiler bug and not the library's problem). Disabling this check
during constant evaluation shouldn't do any harm.

libstdc++-v3/ChangeLog:

PR libstdc++/109517
PR libstdc++/109976
* include/debug/helper_functions.h (__valid_range_aux): Treat
all input iterator ranges as valid during constant evaluation.

(cherry picked from commit 9616deb23a17ebe81ad89ede191d7f9f752abdec)

[Bug libstdc++/90389] std::deque::emplace tries to call wrong overload internally

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

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

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

https://gcc.gnu.org/g:86700d114498ef6ed1f14b54732ba62c9f9504d4

commit r13-9467-g86700d114498ef6ed1f14b54732ba62c9f9504d4
Author: Jonathan Wakely 
Date:   Tue Dec 17 17:38:43 2024 +

libstdc++: Fix std::deque::emplace calling wrong _M_insert_aux [PR90389]

We have several overloads of std::deque::_M_insert_aux, one of which is
variadic and called by std::deque::emplace. With a suitable set of
arguments to emplace, it's possible for one of the non-variadic
_M_insert_aux overloads to be selected by overload resolution, making
emplace ill-formed.

Rename the variadic _M_insert_aux to _M_emplace_aux so that calls to
emplace never select an _M_insert_aux overload. Also add an inline
_M_insert_aux for the const lvalue overload that is called from
insert(const_iterator, const value_type&).

libstdc++-v3/ChangeLog:

PR libstdc++/90389
* include/bits/deque.tcc (_M_insert_aux): Rename variadic
overload to _M_emplace_aux.
* include/bits/stl_deque.h (_M_insert_aux): Define inline.
(_M_emplace_aux): Declare.
* testsuite/23_containers/deque/modifiers/emplace/90389.cc: New
test.

(cherry picked from commit 5f44b1776e748a7528020557036740905a11b1df)

[Bug c++/117966] [12/13/14/15 regression] constexpr std::span construction fails to compile with D_GLIBCXX_DEBUG

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

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

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

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

commit r13-9468-gc55e69d87caf8ec7c4a008b571f2232570255855
Author: Jonathan Wakely 
Date:   Mon Dec 9 17:35:24 2024 +

libstdc++: Skip redundant assertions in std::span construction [PR117966]

As PR c++/117966 shows, the Debug Mode checks cause a compilation error
for a global constexpr std::span. Those debug checks are redundant when
constructing from an array or a range, because we already know we have a
valid range and we know its size. Instead of delegating to the
std::span(contiguous_iterator, contiguous_iterator) constructor, just
initialize the data members directly.

libstdc++-v3/ChangeLog:

PR libstdc++/117966
* include/std/span (span(T (&)[N])): Do not delegate to
constructor that performs redundant checks.
(span(array&), span(const array&)): Likewise.
(span(Range&&), span(const span&)): Likewise.
* testsuite/23_containers/span/117966.cc: New test.

(cherry picked from commit e95bda027e0b81922c1bf44770674190bdf787e8)

[Bug c++/106212] Code becomes non-constexpr with _GLIBCXX_DEBUG

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

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

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

https://gcc.gnu.org/g:083224c28524217b1a4b14f55b0447d520020451

commit r13-9469-g083224c28524217b1a4b14f55b0447d520020451
Author: Jonathan Wakely 
Date:   Mon Dec 9 17:35:24 2024 +

libstdc++: Skip redundant assertions in std::array equality [PR106212]

As PR c++/106212 shows, the Debug Mode checks cause a compilation error
for equality comparisons involving std::array prvalues in constant
expressions. Those Debug Mode checks are redundant when
comparing two std::array objects, because we already know we have a
valid range. We can also avoid the unnecessary step of using
std::__niter_base to do __normal_iterator unwrapping, which isn't needed
because our std::array iterators are just pointers. Using
std::__equal_aux1 instead of std::equal avoids the redundant checks in
std::equal and std::__equal_aux.

libstdc++-v3/ChangeLog:

PR libstdc++/106212
* include/std/array (operator==): Use std::__equal_aux1 instead
of std::equal.
* testsuite/23_containers/array/comparison_operators/106212.cc:
New test.

(cherry picked from commit 3aeb2edee2f9fc39ab77c7e020f09d7204b167ac)

[Bug libstdc++/109976] error: is not a constant expression in std::equal() with _GLIBCXX_DEBUG

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

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

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

https://gcc.gnu.org/g:031cb46341690a66f5b31486942f69105db15297

commit r13-9470-g031cb46341690a66f5b31486942f69105db15297
Author: Jonathan Wakely 
Date:   Tue Dec 10 10:56:41 2024 +

libstdc++: Disable __gnu_debug::__is_singular(T*) in constexpr [PR109517]

Because of PR c++/85944 we have several bugs where _GLIBCXX_DEBUG causes
errors for constexpr code. Although Bug 117966 could be fixed by
avoiding redundant debug checks in std::span, and Bug 106212 could be
fixed by avoiding redundant debug checks in std::array, there are many
more cases where similar __glibcxx_requires_valid_range checks fail to
compile and removing the checks everywhere isn't desirable.

This just disables the __gnu_debug::__check_singular(T*) check during
constant evaluation. Attempting to dereference a null pointer will
certainly fail during constant evaluation (if it doesn't fail then it's
a compiler bug and not the library's problem). Disabling this check
during constant evaluation shouldn't do any harm.

libstdc++-v3/ChangeLog:

PR libstdc++/109517
PR libstdc++/109976
* include/debug/helper_functions.h (__valid_range_aux): Treat
all input iterator ranges as valid during constant evaluation.

(cherry picked from commit 9616deb23a17ebe81ad89ede191d7f9f752abdec)

[Bug libstdc++/119429] size_t __nargs = -1 in std::format

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

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

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

https://gcc.gnu.org/g:1662a95371061018415ef26c2e787451c420aa56

commit r13-9478-g1662a95371061018415ef26c2e787451c420aa56
Author: Jonathan Wakely 
Date:   Mon Mar 24 21:25:20 2025 +

libstdc++: Cast -1 to size_t in  [PR119429]

This avoids a runtime error from Clang's annoying -fsanitize=integer
(even though it's not undefined and behaves correctly).

libstdc++-v3/ChangeLog:

PR libstdc++/119429
* include/std/format (__format::_Scanner::_Scanner): Cast
default argument to size_t.

(cherry picked from commit 039cc50867000e6427924ca490dc810eaa44cf08)

[Bug libstdc++/119550] cross compilation of libstdc++ fail for arm-none-eabi due to tzname tests

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

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2025-03-31
 Ever confirmed|0   |1

--- Comment #1 from Richard Earnshaw  ---
I've not noticed any problems from this patch.  And

> [ERROR]checking for tzname... configure: error: Link tests are not 
> allowed after GCC_NO_EXECUTABLES.

This suggests the problem is earlier.  But you haven't supplied any information
on how GCC is being configured, so saying any more would be a wild guess.

[Bug libstdc++/109517] Failure to compile constexpr std::copy with -D_GLIBCXX_DEBUG

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

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

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

https://gcc.gnu.org/g:031cb46341690a66f5b31486942f69105db15297

commit r13-9470-g031cb46341690a66f5b31486942f69105db15297
Author: Jonathan Wakely 
Date:   Tue Dec 10 10:56:41 2024 +

libstdc++: Disable __gnu_debug::__is_singular(T*) in constexpr [PR109517]

Because of PR c++/85944 we have several bugs where _GLIBCXX_DEBUG causes
errors for constexpr code. Although Bug 117966 could be fixed by
avoiding redundant debug checks in std::span, and Bug 106212 could be
fixed by avoiding redundant debug checks in std::array, there are many
more cases where similar __glibcxx_requires_valid_range checks fail to
compile and removing the checks everywhere isn't desirable.

This just disables the __gnu_debug::__check_singular(T*) check during
constant evaluation. Attempting to dereference a null pointer will
certainly fail during constant evaluation (if it doesn't fail then it's
a compiler bug and not the library's problem). Disabling this check
during constant evaluation shouldn't do any harm.

libstdc++-v3/ChangeLog:

PR libstdc++/109517
PR libstdc++/109976
* include/debug/helper_functions.h (__valid_range_aux): Treat
all input iterator ranges as valid during constant evaluation.

(cherry picked from commit 9616deb23a17ebe81ad89ede191d7f9f752abdec)

[Bug c++/106212] Code becomes non-constexpr with _GLIBCXX_DEBUG

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

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

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

https://gcc.gnu.org/g:031cb46341690a66f5b31486942f69105db15297

commit r13-9470-g031cb46341690a66f5b31486942f69105db15297
Author: Jonathan Wakely 
Date:   Tue Dec 10 10:56:41 2024 +

libstdc++: Disable __gnu_debug::__is_singular(T*) in constexpr [PR109517]

Because of PR c++/85944 we have several bugs where _GLIBCXX_DEBUG causes
errors for constexpr code. Although Bug 117966 could be fixed by
avoiding redundant debug checks in std::span, and Bug 106212 could be
fixed by avoiding redundant debug checks in std::array, there are many
more cases where similar __glibcxx_requires_valid_range checks fail to
compile and removing the checks everywhere isn't desirable.

This just disables the __gnu_debug::__check_singular(T*) check during
constant evaluation. Attempting to dereference a null pointer will
certainly fail during constant evaluation (if it doesn't fail then it's
a compiler bug and not the library's problem). Disabling this check
during constant evaluation shouldn't do any harm.

libstdc++-v3/ChangeLog:

PR libstdc++/109517
PR libstdc++/109976
* include/debug/helper_functions.h (__valid_range_aux): Treat
all input iterator ranges as valid during constant evaluation.

(cherry picked from commit 9616deb23a17ebe81ad89ede191d7f9f752abdec)

[Bug libstdc++/101527] The implementation of std::common_iterator and std::counted_iterator's operator== seems to be wrong

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

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

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

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

commit r14-11488-gda6cea6625be011eeda958b096cf35573d2ab7bb
Author: Jonathan Wakely 
Date:   Mon Mar 24 21:36:16 2025 +

libstdc++: Add testcases for resolved bug [PR101527]

These tests were fixed by a front-end change r13-465-g4df735e01e3199 so
this just adds them to the testsuite to be sure we don't regress.

libstdc++-v3/ChangeLog:

PR libstdc++/101527
* testsuite/24_iterators/common_iterator/101527.cc: New test.
* testsuite/24_iterators/counted_iterator/101527.cc: New test.

(cherry picked from commit f7c0b0fc4fdeaf034dc38356830625f7280d325d)

[Bug tree-optimization/119493] [12/13/14/15 Regression] missing tail call to self with struct in some cases

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

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

--- Comment #17 from Jakub Jelinek  ---
Created attachment 60929
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60929&action=edit
gcc15-pr119493-2.patch

Untested fix for the #c14 issue.

[Bug target/119549] [14/15 Regression] SSE4 code inlined into no-sse4 function

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #2 from Richard Biener  ---
r0-81134-g3b8dd0716ff7c5 introduced OPT_mno_sse4 handling into
ix86_handle_option, but that pre-decodes no- and expects OPT_msse4 to handle it
with value == 0.  I'm testing a patch to make behavior of -mno-sse4 consistent
with all the other flags handled.

[Bug tree-optimization/118924] [12/13/14/15 regression] Wrong code at -O2 and above leading to uninitialized accesses on aarch64-linux-gnu since r10-917-g3b47da42de621c

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

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

--- Comment #18 from Martin Jambor  ---
I have proposed a fix on the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6ldslmk3y@virgil.suse.cz/T/#u

[Bug target/119549] [14/15 Regression] SSE4 code inlined into no-sse4 function

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2025-03-31
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #1 from Richard Biener  ---
I have a patch.

[Bug middle-end/119537] assume with statement expression and ("non-local") label

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Seems the C FE doesn't diagnose this kind of stuff at all and C++ FE just
warns:
volatile int v;

void
foo (void)
{
  __label__ x;
  goto *&&x;
  int b = (__extension__ ({ x: ++v; 0; }));
  (void) b;
}

void
bar (void)
{
  __label__ x;
  goto *&&x;
  #pragma omp parallel
  {
x:;
++v;
  }
}

void
baz (void)
{
  __label__ x;
  #pragma omp parallel
  goto *&&x;
  x:;
}

All those are invalid cases, jumping into a statement expression is invalid,
jumping into OpenMP structured block or out of it as well.
But with computed goto it isn't necessarily proven that it is invalid, we can
just take address of the label somewhere (including inside of the statement
expression or OpenMP region), pass the address back and then goto to that with
whether it is a violation hidden e.g. through some non-visible function.

E.g.
volatile int v;

__attribute__((noipa)) void *
qux (void *x, void *y)
{
  return v ? x : y;
}

void
foo (void)
{
  void *p = (__extension__ ({ x: &&x; }));
  void *q = qux (p, &&y);
  y:;
  goto *q;
}

[Bug target/119549] [14/15 Regression] SSE4 code inlined into no-sse4 function

[haochen.jiang at intel dot com via Gcc-bugs]

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

--- Comment #3 from Haochen Jiang  ---
That is odd the AVX10.1 patch would change that behavior.

Lin, could you have a look on that?

[Bug libstdc++/119550] [15 Regression] cross compilation of libstdc++ fail for arm-none-eabi due to tzname tests since g:778c28c70f85

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug libstdc++/119550] [15 Regression] cross compilation of libstdc++ fail for arm-none-eabi due to tzname tests since g:778c28c70f85

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

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

--- Comment #9 from Jonathan Wakely  ---
Something like this:

dnl
dnl Check for a tm_zone member in struct tm.
dnl
dnl This member is defined as const char* in Glibc, newlib, POSIX.1-2024,
dnl and as char* in BSD (including macOS).
dnl
dnl Defines:
dnl  _GLIBCXX_USE_STRUCT_TM_TM_ZONE if struct tm has a tm_zone member.
dnl
AC_DEFUN([GLIBCXX_STRUCT_TM_TM_ZONE], [

  AC_LANG_SAVE
  AC_LANG_CPLUSPLUS
  ac_save_CXXFLAGS="$CXXFLAGS"
  CXXFLAGS="$CXXFLAGS -std=c++20"

  AC_CACHE_CHECK([for tm_zone member of struct tm], glibcxx_cv_tm_zone, [
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([#include 
],
[struct tm t{}; t.tm_zone = (char*)0;]
)],
[glibcxx_cv_tm_zone=yes],
[glibcxx_cv_tm_zone=no]
  )
])

  if test $glibcxx_cv_tm_zone = yes; then
AC_DEFINE(_GLIBCXX_USE_STRUCT_TM_TM_ZONE, 1,
  [Define if struct tm has a tm_zone member.])
  fi

  CXXFLAGS="$ac_save_CXXFLAGS"
  AC_LANG_RESTORE
])

[Bug tree-optimization/119552] New: Deduplicate __divmodbitint4 calls for quotient and remainder

[mcccs at gmx dot com via Gcc-bugs]

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

Bug ID: 119552
   Summary: Deduplicate __divmodbitint4 calls for quotient and
remainder
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mcccs at gmx dot com
  Target Milestone: ---

_BitInt(1280) a, b, c, d;

void divide() {

c = a/b;

d = a%b;

}

calls __divmodbitint4 twice

Relevant bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43721

[Bug c++/119518] C++ FE violates noipa attribute for nothrow

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|NEW |RESOLVED
   Target Milestone|--- |15.0
 Resolution|--- |FIXED

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

[Bug c++/116960] ICE: Error reporting routines re-entered

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

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

--- Comment #5 from GCC Commits  ---
The trunk branch has been updated by Marek Polacek :

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

commit r15-9068-gc7eec82942496520d6b0604aa945a89f279e2562
Author: Marek Polacek 
Date:   Thu Mar 27 15:03:18 2025 -0400

c++: fix reporting routines re-entered [PR119303]

We crash while we call warning_at ("inline function used but never
defined")
since it invokes dump_template_bindings -> tsubst -> ... -> convert_like ->
... -> c_common_truthvalue_conversion -> warning_at ("enum constant in
boolean
 context")

cp_truthvalue_conversion correctly gets complain=0 but it calls
c_common_truthvalue_conversion from c-family which doesn't have
a similar parameter.

We can fix this by tweaking diagnostic_context::report_diagnostic to
check for recursion after checking if the diagnostic was enabled.

PR c++/116960
PR c++/119303

gcc/ChangeLog:

* diagnostic.cc (diagnostic_context::report_diagnostic): Check for
non-zero m_lock later, after checking diagnostic_enabled.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/lambda-uneval26.C: New test.
* g++.dg/warn/undefined2.C: New test.

Reviewed-by: Jason Merrill 

[Bug libstdc++/119550] [15 Regression] cross compilation of libstdc++ fail for arm-none-eabi due to tzname tests since g:778c28c70f85

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

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

--- Comment #10 from Jonathan Wakely  ---
N.B. this intentionally replaces _GLIBCXX_HAVE_STRUCT_TM_TM_ZONE with
_GLIBCXX_USE_STRUCT_TM_TM_ZONE because the latter "USE" macro is not going to
collide with the one from autoconf, in case that gets re-added at a later date.
This requires a small change to the use of the macro in
include/bits/chrono_io.h obviously.

[Bug c++/107430] [meta-bug] lambda in decltype

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

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

Bug 116960 Summary: ICE: Error reporting routines re-entered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116960

   What|Removed |Added

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