[Bug tree-optimization/111873] [12/13/14/15/16 Regression] runtime Segmentation fault with '-O3 -fno-code-hoisting -fno-early-inlining -fno-tree-fre -fno-tree-pre' since r12-434-g93f8cb4965cebe

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

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

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

[Bug target/120242] [15/16 regression] RISC-V: Miscompile at -O[23] since r15-9239-g4d7a634f6d4

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Last reconfirmed||2025-05-13
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||law at gcc dot gnu.org,
   ||vineetg at rivosinc dot com

[Bug target/120242] [15/16 regression] RISC-V: Miscompile at -O[23] since r15-9239-g4d7a634f6d4

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC|rsandifo at gcc dot gnu.org|

--- Comment #2 from Jeffrey A. Law  ---
So after 2 years, it's finally come back to bite us...  The real regression is
from this:



Vineet/Robin, y'all will certainly remember this gem:

commit 8eb9cdd142182aaa3ee39750924bc0a0491236c3
Author: Vineet Gupta 
Date:   Mon Oct 16 21:59:09 2023 -0600

expr: don't clear SUBREG_PROMOTED_VAR_P flag for a promoted subreg
[target/111466]

RISC-V suffers from extraneous sign extensions, despite/given the ABI
guarantee that 32-bit quantities are sign-extended into 64-bit registers,
meaning incoming SI function args need not be explicitly sign extended
(so do SI return values as most ALU insns implicitly sign-extend too.)
[ ... ]


We've got a bogus promoted state which is interacting badly with combine.  We
weren't ever to find a test for the old code back when we dug into this
problem, but we've got one now

[Bug modula2/120253] Error message column numbers should start at 1 not 0

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

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

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

https://gcc.gnu.org/g:9a485b83e177cb742be17faf20ac5cc7db14fee3

commit r16-601-g9a485b83e177cb742be17faf20ac5cc7db14fee3
Author: Gaius Mulley 
Date:   Tue May 13 22:54:33 2025 +0100

PR modula2/120253: Error message column numbers should start at 1 not 0

This patch ensures that column numbers start at 1 rather than 0.

gcc/m2/ChangeLog:

PR modula2/120253
* m2.flex (FIRST_COLUMN): New define.
(updatepos): Remove commented code.
(consumeLine): Assign column to FIRST_COLUMN.
(initLine): Ditto.
(m2flex_GetColumnNo): Return FIRST_COLUMN if currentLine is NULL.
(m2flex_GetLineNo): Rewrite for positive logic.
(m2flex_GetLocation): Ditto.

Signed-off-by: Gaius Mulley 

[Bug modula2/120253] Error message column numbers should start at 1 not 0

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #3 from Gaius Mulley  ---
Closing.

[Bug tree-optimization/111873] [12/13/14/15/16 Regression] runtime Segmentation fault with '-O3 -fno-code-hoisting -fno-early-inlining -fno-tree-fre -fno-tree-pre' since r12-434-g93f8cb4965cebe

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

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

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

[Bug ipa/120044] [12/13/14/15/16 Regression] wrong code at -O1 and above with "-fno-early-inlining -fno-tree-fre -fno-tree-pre -fno-code-hoisting" on x86_64-linux-gnu

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

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

Martin Jambor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #5 from Martin Jambor  ---
This actually turns out to be a duplicate of PR 111873.

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

[Bug c++/58091] Non-ambiguous member lookup rejected

[herring at lanl dot gov via Gcc-bugs]

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

S. Davis Herring  changed:

   What|Removed |Added

 CC||herring at lanl dot gov

--- Comment #6 from S. Davis Herring  ---
The lookup is ambiguous: generally a < forces ordinary lookup to take place,
even in contexts like declarator-ids where sometimes other possibilities apply
(like defining a hidden friend).  (ADL can still rescue "f<0>(x)", but only
because nowadays there is a rule to form a template-id there if f isn't found
by lookup at all.)  The language does not in general filter lookup
possibilities by which results would work in the syntactic context.

[Bug c++/120267] New: incorrectly ambiguous lookup depending on base class order

[herring at lanl dot gov via Gcc-bugs]

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

Bug ID: 120267
   Summary: incorrectly ambiguous lookup depending on base class
order
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: herring at lanl dot gov
  Target Milestone: ---

GCC incorrectly diagnoses D2::c as ambiguous in the following
:

struct I {using c=int;};
struct F {using c=float;};
struct both : F,I {using F::c;};
struct F2 : F {};  // just to avoid warnings

struct D1 : both,F2 {};
struct D2 : F2,both {};

D1::c x1;
D2::c x2;

Obviously the order of base classes isn't supposed to enter in these
considerations.

[Bug tree-optimization/120268] New: Missed removing loop of setting zero when dereference pointer (memset)

[kaelfandrew at gmail dot com via Gcc-bugs]

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

Bug ID: 120268
   Summary: Missed removing loop of setting zero when dereference
pointer (memset)
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kaelfandrew at gmail dot com
  Target Milestone: ---

Created attachment 61420
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61420&action=edit
C code

When flags are -O3,
f1() compares if ptr[i] is zero before setting it to zero and f0() memset it to
zero.

When flags are -O3 and -march=icelake-client, f1() assembly is now about 150
lines with many je/jbe/jmp instructions.

LLVM is also affected.

gcc -v

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/16/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-16.0./work/gcc-16.0./configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/16
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/16/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/16
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/16/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/16/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/16/include/g++-v16
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/16/python
--enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror
--with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=yes,extra
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 16.0. p,
commit 05d9c70131be267bfe5b36e663acda8729da6456' --with-gcc-major-version-only
--enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point
--enable-targets=all --enable-offload-defaulted
--enable-offload-targets=nvptx-none --enable-libgomp --disable-libssp
--disable-libada --enable-cet --disable-systemtap
--disable-valgrind-annotations --disable-vtable-verify --disable-libvtv
--with-zstd --with-isl --disable-isl-version-check --enable-default-pie
--enable-host-pie --enable-host-bind-now --enable-default-ssp
--disable-fixincludes --with-gxx-libcxx-include-dir=/usr/include/c++/v1
--with-build-config='bootstrap-lto bootstrap-cet'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 16.0.0 20250423 (experimental)
e9a81addd5b7d018e173fa8d59aafc2f84e41d8b (Gentoo 16.0. p, commit
05d9c70131be267bfe5b36e663acda8729da6456)

[Bug fortran/113413] ATAND(Y,X) is unsupported

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

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

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

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

commit r16-602-gb239e9cf98ca9238e61e01864ab4dbb5c7f57ce2
Author: Yuao Ma 
Date:   Mon May 12 23:07:37 2025 +0800

fortran: map atand(y, x) to atan2d(y, x) [PR113413]

According to the Fortran standard, atand(y, x) is equivalent to atan2d(y,
x).
However, the current atand(y, x) function produces an error. This patch
includes the necessary intrinsic mapping, related test, and intrinsic
documentation.
The minor comment change in intrinsic.cc is cherry-picked from Steve's
previous
work.

PR fortran/113413 - ATAND(Y,X) is unsupported

PR fortran/113413

gcc/fortran/ChangeLog:

* intrinsic.cc (do_check): Minor doc polish.
(add_functions): Add atand(y, x) mapping.
* intrinsic.texi: Update atand example.

gcc/testsuite/ChangeLog:

* gfortran.dg/dec_math.f90: Add atand(y, x) testcase.

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

[Bug fortran/113413] ATAND(Y,X) is unsupported

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

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

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

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

commit r16-603-gabe8cd9ba6bf8581fd4e4f23c75a15eec276cc00
Author: Tobias Burnus 
Date:   Wed May 14 00:53:50 2025 +0200

gfortran.dg/dec_math.f90: Add comment regarding F2023 [PR113413]

gcc/testsuite/ChangeLog:

PR fortran/113413
* gfortran.dg/dec_math.f90: Add comment that degree
functions are part of F2023.

[Bug fortran/113413] ATAND(Y,X) is unsupported

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

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Tobias Burnus  ---
Should be FIXED on mainline (GCC 16)
→ close.

[Bug fortran/108577] [meta-bug] Fortran 2023 support

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

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

Bug 113413 Summary: ATAND(Y,X) is unsupported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113413

   What|Removed |Added

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

[Bug libstdc++/120198] [14/15 Regression] std::scoped_lock disabled for non-gthread environments (such as arm-none-eabi)

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
Fixed for 14.3 and 15.2, thanks for the report.

[Bug tree-optimization/120254] wrong code at -O3 on x86_64-pc-linux-gnu

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2025-05-13
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||needs-bisection, wrong-code

--- Comment #1 from Richard Biener  ---
-fno-loop-interchange also fixes it and -fdisable-tree-vect does not, disabling
vectorization also disables the interchange (likely due to different PRE).

So this looks like a bug in loop interchange (IIRC there are some other bugs
about loop interchange).

[Bug libstdc++/120198] [14/15 Regression] std::scoped_lock disabled for non-gthread environments (such as arm-none-eabi)

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

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

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

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

commit r14-11769-gc50b8d550d20e42e88b70f0a6e0f6798e30ddcb2
Author: Jonathan Wakely 
Date:   Fri May 9 17:50:52 2025 +0100

libstdc++: Restore std::scoped_lock for non-gthreads targets [PR120198]

This was a regression introduced with using version.def to define
feature test macros (r14-3248-g083b7f2833d71d). std::scoped_lock doesn't
need to depend on gthreads and so can be defined unconditionally, even
for freestanding.

libstdc++-v3/ChangeLog:

PR libstdc++/120198
* include/bits/version.def (scoped_lock): Do not depend on
gthreads or hosted.
* include/bits/version.h: Regenerate.
* include/std/mutex (scoped_lock): Update comment.
* testsuite/30_threads/scoped_lock/requirements/typedefs.cc:
Remove dg-require-gthreads and use custom lockable type instead
of std::mutex. Check that typedef is only present for a single
template argument.

Reviewed-by: Tomasz KamiÅski 
(cherry picked from commit bdd2753f5f021a15a6c4ef02565356985fea1300)

