[Bug target/120450] New: GCN offloading: ICE 'during RTL pass: expand', 'in assign_temp, at function.cc:990' for C++ 'std::flat_map', 'std::flat_multimap'

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

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

Bug ID: 120450
   Summary: GCN offloading: ICE 'during RTL pass: expand', 'in
assign_temp, at function.cc:990' for C++
'std::flat_map', 'std::flat_multimap'
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, openmp
  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, jakub at gcc dot gnu.org,
kcy at codesourcery dot com
  Target Milestone: ---
Target: GCN

In an OpenMP 'target' region, constructing a C++23-new 'std::flat_map',
'std::flat_multimap' is fine for host and nvptx offloading compilation (and
appears to behave as expected), but we ICE for GCN offloading compilation. 
More elaborate test cases to appear soon, but here's a simple '-O0' reproducer:

#include 
int main (void)
{
  #pragma omp target
  {
std::flat_map m;
  }
  return 0;
}

during RTL pass: expand
In member function ‘__ct ’,
inlined from ‘__ct ’ at
[...]/install/include/c++/16.0.0/flat_map:156:54,
inlined from ‘__ct ’ at
[...]/install/include/c++/16.0.0/flat_map:1431:11,
inlined from ‘main._omp_fn.0’ at
source-gcc/libgomp/testsuite/libgomp.c++/concurrent-flat_multimap.C:41:48:
[...]/install/include/c++/16.0.0/flat_map:160:9: internal compiler error:
in assign_temp, at function.cc:990
  160 |   : _M_cont(), _M_comp(__comp)
  | ^