[Bug target/120256] New: [16 Regression] 4% slowdown of 454.calculix on aarch64

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

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

Bug ID: 120256
   Summary: [16 Regression] 4% slowdown of 454.calculix on aarch64
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Keywords: missed-optimization, needs-bisection
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pheeck at gcc dot gnu.org
Blocks: 26163
  Target Milestone: ---
  Host: aarch64-gnu-linux
Target: aarch64-gnu-linux

As seen here

https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=574.170.0

there was a 5% exec time slowdown of the 454.calculix SPEC 2006 benchmark
between commits

r16-433-g2c46a74d4707bd
r16-457-g49c44911df72f5

when run with -O2 -march=generic -flto on an Ampere Altra (Neoverse N1)
machine.

This is a regression against GCC 15. See the comparison
here:

https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=1035.170.0&plot.1=1220.170.0&plot.2=574.170.0&;


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug fortran/120191] Functions minloc() and maxloc() ignore the "back" parameter when "kind" is present.

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r16-591-gec249be3c287c6f1dfb328712ac9c39e6fa95eca
Author: Jakub Jelinek 
Date:   Tue May 13 14:14:55 2025 +0200

fortran: Fix up minloc/maxloc lowering [PR120191]

We need to drop the kind argument from what is passed to the
library, but need to do it not only when one uses the argument name
for it (so kind=4 etc.) but also when one passes all the arguments
to the intrinsics.

The following patch uses what gfc_conv_intrinsic_findloc uses,
which looks more efficient and cleaner, we already set automatic
vars to point to the kind and back actual arguments, so we can just
free/clear expr on the former and set name to "%VAL" on the latter.

And similarly clears dim argument for the BT_CHARACTER case when using
maxloc2/minloc2, again regardless of whether it was named or not.

2025-05-13  Jakub Jelinek  
Daniil Kochergin  
Tobias Burnus  

PR fortran/120191
* trans-intrinsic.cc (strip_kind_from_actual): Remove.
(gfc_conv_intrinsic_minmaxloc): Don't call strip_kind_from_actual.
Free and clear kind_arg->expr if non-NULL.  Set back_arg->name to
"%VAL" instead of a loop looking for last argument.  Remove actual
variable, use array_arg instead.  Free and clear dim_arg->expr if
non-NULL for BT_CHARACTER cases instead of using a loop.

* gfortran.dg/pr120191_1.f90: New test.

[Bug fortran/120191] Functions minloc() and maxloc() ignore the "back" parameter when "kind" is present.

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

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

--- Comment #10 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:781cfc454b8dc24952fe7f4c5c409296dca505e1

commit r16-593-g781cfc454b8dc24952fe7f4c5c409296dca505e1
Author: Jakub Jelinek 
Date:   Tue May 13 14:19:25 2025 +0200

libfortran: Fix up _gfortran_s{max,min}loc1_{4,8,16}_s{1,4} [PR120191]

There is a bug in _gfortran_s{max,min}loc1_{4,8,16}_s{1,4} which the
following testcase shows.
The functions return but then crash in the caller.
Seems that is because buffer overflows, I believe those functions for
if (mask == NULL || *mask) condition being false are supposed to fill in
the result array with all zeros (or allocate it and fill it with zeros).
My understanding is the result array in that case is integer(kind={4,8,16})
and should have the extents the character input array has.
The problem is that it uses * string_len in the extent multiplication:
  extent[n] = GFC_DESCRIPTOR_EXTENT(array,n) * string_len;
and
  extent[n] =
GFC_DESCRIPTOR_EXTENT(array,n + 1) * string_len;
which is I guess fine and desirable for the extents of the character array,
but not for the extents of the destination array.  Yet the code uses
that extent array for that purpose (and no other purposes).
Here it uses it to set the dimensions for the case where it needs to
allocate (as well as size):
  for (n = 0; n < rank; n++)
{
  if (n == 0)
str = 1;
  else
str = GFC_DESCRIPTOR_STRIDE(retarray,n-1) * extent[n-1];
  GFC_DIMENSION_SET(retarray->dim[n], 0, extent[n] - 1, str);
}
Here it uses it for bounds checking of the destination:
  if (unlikely (compile_options.bounds_check))
{
  for (n=0; n < rank; n++)
{
  index_type ret_extent;

  ret_extent = GFC_DESCRIPTOR_EXTENT(retarray,n);
  if (extent[n] != ret_extent)
runtime_error ("Incorrect extent in return value of"
   " MAXLOC intrinsic in dimension %ld:"
   " is %ld, should be %ld", (long int) n + 1,
   (long int) ret_extent, (long int)
extent[n]);
}
}
and here to find out how many retarray elements to actually fill in each
dimension:
  while(1)
{
  *dest = 0;
  count[0]++;
  dest += dstride[0];
  n = 0;
  while (count[n] == extent[n])
{
  /* When we get to the end of a dimension, reset it and increment
 the next dimension.  */
  count[n] = 0;
  /* We could precalculate these products, but this is a less
 frequently used path so probably not worth it.  */
  dest -= dstride[n] * extent[n];
Seems maxloc1s.m4 and minloc1s.m4 are the only users of ifunction-s.m4,
so we can change SCALAR_ARRAY_FUNCTION in there without breaking anything
else.

2025-05-13  Jakub Jelinek  

PR fortran/120191
* m4/ifunction-s.m4 (SCALAR_ARRAY_FUNCTION): Don't multiply
GFC_DESCRIPTOR_EXTENT(array,) by string_len.
* generated/maxloc1_4_s1.c: Regenerate.
* generated/maxloc1_4_s4.c: Regenerate.
* generated/maxloc1_8_s1.c: Regenerate.
* generated/maxloc1_8_s4.c: Regenerate.
* generated/maxloc1_16_s1.c: Regenerate.
* generated/maxloc1_16_s4.c: Regenerate.
* generated/minloc1_4_s1.c: Regenerate.
* generated/minloc1_4_s4.c: Regenerate.
* generated/minloc1_8_s1.c: Regenerate.
* generated/minloc1_8_s4.c: Regenerate.
* generated/minloc1_16_s1.c: Regenerate.
* generated/minloc1_16_s4.c: Regenerate.

* gfortran.dg/pr120191_3.f90: New test.

[Bug fortran/120191] Functions minloc() and maxloc() ignore the "back" parameter when "kind" is present.

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

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

--- Comment #9 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:482f2192d4ef6af55acae2dc3e0df00b8487cc7d

commit r16-592-g482f2192d4ef6af55acae2dc3e0df00b8487cc7d
Author: Jakub Jelinek 
Date:   Tue May 13 14:18:10 2025 +0200

libfortran: Fix up _gfortran_s{max,min}loc2_{4,8,16}_s{1,4} [PR120191]

I've tried to write a testcase for the BT_CHARACTER maxloc/minloc with
named
or unnamed arguments and indeed the just posted patch fixed the arguments
in there in multiple cases to match what the library expects.
But the testcase still fails, due to library problems.

One dealt with in this patch are _gfortran_s{max,min}loc2_{4,8,16}_s{1,4}
functions.  Those are trivial wrappers around
_gfortrani_{max,min}loc2_{4,8,16}_s{1,4} which should call those functions
if the scalar mask is true and just return 0 otherwise.
The two bugs I see there is that the back, len arguments are swapped,
which means that it always acts as back=.true. and for len will use
character length of 1 or 0 instead of the desired one.
The _gfortrani_{max,min}loc2_{4,8,16}_s{1,4} functions have prototypes like
GFC_INTEGER_4
maxloc2_4_s1 (gfc_array_s1 * const restrict array, GFC_LOGICAL_4 back,
gfc_charlen_type len)
so back comes before len, ditto for the
GFC_INTEGER_4
smaxloc2_4_s1 (gfc_array_s1 * const restrict array,
   GFC_LOGICAL_4 *mask, GFC_LOGICAL_4 back, gfc_charlen_type
len)
The other problem is that it was just testing if (mask).  In my limited
Fortran understanding that means that the optional argument mask was
supplied but nothing about its actual value.  Other scalar mask generated
routines use if (mask == NULL || *mask) as the condition when to call the
non-masked function, i.e. when mask is not supplied (then it should act
like
.true. mask) or when it is supplied and evaluates to .true.).

2025-05-13  Jakub Jelinek  

PR fortran/120191
* m4/maxloc2s.m4: For smaxloc2 call maxloc2 if mask is NULL or
*mask.
Swap back and len arguments.
* m4/minloc2s.m4: Likewise.
* generated/maxloc2_4_s1.c: Regenerate.
* generated/maxloc2_4_s4.c: Regenerate.
* generated/maxloc2_8_s1.c: Regenerate.
* generated/maxloc2_8_s4.c: Regenerate.
* generated/maxloc2_16_s1.c: Regenerate.
* generated/maxloc2_16_s4.c: Regenerate.
* generated/minloc2_4_s1.c: Regenerate.
* generated/minloc2_4_s4.c: Regenerate.
* generated/minloc2_8_s1.c: Regenerate.
* generated/minloc2_8_s4.c: Regenerate.
* generated/minloc2_16_s1.c: Regenerate.
* generated/minloc2_16_s4.c: Regenerate.

* gfortran.dg/pr120191_2.f90: New test.

[Bug libfortran/120196] In findloc2_s* when "back" is true loop goes one more step than needed.

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:748a7bc4624e7b000f6fdb93a8cf7da73ff193bb

commit r16-594-g748a7bc4624e7b000f6fdb93a8cf7da73ff193bb
Author: Jakub Jelinek 
Date:   Tue May 13 14:20:22 2025 +0200

libfortran: Fix up _gfortran_{,m,s}findloc2_s{1,4} [PR120196]

As mentioned in the PR, _gfortran_{,m,s}findloc2_s{1,4} iterate too many
times in the back case if nothing is found.
For !back, the loops are for (i = 1; i <= extent; i++) so i is in the
body [1, extent] if nothing is found, but for back it is
for (i = extent; i >= 0; i--) so i is in the body [0, extent] and compares
one element before the start of the array.
Note, findloc1_s{1,4} uses
  for (n = len; n > 0; n--, src -= delta * len_array)
for the back loop and
  for (n = 1; n <= len; n++, src += delta * len_array)
for !back.  This patch fixes that.
The testcase fails under valgrind without the libgfortran changes and
succeeds with those.

2025-05-13  Jakub Jelinek  

PR libfortran/120196
* m4/ifindloc2.m4 (header1, header2): For back use i > 0 rather
than
i >= 0 as for condition.
* generated/findloc2_s1.c: Regenerate.
* generated/findloc2_s4.c: Regenerate.

* gfortran.dg/pr120196.f90: New test.

[Bug target/120256] [16 Regression] 4% slowdown of 454.calculix on aarch64

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |16.0

[Bug c++/120257] New: ICE (Segfault) when expanding deeply nested macros with constructor calls (std::string) since 15.1

[mario.rodriguezb1 at um dot es via Gcc-bugs]

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

Bug ID: 120257
   Summary: ICE (Segfault) when expanding deeply nested macros
with constructor calls (std::string) since 15.1
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mario.rodriguezb1 at um dot es
  Target Milestone: ---

It seems to be a very specific problem, any modification in the code leads to
the expected behaviour, which is "Killed - processing time exceeded". It
happens in 15.1 and trunk

```
#include 
using namespace std;
#define NESTED(X) X(X(X(X(X(X
#define NESTED2(X) NESTED(X)
#define NESTED3(X) NESTED(NESTED2(X))
#define NESTED4(X) NESTED(NESTED3(X))
#define NESTED5(X) NESTED(NESTED4(X))
#define NESTED6(X) NESTED(NESTED5(X))
int main(int argc, char* argv[])
{
NESTED6(string) x(2);
return 0;
}
```

```
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
Compiler returned: 4
```

To reproduce:

https://godbolt.org/z/P3h89YecG

[Bug modula2/120188] documented example does not work

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

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

--- Comment #9 from GCC Commits  ---
The master branch has been updated by Gaius Mulley :

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

commit r16-595-gf1f94e79dbcfa4b33267db27780870ea7810cd21
Author: Gaius Mulley 
Date:   Tue May 13 13:35:00 2025 +0100

PR modula2/120188: Use existing test for plugin

This is a cleanup patch which to use the existing plugin test
rather than check the configure build options.

gcc/testsuite/ChangeLog:

PR modula2/120188
* gm2.dg/doc/examples/plugin/fail/doc-examples-plugin-fail.exp:
Remove call to gm2-dg-frontend-configure-check and replace with
tests for whether plugin variables exist.

Signed-off-by: Gaius Mulley 

[Bug c++/120243] [15/16 Regression] Exception rethrown from coroutine promise type unhandled_exception not caught under -O1

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

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

--- Comment #4 from Iain Sandoe  ---
(In reply to Patrick Palka from comment #3)
> Started with r15-3148-g6303cd7e41546e "c++, coroutines: Separate the
> analysis, ramp and outlined function synthesis."

thanks; (unfortunately) not fixed by the current ramp rework.

[Bug rtl-optimization/120258] New: [11/12/13/14/15/16 regression] wrong code at -O{s,1,2,3} on x86_64-linux-gnu

[chopra.kavya04 at gmail dot com via Gcc-bugs]

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

Bug ID: 120258
   Summary: [11/12/13/14/15/16 regression] wrong code at
-O{s,1,2,3} on x86_64-linux-gnu
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chopra.kavya04 at gmail dot com
  Target Milestone: ---

Appears to be a regression since gcc11. Godbolt link:
https://godbolt.org/z/aooh6xaj8

kchopra@ast-epyc5:~$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/local/home/kchopra/compilers/libexec/gcc/x86_64-pc-linux-gnu/16.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-bootstrap --enable-checking=yes
--prefix=/local/home/kchopra/compilers --enable-sanitizers
--enable-languages=c,c++ --disable-werror --enable-multilib : (reconfigured)
../configure --disable-bootstrap --enable-checking=yes
--prefix=/local/home/kchopra/compilers --enable-sanitizers
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 16.0.0 20250512 (experimental) (GCC) 
kchopra@ast-epyc5:~$ gcc -O1 bug_gcc_11.c 
kchopra@ast-epyc5:~$ ./a.out 
Aborted
kchopra@ast-epyc5:~$ cat bug_gcc_11.c 
int a = 1, b, c;
int main() {
  c = -2147483647 * b - 2147483647 * a;
  if (b - 2147483647 * a >= 0)
__builtin_abort();
}

[Bug rtl-optimization/120258] [12/13/14/15/16 regression] wrong code at -O{s,1,2,3} on x86_64-linux-gnu

[chopra.kavya04 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Kavya Chopra  ---
This happens to be more latent than the other one though - for instance this is
also present in gcc11, whereas the other one wasn't?

[Bug libstdc++/120259] New: Using Incomplete&& as argument in invoke_r/move_only_function fails to compile

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

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

Bug ID: 120259
   Summary: Using Incomplete&& as argument in
invoke_r/move_only_function fails to compile
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkaminsk at gcc dot gnu.org
  Target Milestone: ---

Passing rvalue reference to incomplete type or instantiating move_only_function
with it as parameter produces ill-formed program.
```
struct Incomplete;
int foo(Incomplete& i);
void bar(Incomplete& i) {
std::invoke_r(&foo, std::move(i)); // ILL-FORMED
std::move_only_function mo(&foo);  // ILL-FORMED
}
```
See: https://godbolt.org/z/GvW7veGKa

The error produced is:
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/type_traits:3055:53:
error: static assertion failed: each argument type must be a complete class or
an unbounded array
 3055 |   static_assert((std::__is_complete_or_unbounded(
  |  ~~~^
 3056 | __type_identity<_ArgTypes>{}) && ...),
  | ~

The failure in `move_only_function` is due instantiation of std::invoke_r.

[Bug gcov-profile/120086] FAIL: gcc.misc-tests/gcov-29.c

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

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

--- Comment #22 from John David Anglin  ---
I was about to install a similar patch for hppa-hpux.

I think the builtin falls back to emitting sync libcalls when enabled or calls
to libatomic.  Not sure whether the atomic support detection could be
improved or not.

[Bug libstdc++/120259] Using Incomplete&& as argument in invoke_r/move_only_function fails to compile

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

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

Tomasz Kamiński  changed:

   What|Removed |Added

  Known to fail||12.1.0
   Last reconfirmed||2025-05-13
   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

[Bug c++/120243] [15/16 Regression] Exception rethrown from coroutine promise type unhandled_exception not caught under -O1

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org

--- Comment #3 from Patrick Palka  ---
Started with r15-3148-g6303cd7e41546e "c++, coroutines: Separate the analysis,
ramp and outlined function synthesis."

[Bug fortran/120191] Functions minloc() and maxloc() ignore the "back" parameter when "kind" is present.

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

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

--- Comment #11 from GCC Commits  ---
The releases/gcc-15 branch has been updated by Jakub Jelinek
:

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

commit r15-9668-ga09774a9bbfca578f79e8fae3da4cfc99ddb120b
Author: Jakub Jelinek 
Date:   Tue May 13 14:14:55 2025 +0200

fortran: Fix up minloc/maxloc lowering [PR120191]

We need to drop the kind argument from what is passed to the
library, but need to do it not only when one uses the argument name
for it (so kind=4 etc.) but also when one passes all the arguments
to the intrinsics.

The following patch uses what gfc_conv_intrinsic_findloc uses,
which looks more efficient and cleaner, we already set automatic
vars to point to the kind and back actual arguments, so we can just
free/clear expr on the former and set name to "%VAL" on the latter.

And similarly clears dim argument for the BT_CHARACTER case when using
maxloc2/minloc2, again regardless of whether it was named or not.

2025-05-13  Jakub Jelinek  
Daniil Kochergin  
Tobias Burnus  

PR fortran/120191
* trans-intrinsic.cc (strip_kind_from_actual): Remove.
(gfc_conv_intrinsic_minmaxloc): Don't call strip_kind_from_actual.
Free and clear kind_arg->expr if non-NULL.  Set back_arg->name to
"%VAL" instead of a loop looking for last argument.  Remove actual
variable, use array_arg instead.  Free and clear dim_arg->expr if
non-NULL for BT_CHARACTER cases instead of using a loop.

* gfortran.dg/pr120191_1.f90: New test.

(cherry picked from commit ec249be3c287c6f1dfb328712ac9c39e6fa95eca)

[Bug fortran/120191] Functions minloc() and maxloc() ignore the "back" parameter when "kind" is present.

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

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

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

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

commit r15-9670-gad998962ccc8cd190da2d85f0274bbb7bb9f6cae
Author: Jakub Jelinek 
Date:   Tue May 13 14:19:25 2025 +0200

libfortran: Fix up _gfortran_s{max,min}loc1_{4,8,16}_s{1,4} [PR120191]

There is a bug in _gfortran_s{max,min}loc1_{4,8,16}_s{1,4} which the
following testcase shows.
The functions return but then crash in the caller.
Seems that is because buffer overflows, I believe those functions for
if (mask == NULL || *mask) condition being false are supposed to fill in
the result array with all zeros (or allocate it and fill it with zeros).
My understanding is the result array in that case is integer(kind={4,8,16})
and should have the extents the character input array has.
The problem is that it uses * string_len in the extent multiplication:
  extent[n] = GFC_DESCRIPTOR_EXTENT(array,n) * string_len;
and
  extent[n] =
GFC_DESCRIPTOR_EXTENT(array,n + 1) * string_len;
which is I guess fine and desirable for the extents of the character array,
but not for the extents of the destination array.  Yet the code uses
that extent array for that purpose (and no other purposes).
Here it uses it to set the dimensions for the case where it needs to
allocate (as well as size):
  for (n = 0; n < rank; n++)
{
  if (n == 0)
str = 1;
  else
str = GFC_DESCRIPTOR_STRIDE(retarray,n-1) * extent[n-1];
  GFC_DIMENSION_SET(retarray->dim[n], 0, extent[n] - 1, str);
}
Here it uses it for bounds checking of the destination:
  if (unlikely (compile_options.bounds_check))
{
  for (n=0; n < rank; n++)
{
  index_type ret_extent;

  ret_extent = GFC_DESCRIPTOR_EXTENT(retarray,n);
  if (extent[n] != ret_extent)
runtime_error ("Incorrect extent in return value of"
   " MAXLOC intrinsic in dimension %ld:"
   " is %ld, should be %ld", (long int) n + 1,
   (long int) ret_extent, (long int)
extent[n]);
}
}
and here to find out how many retarray elements to actually fill in each
dimension:
  while(1)
{
  *dest = 0;
  count[0]++;
  dest += dstride[0];
  n = 0;
  while (count[n] == extent[n])
{
  /* When we get to the end of a dimension, reset it and increment
 the next dimension.  */
  count[n] = 0;
  /* We could precalculate these products, but this is a less
 frequently used path so probably not worth it.  */
  dest -= dstride[n] * extent[n];
Seems maxloc1s.m4 and minloc1s.m4 are the only users of ifunction-s.m4,
so we can change SCALAR_ARRAY_FUNCTION in there without breaking anything
else.

2025-05-13  Jakub Jelinek  

PR fortran/120191
* m4/ifunction-s.m4 (SCALAR_ARRAY_FUNCTION): Don't multiply
GFC_DESCRIPTOR_EXTENT(array,) by string_len.
* generated/maxloc1_4_s1.c: Regenerate.
* generated/maxloc1_4_s4.c: Regenerate.
* generated/maxloc1_8_s1.c: Regenerate.
* generated/maxloc1_8_s4.c: Regenerate.
* generated/maxloc1_16_s1.c: Regenerate.
* generated/maxloc1_16_s4.c: Regenerate.
* generated/minloc1_4_s1.c: Regenerate.
* generated/minloc1_4_s4.c: Regenerate.
* generated/minloc1_8_s1.c: Regenerate.
* generated/minloc1_8_s4.c: Regenerate.
* generated/minloc1_16_s1.c: Regenerate.
* generated/minloc1_16_s4.c: Regenerate.

* gfortran.dg/pr120191_3.f90: New test.

(cherry picked from commit 781cfc454b8dc24952fe7f4c5c409296dca505e1)

[Bug fortran/120191] Functions minloc() and maxloc() ignore the "back" parameter when "kind" is present.

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

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

--- Comment #12 from GCC Commits  ---
The releases/gcc-15 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:65a8260c19834511034fb62c73139aa304f7eac4

commit r15-9669-g65a8260c19834511034fb62c73139aa304f7eac4
Author: Jakub Jelinek 
Date:   Tue May 13 14:18:10 2025 +0200

libfortran: Fix up _gfortran_s{max,min}loc2_{4,8,16}_s{1,4} [PR120191]

I've tried to write a testcase for the BT_CHARACTER maxloc/minloc with
named
or unnamed arguments and indeed the just posted patch fixed the arguments
in there in multiple cases to match what the library expects.
But the testcase still fails, due to library problems.

One dealt with in this patch are _gfortran_s{max,min}loc2_{4,8,16}_s{1,4}
functions.  Those are trivial wrappers around
_gfortrani_{max,min}loc2_{4,8,16}_s{1,4} which should call those functions
if the scalar mask is true and just return 0 otherwise.
The two bugs I see there is that the back, len arguments are swapped,
which means that it always acts as back=.true. and for len will use
character length of 1 or 0 instead of the desired one.
The _gfortrani_{max,min}loc2_{4,8,16}_s{1,4} functions have prototypes like
GFC_INTEGER_4
maxloc2_4_s1 (gfc_array_s1 * const restrict array, GFC_LOGICAL_4 back,
gfc_charlen_type len)
so back comes before len, ditto for the
GFC_INTEGER_4
smaxloc2_4_s1 (gfc_array_s1 * const restrict array,
   GFC_LOGICAL_4 *mask, GFC_LOGICAL_4 back, gfc_charlen_type
len)
The other problem is that it was just testing if (mask).  In my limited
Fortran understanding that means that the optional argument mask was
supplied but nothing about its actual value.  Other scalar mask generated
routines use if (mask == NULL || *mask) as the condition when to call the
non-masked function, i.e. when mask is not supplied (then it should act
like
.true. mask) or when it is supplied and evaluates to .true.).

2025-05-13  Jakub Jelinek  

PR fortran/120191
* m4/maxloc2s.m4: For smaxloc2 call maxloc2 if mask is NULL or
*mask.
Swap back and len arguments.
* m4/minloc2s.m4: Likewise.
* generated/maxloc2_4_s1.c: Regenerate.
* generated/maxloc2_4_s4.c: Regenerate.
* generated/maxloc2_8_s1.c: Regenerate.
* generated/maxloc2_8_s4.c: Regenerate.
* generated/maxloc2_16_s1.c: Regenerate.
* generated/maxloc2_16_s4.c: Regenerate.
* generated/minloc2_4_s1.c: Regenerate.
* generated/minloc2_4_s4.c: Regenerate.
* generated/minloc2_8_s1.c: Regenerate.
* generated/minloc2_8_s4.c: Regenerate.
* generated/minloc2_16_s1.c: Regenerate.
* generated/minloc2_16_s4.c: Regenerate.

* gfortran.dg/pr120191_2.f90: New test.

(cherry picked from commit 482f2192d4ef6af55acae2dc3e0df00b8487cc7d)

[Bug libfortran/120196] In findloc2_s* when "back" is true loop goes one more step than needed.

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

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

--- Comment #4 from GCC Commits  ---
The releases/gcc-15 branch has been updated by Jakub Jelinek
:

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

commit r15-9671-gc84a951a8ee151cb4d80dd84f75f421c5f60fa05
Author: Jakub Jelinek 
Date:   Tue May 13 14:20:22 2025 +0200

libfortran: Fix up _gfortran_{,m,s}findloc2_s{1,4} [PR120196]

As mentioned in the PR, _gfortran_{,m,s}findloc2_s{1,4} iterate too many
times in the back case if nothing is found.
For !back, the loops are for (i = 1; i <= extent; i++) so i is in the
body [1, extent] if nothing is found, but for back it is
for (i = extent; i >= 0; i--) so i is in the body [0, extent] and compares
one element before the start of the array.
Note, findloc1_s{1,4} uses
  for (n = len; n > 0; n--, src -= delta * len_array)
for the back loop and
  for (n = 1; n <= len; n++, src += delta * len_array)
for !back.  This patch fixes that.
The testcase fails under valgrind without the libgfortran changes and
succeeds with those.

2025-05-13  Jakub Jelinek  

PR libfortran/120196
* m4/ifindloc2.m4 (header1, header2): For back use i > 0 rather
than
i >= 0 as for condition.
* generated/findloc2_s1.c: Regenerate.
* generated/findloc2_s4.c: Regenerate.

* gfortran.dg/pr120196.f90: New test.

(cherry picked from commit 748a7bc4624e7b000f6fdb93a8cf7da73ff193bb)

[Bug c++/120127] [12/13/14/15/16 Regression] ICE in GCC when calling destructor of undefined type name in lambda (lookup_template_class crash)

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

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

Patrick Palka  changed:

   What|Removed |Added

Summary|ICE in GCC when calling |[12/13/14/15/16 Regression]
   |destructor of undefined |ICE in GCC when calling
   |type name in lambda |destructor of undefined
   |(lookup_template_class  |type name in lambda
   |crash)  |(lookup_template_class
   ||crash)
   Target Milestone|--- |12.5
 CC||ppalka at gcc dot gnu.org
   Keywords||ice-on-invalid-code

[Bug c++/120126] ICE in GCC with pack-dependent decltype in lambda: cp_type_quals

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org,
   ||simartin at gcc dot gnu.org
   Keywords|needs-bisection |

--- Comment #1 from Patrick Palka  ---
The ICE seems fixed by r15-7238-gceabea405ffdc8 "c++: Don't prune constant
capture proxies only used in array dimensions [PR114292]"

[Bug tree-optimization/120069] [16 Regression] Yes another imagick -march=native -flto -Ofast + PGO regression since r16-270-ga0a64aa5da0af5

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

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

Filip Kastl  changed:

   What|Removed |Added

Summary|[16 Regression] Yes another |[16 Regression] Yes another
   |imagick -march=native -flto |imagick -march=native -flto
   |-Ofast + PGO regression |-Ofast + PGO regression
   |between |since
   |g:1c0cbc1b300e08df5ebfce00a |r16-270-ga0a64aa5da0af5
   |7195890d78f2064 and |
   |g:55b01e17c793688a2878fa43a |
   |76df1266153b438 |
 CC||hjl at gcc dot gnu.org

--- Comment #9 from Filip Kastl  ---
The Zen2 slowdowns bisect to:

commit a0a64aa5da0af5ecb022675cdb9140ccfa098ce3 (HEAD)
Author: H.J. Lu 
AuthorDate: Tue Nov 12 09:03:31 2024 +0800
Commit: H.J. Lu 
CommitDate: Tue Apr 29 15:06:52 2025 +0800

i386: Add ix86_expand_unsigned_small_int_cst_argument

When passing 0xff as an unsigned char function argument with the C frontend
promotion, expand_normal used to get

 constant
255>

and returned the rtx value using the sign-extended representation:

(const_int 255 [0xff])

But after

commit a670ebde3995481225ec62b29686ec07a21e5c10
Author: H.J. Lu 
Date:   Thu Nov 21 07:54:35 2024 +0800

Drop targetm.promote_prototypes from C, C++ and Ada frontends

expand_normal now gets

 constant 255>

and returns

 (const_int -1 [0x])

which doesn't work with the predicates nor the instruction templates which
expect the unsigned expanded value.  Extract the unsigned char and short
integer constants to return

(const_int 255 [0xff])

so that the expanded value is always unsigned, without the C frontend
promotion.

PR target/117547
* config/i386/i386-expand.cc
(ix86_expand_unsigned_small_int_cst_argument):
New function.
(ix86_expand_args_builtin): Call
ix86_expand_unsigned_small_int_cst_argument to expand the argument
before calling fixup_modeless_constant.
(ix86_expand_round_builtin): Likewise.
(ix86_expand_special_args_builtin): Likewise.
(ix86_expand_builtin): Likewise.

Signed-off-by: H.J. Lu 


So the arm slowdowns will most probably be something else.

[Bug tree-optimization/120221] Missed optimization related to switch handling

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

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

--- Comment #7 from Filip Kastl  ---
So this isn't specific for switches.  Rather, this is some kind of forward
propagation of a shift that we don't currently do, right?

[Bug c++/120255] New: C++ template member class parameter name should shadow member name

[rockeet at gmail dot com via Gcc-bugs]

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

Bug ID: 120255
   Summary: C++ template member class parameter name should shadow
member name
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rockeet at gmail dot com
  Target Milestone: ---

template parameter name should hide member name.

```
struct A {
struct B {};
struct C {
template void foo1(B*);
template void foo2(B*) {} // ok
};
template void foo1(B*);
template void foo2(B*) {} // ok
};
template
void A::C::foo1(B*) {} // fail
template
void A::foo1(B*) {} // fail
```

[Bug c++/120255] C++ template member class parameter name should shadow member name

[rockeet at gmail dot com via Gcc-bugs]

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

--- Comment #1 from rockeet  ---
clang compiled the code successfully.

[Bug c++/118590] [14 regression] ICE with acc enter data copyin and dependent types since r14-7033-g1413af02d62182

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

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

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

https://gcc.gnu.org/g:346f3a27f68fd1c4991193b0faba4198162bbe3d

commit r14-11768-g346f3a27f68fd1c4991193b0faba4198162bbe3d
Author: Jakub Jelinek 
Date:   Thu Jan 23 11:17:47 2025 +0100

c++: Fix build_omp_array_section for type dependent array_expr [PR118590]

As can be seen on the testcase, when array_expr is type dependent, assuming
it has non-NULL TREE_TYPE is just wrong, it can often have NULL type, and
even
if not, blindly assuming it is a pointer or array type is also wrong.

So, like in many other spots in the C++ FE, for type dependent expressions
we want to create something which will survive until instantiation and can
be
redone at that point.

Unfortunately, build_omp_array_section is called before we actually do any
kind of checking what array_expr really is, and on invalid code it can be
e.g.
a TYPE_DECL on which type_dependent_expression_p ICEs (as can be seen on
the
pr67522.C testcase).  So, I've hacked this by checking it is not TYPE_DECL,
I hope a TYPE_P can't make it through there when we just lookup an
identifier.

Anyway, this patch is not enough, we can ICE e.g. on
__uint128_t[0:something]
during instantiation, so I think something needs to be done for this in
pt.cc
as well.

2025-01-23  Jakub Jelinek  

PR c++/118590
* typeck.cc (build_omp_array_section): If array_expr is type
dependent
or a TYPE_DECL, build OMP_ARRAY_SECTION with NULL type.

* g++.dg/goacc/pr118590.C: New test.

(cherry picked from commit b02c061bb84c0a2dbf3987e9ff77243d089cbd7a)

[Bug c++/118590] [14 regression] ICE with acc enter data copyin and dependent types since r14-7033-g1413af02d62182

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #16 from Jakub Jelinek  ---
Fixed for 13.3 as well.

[Bug tree-optimization/120254] New: wrong code at -O3 on x86_64-pc-linux-gnu

[zhiyijie at zju dot edu.cn via Gcc-bugs]

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

Bug ID: 120254
   Summary: wrong code at -O3 on x86_64-pc-linux-gnu
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhiyijie at zju dot edu.cn
  Target Milestone: ---

Created attachment 61416
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61416&action=edit
test case

It produces wrong code when compiling using gcc-15.1.0 with -O3 option. I get
sum of array A as -1957771396 using -O0 and -O2, but 1793347916 using -O3.

This situation disappears when I lower the number of "N"(e.g., from 30 to 10),
and also when I add "-fno-tree-vectorize".


Here is the kernel function:
#define N 30
for (int i = 0; i < N - 1; i++) {
for (int j = 0; j < N; j++) {
for (int k = 0; k < N - 1; k++) {
A[k + 1][i][i] += A[k + 1][i][i + 1] - A[k][i][i] - 6;
}
}
}

$ gcc-15 -O0 ./test.c -o ./test0
$ ./test0
-1957771396
$ gcc-15 -O3 ./test.c -o ./test3
$ ./test3
1793347916
$ gcc-15 -O3 -fno-tree-vectorize ./test.c -o ./test3_
$ ./test3_
-1957771396
$ gcc-15 -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with: ../configure --enable-languages=c,c++,fortran
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.1.0 (GCC)

[Bug target/120218] [16 Regression] 8% slowdown of 507.cactuBSSN_r on Intel

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

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

--- Comment #2 from Jan Hubicka  ---
I guess for costing changes, too.  Since this is a weekly tester, bisecting
would help.

[Bug modula2/120188] documented example does not work

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

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

--- Comment #7 from Gaius Mulley  ---
See PR-120253 for the column starting at 0 bug (rather than 1).

[Bug tree-optimization/120069] [16 Regression] Yes another imagick -march=native -flto -Ofast + PGO regression since r16-270-ga0a64aa5da0af5

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

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

--- Comment #10 from Filip Kastl  ---
I would make a pr for the arm slowdowns but it looks like they disappeared. 
But do tell me if you think I should report those or feel free to report them
yourself.

[Bug modula2/120188] documented example does not work

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

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

--- Comment #8 from Gaius Mulley  ---
PR modula2/120253

[Bug modula2/120253] Error message column numbers should start at 1 not 0

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #1 from Gaius Mulley  ---
Confirming the bug and generating a url to the prior PR modula2/120188

[Bug tree-optimization/120069] [16 Regression] Yes another imagick -march=native -flto -Ofast + PGO regression since r16-270-ga0a64aa5da0af5

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

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

--- Comment #11 from Filip Kastl  ---
I've also just bisected this 2006 lbm -Ofast -march=native -flto PGO AMD Zen3
16% slowdown to r16-270-ga0a64aa5da0af5:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=474.240.0

[Bug target/120250] [12/13/14/15/16 Regression] ICE during RTL pass: dwarf2, in create_trace_edges, at dwarf2cfi.cc:2686 since r12-4475

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[12/13/14/15/16 Regression] |[12/13/14/15/16 Regression]
   |ICE during RTL pass:|ICE during RTL pass:
   |dwarf2, in  |dwarf2, in
   |create_trace_edges, at  |create_trace_edges, at
   |dwarf2cfi.cc:2686   |dwarf2cfi.cc:2686 since
   ||r12-4475
 CC||jakub at gcc dot gnu.org,
   ||sayle at gcc dot gnu.org
   Priority|P3  |P2

--- Comment #2 from Jakub Jelinek  ---
Started with r12-4475-g247c407c83f0015f4b92d5f71e45b63192f6757e

[Bug ipa/119852] The output of -fdump-ipa-clones can contain "(null)" as the suffix/reason for cloning

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

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Jambor  ---
Fixed.

[Bug fortran/120260] New: dyld runtime error for gfortran code on Mac OS X Sequoia 15.4

[markus.winterer--- via Gcc-bugs]

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

Bug ID: 120260
   Summary: dyld runtime error for gfortran code on Mac OS X
Sequoia 15.4
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: markus.winte...@uni-due.de
  Target Milestone: ---

I discovered the following problem using a scientific code to perform Reverse
Monte Carlo simulations ('rmcxas') compiled using gcc/gfortran 14.2.0 (Xcode
including command line tools has been installed) on Mac OS Sequoia 15.4 on an
Apple MacBook Air with M4 processor when starting the software:

dyld[10154]: dyld cache '(null)' not loaded: syscall to map cache into shared
region failed
dyld[10154]: Library not loaded: /usr/lib/libSystem.B.dylib
 Referenced from: <0144F82E-003C-37A9-A544-9AE6336E549B>
/Users/markuswinterer/bin/rmcxas
 Reason: tried: '/usr/lib/libSystem.B.dylib' (no such file),
'/System/Volumes/Preboot/Cryptexes/OS/usr/lib/libSystem.B.dylib' (no such
file), '/usr/lib/libSystem.B.dylib' (no such file, no dyld cache),
'/usr/local/lib/libSystem.B.dylib' (no such file)
zsh: abort  rmcxas

The problem occurs only every 5th time the rmcxas code is started.

Help would be highly appreciated.

[Bug target/120242] [15/16 regression] RISC-V: Miscompile at -O[23] since r15-9239-g4d7a634f6d4

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

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

--- Comment #1 from Richard Biener  ---
I'm sure it's a latent issue, possibly a target one.

[Bug tree-optimization/120069] [16 Regression] Yes another imagick -march=native -flto -Ofast + PGO regression (+ wrf and lbm) since r16-270-ga0a64aa5da0af5

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

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

Filip Kastl  changed:

   What|Removed |Added

Summary|[16 Regression] Yes another |[16 Regression] Yes another
   |imagick -march=native -flto |imagick -march=native -flto
   |-Ofast + PGO regression |-Ofast + PGO regression (+
   |since   |wrf and lbm) since
   |r16-270-ga0a64aa5da0af5 |r16-270-ga0a64aa5da0af5

--- Comment #12 from Filip Kastl  ---
And also wrf -O2 -march=generic -flto PGO slowed down on Zen{2,3,4} machines:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=685.270.0
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=693.270.0
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=960.270.0

I haven't bisected this but I think it is caused by the same commit.

[Bug c++/120247] __builtin_assoc_barrier and binding to a reference type

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

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

--- Comment #2 from Richard Biener  ---
PAREN_EXPR should behave like NON_LVALUE_EXPR, aka it produces an rvalue.

[Bug c++/120243] [15/16 Regression] Exception rethrown from coroutine promise type unhandled_exception not caught under -O1

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-05-13
   Target Milestone|--- |15.2
  Known to work||14.2.0

--- Comment #2 from Richard Biener  ---
Confirmed.

[Bug testsuite/120251] cobol tests depend on locale

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Confirmed.  The harness should probably make sure the locale is "standard".

[Bug target/120250] [12/13/14/15/16 Regression] ICE during RTL pass: dwarf2, in create_trace_edges, at dwarf2cfi.cc:2686

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Target||x86_64-*-*
 Status|UNCONFIRMED |NEW
  Known to work||11.5.0
   Target Milestone|--- |12.5
Summary|ICE during RTL pass:|[12/13/14/15/16 Regression]
   |dwarf2, in  |ICE during RTL pass:
   |create_trace_edges, at  |dwarf2, in
   |dwarf2cfi.cc:2686   |create_trace_edges, at
   ||dwarf2cfi.cc:2686
   Keywords||ice-on-valid-code
  Known to fail||12.1.0, 13.3.1, 14.2.1,
   ||15.1.1, 16.0
  Component|rtl-optimization|target
   Last reconfirmed||2025-05-13

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug ada/87778] Remove -q quiet option from some GNAT bootstrap command lines

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |16.0
 Status|NEW |RESOLVED

--- Comment #8 from Eric Botcazou  ---
Thanks, applied.

[Bug testsuite/120251] New: cobol tests depend on locale

[schwab--- via Gcc-bugs]

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

Bug ID: 120251
   Summary: cobol tests depend on locale
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
CC: rdubner at gcc dot gnu.org
  Target Milestone: ---

The tests cobol.dg/group1/check_88.cob,
cobol.dg/group2/ALLOCATE_Rule_8_OPTION_INITIALIZE_with_figconst.cob and
cobol.dg/group2/INSPECT_CONVERTING_TO_figurative_constants.cob all fail when
run in a non-UTF-8 locale.

[Bug modula2/120253] New: Error message column numbers should start at 1 not 0

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

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

Bug ID: 120253
   Summary: Error message column numbers should start at 1 not 0
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: gaius at gcc dot gnu.org
  Target Milestone: ---

This is an off shoot from PR-120188 which was categorised as a documentation
PR.

Expected output: Diagnostics, as documented, but with a reasonable column
number. (Column number 0 is not valid, according to
https://www.gnu.org/prep/standards/html_node/Errors.html : "column numbers
should start from 1 at the beginning of the line".)

[Bug tree-optimization/120221] Missed optimization related to switch handling

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

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

--- Comment #8 from Richard Biener  ---
(In reply to Filip Kastl from comment #7)
> So this isn't specific for switches.  Rather, this is some kind of forward
> propagation of a shift that we don't currently do, right?

Yes, it's basically an expression simplification that to be profitable has to
apply to all uses.

[Bug middle-end/120252] New: -fpatchable-function-entry doesn't work with -ffunction-sections

[hjl.tools at gmail dot com via Gcc-bugs]

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

Bug ID: 120252
   Summary: -fpatchable-function-entry doesn't work with
-ffunction-sections
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

-fpatchable-function-entry doesn't work with -ffunction-sections since
a single __patchable_function_entries section is used for all functions.
It defeats the purpose of -ffunction-sections.

[Bug middle-end/120252] -fpatchable-function-entry doesn't work with -ffunction-sections

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

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

[Bug middle-end/120252] -fpatchable-function-entry doesn't work with -ffunction-sections

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #1 from H.J. Lu  ---
Created attachment 61415
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61415&action=edit
A patch

[Bug ada/87778] Remove -q quiet option from some GNAT bootstrap command lines

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Eric Botcazou :

https://gcc.gnu.org/g:940bc09b446f4876563b0986231724121b33193d

commit r16-590-g940bc09b446f4876563b0986231724121b33193d
Author: Nicolas Boulenguez 
Date:   Tue May 13 10:28:54 2025 +0200

Remove -q quiet option from some GNAT bootstrap command lines

gcc/ada/
PR ada/87778
* Make-generated.in: Remove -q gnatmake option.
* gcc-interface/Makefile.in: Likewise.

[Bug cobol/119377] cobol.dg/group1/declarative_1.cob fails (segfaults, uninitialised vars)

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

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

--- Comment #17 from Iain Sandoe  ---
(In reply to Robert Dubner from comment #13)
> Thanks.  Sadly, that didn't tell me anything useful.
> 
> The front-end code that's failing is slated to be completely eliminated when
> Jim gets a chance to work on it, probably in the next couple of weeks.
> 
> The COBOLworx suite has numerous DECLARATIVE testcases.  But declarative_1
> is the only DejaGnu test with DECLARATIVE, so if it's the only one failing
> for you, I think the most expedient solution is to simply delete the thing
> for now.  After Jim rewrites the offending code, we'll introduce it again.
> 
> But if other testcases are failing, that becomes less attractive.  Let me
> know.

Similar to Sam's results there are several failing tests all with the same
symptoms (90 overall fails) for example:

https://gcc.gnu.org/pipermail/gcc-testresults/2025-May/846718.html

> *** Configuration aarch64-apple-darwin24.3 not supported

The arm64 work is still under development (not $dayjob, sadly) - which means it
only gets updated roughly weekly [ https://github.com/iains/gcc-darwin-arm64 ]

 Given this, and assuming you don't have access to an x86_64 macOS box, I would
actually recommend working under rosetta2 (which does support upstream trunk)
.. once we have the back ports for 14.3 sorted out, I will send some
instructions.

[Bug preprocessor/120249] New: Improve handling of comments with -C similarly to clang

[federico at kircheis dot it via Gcc-bugs]

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

Bug ID: 120249
   Summary: Improve handling of comments with -C similarly to
clang
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: federico at kircheis dot it
  Target Milestone: ---

Consider following program


#define CPP_PP_CAT_(X, ...)  X ## __VA_ARGS__
#define CPP_PP_CAT(X, ...)   CPP_PP_CAT_(X, __VA_ARGS__)


int bar(){
// comment 1
int /*comment2*/ CPP_PP_CAT(a, // comment 3
 b) = 12; // comment4
return ab;
}


GCC, when using "-E -C" triggers the error

> pasting "a" and "/* comment 3*/" does not give a valid preprocessing token

Which is correct.

On the other hand, clang also supports "-E -C" and discards "// comment 3" to
let the proprocessor do its work, but keeps all other comments.

Since the (documented) intended usage for "-C" is to keep comments relevant for
linters, it should be better if a comments is discarded instead of retained and
leading to an error.
Especially since the comment might be irrelevant for the linter.

Example on godbolt: https://godbolt.org/z/1h858bnaW

[Bug c++/86769] [12/13/14 Regression] g++ destroys condition variable in for statement too early

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

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

--- Comment #26 from Jakub Jelinek  ---
Note, this had the PR118822 r15-7502 follow-up, so not really sure it is a good
idea to backport this.

[Bug gcov-profile/120086] FAIL: gcc.misc-tests/gcov-29.c

[j at lambda dot is via Gcc-bugs]

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

--- Comment #21 from Jørgen Kvalsvik  ---
Does that mean that the feature detection of atomics, leading to the use
BUILT_IN_ATOMIC_FETCH_* is wrong? We use the BUILT_IN for emitting
instructions. It could be that it's the detection itself that needs some
tweaking. Maybe a separate report?

Interestingly, it was John that defined HAVE_sync_compare_and_swapdi in 2015:

commit 7e7c9d40d17e0efb27691fe9dfc4c831d03c7ff2
Author: John David Anglin 
Date:   Fri Sep 25 00:01:34 2015 +

pa-linux.h (HAVE_sync_compare_and_swapdi): Define.

[Bug c/118868] __builtin_assoc_barrier with pointers cause ICE

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

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

--- Comment #8 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

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

commit r16-599-ge4fb1b435a65f505b0172b4f0213483c3a07adbf
Author: Andrew Pinski 
Date:   Mon May 12 18:58:32 2025 -0700

verifier: Fix up PAREN_EXPR verification [PR118868]

The verification added in r12-1608-g2f1686ff70b25f, was incorrect
for PAREN_EXPR, pointer types should be valid for PAREN_EXPR.
Also for PAREN_EXPR, aggregate types don't make sense (currently
they ICE much earlier in the gimplifier rather than error message) so
we should disallow them here too.

Bootstrapped and tested on x86_64-linux-gnu.

PR middle-end/118868

gcc/ChangeLog:

* tree-cfg.cc (verify_gimple_assign_unary): Allow pointers
but disallow aggregate types for PAREN_EXPR.

gcc/testsuite/ChangeLog:

* c-c++-common/pr118868-1.c: New test.

Signed-off-by: Andrew Pinski 

[Bug ipa/119852] The output of -fdump-ipa-clones can contain "(null)" as the suffix/reason for cloning

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

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

--- Comment #7 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Martin Jambor
:

https://gcc.gnu.org/g:168ce6032dd582e39f9ddadcc195fc73f364c4dd

commit r13-9654-g168ce6032dd582e39f9ddadcc195fc73f364c4dd
Author: Martin Jambor 
Date:   Tue May 6 17:28:43 2025 +0200

ipa: Do not emit info about temporary clones to ipa-clones dump (PR119852)

As described in PR 119852, the output of -fdump-ipa-clones can contain
"(null)" as the suffix/reason for cloning when we need to create a
clone to hold the original function during recursive inlining.  Such
clone is never output and so should not be part of the dump output
either.

gcc/ChangeLog:

2025-04-23  Martin Jambor  

PR ipa/119852
* cgraphclones.cc (dump_callgraph_transformation): Document the
function.  Do not dump if suffix is NULL.

gcc/testsuite/ChangeLog:

2025-04-23  Martin Jambor  

PR ipa/119852
* gcc.dg/ipa/pr119852.c: New test.

(cherry picked from commit fb5829a01651d427a63a12c44ecc8baa47dbfc83)

[Bug target/120263] New: RISC-V: FRM not restored if clobbered via inline asm

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

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

Bug ID: 120263
   Summary: RISC-V: FRM not restored if clobbered via inline asm
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: vineetg at gcc dot gnu.org
  Reporter: vineetg at gcc dot gnu.org
CC: jeffreyalaw at gmail dot com, pan2.li at intel dot com,
rdapp at gcc dot gnu.org
  Target Milestone: ---

This is a variation of 

gcc/testsuite/gcc.target/riscv/rvv/base/float-point-frm-insert-9.c

# -O3 -march=rv64gcv -mabi=lp64 

#pragma riscv intrinsic "vector"

typedef long unsigned int size_t;

void
test_float_point_frm_static (float *out, vfloat32m1_t op1, vfloat32m1_t op2,
size_t vl)
{
  vfloat32m1_t result = __riscv_vfadd_vv_f32m1 (op1, op2, vl);

  asm volatile (
"fsrmi 4"
:
:
:"frm"
  );

  result = __riscv_vfadd_vv_f32m1 (op1, result, vl);
  *(vfloat32m1_t *)out = result;
}

The second vfadd needs to execute with the "global" rounding mode and thus
needs to be saved/restored around the inline asm.

vsetvli zero,a1,e32,m1,ta,ma
vfadd.vvv9,v8,v9
frrma5 <-- missing
fsrmi 4
fsrma5 <-- missing
vfadd.vvv8,v8,v9
vs1r.v  v8,0(a0)
ret

[Bug modula2/119915] Sprintf1 repeats the entire format string if it starts with a directive

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #5 from Gaius Mulley  ---
Closing now that the patches have been applied to master and releases/gcc-15.

[Bug modula2/115276] libgm2 wraptime.InitTM returns NIL

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

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

Gaius Mulley  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Gaius Mulley  ---
Closing now that the patches have been applied to master and releases/gcc-15.

[Bug modula2/120117] ICE when attempting to obtain the MAX of an aliased set type.

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

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-15 branch has been updated by Gaius Mulley
:

https://gcc.gnu.org/g:61fada934e894c7fb4a1f1626ea0d0f1f1f1d2f4

commit r15-9677-g61fada934e894c7fb4a1f1626ea0d0f1f1f1d2f4
Author: Gaius Mulley 
Date:   Tue May 13 19:42:39 2025 +0100

[PATCH] PR modula2/120117: ICE when attempting to obtain the MAX of an
aliased set type

The ICE occurred because of a bug in M2GenGCC.mod:FoldBecomes which
attempted to remove the same quadruple twice.  Thereafter cc1gm2
generated an erroneous error type error as PCSymBuild did not skip
an aliased set type.  The type of the const was set incorrectly
(as a set type) rather than the type of the set element.

gcc/m2/ChangeLog:

PR modula2/120117
* gm2-compiler/M2GenGCC.mod (FoldBecomes): Remove the call to
RemoveQuad since this is performed by TypeCheckBecomes.
* gm2-compiler/PCSymBuild.mod (buildConstFunction): Rewrite
header comment.
Check for a set or a type aliased set and appropriately
skip type equivalences and obtain the element type.
* gm2-compiler/SymbolTable.mod (PutConst): Add call to
CheckBreak.

gcc/testsuite/ChangeLog:

PR modula2/120117
* gm2/pim/pass/highbit.mod: New test.
* gm2/pim/pass/highbit2.mod: New test.

(cherry picked from commit bb83283e5c5c55eab7493a58c5e415aa56f5940c)

Signed-off-by: Gaius Mulley 

[Bug c++/120262] internal compiler error: in remap_type_1 since version 12.1

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=107360
   Keywords||ice-on-invalid-code
   Last reconfirmed||2025-05-13
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
This code should be rejected as returning an pointer to a VLA type is
questionable.

[Bug target/120263] RISC-V: FRM not restored if clobbered via inline asm

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

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

Vineet Gupta  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||riscv

--- Comment #1 from Vineet Gupta  ---
RISC-V TARGET_MODE_AFTER seems to handle this case but is transitioning to
wrong state and missing out in generating the restore.

Preliminary patch which fixes the test is 

@@ -12438,7 +12438,7 @@ riscv_frm_mode_after (rtx_insn *insn, int mode)
 return mode;

   if (frm_unknown_dynamic_p (insn))
-return riscv_vector::FRM_DYN;
+return riscv_vector::FRM_DYN_EXIT;

[Bug c++/120126] ICE in GCC with pack-dependent decltype in lambda: cp_type_quals

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

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

Simon Martin  changed:

   What|Removed |Added

   Last reconfirmed||2025-05-13
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |simartin at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #2 from Simon Martin  ---
Good catch Patrick, thanks! I just checked and the key part from the patch that
fixes this PR is [...]when walking a DECL_EXPR, it also walks the DECL's
type[...].

I'll submit a patch adding this PR case to the testsuite.

[Bug c++/120262] internal compiler error: in remap_type_1 since version 12.1

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

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

--- Comment #2 from Andrew Pinski  ---
Created attachment 61418
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61418&action=edit
Reduced testcase

[Bug c++/120255] C++ template member class parameter name should shadow member name

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Confirmed, does not look up a regression; I had thought there was a dup of this
but I can't seem to find it.

[Bug c++/120247] __builtin_assoc_barrier and binding to a reference type

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #6)
> Perhaps __builtin_assoc_barrier should lower to NON_LVALUE_EXPR (PAREN_EXPR
> (expr))
> or PAREN_EXPR (NON_LVALUE_EXPR (expr)) for C++?
> Of course, a big question is what the builtin should do for class types (if
> it shouldn't be an error).

It should be an error, PR 118869 records the case where GCC incorrectly accepts
it for class types and gets ICE.

> And for C++ it also means that __builtin_assoc_barrier can have dependent
> argument and only during instantiation we'd find out if it has
> supported/able type or not.
> Though, __builtin_assoc_barrier is parsed immediately to PAREN_EXPR. 
> Perhaps we want some language flag on whether it is __builtin_assoc_barrier
> or the force_paren_expr created one?

[Bug c++/120247] __builtin_assoc_barrier and binding to a reference type

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Oh I based on comment #4, this is going to be harder than I expected.

[Bug tree-optimization/120254] wrong code at -O3 on x86_64-pc-linux-gnu

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
gcc -fsanitize=undefined -o pr120254{,.c}; ./pr120254
pr120254.c:20:32: runtime error: signed integer overflow: -804068425 +
-2004610352 cannot be represented in type 'int'
Resulting sum of array A:
pr120254.c:31:23: runtime error: signed integer overflow: 2112539415 +
126566608 cannot be represented in type 'int'
-1957771396

[Bug target/120260] dyld runtime error for gfortran code on Mac OS X Sequoia 15.4

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

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

--- Comment #1 from Andrew Pinski  ---
https://developer.apple.com/forums/thread/697494

[Bug modula2/120188] documented example does not work

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

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

--- Comment #11 from GCC Commits  ---
The releases/gcc-15 branch has been updated by Gaius Mulley
:

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

commit r15-9673-gc220b8e7b422ed04b6aaa1b9243b550df913f476
Author: Gaius Mulley 
Date:   Tue May 13 16:51:06 2025 +0100

[PATCH] PR modula2/120188: Use existing test for plugin

This is a cleanup patch which to use the existing plugin test
rather than check the configure build options.

gcc/testsuite/ChangeLog:

PR modula2/120188
* gm2.dg/doc/examples/plugin/fail/doc-examples-plugin-fail.exp:
Remove call to gm2-dg-frontend-configure-check and replace with
tests for whether plugin variables exist.

(cherry picked from commit f1f94e79dbcfa4b33267db27780870ea7810cd21)

Signed-off-by: Gaius Mulley 

[Bug modula2/120188] documented example does not work

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #12 from Gaius Mulley  ---
Closing now that the patches have been applied.

[Bug c++/120261] New: GCC rejects valid constexpr value initialization

[danny321974345 at gmail dot com via Gcc-bugs]

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

Bug ID: 120261
   Summary: GCC rejects valid constexpr value initialization
   Product: gcc
   Version: 15.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danny321974345 at gmail dot com
  Target Milestone: ---

Here is a minimal example:
class Foo {
int a = 0;
int b;
};

int main() {
constexpr Foo foo{};
}

GCC Output:
: In function 'int main()':
:7:23: error: 'Foo{0}' is not a constant expression
7 | constexpr Foo foo{};
  |   ^
:7:23: error: 'Foo()' is not a constant expression because it refers to
an incompletely initialized variable
Compiler returned: 1

This code compiles successfully with both Clang and MSVC under the C++20
standard.

According to C++20, Foo is a literal type because it has an implicitly declared
constexpr default constructor. Value-initialization via Foo{} zero-initializes
all members, making the object fully initialized and suitable for use in a
constexpr context.

[Bug libfortran/120196] In findloc2_s* when "back" is true loop goes one more step than needed.

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed for 14.3/15.2/16+ so far.

[Bug c/118868] __builtin_assoc_barrier with pointers cause ICE

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #9 from Andrew Pinski  ---
Fixed.

[Bug libstdc++/67990] compare() does not sort null characters in locale collation order

[hstong at ca dot ibm.com via Gcc-bugs]

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

--- Comment #2 from Hubert Tong  ---
POSIX.1-2024 has added a note permitting POSIX interfaces to exhibit "unusual
behavior" for locales where  does not have the lowest primary weight in
the collation ordering:
https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap07.html

[Bug fortran/120191] Functions minloc() and maxloc() ignore the "back" parameter when "kind" is present.

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

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

--- Comment #16 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
:

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

commit r14-11772-ga79e30dabb6b3edc29f2656b7d480076a1f4d3bd
Author: Jakub Jelinek 
Date:   Tue May 13 14:19:25 2025 +0200

libfortran: Fix up _gfortran_s{max,min}loc1_{4,8,16}_s{1,4} [PR120191]

There is a bug in _gfortran_s{max,min}loc1_{4,8,16}_s{1,4} which the
following testcase shows.
The functions return but then crash in the caller.
Seems that is because buffer overflows, I believe those functions for
if (mask == NULL || *mask) condition being false are supposed to fill in
the result array with all zeros (or allocate it and fill it with zeros).
My understanding is the result array in that case is integer(kind={4,8,16})
and should have the extents the character input array has.
The problem is that it uses * string_len in the extent multiplication:
  extent[n] = GFC_DESCRIPTOR_EXTENT(array,n) * string_len;
and
  extent[n] =
GFC_DESCRIPTOR_EXTENT(array,n + 1) * string_len;
which is I guess fine and desirable for the extents of the character array,
but not for the extents of the destination array.  Yet the code uses
that extent array for that purpose (and no other purposes).
Here it uses it to set the dimensions for the case where it needs to
allocate (as well as size):
  for (n = 0; n < rank; n++)
{
  if (n == 0)
str = 1;
  else
str = GFC_DESCRIPTOR_STRIDE(retarray,n-1) * extent[n-1];
  GFC_DIMENSION_SET(retarray->dim[n], 0, extent[n] - 1, str);
}
Here it uses it for bounds checking of the destination:
  if (unlikely (compile_options.bounds_check))
{
  for (n=0; n < rank; n++)
{
  index_type ret_extent;

  ret_extent = GFC_DESCRIPTOR_EXTENT(retarray,n);
  if (extent[n] != ret_extent)
runtime_error ("Incorrect extent in return value of"
   " MAXLOC intrinsic in dimension %ld:"
   " is %ld, should be %ld", (long int) n + 1,
   (long int) ret_extent, (long int)
extent[n]);
}
}
and here to find out how many retarray elements to actually fill in each
dimension:
  while(1)
{
  *dest = 0;
  count[0]++;
  dest += dstride[0];
  n = 0;
  while (count[n] == extent[n])
{
  /* When we get to the end of a dimension, reset it and increment
 the next dimension.  */
  count[n] = 0;
  /* We could precalculate these products, but this is a less
 frequently used path so probably not worth it.  */
  dest -= dstride[n] * extent[n];
Seems maxloc1s.m4 and minloc1s.m4 are the only users of ifunction-s.m4,
so we can change SCALAR_ARRAY_FUNCTION in there without breaking anything
else.

2025-05-13  Jakub Jelinek  

PR fortran/120191
* m4/ifunction-s.m4 (SCALAR_ARRAY_FUNCTION): Don't multiply
GFC_DESCRIPTOR_EXTENT(array,) by string_len.
* generated/maxloc1_4_s1.c: Regenerate.
* generated/maxloc1_4_s4.c: Regenerate.
* generated/maxloc1_8_s1.c: Regenerate.
* generated/maxloc1_8_s4.c: Regenerate.
* generated/maxloc1_16_s1.c: Regenerate.
* generated/maxloc1_16_s4.c: Regenerate.
* generated/minloc1_4_s1.c: Regenerate.
* generated/minloc1_4_s4.c: Regenerate.
* generated/minloc1_8_s1.c: Regenerate.
* generated/minloc1_8_s4.c: Regenerate.
* generated/minloc1_16_s1.c: Regenerate.
* generated/minloc1_16_s4.c: Regenerate.

* gfortran.dg/pr120191_3.f90: New test.

(cherry picked from commit 781cfc454b8dc24952fe7f4c5c409296dca505e1)

[Bug fortran/120191] Functions minloc() and maxloc() ignore the "back" parameter when "kind" is present.

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

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

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

https://gcc.gnu.org/g:87c7061cc0acc99c8f580d5e76eba288db341807

commit r14-11771-g87c7061cc0acc99c8f580d5e76eba288db341807
Author: Jakub Jelinek 
Date:   Tue May 13 14:18:10 2025 +0200

libfortran: Fix up _gfortran_s{max,min}loc2_{4,8,16}_s{1,4} [PR120191]

I've tried to write a testcase for the BT_CHARACTER maxloc/minloc with
named
or unnamed arguments and indeed the just posted patch fixed the arguments
in there in multiple cases to match what the library expects.
But the testcase still fails, due to library problems.

One dealt with in this patch are _gfortran_s{max,min}loc2_{4,8,16}_s{1,4}
functions.  Those are trivial wrappers around
_gfortrani_{max,min}loc2_{4,8,16}_s{1,4} which should call those functions
if the scalar mask is true and just return 0 otherwise.
The two bugs I see there is that the back, len arguments are swapped,
which means that it always acts as back=.true. and for len will use
character length of 1 or 0 instead of the desired one.
The _gfortrani_{max,min}loc2_{4,8,16}_s{1,4} functions have prototypes like
GFC_INTEGER_4
maxloc2_4_s1 (gfc_array_s1 * const restrict array, GFC_LOGICAL_4 back,
gfc_charlen_type len)
so back comes before len, ditto for the
GFC_INTEGER_4
smaxloc2_4_s1 (gfc_array_s1 * const restrict array,
   GFC_LOGICAL_4 *mask, GFC_LOGICAL_4 back, gfc_charlen_type
len)
The other problem is that it was just testing if (mask).  In my limited
Fortran understanding that means that the optional argument mask was
supplied but nothing about its actual value.  Other scalar mask generated
routines use if (mask == NULL || *mask) as the condition when to call the
non-masked function, i.e. when mask is not supplied (then it should act
like
.true. mask) or when it is supplied and evaluates to .true.).

2025-05-13  Jakub Jelinek  

PR fortran/120191
* m4/maxloc2s.m4: For smaxloc2 call maxloc2 if mask is NULL or
*mask.
Swap back and len arguments.
* m4/minloc2s.m4: Likewise.
* generated/maxloc2_4_s1.c: Regenerate.
* generated/maxloc2_4_s4.c: Regenerate.
* generated/maxloc2_8_s1.c: Regenerate.
* generated/maxloc2_8_s4.c: Regenerate.
* generated/maxloc2_16_s1.c: Regenerate.
* generated/maxloc2_16_s4.c: Regenerate.
* generated/minloc2_4_s1.c: Regenerate.
* generated/minloc2_4_s4.c: Regenerate.
* generated/minloc2_8_s1.c: Regenerate.
* generated/minloc2_8_s4.c: Regenerate.
* generated/minloc2_16_s1.c: Regenerate.
* generated/minloc2_16_s4.c: Regenerate.

* gfortran.dg/pr120191_2.f90: New test.

(cherry picked from commit 482f2192d4ef6af55acae2dc3e0df00b8487cc7d)

[Bug fortran/120191] Functions minloc() and maxloc() ignore the "back" parameter when "kind" is present.

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #17 from Jakub Jelinek  ---
Fixed for 14.3/15.2/16+ for now.

[Bug tree-optimization/119903] [13/14/15/16 Regression] non-call exception vs traping comparison

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|13.4|16.0
 Status|ASSIGNED|RESOLVED

--- Comment #7 from Andrew Pinski  ---
Fixed on the trunk, I found this when I was fixing up forwprop and I doubt
anyone has run into this and even uses non-call exceptions with trapping math
that often.

[Bug libfortran/120196] In findloc2_s* when "back" is true loop goes one more step than needed.

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

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:627d83c2b196340cccaee8bb4032fade7ad6

commit r14-11773-g627d83c2b196340cccaee8bb4032fade7ad6
Author: Jakub Jelinek 
Date:   Tue May 13 14:20:22 2025 +0200

libfortran: Fix up _gfortran_{,m,s}findloc2_s{1,4} [PR120196]

As mentioned in the PR, _gfortran_{,m,s}findloc2_s{1,4} iterate too many
times in the back case if nothing is found.
For !back, the loops are for (i = 1; i <= extent; i++) so i is in the
body [1, extent] if nothing is found, but for back it is
for (i = extent; i >= 0; i--) so i is in the body [0, extent] and compares
one element before the start of the array.
Note, findloc1_s{1,4} uses
  for (n = len; n > 0; n--, src -= delta * len_array)
for the back loop and
  for (n = 1; n <= len; n++, src += delta * len_array)
for !back.  This patch fixes that.
The testcase fails under valgrind without the libgfortran changes and
succeeds with those.

2025-05-13  Jakub Jelinek  

PR libfortran/120196
* m4/ifindloc2.m4 (header1, header2): For back use i > 0 rather
than
i >= 0 as for condition.
* generated/findloc2_s1.c: Regenerate.
* generated/findloc2_s4.c: Regenerate.

* gfortran.dg/pr120196.f90: New test.

(cherry picked from commit 748a7bc4624e7b000f6fdb93a8cf7da73ff193bb)

[Bug fortran/120191] Functions minloc() and maxloc() ignore the "back" parameter when "kind" is present.

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

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

--- Comment #14 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
:

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

commit r14-11770-gc12443e824cf96311db7a1be82b3626909c8ceeb
Author: Jakub Jelinek 
Date:   Tue May 13 14:14:55 2025 +0200

fortran: Fix up minloc/maxloc lowering [PR120191]

We need to drop the kind argument from what is passed to the
library, but need to do it not only when one uses the argument name
for it (so kind=4 etc.) but also when one passes all the arguments
to the intrinsics.

The following patch uses what gfc_conv_intrinsic_findloc uses,
which looks more efficient and cleaner, we already set automatic
vars to point to the kind and back actual arguments, so we can just
free/clear expr on the former and set name to "%VAL" on the latter.

And similarly clears dim argument for the BT_CHARACTER case when using
maxloc2/minloc2, again regardless of whether it was named or not.

2025-05-13  Jakub Jelinek  
Daniil Kochergin  
Tobias Burnus  

PR fortran/120191
* trans-intrinsic.cc (strip_kind_from_actual): Remove.
(gfc_conv_intrinsic_minmaxloc): Don't call strip_kind_from_actual.
Free and clear kind_arg->expr if non-NULL.  Set back_arg->name to
"%VAL" instead of a loop looking for last argument.  Remove actual
variable, use array_arg instead.  Free and clear dim_arg->expr if
non-NULL for BT_CHARACTER cases instead of using a loop.

* gfortran.dg/pr120191_1.f90: New test.

(cherry picked from commit ec249be3c287c6f1dfb328712ac9c39e6fa95eca)

[Bug tree-optimization/120254] wrong code at -O3 on x86_64-pc-linux-gnu

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|needs-bisection |

--- Comment #5 from Jakub Jelinek  ---
With -O3 -fwrapv this started with
r8-5164-gfbdec14e80e9399cd301ed30340268bdc5b5c2eb
aka introduction of -floop-interchange.