0x20b1426 internal_error(char const*, ...)
[...]/source-gcc/gcc/diagnostic-global-context.cc:517
0xa3b67c fancy_abort(char const*, int, char const*)
[...]/source-gcc/gcc/diagnostic.cc:1815
0x7ac610 assign_temp(tree_node*, int, int)
[...]/source-gcc/gcc/function.cc:990
0xc42857 expand_constructor
[...]/source-gcc/gcc/expr.cc:9447
0xc2dcd8 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
[...]/source-gcc/gcc/expr.cc:11754
0xc41da3 expand_expr_real(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
[...]/source-gcc/gcc/expr.cc:9529
0xc41da3 expand_normal(tree_node*)
[...]/source-gcc/gcc/expr.h:329
0xc41da3 store_field
[...]/source-gcc/gcc/expr.cc:8246
0xc3d2a9 expand_assignment(tree_node*, tree_node*, bool)
[...]/source-gcc/gcc/expr.cc:6334
0xaede1e expand_gimple_stmt_1
[...]/source-gcc/gcc/cfgexpand.cc:4289
0xaede1e expand_gimple_stmt
[...]/source-gcc/gcc/cfgexpand.cc:4370
0xaf2d98 expand_gimple_basic_block
[...]/source-gcc/gcc/cfgexpand.cc:6433
0xaf5186 execute
[...]/source-gcc/gcc/cfgexpand.cc:7181

It appears to share some similarity with PR114572 '[OpenMP] "internal compiler
error: in assign_temp" with assignment operator and lastprivate clause', but
that one has been fixed long ago.

[Bug target/120428] [14/15/16 regression] Suboptimal autovec involving blocked permutation and std::copy

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

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

--- Comment #15 from Jonathan Wakely  ---
(In reply to Hongtao Liu from comment #13)
> The inner loop is not completely unrolled since std::copy is lowered to
> __builtin_memmove instead of __builtin_memcpy

std::copy allows the end of the output range to overlap with the start of the
input range, so memcpy is not suitable.

It was always using memmove, even before the r15-4475-g7ed561f63e7955 changes
to the library headers.

[Bug c++/117785] [C++26] P3068R5 - constexpr exceptions

[hanicka at hanicka dot net via Gcc-bugs]

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

--- Comment #17 from Hana Dusíková  ---
(In reply to Jakub Jelinek from comment #16)
> So, the paper added also the new case to
> https://eel.is/c++draft/expr.const#10.27
> but
> https://eel.is/c++draft/expr.new#8.5
> has not been changed and still says that say new int[-1] in constexpr
> function is ill-formed.  So, when should one expect
> std::bad_array_new_length() to be actually thrown (except when throwing it
> manually)?

Only when you allocate size bigger than a limit of allocation.

[Bug ada/120440] [15/16 regression] gnat exception handling miscompiled (`gnat ls` crashes when bootstrapped with -march=znver3) since r15-8901-g7bec4570301c43

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

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

--- Comment #6 from Eric Botcazou  ---
> It bisects to r15-8901-g7bec4570301c43 which I find very surprising. Double
> checked with a build of r15-8900-g525d4a10302113 (which works) and
> r15-8901-g7bec4570301c43 (which doesn't).

This patch does change the way host tools are built though.

[Bug libfortran/116400] [15/16 Regression] Regenerated files are no longer written to the source directory

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

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

--- Comment #10 from Francois-Xavier Coudert  ---
> It would be much nicer if we could do something more like other places
> in the compiler, where there is some script to run in the source directory
> that can be done when one changes the m4 (and independently of the build).

I strongly agree with that, for two reasons:

- the build system is a complicated mess, and we don't have people skilled
enough to fix the existing issues (otherwise we would have fixed this PR)
- as a maintainer, I like to be able to regenerate files before/without doing a
build, to look at the changes

I'd rather have a script like libgfortran/regenerate.sh, that calls m4 and
updates the tree. Then maintainers know that, if they changed any m4 file, they
need to regenerate. (It does not happen that often.)

[Bug target/120447] [16 Regression] cpython fails to compile on AArch64 after r16-446-g210d06502f22964c7214586c54f8eb54a6965bfd

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

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

--- Comment #2 from Andrew Pinski  ---
Created attachment 61530
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61530&action=edit
`-mcpu=neoverse-v2 -Ofast` is enough with this one

This is a better reduced testcase that fails even without lto.

[Bug c/117025] [C2y] Implement N3369, New _Lengthof()

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

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

--- Comment #10 from Haochen Jiang  ---
Fixed that texi issue for now by committing the patch.

[Bug driver/120448] -fuse-ld=eld should be supported

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

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

--- Comment #2 from Richard Biener  ---
-fuse-ld is deeply flawed - all configure time checks on linker features are
for the wrong linker then.  We need to get rid of those to make it sound.

[Bug libfortran/116400] [15/16 Regression] Regenerated files are no longer written to the source directory

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

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

--- Comment #9 from Iain Sandoe  ---
If the Fortran maintainers prefer to revert the patch then I shall not
complain.

The configure version was changed in GCC-9 and no-one had stepped forward to
update the Fortran build code even by GCC-15.  I (and others) had also wasted
time when reconfigure errors were missed in the pages of warnings coming from
the unconverted code.  That wasted time was my motivation to do the work for
the patch.

your recollection is, I think, correct, that the original change to
autoconf-2.69 and automake-15.1 was committed knowing that libgfortran was
unconverted.

the patch was not committed knowing that this aspect was broken - it was
committed without testing this aspect (arguably as bad, but...)

I will try and look after 13.4 release work is out of the way.

It would be much nicer if we could do something more like other places in the
compiler, where there is some script to run in the source directory that can be
done when one changes the m4 (and independently of the build).

[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel

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

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

--- Comment #34 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Iain D Sandoe
:

https://gcc.gnu.org/g:3599245e4972b2322f75c909bc81961e41bc64ad

commit r13-9719-g3599245e4972b2322f75c909bc81961e41bc64ad
Author: Mark Mentovai 
Date:   Tue Sep 24 16:11:14 2024 -0400

libgcc, Darwin: Drop the legacy library build for macOS >= 10.12
[PR116809].

From macOSX15 SDK,  the unwinder no longer exports some of the symbols used
in that library which (a) causes bootstrap fail and (b) means that the
legacy library is no longer useful.

No open branch of GCC emits references to this library - and any already
-built code that depends on the symbols would need rework anyway.

We have been asked to extend this back to the earliest OS vesion supported
by the SDK (10.12).

PR target/116809

libgcc/ChangeLog:

* config.host: Build legacy libgcc_s.1 on hosts before macOS 10.12.
* config/i386/t-darwin: Remove reference to legacy libgcc_s.1
* config/rs6000/t-darwin: Likewise.
* config/t-darwin-libgccs1: New file.

Signed-off-by: Iain Sandoe 
(cherry picked from commit d9cafa0c4f0a81304d9b95a78ccc8e9003c6d7a3)

[Bug target/119172] [12/13 regression] macOS SDK version is not set by gcc

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

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Iain D Sandoe
:

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

commit r13-9721-gd9cd8d7babe838b577c6ede08589a79bb3df7810
Author: Iain Sandoe 
Date:   Sun Mar 9 09:24:34 2025 +

Darwin: Pass -macos_version_min to the linker [PR119172].

For binaries to be notarised, the SDK version must be available.
Since we do not, at present, parse this information we have been
passing "0.0" to ld64.  This now results in a warning and a fail
to notarise.  As a quick-fix, we can fall back to letting ld64
figure out the SDK version (which it does for -macos_version_min).

TODO: Parse the SDKSetting.plist at some point.

cherry-picked from 952e17223d3a9 and fc728cfd569e291a5

PR target/119172

gcc/ChangeLog:

* config.in: Regenerate.
* config/darwin.h (DARWIN_PLATFORM_ID): Add the option to
use -macos_version_min where available.
* configure: Regenerate.
* configure.ac: Check for ld64 support of -macos_version_min.

Co-authored-by: Andrew Pinski 

Signed-off-by: Iain Sandoe 
Signed-off-by: Andrew Pinski 

[Bug target/120447] [16 Regression] cpython fails to compile on AArch64 after r16-446-g210d06502f22964c7214586c54f8eb54a6965bfd

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

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

Tamar Christina  changed:

   What|Removed |Added

 Status|WAITING |NEW
   Keywords|needs-source|

--- Comment #1 from Tamar Christina  ---
reduced testcase:

-- cpython.i

int a;
char g;
long h;
void b();
void c() {
  char *d = d ? " and " : " or ";
  b(a, d);
}
double ldexp();
void e() {
  double f = ldexp();
  e(f);
}
unsigned long strlen();
typedef struct {
  void *data
} i;
void b(i *j, char *p2) {
  h = strlen(p2);
  while (g)
;
  int *k = j->data;
  char *l = p2, *m = p2 + h;
  l += 4;
  while (l < m)
*k++ = *l++;
}

---

compiled with

gcc -std=c18 -mcpu=neoverse-v2 -Ofast -flto cpython.i -lm -r

will trigger the ICE.

[Bug c++/117785] [C++26] P3068R5 - constexpr exceptions

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

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

--- Comment #16 from Jakub Jelinek  ---
So, the paper added also the new case to
https://eel.is/c++draft/expr.const#10.27
but
https://eel.is/c++draft/expr.new#8.5
has not been changed and still says that say new int[-1] in constexpr function
is ill-formed.  So, when should one expect std::bad_array_new_length() to be
actually thrown (except when throwing it manually)?

[Bug target/120447] [16 Regression] cpython fails to compile on AArch64 after r16-446-g210d06502f22964c7214586c54f8eb54a6965bfd

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #61530|0   |1
is obsolete||

--- Comment #3 from Andrew Pinski  ---
Created attachment 61531
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61531&action=edit
`-mcpu=neoverse-v2 -Ofast` is enough with this one

Removed the unitialized variable.

[Bug c++/117785] [C++26] P3068R5 - constexpr exceptions

[hanicka at hanicka dot net via Gcc-bugs]

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

--- Comment #18 from Hana Dusíková  ---
(In reply to Jakub Jelinek from comment #16)
> So, the paper added also the new case to
> https://eel.is/c++draft/expr.const#10.27
> but
> https://eel.is/c++draft/expr.new#8.5
> has not been changed and still says that say new int[-1] in constexpr
> function is ill-formed.  So, when should one expect
> std::bad_array_new_length() to be actually thrown (except when throwing it
> manually)?

I don't think`-1` doesn't make it "potentially-evaluated core constant
expression".

[Bug tree-optimization/120032] Fails to pattern match clz from DeBruijn

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

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

--- Comment #4 from Richard Biener  ---
I'll also note that as written the table-based lookup has a value of 31 for
zero input but lzcnt will get you 32.  So unless you make the input of zero
undefined by guarding the code (thus provide a value-range for 'val'), we can't
match those up unless emitting val == 0 ? 31 : clz(val).  BMI has the value at
zero
undefined and thus would also require such a conditional.

[Bug tree-optimization/120451] New: CSWTCH variables should be mergable

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

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

Bug ID: 120451
   Summary: CSWTCH variables should be mergable
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: pinskia at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

CSWTCH variables created by switch conversion should be mergable as we don't
take the address of the variable and it is an artifical one.

[Bug tree-optimization/120451] CSWTCH variables should be mergable

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2025-05-28

--- Comment #1 from Andrew Pinski  ---
We just need to add:
  DECL_MERGEABLE (decl) = 1;

after we create the variable.

I will handle this soon.

I Noticed this while looking into code generation of GCC itself.

[Bug libfortran/116400] [15/16 Regression] Regenerated files are no longer written to the source directory

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

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

--- Comment #11 from Jonathan Wakely  ---
(In reply to Francois-Xavier Coudert from comment #10)
> I'd rather have a script like libgfortran/regenerate.sh, that calls m4 and
> updates the tree. Then maintainers know that, if they changed any m4 file,
> they need to regenerate. (It does not happen that often.)

Yes! As I've pointed out before, --enable-maintainer-mode affects the entire
build tree, not just the fortran sub-dirs. That means it's fragile and prone to
problems that are caused by changes outside the fortran sub-dirs (because
nobody except the fortran devs ever uses maintainer-mode). This then leads to
fortran devs being blocked waiting for changes from non-fortran devs, which are
unnecessary dependencies and cause frustration.

It would be much more reliable to use the common approach for regenerating
Makefile.in, configure etc (i.e. autoreconf like the rest of the GCC tree) and
then use a separate libgfortran-specific solution for regenerating source files
using m4.

Having that regeneration happen as a side effect of building with
--enable-maintainer-mode **and being unable to do it any other way** is a
fragile hack.

It would probably be fine for maintainer mode to *also* run that script when
appropriate, but there should be some standalone script (or makefile target, or
whatever) to perform that regeneration step independent of maintainer mode.

For example, libstdc++-v3/include/bits/version.h needs to be regenerated when
libstdc++-v3/include/bits/version.def is changed. You can either do that
manually by running 'autogen version.def' in the source dir, or running 'make
-C include update-version' in the build dir. When maintainer mode is enabled,
version.h will be automatically regenerated if it's older than version.def. But
since none of the libstdc++ devs use maintainer-mode, we just regenerate it
manually as needed. If it wasn't just a single autogen command then we'd
provide a script to do whatever steps were needed.

[Bug tree-optimization/120451] CSWTCH variables should be mergable

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

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

--- Comment #2 from Andrew Pinski  ---
Oh DECL_MERGEABLE was only added recently in GCC 14 by
r14-1500-g4d935f52b0d5c0. This might be the reason why it was not marked as
CSWTCH was added in r0-92923-g7156c8abaf8f39 (4.5).

[Bug target/120461] New: ICE: in gen_reg_rtx, at emit-rtl.cc:1189 with -mcpu=xt-c920 -mrvv-vector-bits=zvl -fzero-call-used-regs=all

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 120461
   Summary: ICE: in gen_reg_rtx, at emit-rtl.cc:1189 with
-mcpu=xt-c920 -mrvv-vector-bits=zvl
-fzero-call-used-regs=all
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: riscv64-unknown-linux-gnu

Compiler output:
$ $ echo 'void foo() {}' | riscv64-unknown-linux-gnu-gcc -mcpu=xt-c920
-mrvv-vector-bits=zvl -fzero-call-used-regs=all -xc -
during RTL pass: zero_call_used_regs
: In function 'foo':
:1:13: internal compiler error: in gen_reg_rtx, at emit-rtl.cc:1189
0x30b1e41 internal_error(char const*, ...)
/repo/gcc-trunk/gcc/diagnostic-global-context.cc:517
0xf7717b fancy_abort(char const*, int, char const*)
/repo/gcc-trunk/gcc/diagnostic.cc:1803
0xb0dd59 gen_reg_rtx(machine_mode)
/repo/gcc-trunk/gcc/emit-rtl.cc:1189
0x129dd3e copy_to_mode_reg(machine_mode, rtx_def*)
/repo/gcc-trunk/gcc/explow.cc:650
0x15c3da2 maybe_legitimize_operand
/repo/gcc-trunk/gcc/optabs.cc:8040
0x15c3da2 maybe_legitimize_operands(insn_code, unsigned int, unsigned int,
expand_operand*)
/repo/gcc-trunk/gcc/optabs.cc:8183
0x15bfed9 maybe_gen_insn(insn_code, unsigned int, expand_operand*)
/repo/gcc-trunk/gcc/optabs.cc:8202
0x15c4a38 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
/repo/gcc-trunk/gcc/optabs.cc:8257
0x15c4a38 expand_insn(insn_code, unsigned int, expand_operand*)
/repo/gcc-trunk/gcc/optabs.cc:8288
0x1c7e37d riscv_vector::emit_vlmax_insn_lra(unsigned int, unsigned int,
rtx_def**, rtx_def*)
/repo/gcc-trunk/gcc/config/riscv/riscv-v.cc:419
0x1b93efe vector_zero_call_used_regs
/repo/gcc-trunk/gcc/config/riscv/riscv.cc:12018
0x1b93efe riscv_zero_call_used_regs(HARD_REG_SET)
/repo/gcc-trunk/gcc/config/riscv/riscv.cc:12038
0x133d622 gen_call_used_regs_seq
/repo/gcc-trunk/gcc/function.cc:5973
0x133d622 execute
/repo/gcc-trunk/gcc/function.cc:6829
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


$ riscv64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-riscv64//bin/riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-20250528154756-r16-937-g0f73ae763c02ad-checking-yes-rtl-df-extra-riscv64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/16.0.0/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-isa-spec=2.2 --with-sysroot=/usr/riscv64-unknown-linux-gnu
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=riscv64-unknown-linux-gnu
--with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld
--with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib
--enable-libsanitizer --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-20250528154756-r16-937-g0f73ae763c02ad-checking-yes-rtl-df-extra-riscv64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 16.0.0 20250528 (experimental) (GCC)

[Bug other/120462] New: install.texi missing --enable-checking flag

[ingo at hannover dot ccc.de via Gcc-bugs]

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

Bug ID: 120462
   Summary: install.texi missing --enable-checking flag
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ingo at hannover dot ccc.de
  Target Milestone: ---

Created attachment 61541
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61541&action=edit
install.texi.diff

The flag "fold" is missing in the enabled checks for the list "yes". See
attached diff.

[Bug fortran/119856] Missing commas in I/O formats not diagnosed by default at compile time.

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

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

--- Comment #4 from Jerry DeLisle  ---
Note: I biffed the PR number in the log.

The master branch has been updated by Jerry DeLisle :

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

commit r16-939-ge2bf0b3910de7e65363435f0a7fa606e2448a677
Author: Jerry DeLisle 
Date:   Wed May 28 07:56:12 2025 -0700

Fortran: Adjust handling of optional comma in FORMAT.

This change adjusts the error messages for optional commas
in format strings to give a warning at compile time unless
-std=legacy is used. This is more consistant with the
runtime library. A missing comma separator should not be
encouraged as it is non-standard fortran.

PR fortran/119586

gcc/fortran/ChangeLog:

* io.cc: Set missing comma error checks to STD_STD_LEGACY.

gcc/testsuite/ChangeLog:

* gfortran.dg/comma_format_extension_1.f: Update dg-options to
"-std=legacy".
* gfortran.dg/comma_format_extension_3.f: Likewise.
* gfortran.dg/continuation_13.f90: Likewise.

[Bug ada/120463] New: Pb Doubled linked List

[zzbard at wanadoo dot fr via Gcc-bugs]

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

Bug ID: 120463
   Summary: Pb Doubled linked List
   Product: gcc
   Version: 13.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zzbard at wanadoo dot fr
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 61542
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61542&action=edit
All files necessary to reproduce the bug (change the paths).

Compilation error without no evident root cause, probably linked to Container
Doubly Link List.

$ ./compile.sh
---
Compilation de checkpres
---
Compile
   [Ada]  fichier.adb
+===GNAT BUG DETECTED==+
| 13.3.0 (x86_64-linux-gnu) Storage_Error stack overflow or erroneous memory
access|
| Error detected at fichier.adb:505:3  |
| Compiling
/media/4To/Donnees/Courrier/020-Ada/M-Sources/110-Utilitaires/130-Bureautique/015-HTML/G1R8/G1R8_1/A-src/Biblio/fichier.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).

/media/4To/Donnees/Courrier/020-Ada/M-Sources/110-Utilitaires/130-Bureautique/015-HTML/G1R8/G1R8_1/A-src/Biblio/fichier.adb
/media/4To/Donnees/Courrier/020-Ada/M-Sources/110-Utilitaires/130-Bureautique/015-HTML/G1R8/G1R8_1/A-src/Biblio/fichier.ads

fichier.adb:552:36: warning: "return" statement missing following this
statement [enabled by default]
fichier.adb:552:36: warning: Program_Error will be raised at run time [enabled
by default]
compilation abandoned
gprbuild: *** compilation phase failed
$
$ gnat
GNAT 13.3.0
Copyright 1996-2023, Free Software Foundation, Inc.

To list Ada build switches use --help-ada

List of available commands

gnat bind   x86_64-linux-gnu-gnatbind-13
gnat chop   x86_64-linux-gnu-gnatchop-13
gnat clean  x86_64-linux-gnu-gnatclean-13
gnat compilex86_64-linux-gnu-gnatmake-13 -f -u -c
gnat check  x86_64-linux-gnu-gnatcheck-13
gnat elim   x86_64-linux-gnu-gnatelim-13
gnat krunch x86_64-linux-gnu-gnatkr-13
gnat link   x86_64-linux-gnu-gnatlink-13
gnat list   x86_64-linux-gnu-gnatls-13
gnat make   x86_64-linux-gnu-gnatmake-13
gnat metric x86_64-linux-gnu-gnatmetric-13
gnat name   x86_64-linux-gnu-gnatname-13
gnat preprocess x86_64-linux-gnu-gnatprep-13
gnat pretty x86_64-linux-gnu-gnatpp-13
gnat stack  x86_64-linux-gnu-gnatstack-13
gnat stub   x86_64-linux-gnu-gnatstub-13
gnat test   x86_64-linux-gnu-gnattest-13


Report bugs to rep...@adacore.com
$

[Bug libfortran/83282] missing comma in format changes output

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

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #7 from Jerry DeLisle  ---
We now do the following:

$ gfc pr83282.f90 
pr83282.f90:1:13:

1 |write(*,'(aa)') "ab", "bc"
  | 1
Warning: Legacy Extension: Missing comma in FORMAT string at (1)
pr83282.f90:3:19:

3 |write(*,'(a,"cd"a)') "ab", "bc"
  |   1
Warning: Legacy Extension: Missing comma in FORMAT string at (1)
$ ./a.out 
At line 1 of file pr83282.f90 (unit = 6, file = 'stdout')
Fortran runtime error: Missing comma between descriptors
(aa)
  ^
Using -std=legacy we get:

$ gfc -std=legacy  pr83282.f90 
$ ./a.out 
abbc
abbc
abcdbc

I would like to close this.

[Bug fortran/119856] Missing commas in I/O formats not diagnosed by default at compile time.

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

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #5 from Jerry DeLisle  ---
Closing as fixed. I will amend the ChangeLog file tomorrow. I see no need to
backport this. Let me know otherwise.

[Bug fortran/119856] Missing commas in I/O formats not diagnosed by default at compile time.

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

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

Bug 83282 Summary: missing comma in format changes output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83282

   What|Removed |Added

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

[Bug bootstrap/120464] New: Build broken in ggc-page.cc on master

[zmajeed at sbcglobal dot net via Gcc-bugs]

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

Bug ID: 120464
   Summary: Build broken in ggc-page.cc on master
   Product: gcc
   Version: 15.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zmajeed at sbcglobal dot net
  Target Milestone: ---

GCC build fails on master due to commit
725063bc1fda6b0403a8b72fce3b4c9cc6a4ba3a

It moved the page_entry* free_pages field from ggc_globals to a new struct
free_list - and missed updating a line of initializations

958: struct page_entry *e, *f = G.free_pages;

that should be

struct page_entry *e, *f = free_list->free_pages;

[Bug bootstrap/120464] Build broken in ggc-page.cc on master

[zmajeed at sbcglobal dot net via Gcc-bugs]

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

--- Comment #1 from Zartaj Majeed  ---
The build error is

g++ -std=c++14  -fno-PIE -c   -g -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-error=narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -Wconditionally-supported
-Woverloaded-virtual -pedantic-Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings  -DHAVE_CONFIG_H -fno-PIE -I. -I. -Igcc -Igcc/.
-Igcc/../include  -Igcc/../libcpp/include -Igcc/../libcody 
-Igcc/../libdecnumber -Igcc/../libdecnumber/bid -I../libdecnumber
-Igcc/../libbacktrace   -o ggc-page.o -MT ggc-page.o -MMD -MP -MF
./.deps/ggc-page.TPo gcc/ggc-page.cc

gcc/ggc-page.cc: In function ‘page_entry* alloc_page(unsigned int)’:
gcc/ggc-page.cc:958:40: error: ‘struct ggc_globals’ has no member named
‘free_pages’
  958 |   struct page_entry *e, *f = G.free_pages;
  |^~
make[3]: *** [Makefile:1210: ggc-page.o] Error 1

[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions

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

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

--- Comment #21 from GCC Commits  ---
The master branch has been updated by Tobias Burnus :

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

commit r16-938-ge8fdd55ec907496ff3c80fed55d8da3ddbdc1a2b
Author: Yuao Ma 
Date:   Wed May 28 23:13:45 2025 +0800

fortran: add constant input support for trig functions with
half-revolutions

This patch introduces constant input support for trigonometric functions,
including those involving half-revolutions. Both valid and invalid inputs
have
been thoroughly tested, as have mpfr versions greater than or equal to 4.2
and
less than 4.2.

Inspired by Steve's previous work, this patch also fixes subtle bugs
revealed
by newly added test cases.

If this patch is merged, I plan to work on middle-end optimization support
for
previously added GCC built-ins and libgfortran intrinsics.

PR fortran/113152

gcc/fortran/ChangeLog:

* gfortran.h (enum gfc_isym_id): Add new enum.
* intrinsic.cc (add_functions): Register new intrinsics. Changing
the call
from gfc_resolve_trigd{,2} to gfc_resolve_trig{,2}.
* intrinsic.h (gfc_simplify_acospi, gfc_simplify_asinpi,
gfc_simplify_asinpi, gfc_simplify_atanpi, gfc_simplify_atan2pi,
gfc_simplify_cospi, gfc_simplify_sinpi, gfc_simplify_tanpi): New.
(gfc_resolve_trig): Rename from gfc_resolve_trigd.
(gfc_resolve_trig2): Rename from gfc_resolve_trigd2.
* iresolve.cc (gfc_resolve_trig): Rename from gfc_resolve_trigd.
(gfc_resolve_trig2): Rename from gfc_resolve_trigd2.
* mathbuiltins.def: Add 7 new math builtins and re-align.
* simplify.cc (gfc_simplify_acos, gfc_simplify_asin,
gfc_simplify_acosd, gfc_simplify_asind): Revise error message.
(gfc_simplify_acospi, gfc_simplify_asinpi,
gfc_simplify_asinpi, gfc_simplify_atanpi, gfc_simplify_atan2pi,
gfc_simplify_cospi, gfc_simplify_sinpi, gfc_simplify_tanpi): New.

gcc/testsuite/ChangeLog:

* gfortran.dg/dec_math_3.f90: Test invalid input.
* gfortran.dg/dec_math_5.f90: Test valid output.
* gfortran.dg/dec_math_6.f90: New test.

Signed-off-by: Yuao Ma 
Co-authored-by: Steven G. Kargl 

[Bug tree-optimization/119586] [15 Regression] wrong code at -O2 with "-ftree-loop-vectorize -fno-inline" on x86_64-linux-gnu since r15-8047

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Jerry DeLisle :

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

commit r16-939-ge2bf0b3910de7e65363435f0a7fa606e2448a677
Author: Jerry DeLisle 
Date:   Wed May 28 07:56:12 2025 -0700

Fortran: Adjust handling of optional comma in FORMAT.

This change adjusts the error messages for optional commas
in format strings to give a warning at compile time unless
-std=legacy is used. This is more consistant with the
runtime library. A missing comma separator should not be
encouraged as it is non-standard fortran.

PR fortran/119586

gcc/fortran/ChangeLog:

* io.cc: Set missing comma error checks to STD_STD_LEGACY.

gcc/testsuite/ChangeLog:

* gfortran.dg/comma_format_extension_1.f: Update dg-options to
"-std=legacy".
* gfortran.dg/comma_format_extension_3.f: Likewise.
* gfortran.dg/continuation_13.f90: Likewise.

[Bug target/110634] Incorrect RISC-V assembly with -fno-omit-frame-pointer

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

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

--- Comment #7 from Vineet Gupta  ---
As of gcc-15.1 release, ra is being stored and both gcc and llvm seem to be
generate compatible code.

https://godbolt.org/z/jze1TMKbW

foo:
addisp,sp,-16
sd  s0,0(sp)
sd  ra,8(sp)
addis0,sp,16
ld  ra,8(sp)
ld  s0,0(sp)
addwa0,a0,a1
addisp,sp,16
jr  ra
.size   foo, .-foo
.ident  "GCC: (gec30a04a80cc) 15.1.0"
.section.note.GNU-stack,"",@progbits

[Bug tree-optimization/119586] [15 Regression] wrong code at -O2 with "-ftree-loop-vectorize -fno-inline" on x86_64-linux-gnu since r15-8047

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

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #9 from Jerry DeLisle  ---
(In reply to GCC Commits from comment #8)
> The master branch has been updated by Jerry DeLisle :
> 
> https://gcc.gnu.org/g:e2bf0b3910de7e65363435f0a7fa606e2448a677
> 
> commit r16-939-ge2bf0b3910de7e65363435f0a7fa606e2448a677
> Author: Jerry DeLisle 
> Date:   Wed May 28 07:56:12 2025 -0700

I biffed the PR number, sorry about that. How to fix?

[Bug bootstrap/120464] Build broken in ggc-page.cc on master

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
You didn't say which host was this (nor which target).
I assume it is some host without working mmap.

Anyway, trying to reproduce it on x86_64-linux with
--- gcc/ggc-page.cc.jj  2025-05-27 23:08:37.969726172 +0200
+++ gcc/ggc-page.cc 2025-05-28 21:16:49.545802332 +0200
@@ -44,6 +44,7 @@ along with GCC; see the file COPYING3.
 #ifdef HAVE_MMAP_DEV_ZERO
 # define USING_MMAP
 #endif
+#undef USING_MMAP

 #ifndef USING_MMAP
 #define USING_MALLOC_PAGE_GROUPS
@@ -955,7 +956,7 @@ alloc_page (unsigned order)
   /* If we allocated multiple pages, put the rest on the free list.  */
   if (multiple_pages)
{
- struct page_entry *e, *f = G.free_pages;
+ struct page_entry *e, *f = free_list->free_pages;
  for (a = enda - G.pagesize; a != page; a -= G.pagesize)
{
  e = XCNEWVAR (struct page_entry, page_entry_size);
things progress a little bit further but ICE during selftest:
cc1plus: internal compiler error: Segmentation fault
0x26ed16f internal_error(char const*, ...)
../../gcc/diagnostic-global-context.cc:517
0x13d5f1f crash_signal
../../gcc/toplev.cc:321
0xe25ecf do_release_pages
../../gcc/ggc-page.cc:1204
0xe25ecf release_pages
../../gcc/ggc-page.cc:1242
0xe27632 ggc_collect(ggc_collect)
../../gcc/ggc-page.cc:2316
0x102fdfe test_length
../../gcc/ggc-tests.cc:80
0x102fdfe selftest::ggc_tests_cc_tests()
../../gcc/ggc-tests.cc:468
0x25dcbe5 selftest::run_tests()
../../gcc/selftest-run-tests.cc:71
0x13d761a toplev::run_self_tests()
../../gcc/toplev.cc:2266
The segfault line is
  /* Remove all pages from free page groups from the list.  */
  pp = &free_list->free_pages;
  while ((p = *pp) != NULL)
if (p->group->in_use == 0)
  {
*pp = p->next;
free (p);
  }
else
  pp = &p->next;
the if (p->group->in_use == 0) one.  And p->group in that case refers to
already freed memory.

[Bug libfortran/116400] [15/16 Regression] Regenerated files are no longer written to the source directory

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

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

--- Comment #12 from Francois-Xavier Coudert  ---
Created attachment 61532
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61532&action=edit
Regeneration script

Attached is a shell script, to be placed in libgfortran/, that can be run in
that directory to regenerated all files. If people agree with this approach, I
would then remove the hackish "maintainer mode" code from
libgfortran/Makefile.am, leading to behavior that is identical to other GCC
runtime libraries:
  - maintainer mode regenerates automake/autoconf files
  - regeneration of library code is done manually by developers, through a
script

I think this is definitely more robust. Let me know what you think.



Applying that script should lead to no difference, but it does not :) it leads
to a lot of whitespace changes, demonstrating why we need to change the current
situation is: those whitespace changes, introduced in the m4 files in this
commit

commit 5e918a4db9e4a5bdbeafec6881fa8b22a55d3789
Author: Thomas Koenig 
Date:   2024-09-24 21:59:10 +0200

* m4/ifunction.m4: Whitespace fix.

has not been included in the regenerated files, almost one year later.

[Bug rtl-optimization/99015] [12/13 Regression] ICE: Max. number of generated reload insns per insn is achieved (90)

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

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

--- Comment #12 from Vladimir Makarov  ---
Created attachment 61535
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61535&action=edit
A candidate patch for gcc-13

[Bug rtl-optimization/99015] [12/13 Regression] ICE: Max. number of generated reload insns per insn is achieved (90)

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

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

--- Comment #13 from Vladimir Makarov  ---
(In reply to Jakub Jelinek from comment #11)
> r14-7141-ga729b6e002fe76208f33fdcdee49d6a310a1940e fixed it.

The patch needed some reworking for gcc-13 as there were changes in the same
code parts.

I am putting a candidate patch in the attachment.  I'll approve it after
finishing tests and bootstraps on amd64, arm64, ppc64.

[Bug c/71713] "initializer element is not constant" with nested casts

[zsojka at seznam dot cz via Gcc-bugs]

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

Zdenek Sojka  changed:

   What|Removed |Added

 CC||zsojka at seznam dot cz

--- Comment #3 from Zdenek Sojka  ---
The code from comment #0 is accepted (with a pedwarn) by at least gcc-13.3.1
(but rejected by gcc-12.4.1).

[Bug target/120450] GCN offloading: ICE 'during RTL pass: expand', 'in assign_temp, at function.cc:990' for C++ 'std::flat_map', 'std::flat_multimap'

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

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

--- Comment #1 from Richard Biener  ---
The question is what's the reason we end up here from expand_constructor. 
There's

  /* Handle calls that pass values in multiple non-contiguous
 locations.  The Irix 6 ABI has examples of this.  */
  if (target == 0 || ! safe_from_p (target, exp, 1)
  || GET_CODE (target) == PARALLEL || modifier == EXPAND_STACK_PARM
  /* Also make a temporary if the store is to volatile memory, to
 avoid individual accesses to aggregate members.  */
  || (GET_CODE (target) == MEM
  && MEM_VOLATILE_P (target)
  && !TREE_ADDRESSABLE (TREE_TYPE (exp
{
  if (avoid_temp_mem)
return NULL_RTX;

  target = assign_temp (type, TREE_ADDRESSABLE (exp), 1);

I guess the && !TREE_ADDRESSABLE (TREE_TYPE (exp)) should be applied globally,
but then other cases might break(?)

So how does 'target' look like, is !safe_from_p true?

[Bug c++/120453] [16 regression] qcoro fails to build its tests

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

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

Sam James  changed:

   What|Removed |Added

   Keywords||rejects-valid
   See Also||https://bugs.gentoo.org/sho
   ||w_bug.cgi?id=956633
   Target Milestone|--- |16.0

--- Comment #1 from Sam James  ---
```
$ g++ -c qcorolazytask.cpp.ii -std=gnu++20
/var/tmp/portage/dev-libs/qcoro-0.12.0/work/qcoro-0.12.0/tests/qcorolazytask.cpp:
In lambda function:
/var/tmp/portage/dev-libs/qcoro-0.12.0/work/qcoro-0.12.0/tests/qcorolazytask.cpp:21:31:
error: use of deleted function ‘QCoro::LazyTask<>::LazyTask(const
QCoro::LazyTask<>&)’
In file included from
/var/tmp/portage/dev-libs/qcoro-0.12.0/work/qcoro-0.12.0/tests/qcorolazytask.cpp:9:
/var/tmp/portage/dev-libs/qcoro-0.12.0/work/qcoro-0.12.0/qcoro/qcorolazytask.h:40:7:
note: ‘QCoro::LazyTask<>::LazyTask(const QCoro::LazyTask<>&)’ is implicitly
deleted because the default definition would be ill-formed:
/var/tmp/portage/dev-libs/qcoro-0.12.0/work/qcoro-0.12.0/qcoro/qcorolazytask.h:
At global scope:
/var/tmp/portage/dev-libs/qcoro-0.12.0/work/qcoro-0.12.0/qcoro/qcorolazytask.h:40:7:
error: use of deleted function ‘QCoro::detail::TaskBase::TaskBase(const QCoro::detail::TaskBase&) [with T = void; TaskImpl = QCoro::LazyTask; PromiseType =
QCoro::detail::LazyTaskPromise]’
In file included from
/var/tmp/portage/dev-libs/qcoro-0.12.0/work/qcoro-0.12.0/tests/testlibs/testobject.h:13,
 from
/var/tmp/portage/dev-libs/qcoro-0.12.0/work/qcoro-0.12.0/tests/qcorolazytask.cpp:6:
/var/tmp/portage/dev-libs/qcoro-0.12.0/work/qcoro-0.12.0/qcoro/qcorotask.h:343:5:
note: declared here
[...]
```

GCC 15 accepts it.

[Bug c++/120453] [16 regression] qcoro fails to build its tests

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

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

--- Comment #2 from Sam James  ---
Created attachment 61534
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61534&action=edit
partial.cpp.ii.xz

Attaching a partial reduction, still running, but it's slow.

[Bug c++/120454] New: C++ constexpr vs. OpenMP implicit mapping

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

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

Bug ID: 120454
   Summary: C++ constexpr vs. OpenMP implicit mapping
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: burnus at gcc dot gnu.org, jakub at gcc dot gnu.org,
waffl3x at gcc dot gnu.org
  Target Milestone: ---
Target: GCN, nvptx

(More elaborate test cases to appear soon, but) for a simple C++23 code:

#include 
#include 
//#pragma omp declare target(std::ranges::iota)
int main()
{
#pragma omp target defaultmap(none)
  {
int data[4];
std::span span = {data, sizeof data / sizeof data[0]};
std::ranges::iota(span, -13);
for (size_t i = 0; i < sizeof data / sizeof data[0]; ++i)
  if (data[i] != -13 + (int) i)
__builtin_abort();
  }
  return 0;
}

..., we get:

pr.C: In function ‘int main()’:
pr.C:10:22: error: ‘iota’ not specified in enclosing ‘target’
   10 | std::ranges::iota(span, -10);
  | ~^~~
pr.C:6:9: note: enclosing ‘target’
6 | #pragma omp target defaultmap(none)
  | ^~~

If removing the 'defaultmap(none)' clause, it complies fine, but SIGSEGVs for
offloading execution test, when libgomp tries to 'GOMP_OFFLOAD_dev2host' for
'std::ranges::iota', because that one got an implicit 'map(tofrom:iota [len: 1]
[runtime_implicit])' clause, huh.

C++ constexpr 'std::ranges::iota' vs. OpenMP implicit mapping issue?

We can resolve the SIGSEGV with an explicit '#pragma omp declare
target(std::ranges::iota)'.  (..., but still get an implicit 'map' clause for
it, as above?)

[Bug middle-end/118694] OpenMP: target/metadirective/teams directive nesting gives error

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

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

--- Comment #13 from GCC Commits  ---
The master branch has been updated by Tobias Burnus :

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

commit r16-935-g5b2e7afb135aa10e17e51b891d4b2c85ee541ade
Author: Tobias Burnus 
Date:   Wed May 28 15:14:14 2025 +0200

libgomp.fortran/metadirective-1.f90: Expect 'error:' for nvptx compile
[PR118694]

This should have been part of commit r16-838-gb3d07ec7ac2ccd or
r16-883-g5d6ed6d604ff94 - all showing the same issue:
'!$omp target' followed by a metadirective with 'teams'; if
the metadirective cannot be early resolved, a diagnostic
error is shown about using directives between 'target' and
'teams'.

While the message is misleading, the problem is that the
host invokes 'target' differently when 'teams' is present;
in this case, host fallback + amdgcn offload require the
no-teams case, nvptx offload the teams case such that it
only can be resolved at runtime.

Mark the error as 'dg-bogus + xfail' to silence the FAIL,
when nvptx offloading is compiled for. (If not, the
metadirective can be resolved early during compilation.)

libgomp/ChangeLog:

PR middle-end/118694
* testsuite/libgomp.fortran/metadirective-1.f90: xfail when
compiling (also) for nvptx offloading as an error is then expected.

[Bug target/120436] division-by-zero when calling some RVV intrinsics without the V extension

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

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

Robin Dapp  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
 CC||rdapp at gcc dot gnu.org

--- Comment #2 from Robin Dapp  ---
Fixed on trunk.

[Bug libstdc++/99832] std::chrono::system_clock::to_time_t needs ABI tag for 32-bit time_t

[dave.anglin at bell dot net via Gcc-bugs]

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

--- Comment #13 from dave.anglin at bell dot net ---
If you have a proposed patch, I'm willing to test.

[Bug c++/120453] [16 regression] qcoro fails to build its tests (error: use of deleted function ... is implicitly deleted because the default definition would be ill-formed) since r16-773-ge06555a40c0

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

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

--- Comment #5 from Iain Sandoe  ---
thanks for the report.
Note that GCC-15 is not doing the correct operations in respect of the CWG2563
discussions (see PR119916 and PR115908).

However, this can still be a new issue (not analysed so far).

[Bug libstdc++/120432] flat_map operator[] is broken for const lvalue keys

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

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

--- Comment #4 from Patrick Palka  ---
(In reply to Patrick Palka from comment #3)
> (In reply to Arthur O'Dwyer from comment #2)
> > But I think a better answer in this case is "because using
> > a volatile index *will not actually compile*, so flat_map shouldn't
> > gratuitously advertise that signature to SFINAE."
> > https://godbolt.org/z/bdTK7nPKG
> Good point.. I think this also means the standard transparent-compare
> overload is underconstrained: https://godbolt.org/z/354GTTsxG
So with the current wording, m[k] for volatile k is a soft/constraint error if
the comparator is non-transparent, but is a hard error if the comparator is
transparent.  Naturally one would expect m[k] to behave consistently regardless
of comparator transparency, so the current behavior seems like a wording
defect.
It's not clear whether the solution is to uniformly accept, or reject, volatile
k.

[Bug c++/120456] New: __builtin_shuffle produces unnecessary vperm2i128

[adamant.pwn at gmail dot com via Gcc-bugs]

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

Bug ID: 120456
   Summary: __builtin_shuffle produces unnecessary vperm2i128
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adamant.pwn at gmail dot com
  Target Milestone: ---

Consider the following snippet:

auto test1(uint32_t bits) {
auto bytes = u8x32(u32x8() + bits);
u8x32 shuffler = {
0, 0, 0, 0, 0, 0, 0, 0,
1, 1, 1, 1, 1, 1, 1, 1,
2, 2, 2, 2, 2, 2, 2, 2,
3, 3, 3, 3, 3, 3, 3, 3
};
auto shuffle = __builtin_shuffle(bytes, shuffler);
return shuffle;
}

It produces an unnecessary vperm2i128 command in the output. Same if I try to
use __builtin_shufflevector. Also if I try to change one of the bytes to the
second half, e.g. 3 to 31, it produces an unnecessary vpermq instead of
vperm2i128.

See https://godbolt.org/z/eEnd673e6 for details, and comparison with manual
implementation of the same function with intrinsics.

[Bug c++/120453] [16 regression] qcoro fails to build its tests (error: use of deleted function ... is implicitly deleted because the default definition would be ill-formed) since r16-773-ge06555a40c0

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

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

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

[Bug c++/107600] New __is_destructible built-in

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2022-11-10 00:00:00 |2025-5-28

--- Comment #3 from Jonathan Wakely  ---
I was reminded recently that the library currently uses
__has_trivial_destructor as part of std::is_trivially_destructible, which is
not an exact match for the semantics of the standard trait:

#include 

struct D {
  ~D() = delete;
};

static_assert( __has_trivial_destructor(D) );
static_assert( not std::is_trivially_destructible_v );


Also, Clang has deprecated __has_trivial_destructor in favour of their newer
__is_trivially_destructible built-in:

dest.cc:7:16: warning: builtin __has_trivial_destructor is deprecated; use
__is_trivially_destructible instead [-Wdeprecated-builtins]
7 | static_assert( __has_trivial_destructor(D) );
  |^
1 warning generated.


So it would be nice if we had __is_trivially_destructible too, in addition to
__is_destructible and __is_nothrow_destructible.

[Bug c++/120458] module-name does not allow non-ASCII characters

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

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

--- Comment #1 from Jonathan Wakely  ---
Clang compiles this, and I think MSVC does, but EDG doesn't (but EDG also
doesn't accept that identifier for a variable name, at least with the default
options).

[Bug libfortran/116400] [15/16 Regression] Regenerated files are no longer written to the source directory

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

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

--- Comment #14 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #13)
> (In reply to Francois-Xavier Coudert from comment #12)
> > Created attachment 61532 [details]
> > Regeneration script
> > 
> > Attached is a shell script, to be placed in libgfortran/, that can be run in
> > that directory to regenerated all files. If people agree with this approach,
> > I would then remove the hackish "maintainer mode" code from
> > libgfortran/Makefile.am, leading to behavior that is identical to other GCC
> > runtime libraries:
> >   - maintainer mode regenerates automake/autoconf files
> >   - regeneration of library code is done manually by developers, through a
> > script
> >  
> > I think this is definitely more robust. Let me know what you think.

> cool ...
> what might be nice is to share the list by including it in both the regen
> script and the Makefile... that seems like it should be possible?

In addition to sharing the input list 

I'd think that the Makefile can have
-include $(srdir)/generated_sources_list

and the script can just

. generated_sources_list



1/

I think that the regen script should collect all the inputs into one list and
do something like:

for f in ${all_generated} ; do
  $(M4) -Dfile=$f -I./m4 powu.m4 > $f.tmp
  ../move-if-changed $f.tmp $f
done

otherwise it's going to touch all the files?

2/ if this is called from the Makefile then we definitely need to use $(M4); I
guess the script can fallback to 'm4' if that is unset?

[Bug c++/115908] [coroutines] Wrong behavior of using get_return_object() when creating coroutines

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

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

--- Comment #10 from Iain Sandoe  ---
my understanding is that the conclusion of CWG2563 is that this behaviour was
not the intended design - and the resolution to this is in PR119916.

(so that, unless there's new information, this bug would be closed as INVALID).

[Bug c/11234] -pedantic accepts function pointer <-> void*

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||ssofroni at cytanet dot com.cy

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

[Bug c/120452] error: ISO C forbids conversion of function pointer to object pointer type

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
>Is it an expected behavior or a regression from previous versions?

YES. GCC has correctly rejected this with -pedantic since GCC 3.4.0; see PR
11234.

Also see PR 109214 where the extension is mentioned that it is not documented.

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

[Bug libstdc++/120432] flat_map operator[] is broken for const lvalue keys

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

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

--- Comment #6 from Jonathan Wakely  ---
Please don't waste time on the volatile question. What does it mean to lookup a
volatile value that could change at any moment? What is the library even
supposed to do with a volatile int& there, read it again for every comparison?
Copy it once and then use that value?

[Bug c/120452] error: ISO C forbids conversion of function pointer to object pointer type

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

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

--- Comment #2 from Andrew Pinski  ---
Basically don't use -Wpedantic if you don't want any extensions (include
extensions required for POSIX).

[Bug fortran/109345] [12/13/14 Regression] class(*) variable that is a string array is not handled correctly

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

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #15 from Jerry DeLisle  ---
(In reply to Paul Thomas from comment #14)
> (In reply to Paul Thomas from comment #13)
>  
> > I have had a period of not being able to work on gfortran. I'll take a look
> > at this today.
> 
> Some other patch has been applied to 14-branch onwards that results in the
> component references being handled completely differently to 12- and 13-.
> The newer branches create a temporary array and point the descriptor to
> that, while 12- and 13- attempt to point to the original data field and
> screw it up.
> 
> Since the original problem is fixed, my inclination is to comment out the
> last two calls to foo. OK?
> 
> Paul

Only on those two branches, yes. Non of us have time to go back and rework
everything.

[Bug c++/117785] [C++26] P3068R5 - constexpr exceptions

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #61528|0   |1
is obsolete||

--- Comment #19 from Jakub Jelinek  ---
Created attachment 61540
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61540&action=edit
gcc16-pr117785-wip.patch

Further progress, still need to debug std::rethrow_exception, adjust testsuite
not yet tested for C++26 changes if throw appears (so far adjusted just the
C++20 dynamic_cast/typeid ones) and maybe add helper to evaluate what () and
print it in the diagnostics.
Also maybe add some flags on MUST_NOT_THROW_EXPR to differentiate the reasons
why it has been emitted into the IL and take it into account in the
diagnostics.

[Bug c++/120460] std::function ignores [[nodiscard]] attribute

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2025-05-28
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Jonathan Wakely  ---
This variation doesn't warn even with -Wsystem-headers

#include 

[[nodiscard]] int f();

void g() {
  std::invoke_r(f);
}


That's because where the call to f() happens the return value is propagated to
the caller:

  template
constexpr _Res
__invoke_impl(__invoke_other, _Fn&& __f, _Args&&... __args)
{ return std::forward<_Fn>(__f)(std::forward<_Args>(__args)...); }


But then that caller discards it:

  if constexpr (is_void_v<_Res>)
std::__invoke_impl<__type>(__tag{}, std::forward<_Callable>(__fn),
std::forward<_Args>(__args)...);

I don't think [[nodiscard]] on the function can work here. The caller doesn't
know that the int shouldn't be discarded, it's just an int by that point.

For Avi's original example, the A object carries the [[nodiscard]] with it so
that there's still a warning if/when it is ever discarded. But I agree that
it's a limitation of the front-end. I don't think we need to worry about
badly-written system headers that are discarding [[nodiscard]] results, because
any headers using [[nodiscard]] are probably quite new C++ code and probably
still maintained, and could be fixed to cast to void if needed.

[Bug c++/120460] std::function ignores [[nodiscard]] attribute

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

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

--- Comment #3 from Jonathan Wakely  ---
i.e. maybe this warning should ignore whether it's in a system header or not.

[Bug c++/120453] [16 regression] qcoro fails to build its tests (error: use of deleted function ... is implicitly deleted because the default definition would be ill-formed) since r16-773-ge06555a40c0

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

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #9 from Iain Sandoe  ---
OK so the reason this fails is because check_return_expr() concludes that we
cannot do NRVO and we try to do the bad conversion.

There are two reasons that it makes this conclusion.

1. We actually need a "DECL_RAMP_P()" - that is easy to fix (i have a fix).

#define DECL_RAMP_P(NODE) \
  DECL_COROUTINE_P (NODE) && !DECL_RAMP_FN (NODE)

2. named_return_value_okay_p is false
  because want_nrvo_p() is false
because aggregate_value_p () is false
  because TYPE_EMPTY_P() is true for the return type.

Now ISTM that we can elide the conversion in the case that TYPE_EMPTY_P() ==
true (assuming that can_do_nrvo_p() would be true otherwise).

so... updating the condition to:

  if (DECL_RAMP_P (current_function_decl)
  && (named_return_value_okay_p
  || (can_do_nrvo_p (bare_retval, functype)
  && TYPE_EMPTY_P (functype
converted = true;

@jason - does this seem reasonable, or are there yet other cases we should
cater for?

[Bug target/110634] Incorrect RISC-V assembly with -fno-omit-frame-pointer

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

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

Vineet Gupta  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|WAITING |RESOLVED

--- Comment #8 from Vineet Gupta  ---
More specifically it is this commit which cured it.

commit 39663298b5934831a0125e12f113ebd83248c3be (HEAD ->
pr110634-stack-ops-fix)
Author: Yanzhang Wang 
Date:   Tue Jul 18 15:49:58 2023 +0800

RISCV: Add -m(no)-omit-leaf-frame-pointer support.

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_save_reg_p): Save ra for leaf
when enabling -mno-omit-leaf-frame-pointer
(riscv_option_override): Override omit-frame-pointer.
(riscv_frame_pointer_required): Save s0 for non-leaf function
(TARGET_FRAME_POINTER_REQUIRED): Override defination
* config/riscv/riscv.opt: Add option support.

[Bug c++/120465] New: Incorrect value_type for std::flat_map

[eligorkadaf at gmail dot com via Gcc-bugs]

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

Bug ID: 120465
   Summary: Incorrect value_type for std::flat_map
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eligorkadaf at gmail dot com
  Target Milestone: ---

As per https://eel.is/c++draft/flat.map.defn std::flat_map's value_type is
std::pair. Also, erase_if predicate is supposed to recieve pair as argument as
well: https://eel.is/c++draft/flat.map.erasure.
However, it seems that in libstdc++ implementation of std::flat_map it's
value_type is std::tuple.
Godbolt example: https://godbolt.org/z/qP11o4osq

[Bug libstdc++/120465] Incorrect value_type for std::flat_map

[eligorkadaf at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Eligor Kadaf  ---
The value_type seems to be as expected: https://godbolt.org/z/MWs531orx
However the example in comment above shall compile, yet it doesn't.
Fun fact is that if we change const auto& pair to const std::pair& pair it compiles.

[Bug c++/107600] New __is_destructible built-in

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions

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

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

--- Comment #22 from GCC Commits  ---
The master branch has been updated by Tobias Burnus :

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

commit r16-940-ga64a7f0a6cf8afcbad4bd6c9e1b0f1d4f2d5b958
Author: Tobias Burnus 
Date:   Wed May 28 22:35:03 2025 +0200

Fortran: gfc_simplify_{cospi,sinpi} - fix for MPFR < 4.2.0

gcc/fortran/ChangeLog:

PR fortran/113152
* simplify.cc (gfc_simplify_cospi, gfc_simplify_sinpi): Avoid using
mpfr_fmod_ui in the MPFR < 4.2.0 version.

[Bug libstdc++/104454] filesystem::canonical needs to strip trailing slash

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

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

--- Comment #4 from Jonathan Wakely  ---
Actually that's wrong because path("foo/bar/..").lexically_normal() is just
"foo" which ignores whether foo/bar is a symlink to somewhere else.

I think the right fix is to just not define _GLIBCXX_USE_REALPATH for AIX.

[Bug c++/120453] [16 regression] qcoro fails to build its tests (error: use of deleted function ... is implicitly deleted because the default definition would be ill-formed) since r16-773-ge06555a40c0

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

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

--- Comment #10 from Jason Merrill  ---
(In reply to Iain Sandoe from comment #9)
> OK so the reason this fails is because check_return_expr() concludes that we
> cannot do NRVO

Yes, because the implementation is permitted to use temporary objects for the
return, because the move ctor is trivial.

> and we try to do the bad conversion.

Because we're wrongly trying to call the deleted copy constructor when we
should call the move constructor, because the return is move-eligible.  That's
the bug.

[Bug analyzer/120466] New: Analyzer report for C++ 'std::stringbuf' instantiation

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

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

Bug ID: 120466
   Summary: Analyzer report for C++ 'std::stringbuf' instantiation
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

Given:

#include 
void f()
{
  std::stringbuf out_b;
}

..., '-fanalyzer' reports:

In file included from
[...]/build-gcc/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/c++allocator.h:33,
 from
[...]/build-gcc/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/allocator.h:46,
 from
[...]/build-gcc/x86_64-pc-linux-gnu/libstdc++-v3/include/string:45,
 from
[...]/build-gcc/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/locale_classes.h:42,
 from
[...]/build-gcc/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/ios_base.h:43,
 from
[...]/build-gcc/x86_64-pc-linux-gnu/libstdc++-v3/include/ios:46,
 from
[...]/build-gcc/x86_64-pc-linux-gnu/libstdc++-v3/include/istream:42,
 from
[...]/build-gcc/x86_64-pc-linux-gnu/libstdc++-v3/include/sstream:42,
 from [...]/a.C:1:
   
[...]/build-gcc/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/new_allocator.h:
In member function ‘void std::__new_allocator<_Tp>::deallocate(_Tp*, size_type)
[with _Tp = char]’:
   
[...]/build-gcc/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/new_allocator.h:172:66:
warning: ‘delete’ of ‘__p’ which points to memory on the stack [CWE-590]
[-Wanalyzer-free-of-non-heap]
  172 | _GLIBCXX_OPERATOR_DELETE(_GLIBCXX_SIZED_DEALLOC(__p, __n));
  |  ^
  ‘void f()’: events 1-3
|
|[...]/a.C:2:6:
|2 | void f()
|  |  ^
|  |  |
|  |  (1) entry to ‘f’
|3 | {
|4 |   std::stringbuf out_b;
|  |  ~
|  |  |
|  |  (2) region created on stack here
|5 | }
|  | ~ 
|  | |
|  | (3) calling
‘std::__cxx11::basic_stringbuf::~basic_stringbuf’ from ‘f’
|
+--> ‘std::__cxx11::basic_stringbuf::~basic_stringbuf()’: events
4-5
   |
  
|[...]/build-gcc/x86_64-pc-linux-gnu/libstdc++-v3/include/sstream:81:11:
   |   81 | class basic_stringbuf : public
basic_streambuf<_CharT, _Traits>
   |  |   ^~~
   |  |   |
   |  |   (4) entry to
‘std::__cxx11::basic_stringbuf::~basic_stringbuf’
   |  |   (5) calling
‘std::__cxx11::basic_string::~basic_string’ from
‘std::__cxx11::basic_stringbuf::~basic_stringbuf’
   |
   +--> ‘constexpr std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::~basic_string() [with _CharT = char; _Traits = std::char_traits;
_Alloc = std::allocator]’: events 6-7
  |
 
|[...]/build-gcc/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:895:7:
  |  895 |   ~basic_string()
  |  |   ^
  |  |   |
  |  |   (6) entry to
‘std::__cxx11::basic_string::~basic_string’
  |  896 |   { _M_dispose(); }
  |  | 
  |  |   |
  |  |   (7) calling
‘std::__cxx11::basic_string::_M_dispose’ from
‘std::__cxx11::basic_string::~basic_string’
  |
  +--> ‘constexpr void std::__cxx11::basic_string<_CharT,
_Traits, _Alloc>::_M_dispose() [with _CharT = char; _Traits =
std::char_traits; _Alloc = std::allocator]’: events 8-9
 |
 |  296 |   _M_dispose()
 |  |   ^~
 |  |   |
 |  |   (8) entry to
‘std::__cxx11::basic_string::_M_dispose’
 |  297 |   {
 |  298 | if (!_M_is_local())
 |  |  ~
 |  | |
 |  | (9) calling
‘std::__cxx11::basic_string::_M_is_local’ from
‘std::__cxx11::basic_string::_M_dispose’
 |
 +--> ‘constexpr bool
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::_M_is_local(

[Bug c/120353] Flex array struct referenced in the middle via type alias of forward declaration is not reported by -Wflex-array-member-not-at-end option

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

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

--- Comment #2 from qinzhao at gcc dot gnu.org ---
the following patch fixes the issue:
[opc@qinzhao-aarch64-ol8 c]$ git diff
diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index ad66d7d258b..4733287eaf8 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -9891,6 +9891,7 @@ finish_struct (location_t loc, tree t, tree fieldlist,
tree attributes,
   C_TYPE_VARIABLE_SIZE (x) = C_TYPE_VARIABLE_SIZE (t);
   C_TYPE_VARIABLY_MODIFIED (x) = C_TYPE_VARIABLY_MODIFIED (t);
   C_TYPE_INCOMPLETE_VARS (x) = NULL_TREE;
+  TYPE_INCLUDES_FLEXARRAY (x) = TYPE_INCLUDES_FLEXARRAY (t);
 }

   /* Update type location to the one of the definition, instead of e.g.

[Bug analyzer/120467] New: Analyzer: Diagnose cases where C++ 'std::basic_string_view::data()' is used as NUL-terminated string, but isn't

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

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

Bug ID: 120467
   Summary: Analyzer: Diagnose cases where C++
'std::basic_string_view::data()' is used as
NUL-terminated string, but isn't
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

I guess this is too much to ask for GCC's standard diagnostics, but could the
analyzer maybe detect this case, where C++ 'std::basic_string_view::data()' is
used as NUL-terminated string, but isn't?

As is noted on
:

> Unlike 'std::basic_string::data()' and string literals, 
> 'std::basic_string_view::data()' returns a pointer to a buffer that is not 
> necessarily null-terminated, for example a substring view (e.g. from 
> 'remove_suffix'). Therefore, it is typically a mistake to pass 'data()' to a 
> routine that takes just a 'const CharT*' and expects a null-terminated string.

Guess who just wrote code similar to this:

#include 
#include 

int main()
{
  /* Manually set up a buffer we can stream into, similar to 'cout <<
[...]', and print it at the end.  */
  std::stringbuf out_b;
  std::ostream out(&out_b);

  out << "Yo\n";

#if 0
  /* Terminate with a NUL.  Otherwise, we'd have to use:
 __builtin_printf("%.*s", (int) out_b_sv.size(), out_b_sv.data());
  */
  out << '\0';
#endif
  std::string_view out_b_sv = out_b.view();
  __builtin_printf("%s", out_b_sv.data());

  return 0;
}

(The analyzer currently only reports PR120466 "Analyzer report for C++
'std::stringbuf' instantiation".)

$ valgrind ./a.out 
[...] Memcheck, a memory error detector
[...] [...]
[...] Conditional jump or move depends on uninitialised value(s)
[...]at 0x484ED28: strlen (vg_replace_strmem.c:494)
[...]by 0x4C78D30: __vfprintf_internal (vfprintf-internal.c:1517)
[...]by 0x4C6279E: printf (printf.c:33)
[...]by 0x401232: main (s.C:19)

[Bug bootstrap/120464] [16 Regression] Build broken in ggc-page.cc on master since r16-852

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |16.0
   Priority|P3  |P1
Summary|Build broken in ggc-page.cc |[16 Regression] Build
   |on master   |broken in ggc-page.cc on
   ||master since r16-852

--- Comment #3 from Jakub Jelinek  ---
I think the problem is that
1212  /* Remove all free page groups, and release the storage.  */
1213  gp = &G.page_groups;
1214  while ((g = *gp) != NULL)
1215if (g->in_use == 0)
1216  {
1217*gp = g->next;
1218G.bytes_mapped -= g->alloc_size;
1219n1 += g->alloc_size;
1220free (g->allocation);
1221  }
1222else
1223  gp = &g->next;
walks all page groups each time, the first time it frees something, the second
time and onwards doesn't really do anything, but the second and following
freelists might still access those freed groups.

So, I'd go with:
2025-05-28  Jakub Jelinek  

PR bootstrap/120464
* ggc-page.cc (struct ggc_globals): Fix up comment formatting.
(find_free_list): Likewise.
(alloc_page): For defined(USING_MALLOC_PAGE_GROUPS) use
free_list->free_pages instead of G.free_pages.
(do_release_pages): Add n1 and n2 arguments, make them used.
Move defined(USING_MALLOC_PAGE_GROUPS) page group freeing to
release_pages and dumping of statistics as well.  Formatting fixes.
(release_pages): Adjust do_release_pages caller, move here
defined(USING_MALLOC_PAGE_GROUPS) page group freeing and dumping
of statistics.
(ggc_handle_finalizers): Fix up comment formatting.

--- gcc/ggc-page.cc.jj  2025-05-27 23:08:37.969726172 +0200
+++ gcc/ggc-page.cc 2025-05-28 22:59:27.206533376 +0200
@@ -426,7 +426,7 @@ static struct ggc_globals
   int dev_zero_fd;
 #endif

-  /* A cache of free system pages. Entry 0 is fallback.  */
+  /* A cache of free system pages.  Entry 0 is fallback.  */
   struct free_list free_lists[num_free_list];

 #ifdef USING_MALLOC_PAGE_GROUPS
@@ -787,7 +787,7 @@ find_free_list (size_t entry_size)
  return &G.free_lists[i];
}
 }
-  /* Fallback. Does this happen?  */
+  /* Fallback.  Does this happen?  */
   if (GATHER_STATISTICS)
 G.stats.fallback++;
   return &G.free_lists[0];
@@ -955,7 +955,7 @@ alloc_page (unsigned order)
   /* If we allocated multiple pages, put the rest on the free list.  */
   if (multiple_pages)
{
- struct page_entry *e, *f = G.free_pages;
+ struct page_entry *e, *f = free_list->free_pages;
  for (a = enda - G.pagesize; a != page; a -= G.pagesize)
{
  e = XCNEWVAR (struct page_entry, page_entry_size);
@@ -1073,10 +1073,10 @@ free_page (page_entry *entry)
 /* Release the free page cache for FREE_LIST to the system.  */

 static void
-do_release_pages (struct free_list *free_list)
+do_release_pages (struct free_list *free_list, size_t &n1, size_t &n2)
 {
-  size_t n1 = 0;
-  size_t n2 = 0;
+  (void) n1;
+  (void) n2;
 #ifdef USING_MADVISE
   page_entry *p, *start_p;
   char *start;
@@ -1089,7 +1089,7 @@ do_release_pages (struct free_list *free
  This allows other allocators to grab these areas if needed.
  This is only done on larger chunks to avoid fragmentation.
  This does not always work because the free_pages list is only
- approximately sorted. */
+ approximately sorted.  */

   p = free_list->free_pages;
   prev = NULL;
@@ -1104,7 +1104,7 @@ do_release_pages (struct free_list *free
 {
   len += p->bytes;
  if (!p->discarded)
- mapped_len += p->bytes;
+   mapped_len += p->bytes;
  newprev = p;
   p = p->next;
 }
@@ -1129,7 +1129,7 @@ do_release_pages (struct free_list *free
}

   /* Now give back the fragmented pages to the OS, but keep the address
- space to reuse it next time. */
+ space to reuse it next time.  */

   for (p = free_list->free_pages; p; )
 {
@@ -1149,10 +1149,10 @@ do_release_pages (struct free_list *free
 }
   /* Give the page back to the kernel, but don't free the mapping.
  This avoids fragmentation in the virtual memory map of the
-process. Next time we can reuse it by just touching it. */
+process.  Next time we can reuse it by just touching it.  */
   madvise (start, len, MADV_DONTNEED);
   /* Don't count those pages as mapped to not touch the garbage collector
- unnecessarily. */
+ unnecessarily.  */
   G.bytes_mapped -= len;
   n2 += len;
   while (start_p != p)
@@ -1195,7 +1195,6 @@ do_release_pages (struct free_list *free
 #endif
 #ifd

[Bug libstdc++/104454] filesystem::canonical needs to strip trailing slash

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

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

--- Comment #5 from Jonathan Wakely  ---
I did try this:

--- a/libstdc++-v3/src/c++17/fs_ops.cc
+++ b/libstdc++-v3/src/c++17/fs_ops.cc
@@ -164,6 +164,21 @@ fs::canonical(const path& p, error_code& ec)
   path result;
 #ifdef _GLIBCXX_FILESYSTEM_IS_WINDOWS
   const path pa = absolute(p.lexically_normal(), ec);
+#elif defined _AIX
+  // AIX realpath returns ENOENT for paths containing "//.."
+  path pa;
+  auto str = p.native();
+  auto pos = str.find("//..");
+  if (pos == str.npos)
+pa = absolute(p, ec);
+  else
+{
+  do {
+   str.erase(pos, 1);
+   pos = str.find("//..", pos);
+  } while (pos != str.npos);
+  pa = absolute(str, ec);
+}
 #else
   const path pa = absolute(p, ec);
 #endif

But it doesn't solve the trailing slash problem, so isn't a complete fix
anyway. Just avoiding realpath seems simpler.

[Bug libstdc++/120465] Incorrect value_type for std::flat_map

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-05-28
 Ever confirmed|0   |1
   Target Milestone|--- |15.2
 CC||ppalka at gcc dot gnu.org

--- Comment #2 from Jonathan Wakely  ---
--- a/libstdc++-v3/include/std/flat_map
+++ b/libstdc++-v3/include/std/flat_map
@@ -895,7 +895,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
  auto __guard = _M_make_clear_guard();
  auto __zv = views::zip(_M_cont.keys, _M_cont.values);
- auto __sr = ranges::remove_if(__zv, __pred);
+ auto __sr = ranges::remove_if(__zv, __pred,
+   [](const auto& e) {
+ return const_reference(e);
+   });
  auto __erased = __sr.size();
  erase(end() - __erased, end());
  __guard._M_disable();

[Bug libstdc++/120465] std::erase_if for std::flat_map calls predicate with incorrect type

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Eligor Kadaf from comment #0)
> However, it seems that in libstdc++ implementation of std::flat_map it's
> value_type is std::tuple.

No, the predicate is just called on the elements of a zip_view, and *that* has
a tuple as its value_type. The actual flat_map::value_type is correct, but is
not used by erase_if.

[Bug libstdc++/104454] filesystem::canonical needs to strip trailing slash

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

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

--- Comment #6 from Jonathan Wakely  ---
See also https://lists.gnu.org/archive/html/bug-make/2025-05/msg2.html

[Bug fortran/120431] SPREAD does not handle scalar argument and NCOPIES=-1 correctly

[kargls at comcast dot net via Gcc-bugs]

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

--- Comment #7 from kargls at comcast dot net ---
Created attachment 61543
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61543&action=edit
Fix for scalar source with ncopies < 0

This patch fixes the case of a scalar SOURCE and NCOPIES < 0.

Here are suitable ChangeLog entries.

2015-05-28  Steven G. Kargl  

PR fortran/120431
* m4/spread.m4: Fix scalar source case with ncopies < 0.
* generated/spread_c10.c: Regenerated.  
* generated/spread_c16.c: Ditto.
* generated/spread_c4.c: Ditto.
* generated/spread_c8.c: Ditto.
* generated/spread_i1.c: Ditto.
* generated/spread_i16.c: Ditto.
* generated/spread_i2.c: Ditto.
* generated/spread_i4.c: Ditto.
* generated/spread_i8.c: Ditto.
* generated/spread_r10.c: Ditto.
* generated/spread_r16.c: Ditto.
* generated/spread_r17.c: Ditto.
* generated/spread_r4.c: Ditto.
* generated/spread_r8.c: Ditto.


2015-05-28  Steven G. Kargl  

PR fortran/120431
* gfortran.dg/spread_scalar_zerosize.f90: New testcase.

[Bug c++/120453] [16 regression] qcoro fails to build its tests (error: use of deleted function ... is implicitly deleted because the default definition would be ill-formed) since r16-773-ge06555a40c0

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

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

--- Comment #13 from Jason Merrill  ---
In the original testcase we do choose to do NRVO, but this fails

  /* Don't check copy-initialization for NRV in a coroutine ramp; we
 implement this case as NRV, but it's specified as directly 
 initializing the return value from get_return_object().  */
  if (DECL_RAMP_FN (current_function_decl) && named_return_value_okay_p)
converted = true;

because DECL_RAMP_FN is null in the ramp.

So then we try to do the conversion, which fails because LazyTask doesn't have
a move constructor (because it has a user-declared destructor).

So I think DECL_RAMP_P is the only fix we need.

[Bug c++/120449] g++ -Wtype-limits without -P doesn't warn on unsigned compare to zero

[zmajeed at sbcglobal dot net via Gcc-bugs]

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

--- Comment #6 from Zartaj Majeed  ---
Thanks - the following works

diff --git a/gcc/c-family/c-common.cc b/gcc/c-family/c-common.cc
index f71cb2652d5..6d7ef006c6a 100644
--- a/gcc/c-family/c-common.cc
+++ b/gcc/c-family/c-common.cc
@@ -3318,7 +3318,7 @@ shorten_compare (location_t loc, tree *op0_ptr, tree
*op1_ptr,
 warning.  */
  tree folded_op0 = fold_for_warn (op0);
  bool warn =
-   warn_type_limits && !in_system_header_at (loc)
+   warn_type_limits && diagnostic_report_warnings_p(global_dc, loc)
&& !(TREE_CODE (folded_op0) == INTEGER_CST
 && !TREE_OVERFLOW (convert (c_common_signed_type (type),



g++ -c -Wtype-limits -std=c++20 -Wsystem-headers typelimits.cpp

In file included from requires_hosted.h:31,
 from semaphore:36,
 from typelimits.cpp:1:
semaphore_base.h: In constructor
‘std::__atomic_semaphore::__atomic_semaphore(std::__detail::__platform_wait_t)’:
semaphore_base.h:178:7: warning: comparison of unsigned expression in ‘>= 0’ is
always true [-Wtype-limits]
  178 |   __glibcxx_assert(__count >= 0 && __count <= _S_max);
  |   ^~~~

Though position of underline is off



Underline is wrong and confusing with --save-temps

g++ -c -Wtype-limits -std=c++20 -Wsystem-headers --save-temps typelimits.cpp

In file included from semaphore:39,
 from typelimits.cpp:1:
semaphore_base.h: In constructor
‘std::__atomic_semaphore::__atomic_semaphore(std::__detail::__platform_wait_t)’:
semaphore_base.h:178:47: warning: comparison of unsigned expression in ‘>= 0’
is always true [-Wtype-limits]
  178 |   __glibcxx_assert(__count >= 0 && __count <= _S_max);
  |   ^~~~



Underline is correctly positioned with -P

g++ -c -Wtype-limits -std=c++20 -Wsystem-headers --save-temps -P typelimits.cpp

typelimits.ii: In constructor
‘std::__atomic_semaphore::__atomic_semaphore(std::__detail::__platform_wait_t)’:
typelimits.ii:10140:47: warning: comparison of unsigned expression in ‘>= 0’ is
always true [-Wtype-limits]
10140 |   do { if (__builtin_expect(!bool(__count >= 0 && __count <=
_S_max), false)) std::__glibcxx_assert_fail("semaphore_base.h", 178,
__PRETTY_FUNCTION__, "__count >= 0 && __count <= _S_max"); } while (false);
  |   ^~~~

[Bug c++/120449] g++ -Wtype-limits without -P doesn't warn on unsigned compare to zero

[zmajeed at sbcglobal dot net via Gcc-bugs]

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

--- Comment #7 from Zartaj Majeed  ---
Should I open a separate bug for libstdc++ for the warning?

[Bug fortran/119856] Missing commas in I/O formats not diagnosed by default at compile time.

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Jerry DeLisle :

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

commit r16-948-gbd9d8f9b294d9aef8799227234bd09e26a9a6640
Author: Jerry DeLisle 
Date:   Wed May 28 21:04:13 2025 -0700

Fortran: Fix ChangeLog.

PR fortran/119856

gcc/fortran/ChangeLog:

* ChangeLog: Fix PR number in log.

[Bug c++/120449] g++ -Wtype-limits without -P doesn't warn on unsigned compare to zero

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Zartaj Majeed from comment #6)
> Underline is wrong and confusing with --save-temps

Don't use -save-temps if you want decent diagnostic/column info.

[Bug c++/120453] [16 regression] qcoro fails to build its tests (error: use of deleted function ... is implicitly deleted because the default definition would be ill-formed) since r16-773-ge06555a40c0

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

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

--- Comment #7 from Iain Sandoe  ---
(In reply to Andrew Pinski from comment #6)
> Interesting if I change the lambda into a normal function:
> ```
> auto coro() ->LazyTask
> {
> co_await []() -> Task {}();
> }
> ```
> 
> GCC 15 rejects it and then ICEs:
> ```
> : In function 'QCoro::LazyTask QCoro::coro()':
> :81:39: error: wrong number of template arguments (1, should be 2)
>81 | co_await []() -> Task {}();
>   |   ^
> :6:46: note: provided for 'template struct
> std::coroutine_traits'
> 6 | template  struct coroutine_traits :
> _Result {};
>   |  ^~~~
> :81:9: error: cannot instantiate 'coroutine traits'
>81 | co_await []() -> Task {}();
>   | ^~~~
> ```

this second observation is possibly a dup; (but need to check)
with lambdas we reach finish_function before the closure is finished - and IIRC
that puts us into a problem with complete_type_or_else.  I had a discussion
with Jason about that and have on my TODO to attempt to alter the finishing of
the closure object before the finish_function for the lambda (since the closure
object content is actually known at that point).

[Bug c/68612] Const-compatibility in C

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||lavr at ncbi dot nlm.nih.gov

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

[Bug c/120455] char** and -Wincompatible-pointer-types

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug c++/120453] [16 regression] qcoro fails to build its tests (error: use of deleted function ... is implicitly deleted because the default definition would be ill-formed) since r16-773-ge06555a40c0

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-05-28

--- Comment #8 from Iain Sandoe  ---
For the reduced test case (with a couple of small tweaks to avoid miscellaneous
warnings).
  * frame #0: 0x000102f388b4 cc1plus`error(gmsgid="use of deleted function
%qD") at diagnostic-global-context.cc:393:25
frame #1: 0x0001001d0ce5 cc1plus`mark_used(decl=0x00010c301800,
complain=3) at decl2.cc:6352:9
frame #2: 0x00010002f37e
cc1plus`::build_over_call(cand=0x000130008110, flags=5, complain=3) at
call.cc:10332:14
frame #3: 0x00010003786b
cc1plus`build_new_method_call(instance=0x000108bfb7e0,
fns=0x000108bfbd80, args=0x00030b1f8790,
conversion_path=0x000108a0e820, flags=5, fn_p=0x,
complain=3) at call.cc:12188:31
frame #4: 0x000100035641
cc1plus`build_special_member_call(instance=0x000108bfb7e0,
name=0x000108a23840, args=0x00030b1f8790, binfo=0x000108a0e820,
flags=5, complain=3) at call.cc:11671:31
frame #5: 0x0001000263b0 cc1plus`::build_temp(expr=0x000108bfb7a0,
type=0x000108bca738, flags=5, diagnostic_kind=0x00030b1f8960,
complain=3) at call.cc:8428:36
frame #6: 0x00010002a1c7
cc1plus`::convert_like_internal(convs=0x000130008040,
expr=0x000108bfb7a0, fn=0x, argnum=0,
issue_conversion_warnings=true, c_cast_p=false, nested_p=false, complain=3) at
call.cc:9171:25
frame #7: 0x00010002af6e
cc1plus`::convert_like(convs=0x000130008040, expr=0x000108bfb7a0,
fn=0x, argnum=0, issue_conversion_warnings=true,
c_cast_p=false, nested_p=false, complain=3) at call.cc:9416:32
frame #8: 0x00010002afe4
cc1plus`::convert_like(convs=0x000130008040, expr=0x000108bfb7a0,
complain=3) at call.cc:9429:23
frame #9: 0x00010003fbb7
cc1plus`perform_implicit_conversion_flags(type=0x000108bca738,
expr=0x000108bfb7a0, complain=3, flags=5) at call.cc:14007:27
frame #10: 0x00010053f83d
cc1plus`convert_for_initialization(exp=0x,
type=0x000108bca738, rhs=0x000108bfb7a0, flags=5, errtype=ICR_RETURN,
fndecl=0x, parmnum=0, complain=3) at typeck.cc:10662:46
frame #11: 0x00010054469f
cc1plus`check_return_expr(retval=0x000108bfb7a0,
no_warning=0x00030b1f8d67, dangling=0x00030b1f8d66) at
typeck.cc:11477:4
frame #12: 0x00010049147a
cc1plus`finish_return_stmt(expr=0x000108bf08e8) at semantics.cc:1588:28
frame #13: 0x0001000ef16b
cc1plus`cp_coroutine_transform::build_ramp_function(this=0x000107704aa0) at
coroutines.cc:5300:22




but ...
  11474  case that functype is smaller than the valtype.  */
   11475  if (!converted)
   11476retval = convert_for_initialization
-> 11477  (NULL_TREE, functype, retval, flags, ICR_RETURN,
NULL_TREE, 0,
   11478   tf_warning_or_error);



(lldb) p coro_get_ramp_function (current_function_decl)
(tree) $3 = nullptr
(lldb) p named_return_value_okay_p
(bool) $4 = false

So something is amiss earlier in the code - we are attempting a conversion
which we should not be.

[Bug c/120455] char** and -Wincompatible-pointer-types

[lavr at ncbi dot nlm.nih.gov via Gcc-bugs]

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

--- Comment #5 from lavr at ncbi dot nlm.nih.gov ---
Wow, it's a ten year old problem now is breaking the builds because of the
warning to error promotion!  The latter should not have been done with the
outstanding problem like that.

[Bug c/120455] char** and -Wincompatible-pointer-types

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

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

--- Comment #6 from Sam James  ---
(In reply to lavr from comment #5)
> Wow, it's a ten year old problem now is breaking the builds because of the
> warning to error promotion!  The latter should not have been done with the
> outstanding problem like that.

The discussion in the bug is clear that it would be an *extension*.

[Bug c/68612] Const-compatibility in C

[lavr at ncbi dot nlm.nih.gov via Gcc-bugs]

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

--- Comment #9 from lavr at ncbi dot nlm.nih.gov ---
GCC14 is breaking builds now, because the warning has been promoted to error,
with this problem still unresolved.

[Bug c/120455] char** and -Wincompatible-pointer-types

[lavr at ncbi dot nlm.nih.gov via Gcc-bugs]

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

--- Comment #7 from lavr at ncbi dot nlm.nih.gov ---
> it would be an *extension*.

An extension to what?  Other compilers allow the const qualifier conversion,
and it's logically correct (and it is correct in C++, like shown).

[Bug libstdc++/104454] filesystem::canonical needs to strip trailing slash

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2025-05-28

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> This may not be worth fixing, because AIX realpath is broken anyway

It can't handle paths containing "//":

#include 
#include 
#include 
#include 

char buf[512];

void realpath_or_bust(const char* s)
{
  const char* p = realpath(s, buf);
  if (p)
puts(p);
  else
perror(s);
}

int main()
{
  rmdir("testdir/foo");
  rmdir("testdir");
  mkdir("testdir", S_IRWXU);
  mkdir("testdir/foo", S_IRWXU);
  realpath_or_bust("testdir/foo//..");
  realpath_or_bust("testdir/foo//../foo");
}

This prints:

/home/jwakely/tmp/testdir/foo
testdir/foo//../foo: No such file or directory

[Bug libstdc++/104454] filesystem::canonical needs to strip trailing slash

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

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

--- Comment #3 from Jonathan Wakely  ---
This fixes the FAIL for 27_io/filesystem/operations/weakly_canonical.cc

--- a/libstdc++-v3/src/c++17/fs_ops.cc
+++ b/libstdc++-v3/src/c++17/fs_ops.cc
@@ -162,7 +162,7 @@ fs::path
 fs::canonical(const path& p, error_code& ec)
 {
   path result;
-#ifdef _GLIBCXX_FILESYSTEM_IS_WINDOWS
+#if defined _GLIBCXX_FILESYSTEM_IS_WINDOWS || defined _AIX
   const path pa = absolute(p.lexically_normal(), ec);
 #else
   const path pa = absolute(p, ec);


but not for 27_io/filesystem/operations/canonical.cc so we might still need to
strip the trailing slash from the result of canonical.

[Bug libfortran/116400] [15/16 Regression] Regenerated files are no longer written to the source directory

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

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

--- Comment #13 from Iain Sandoe  ---
(In reply to Francois-Xavier Coudert from comment #12)
> Created attachment 61532 [details]
> Regeneration script
> 
> Attached is a shell script, to be placed in libgfortran/, that can be run in
> that directory to regenerated all files. If people agree with this approach,
> I would then remove the hackish "maintainer mode" code from
> libgfortran/Makefile.am, leading to behavior that is identical to other GCC
> runtime libraries:
>   - maintainer mode regenerates automake/autoconf files
>   - regeneration of library code is done manually by developers, through a
> script
>  
> I think this is definitely more robust. Let me know what you think.
> 
> 
> 
> Applying that script should lead to no difference, but it does not :) it
> leads to a lot of whitespace changes, demonstrating why we need to change
> the current situation is: those whitespace changes, introduced in the m4
> files in this commit
> 
> commit 5e918a4db9e4a5bdbeafec6881fa8b22a55d3789
> Author: Thomas Koenig 
> Date:   2024-09-24 21:59:10 +0200
> 
> * m4/ifunction.m4: Whitespace fix.
> 
> has not been included in the regenerated files, almost one year later.

cool ...
what might be nice is to share the list by including it in both the regen
script and the Makefile... that seems like it should be possible?

[Bug libstdc++/120432] flat_map operator[] is broken for const lvalue keys

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

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

--- Comment #3 from Patrick Palka  ---
(In reply to Arthur O'Dwyer from comment #2)
> But I think a better answer in this case is "because using
> a volatile index *will not actually compile*, so flat_map shouldn't
> gratuitously advertise that signature to SFINAE."
> https://godbolt.org/z/bdTK7nPKG
Good point.. I think this also means the standard transparent-compare overload
is underconstrained: https://godbolt.org/z/354GTTsxG

[Bug libstdc++/99832] std::chrono::system_clock::to_time_t needs ABI tag for 32-bit time_t

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

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

--- Comment #12 from Jonathan Wakely  ---
Also, I don't think we need the abi tag from from_time_t, because the mangled
name of that function already depends on the type of time_t. The problem with
to_time_t is that the mangled name does not depend on the return type for a
non-template function. But it does depend on the parameter types, so
system_clock::from_time_t(time_t) already changes mangled name when time_t
changes.

[Bug target/120450] GCN offloading: ICE 'during RTL pass: expand', 'in assign_temp, at function.cc:990' for C++ 'std::flat_map', 'std::flat_multimap'

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-reduction

--- Comment #2 from Richard Biener  ---
also needs reduction to not require the standard library.

[Bug middle-end/118694] OpenMP: target/metadirective/teams directive nesting gives error

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

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

--- Comment #14 from GCC Commits  ---
The releases/gcc-15 branch has been updated by Tobias Burnus
:

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

commit r15-9740-gc38760cdb2ac21f690647e965acc0eaba3250f6d
Author: Tobias Burnus 
Date:   Wed May 28 15:14:14 2025 +0200

libgomp.fortran/metadirective-1.f90: Expect 'error:' for nvptx compile
[PR118694]

This should have been part of commit r16-838-gb3d07ec7ac2ccd or
r16-883-g5d6ed6d604ff94 - all showing the same issue:
'!$omp target' followed by a metadirective with 'teams'; if
the metadirective cannot be early resolved, a diagnostic
error is shown about using directives between 'target' and
'teams'.

While the message is misleading, the problem is that the
host invokes 'target' differently when 'teams' is present;
in this case, host fallback + amdgcn offload require the
no-teams case, nvptx offload the teams case such that it
only can be resolved at runtime.

Mark the error as 'dg-bogus + xfail' to silence the FAIL,
when nvptx offloading is compiled for. (If not, the
metadirective can be resolved early during compilation.)

libgomp/ChangeLog:

PR middle-end/118694
* testsuite/libgomp.fortran/metadirective-1.f90: xfail when
compiling (also) for nvptx offloading as an error is then expected.

(cherry picked from commit 5b2e7afb135aa10e17e51b891d4b2c85ee541ade)

[Bug c/120455] char** and -Wincompatible-pointer-types

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

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

--- Comment #1 from Sam James  ---
https://x.com/__phantomderp/status/1804967387864691052

[Bug c++/120453] [16 regression] qcoro fails to build its tests (error: use of deleted function ... is implicitly deleted because the default definition would be ill-formed) since r16-773-ge06555a40c0

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

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

--- Comment #6 from Andrew Pinski  ---
Interesting if I change the lambda into a normal function:
```
auto coro() ->LazyTask
{
co_await []() -> Task {}();
}
```

GCC 15 rejects it and then ICEs:
```
: In function 'QCoro::LazyTask QCoro::coro()':
:81:39: error: wrong number of template arguments (1, should be 2)
   81 | co_await []() -> Task {}();
  |   ^
:6:46: note: provided for 'template struct
std::coroutine_traits'
6 | template  struct coroutine_traits : _Result
{};
  |  ^~~~
:81:9: error: cannot instantiate 'coroutine traits'
   81 | co_await []() -> Task {}();
  | ^~~~
```