[Bug target/120186] [pa] internal compiler error: in fail, at selftest.cc:47 during bootstrap with LRA enabled

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #5 from John Paul Adrian Glaubitz  ---
(In reply to John David Anglin from comment #3)
> I presume you edited pa.opt to enable LRA.

Yes.

> Would you provide full configure command and relevant environment options.

I built with:

./configure --disable-multilib --enable-multiarch --enable-bootstrap
--enable-languages=c,c++ && make -j32

I applied the following three Debian patches for proper MultiArch support:

https://salsa.debian.org/toolchain-team/gcc/-/blob/gcc-14-debian/debian/patches/g++-multiarch-incdir.diff

https://salsa.debian.org/toolchain-team/gcc/-/blob/gcc-14-debian/debian/patches/gcc-multiarch.diff

https://salsa.debian.org/toolchain-team/gcc/-/blob/gcc-14-debian/debian/patches/gcc-multilib-multiarch.diff

> You might try building with old reload.

Can do that later.

> My last build of gcc-16 was at revision r16-175-g1c5cf7cc82d.

With LRA enabled?

> Probably, we will need to bisect this bug.
> 
> I'm currently working on fixing Debian builds of gcc-12 and gcc-13 on hppa.
> There is a report that gcc-15 is also broken...

OK.

[Bug ipa/120048] [14/15/16 Regression] ICE on valid code at -O{s,2} with "-fno-tree-vrp -fno-tree-fre" on x86_64-linux-gnu: in type, at value-range.h:982 since r16-244-gce489c870bf28e

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

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

--- Comment #15 from Andrew Macleod  ---
Yes fixed for gcc 14 forward.

[Bug target/120201] G++ generates a misaligned vector operation for std::memcpy

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

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

--- Comment #1 from Andrew Pinski  ---
I can't reproduce this on the trunk but I am running on a skylake-avx512
machine.

Can you provide the -v output as requested?

[Bug target/120201] G++ generates a misaligned vector operation for std::memcpy

[stuart.a.hayhurst at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Stuart  ---
Sure, sorry if the bug report was a little slapdash, my dinner was ready to
come out of the oven :)

g++ test.cpp -O3 -march=native -fsanitize=address -std=c++23 -g -v:

```
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-gnu/14/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 14.2.0-19'
--with-bugurl=file:///usr/share/doc/gcc-14/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2,rust --prefix=/usr
--with-gcc-major-version-only --program-suffix=-14
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-libstdcxx-backtrace
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/reproducible-path/gcc-14-14.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/reproducible-path/gcc-14-14.2.0/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=3
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.2.0 (Debian 14.2.0-19) 
COLLECT_GCC_OPTIONS='-O3' '-march=native' '-fsanitize=address' '-std=c++23'
'-g' '-v' '-foffload-options=-l_GCC_m' '-shared-libgcc' '-dumpdir' 'a-'
 /usr/libexec/gcc/x86_64-linux-gnu/14/cc1plus -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE test.cpp -march=znver4 -mmmx -mpopcnt -msse
-msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx -mavx2 -msse4a -mno-fma4 -mno-xop
-mfma -mavx512f -mbmi -mbmi2 -maes -mpclmul -mavx512vl -mavx512bw -mavx512dq
-mavx512cd -mavx512vbmi -mavx512ifma -mavx512vpopcntdq -mavx512vbmi2 -mgfni
-mvpclmulqdq -mavx512vnni -mavx512bitalg -mavx512bf16 -mno-avx512vp2intersect
-mno-3dnow -madx -mabm -mno-cldemote -mclflushopt -mclwb -mclzero -mcx16
-mno-enqcmd -mf16c -mfsgsbase -mfxsr -mno-hle -msahf -mno-lwp -mlzcnt -mmovbe
-mno-movdir64b -mno-movdiri -mmwaitx -mno-pconfig -mpku -mprfchw -mno-ptwrite
-mrdpid -mrdrnd -mrdseed -mno-rtm -mno-serialize -mno-sgx -msha -mshstk
-mno-tbm -mno-tsxldtrk -mvaes -mno-waitpkg -mwbnoinvd -mxsave -mxsavec
-mxsaveopt -mxsaves -mno-amx-tile -mno-amx-int8 -mno-amx-bf16 -mno-uintr
-mno-hreset -mno-kl -mno-widekl -mno-avxvnni -mno-avx512fp16 -mno-avxifma
-mno-avxvnniint8 -mno-avxneconvert -mno-cmpccxadd -mno-amx-fp16 -mno-prefetchi
-mno-raoint -mno-amx-complex -mno-avxvnniint16 -mno-sm3 -mno-sha512 -mno-sm4
-mno-apxf -mno-usermsr --param l1-cache-size=32 --param l1-cache-line-size=64
--param l2-cache-size=1024 -mtune=znver4 -quiet -dumpdir a- -dumpbase test.cpp
-dumpbase-ext .cpp -g -O3 -std=c++23 -version -fsanitize=address
-foffload-options=-l_GCC_m -fasynchronous-unwind-tables -o /tmp/ccz9XEbY.s
GNU C++23 (Debian 14.2.0-19) version 14.2.0 (x86_64-linux-gnu)
compiled by GNU C version 14.2.0, GMP version 6.3.0, MPFR version
4.2.1, MPC version 1.3.1, isl version isl-0.27-GMP

warning: MPFR header version 4.2.1 differs from library version 4.2.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/14"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/14/include-fixed/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/14/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/14/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/14
 /usr/include/x86_64-linux-gnu/c++/14
 /usr/include/c++/14/backward
 /usr/lib/gcc/x86_64-linux-gnu/14/include
 /usr/local/include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
Compiler executable checksum: a0e1d70a4b6c50c7ed1b3d36dfd3f9a4
COLLECT_GCC_OPTIONS='-O3' '-march=native' '-fsanitize=address' '-std=c++23'
'-g' '-v' '-foffload-options=-l_GCC_m' '-shared-libgcc' '-dumpdir' 'a-'
 as -v --gdwarf-5 --64 -o /tmp/ccWB8VmV.o /tmp/ccz9XEbY.s
GNU assembler version 2.44 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Debian) 2.44
COMPILER_PATH=/usr/libexec/gcc/x86_64-linux-gnu/14/:/usr/libexec/gcc/x86_64-linux-gnu/14/:/usr/libexec/gcc/x86_64-linux-

[Bug target/120201] G++ generates a misaligned vector operation for std::memcpy

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-05-09

--- Comment #3 from Andrew Pinski  ---
Partition 0: size 384 align 16
transforms

That looks correct.

But this looks wrong:
;; [t.cc:17:20] _34 = [t.cc:17:20] MEM  [(char *
{ref-all})&transforms];

(insn 98 97 0 (set (reg:V64QI 111 [ _34 ])
(mem/c:V64QI (plus:DI (reg:DI 899)
(const_int -448 [0xfe40])) [0 [t.cc:17:20] MEM
 [(char * {ref-all})&transforms]+0 S64 A512]))
"t.cc":17:20 -1
 (nil))

Notice the 512 bit alignment.

But the alignment is correct in gimple:
  _34 = __MEM  ((char *
{ref-all})&transforms);

Note the 8 which is 128 bit aligned.

Note this needs -march=znver4 as -march=skylake-avx512 does not unroll the loop
(I have not looked why though).

[Bug tree-optimization/119712] [14 Regression] compiler hang at -O{1,2,3,s} since r14-5109

[amacleod at redhat dot com via Gcc-bugs]

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

Bug 120048 Summary: [14/15/16 Regression] ICE on valid code at -O{s,2} with 
"-fno-tree-vrp -fno-tree-fre" on x86_64-linux-gnu: in type, at 
value-range.h:982 since r16-244-gce489c870bf28e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120048

   What|Removed |Added

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

[Bug preprocessor/119753] gcc -E is not POSIX-compliant

[love4boobies at yahoo dot com via Gcc-bugs]

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

--- Comment #10 from Bogdan  ---
Actually, EDG seems to have a GCC compatibility mode on godbolt where it
doesn't use the #line format. I haven't tested to see whether it prints flags
or not, just wanted wanted to correct that bit.

[Bug target/118603] aarch64-cores.def causes narrowing conversion warnings due to -1 for variant

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

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

--- Comment #2 from Andrew Pinski  ---
Patch finally submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2025-May/683175.html

[Bug fortran/120049] ICE when using IS_C_ASSOCIATED ()

[kargls at comcast dot net via Gcc-bugs]

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

--- Comment #25 from kargls at comcast dot net ---
On 5/9/25 20:22, jvdelisle at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120049
> 
> --- Comment #24 from Jerry DeLisle  ---
> It is interestingly complex. As I try different test cases I learn new things.

Yes, it is.  The iso_c_binding module is built-on-fly by the compiler.
You'll find checks in various places (see, primary.cc lines 4048-4062).
The functions supplied with the module are sort of treated as
intrinsic subprogram, but their actual not.

[Bug middle-end/120205] [15/16 regression] unifdef miscompiled since r15-5597-g684595188dea02

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #12 from Andrew Pinski  ---
.

[Bug fortran/120049] ICE when using IS_C_ASSOCIATED ()

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

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #21 from Jerry DeLisle  ---
I have been digging in on this further. The basic types are defined in
libgfortran.h as shown here:

typedef enum
{ BT_UNKNOWN = 0, BT_INTEGER, BT_LOGICAL, BT_REAL, BT_COMPLEX,
  BT_DERIVED, BT_CHARACTER, BT_CLASS, BT_PROCEDURE, BT_HOLLERITH, BT_VOID,
  BT_ASSUMED, BT_UNION, BT_BOZ, BT_UNSIGNED
}
bt;

I have been checking for each one of these and building a test case. Obviously
our original checks based on (ts.type != BT_DERIVED) is too broad and short
circuiting based on the expr_type is too narrow. The simpler types BT_INTEGER,
BT_LOGICAL, BT_REAL, BT_COMPLEX, BT_CHARACTER, BT_HOLLERITH, BT_BOZ,
BT_UNSIGNED I think can be rejected


The BT_CLASS, BT_PROCEDURE, BT_ASSUMED, BT_UNION seem to not make sense to me
either. Steve, what do yo think about these last types. I can easily reject
them as well.

Look at my WIP patch now I am pretty sure I will be able to re-factor this code
and I will work on this while waiting for further feedback on this.

[Bug tree-optimization/114999] A few missing optimizations due to `a - b` and `b - a` not being detected as negatives of each other

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

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

--- Comment #15 from Andrew Pinski  ---
(In reply to Jennifer Schmitz from comment #12)
> Created attachment 60149 [details]
> Proposed patch for detecting abs diff for signed integers

Note the change for `-(A - B) -> B - A` with the addition of a nop_convert can
introduce a signed integer overflow if the cast is from signed to unsigned.

That is:

`-(unsigned)(int1 = int2)` is not the same as `(unsigned)(int2 - int1)` if int1
is INT_MIN and int2 is 0.  The subtraction has to be done in unsigned type to
be valid transformation.

The other way around is a problem too:
`-(signed)(unsigned1 - unsigned2)`
that is take unsigned1 == 1 and unsigned2 = (unsigned)INT_MIN. INT_MIN-1 would
have an overflow; but the original (1-(unsigned)INT_MIN) is well defined (for
32bit it is -2147483647) and taking negative of that also would be well defined
in signed integer.

[Bug fortran/120049] ICE when using IS_C_ASSOCIATED ()

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

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

--- Comment #24 from Jerry DeLisle  ---
It is interestingly complex. As I try different test cases I learn new things.

For example this error is caught already somewhere else in the code path. I am
going to identify where tomorrow. This may be a better place to do some of this
checking.

test.f90:30:24:

   30 |   print *, c_associated(42)
  |1
Error: Argument C_PTR_1 at (1) to C_ASSOCIATED shall have the type TYPE(C_PTR)
or TYPE(C_FUNPTR)

I found this only because my draft patch caught this and I found a test failure
in the testsuite, My error message was different. In c_assoc_2.f03:

if(.not. c_associated(my_integer)) then ! { dg-error "shall have the type
   TYPE.C_PTR. or TYPE.C_FUNPTR." }
   STOP 6
end if

[Bug middle-end/120205] [15/16 regression] unifdef miscompiled since r15-5597-g684595188dea02

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

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

Sam James  changed:

   What|Removed |Added

Summary|[15/16 regression] unifdef  |[15/16 regression] unifdef
   |miscompiled |miscompiled since
   ||r15-5597-g684595188dea02
 CC||siddhesh at gcc dot gnu.org

--- Comment #11 from Sam James  ---
r15-5597-g684595188dea02

[Bug libstdc++/119714] [15/16 Regression] Failure when using == operator on a class derived from std::expected

[erikbsolem at hotmail dot com via Gcc-bugs]

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

Erik Bråthen Solem  changed:

   What|Removed |Added

 CC||erikbsolem at hotmail dot com

--- Comment #5 from Erik Bråthen Solem  ---
So the problematic equality operator is:

template< class T2 >
friend constexpr bool operator==( const expected& lhs, const T2& val );

In GCC 15’s  header the definition looks like this after the
constraints were added:

  template
requires (!__expected::__is_expected<_Up>)
  && requires (const _Tp& __t, const _Up& __u) {
{ __t == __u } -> convertible_to;
  }
friend constexpr bool
operator==(const expected& __x, const _Up& __v)
noexcept(noexcept(bool(*__x == __v)))
{ return __x.has_value() && bool(*__x == __v); }

According to cppreference this operator requires that *lhs == val is
well-formed, with the exact wording being changed between C++23 and C++26.
Perhaps a dumb question, but should it not be

 { *__t == __u } -> convertible_to;

then, instead of

 { __t == __u } -> convertible_to;

i.e., with the asterisk? Since it is the contained value of lhs (not the
container) that must be comparable to val?

I tried the following comparisons:

expected e = 42;
function()> fun;

fun == nullptr;
*e == fun;

- GCC 14.2 accepts both comparisons (but the program SEGFAULTs upon execution
because *e == fun does not make sense).
- GCC 15.1 reports this circular dependency for both.
- GCC 15.1 where I manually edited expected as suggested above accepts the
first one and rejects the second one, this time with the correct “no match for
'operator=='” message, and the printout shows that the candidate operator in
question is skipped with reason “constraints not satisfied” (and not because
something depends on itself).

[Bug fortran/120049] ICE when using IS_C_ASSOCIATED ()

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

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

--- Comment #22 from Jerry DeLisle  ---
I forgot to mention that when you flip the test example around:

  print *, c_associated(42, c_loc(val))

It also gives an internal error. So I am taking care of it as well.

[Bug tree-optimization/120206] Removal of forward_propagate_into_gimple_cond/forward_propagate_into_comparison

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

[Bug tree-optimization/120206] Removal of forward_propagate_into_gimple_cond/forward_propagate_into_comparison

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

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 61390
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61390&action=edit
Current patch

This includes some additional match.pd pattern changes which I will submit
seperately but tree-ssa.exp is clean.

[Bug c++/120136] [12/13/14/15/16 Regression] internal compiler error: tree check: accessed elt 1 of 'tree_vec' with -1 elts in add_to_template_args, at cp/pt.cc:612

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

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

--- Comment #6 from Andrew Pinski  ---
Note the ICE only happens for comment #0 if configured with
--enable-checking=yes (which is the default on the trunk).

[Bug target/120181] Bug in alpha jump tables

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #11 from John Paul Adrian Glaubitz  ---
(In reply to camm from comment #10)
> Greetings!  It is a linker issue -- thanks again for the suggestion and all
> the other comments.  Closing this now.

Could you please link to the binutils issue if you filed one?

[Bug c++/120183] Incomplete type error in module import

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

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

Nathaniel Shead  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 CC||nshead at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Nathaniel Shead  ---
Thanks for the report!  This appears to be an issue with the CNTTP used here,
and works on trunk, so resolving as duplicate.

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

[Bug c++/103524] [meta-bug] modules issue

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

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

Bug 120183 Summary: Incomplete type error in module import
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120183

   What|Removed |Added

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

[Bug c++/119938] [15/16 Regression][modules] Class type NTTPs are not considered constant when imported

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

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

Nathaniel Shead  changed:

   What|Removed |Added

 CC||rafel.perello at upc dot edu

--- Comment #4 from Nathaniel Shead  ---
*** Bug 120183 has been marked as a duplicate of this bug. ***

[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

--- Comment #4 from Jakub Jelinek  ---
Yes.  You need to write a ChangeLog entry, which would be in this case I think
something like
PR fortran/120191
* trans-intrinsic.cc (gfc_conv_intrinsic_minmaxloc):
Call strip_kind_from_actual unconditionally.

* gfortran.dg/pr120191.f90: New test.
(though with tabs instead of 8 spaces).

[Bug other/105404] Update in-tree copy of zlib to zlib-1.3.1

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

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

--- Comment #17 from Iain Sandoe  ---
(In reply to Joel Sherrill from comment #16)
> Over at RTEMS.org, we have a report from a Mac user that the gcc zlib needs
> updating or patched to build there. We are seeing this with GCC 13 but the
> version looks to be the same back to at least GCC 11.
> 
> Just confirming that there are GCC/RTEMS users who noticed this and asked.
> We are not carrying a patch for GCC to be able to build this zlib on new
> MacOS. 
> 
> Updating GCC master to have a new zlib obviously will not help avoid the
> need for patches in the near future. But it's a good move.

note that the issue on macOS starts with Xcode16.3 on recent OS versions which
have an up to date installed zlib (so the --with-system-zlib is a reasonable
work-around).

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

[daniil2472s at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Daniil Kochergin  ---
Done. Thank you!

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

[daniil2472s at gmail dot com via Gcc-bugs]

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

Bug ID: 120196
   Summary: In findloc2_s* when "back" is true loop goes one more
step than needed.
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniil2472s at gmail dot com
  Target Milestone: ---

Greetings!

Found a bug that actually doesn't have any effects in tests.

In findloc2_s1.c, findloc2_s4.c, and corresponding ifindloc2.m4, there are two
functions, findloc2_s* and mfindloc2_s*, with the following problem.

When "back" is true loop goes one more step than needed.

$ cat /libgfortran/generated/findloc2_s1.c
...
index_type
findloc2_s1 (gfc_array_s1 * const restrict array, const GFC_UINTEGER_1 *
restrict value,
  GFC_LOGICAL_4 back,
  gfc_charlen_type len_array, gfc_charlen_type len_value)
...
  if (back)
{
  src = array->base_addr + (extent - 1) * sstride;
  for (i = extent; i >= 0; i--)
{
  if (compare_string (len_array, (char *) src, len_value, (char *)
value) == 0)
return i;
  src -= sstride;
}
}
  else
{
  src = array->base_addr;
  for (i = 1; i <= extent; i++)
{
  if (compare_string (len_array, (char *) src, len_value, (char *)
value) == 0)
return i;
  src += sstride;
}
}
...

Please note following string: 
for (i = extent; i >= 0; i--)
It must be constraints with i >= 1 or i > 0.

I couldn't create any test that failed due to the mistake, because when the
required value lies beyond the string bound, the function returns 0, like it
hasn't found any value. To prove that there are mistakes, we can count the
number of steps when "back" is false or compare with other findlocs.

For example:
$ cat findloc1_i4.c
...
extern void
findloc1_i4 (gfc_array_index_type * const restrict retarray,
gfc_array_i4 * const restrict array, GFC_INTEGER_4 value,
const index_type * restrict pdim, GFC_LOGICAL_4 back)
...
  if (back)
{
  src = base + (len - 1) * delta * 1;
  for (n = len; n > 0; n--, src -= delta * 1)
{
  if (*src == value)
{
  result = n;
  break;
}
}
}
  else
{
  src = base;
  for (n = 1; n <= len; n++, src += delta * 1)
{
  if (*src == value)
{
  result = n;
  break;
}
}
}
...

[Bug c/107308] ICE in expand_fn_using_insn, at internal-fn.cc:153

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> Created attachment 61374 [details]
> Verifier in testing

I had some typos in the patch. And CRC/CRC_REV needs to be handled special. Oh
and ifcvt inserts COND_* in some cases (correctly) but this patch does not
handle that case at all. We need a new property that says COND_* for scalars
are allowed and which ifcvt will set and the vectorizer will remove. I won't be
able to get to this until next week at the earliest.

[Bug c++/118388] ICEs from c++ testsuite when run with -fpermissive due to seen_error () not counting "downgraded errors"

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

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

--- Comment #5 from Simon Martin  ---
Some of the tests from comment #4 are either not linked to seen_error
(unary_trait_incomplete.C), or use constexpr_error that bypasses some of the
diagnostics machinery and are not easy to fix (constexpr-ice20.C), or continue
to fail only in C++98 mode (inh-ctor37.C). I won't tackle them just now.

The updated list of tests that I'll address via this ticket is therefore

- g++.dg/cpp0x/lambda/lambda-ice21.C
- g++.dg/cpp0x/lambda/lambda-ice5.C
- g++.dg/cpp0x/noexcept28.C
- g++.dg/cpp0x/pr31437.C
- g++.dg/cpp0x/pr34056.C
- g++.dg/cpp2a/lambda-uneval25.C

[Bug modula2/120188] documented example does not work

[bruno at clisp dot org via Gcc-bugs]

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

--- Comment #4 from Bruno Haible  ---
> I suspect gm2-15.1 is the same.

Yes, in 15.1.0, with the option -fm2-plugin, I get the same output as you
showed.

[Bug tree-optimization/114166] word_mode vectorization still relies on vector lowering

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
I think this is now fixed (not SLP producing vector(1)).

[Bug tree-optimization/114166] word_mode vectorization still relies on vector lowering

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

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

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

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

commit r16-501-ga470433732e77ae29a717cf79049ceeea3cbe979
Author: Richard Biener 
Date:   Fri May 9 13:48:21 2025 +0200

tree-optimization/114166 - vectorize to lowered form with word_mode

The following adjusts the non-PLUS/MINUS/NEGATE_EXPR vectorizations
of "word_mode" vectors to emit the form vector lowering will later use.
This allows us to move the vector lowering pass before vectorization,
specifically closing the gap between vectorization and lowering,
so we can eventually assert the vectorizer doesn't emit any code
that's not directly supported by the target.

PR tree-optimization/114166
* tree-vect-stmts.cc (vectorizable_operation): Lower also
bitwise operations on word-mode vectors.

[Bug c/120192] New: Internal compiler error when building ring Rust crate

[filip.stamcar at hotmail dot com via Gcc-bugs]

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

Bug ID: 120192
   Summary: Internal compiler error when building ring Rust crate
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: filip.stamcar at hotmail dot com
  Target Milestone: ---

When building a Rust project that depends on a ring
(https://github.com/briansmith/ring) Rust crate using
`stable-x86_64-pc-windows-gnu` toolchain on Windows, I get internal compiler
error:

❯ cargo build  
   Compiling yoke v0.7.5
   Compiling socket2 v0.5.9
   Compiling mio v1.0.3
   Compiling darling_macro v0.20.11
   Compiling dioxus-core v0.6.3
   Compiling gemm-common v0.17.1
   Compiling ring v0.17.14
   Compiling aho-corasick v1.1.3
   Compiling rustls-pki-types v1.11.0
   Compiling indexmap v2.9.0
   Compiling phf v0.11.3
   Compiling untrusted v0.9.0
   Compiling precomputed-hash v0.1.1
warning: ring@0.17.14: during RTL pass: expand  
warning: ring@0.17.14: In file included from
E:\Cache\rust\cargo\registry\src\index.crates.io-1949cf8c6b5b557f\ring-0.17.14\crypto/curve25519/internal.h:20,
warning: ring@0.17.14:  from
E:\Cache\rust\cargo\registry\src\index.crates.io-1949cf8c6b5b557f\ring-0.17.14\crypto/curve25519/curve25519.c:24:
warning: ring@0.17.14:
E:/Cache/rust/cargo/registry/src/index.crates.io-1949cf8c6b5b557f/ring-0.17.14/crypto/internal.h:
In function 'constant_time_conditional_memxor':
warning: ring@0.17.14:
E:/Cache/rust/cargo/registry/src/index.crates.io-1949cf8c6b5b557f/ring-0.17.14/crypto/internal.h:260:20:
internal compiler error: in expand_one_stack_var_1, at cfgexpand.cc:1738
warning: ring@0.17.14:   260 | static inline void
constant_time_conditional_memxor(void *dst, const void *src,
warning: ring@0.17.14:   |   
^~~~
warning: ring@0.17.14: Please submit a full bug report, with
preprocessed source (by using -freport-bug).
warning: ring@0.17.14: See  for
instructions.
error: failed to run custom build command for `ring v0.17.14`

Caused by:
  process didn't exit successfully:
`E:\Projects\School\SrednjeveskiArhivi\target\debug\build\ring-f4c4918d144c179c\build-script-build`
(exit code: 1)
  --- stdout
  cargo:rerun-if-env-changed=CARGO_MANIFEST_DIR
  cargo:rerun-if-env-changed=CARGO_PKG_NAME
  cargo:rerun-if-env-changed=CARGO_PKG_VERSION_MAJOR
  cargo:rerun-if-env-changed=CARGO_PKG_VERSION_MINOR
  cargo:rerun-if-env-changed=CARGO_PKG_VERSION_PATCH
  cargo:rerun-if-env-changed=CARGO_PKG_VERSION_PRE
  cargo:rerun-if-env-changed=CARGO_MANIFEST_LINKS
  cargo:rerun-if-env-changed=RING_PREGENERATE_ASM
  cargo:rerun-if-env-changed=OUT_DIR
  cargo:rerun-if-env-changed=CARGO_CFG_TARGET_ARCH
  cargo:rerun-if-env-changed=CARGO_CFG_TARGET_OS
  cargo:rerun-if-env-changed=CARGO_CFG_TARGET_ENV
  cargo:rerun-if-env-changed=CARGO_CFG_TARGET_ENDIAN
  OPT_LEVEL = Some(0)
  OUT_DIR =
Some(E:\Projects\School\SrednjeveskiArhivi\target\debug\build\ring-2f9bf6e1f47e27e4\out)
  TARGET = Some(x86_64-pc-windows-gnu)
  HOST = Some(x86_64-pc-windows-gnu)
  cargo:rerun-if-env-changed=CC_x86_64-pc-windows-gnu
  CC_x86_64-pc-windows-gnu = None
  cargo:rerun-if-env-changed=CC_x86_64_pc_windows_gnu
  CC_x86_64_pc_windows_gnu = None
  cargo:rerun-if-env-changed=HOST_CC
  HOST_CC = None
  cargo:rerun-if-env-changed=CC
  CC = None
  cargo:rerun-if-env-changed=CC_ENABLE_DEBUG_OUTPUT
  RUSTC_WRAPPER = None
  cargo:rerun-if-env-changed=CRATE_CC_NO_DEFAULTS
  CRATE_CC_NO_DEFAULTS = None
  DEBUG = Some(true)
  CARGO_CFG_TARGET_FEATURE =
Some(adx,aes,avx,avx2,bmi1,bmi2,cmpxchg16b,f16c,fma,fxsr,lzcnt,movbe,pclmulqdq,popcnt,rdrand,rdseed,sha,sse,sse2,sse3,sse4.1,sse4.2,ssse3,xsave,xsavec,xsaveopt,xsaves)
  cargo:rerun-if-env-changed=CFLAGS
  CFLAGS = Some(-march=native)
  cargo:rerun-if-env-changed=CC_SHELL_ESCAPED_FLAGS
  CC_SHELL_ESCAPED_FLAGS = None
  cargo:rerun-if-env-changed=HOST_CFLAGS
  HOST_CFLAGS = None
  cargo:rerun-if-env-changed=CFLAGS_x86_64_pc_windows_gnu
  CFLAGS_x86_64_pc_windows_gnu = None
  cargo:rerun-if-env-changed=CFLAGS_x86_64-pc-windows-gnu
  CFLAGS_x86_64-pc-windows-gnu = None
  CARGO_ENCODED_RUSTFLAGS = Some(-Ctarget-cpu=native)
  cargo:warning=during R

[Bug c++/120197] New: ICE in GCC with decltype(cout << a) in default function parameter leads to recursive diagnostics with -std=c++20

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

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

Bug ID: 120197
   Summary: ICE in GCC with decltype(cout << a) in default
function parameter leads to recursive diagnostics with
-std=c++20
   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: ---

Using decltype(cout << a) as a default argument causes GCC to enter
error-reporting routines recursively when a is deduced to a stream type,
leading to an internal compiler error.

```
#include 
using namespace std;
template 
void myFunc(T a, decltype(cout << a) o=cout) {
  cout << o << endl;
}
int main() {
  myFunc(5);
}
```

Not a specific ICE is shown in trunk, just: internal compiler error: error
reporting routines re-entered.

```
internal compiler error: error reporting routines re-entered.


internal compiler error: error reporting routines re-entered.
0x293b1be diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x293b2d5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2954bdf error_at(unsigned long, char const*, ...)
???:0
0xb59baa satisfaction_cache::get()
???:0
0xb60248 constraints_satisfied_p(tree_node*, tree_node*)
???:0
0xd32096 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xd3176b tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xd4e9bd instantiate_template(tree_node*, tree_node*, int)
???:0
0xd59dc6 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
???:0
0xb104a6 build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, int)
???:0
0xdbada2 build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node*, tree_node**, int)
???:0
0xd3195d tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x2978ca3 pretty_printer::format(text_info&)
???:0
0x297e463 pp_verbatim(pretty_printer*, char const*, ...)
???:0
0x29529a8 diagnostic_text_output_format::on_report_diagnostic(diagnostic_info
const&, diagnostic_t)
???:0
0x293ae26 diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x293b2d5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x29552f6 internal_error(char const*, ...)
???:0
0xad6166 fancy_abort(char const*, int, char const*)
???:0
0x293a6eb diagnostic_context::finish()
???:0
```

It happens in trunk and from version 11.2

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

[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 #20 from John David Anglin  ---
(In reply to John David Anglin from comment #19)
> It's not clear why gcov-30 passes on Linux.  I searched the entire tree and
> couldn't find how TARGET_HAVE_LIBATOMIC gets set on Linux.  Also, always
> setting TARGET_HAVE_LIBATOMIC to true doesn't seem 100% correct because I
> believe it's possible to disable building libatomic.

It's not set on Linux.

I see issue.  We have in tree-profile.cc:

 /* Verify whether we can utilize atomic update operations.  */
  bool can_support_atomic = targetm.have_libatomic;
  unsigned HOST_WIDE_INT gcov_type_size
= tree_to_uhwi (TYPE_SIZE_UNIT (get_gcov_type ()));
  bool have_atomic_4
= HAVE_sync_compare_and_swapsi || HAVE_atomic_compare_and_swapsi;
  bool have_atomic_8
= HAVE_sync_compare_and_swapdi || HAVE_atomic_compare_and_swapdi;
  bool needs_split = gcov_type_size == 8 && !have_atomic_8 && have_atomic_4;
  if (!can_support_atomic)
{
  if (gcov_type_size == 4)
can_support_atomic = have_atomic_4;
  else if (gcov_type_size == 8)
can_support_atomic = have_atomic_8;
}

HAVE_sync_compare_and_swapdi isn't defined because this operation is
implemented as a libcall.  This is also true on Linux but we have
in pa-linux.h:

/* The SYNC operations are implemented as library functions, not
   INSN patterns.  As a result, the HAVE defines for the patterns are
   not defined.  We need to define them to generate the corresponding
   __GCC_HAVE_SYNC_COMPARE_AND_SWAP_* and __GCC_ATOMIC_*_LOCK_FREE
   defines.  */

#define HAVE_sync_compare_and_swapqi 1
#define HAVE_sync_compare_and_swaphi 1
#define HAVE_sync_compare_and_swapsi 1
#define HAVE_sync_compare_and_swapdi 1

[Bug c++/120185] [16 Regression] nss-3.11 ICE since r16-479-gabab79397ef97a in type_has_converting_constructor

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

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

--- Comment #3 from Sergei Trofimovich  ---
The change also fixed nss-3.11 build for me. Thank you!

[Bug middle-end/120192] Internal compiler error when building ring Rust crate

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||needs-source
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2025-05-09

--- Comment #2 from Andrew Pinski  ---
Since this looks like it is c code that is causing the ice please supply the
preprocessed source?

[Bug fortran/120193] New: Incorrect debug info for unsigned(kind=1) and unsigned(kind=4)

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

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

Bug ID: 120193
   Summary: Incorrect debug info for unsigned(kind=1) and
unsigned(kind=4)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

unsigned(kind=1) :: a(2), e
  unsigned(kind=2) :: b(2), f
  unsigned(kind=4) :: c(2), g
  unsigned(kind=8) :: d(2), h
  a = 1u_1
  b = 1u_2
  c = 1u_4
  d = 1u_8
  e = 1u_1
  f = 1u_2
  g = 1u_4
  h = 1u_8
end

./f951 -quiet -g -dA a.f90 -funsigned -o - | grep -A3 DW_TAG_base_type | grep
DW_AT_name
.long   .LASF4  # DW_AT_name: "integer(kind=4)"
.long   .LASF5  # DW_AT_name: "character(kind=1)"
.long   .LASF6  # DW_AT_name: "integer(kind=8)"
.long   .LASF7  # DW_AT_name: "unsigned(kind=2)"
.long   .LASF8  # DW_AT_name: "character(kind=4)"
.long   .LASF9  # DW_AT_name: "unsigned(kind=8)"

As you can see, unsigned(kind=2) and unsigned(kind=8) is properly in there, but
instead of unsigned(kind=1) and unsigned(kind=4) there is character(kind=1) and
character(kind=4).
One can see it even in -fdump-tree-gimple dump:
  character(kind=1) a[2];
  unsigned(kind=2) b[2];
  character(kind=4) c[2];
  unsigned(kind=8) d[2];
  character(kind=1) e;
  unsigned(kind=2) f;
  character(kind=4) g;
  unsigned(kind=8) h;

This results in really bad debugging experience, as debuggers will try to print
the unsigned(kind=1) arrays as character(1) strings and similarly for
unsigned(kind=4).

trans-types.cc says:
  /* The middle end only recognizes a single unsigned type.  For
 compatibility of existing test cases, let's just use the
 character type.  The reader of tree dumps is expected to be able
 to deal with this.  */
Sure, make_unsigned_type will return just one type, but can't it just
build_variant_type_copy or something similar?

[Bug target/120192] Internal compiler error when building ring Rust crate

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|1   |0
 Status|WAITING |UNCONFIRMED

[Bug middle-end/110027] [11 regression] Stack objects with extended alignments (vectors etc) misaligned on detect_stack_use_after_return

[stuart.a.hayhurst at gmail dot com via Gcc-bugs]

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

--- Comment #31 from Stuart  ---
I can reproduce this with GCC 14.2 and GCC 15.1 on Debian Sid.

In my case it was std::memcpy that gave me an issue, but the reproducer here is
the same issue.

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

[ajcozzol at us dot ibm.com via Gcc-bugs]

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

--- Comment #1 from Anthony Cozzolino  ---
Copying the code and compiler error here for convenience:

#include 

struct MutexLike
{
void lock() { }
void unlock() { }
bool try_lock() { return true; }
};

int main()
{
MutexLike m1, m2;
std::lock(m1, m2);
std::scoped_lock sl(m1, m2);
return 0;
}

: In function 'int main()':
:14:10: error: 'scoped_lock' is not a member of 'std'
   14 | std::scoped_lock sl(m1, m2);
  |  ^~~
:2:1: note: 'std::scoped_lock' is defined in header ''; this is
probably fixable by adding '#include '
1 | #include 
  +++ |+#include 
2 | 
Compiler returned: 1

[Bug middle-end/110027] [11 regression] Stack objects with extended alignments (vectors etc) misaligned on detect_stack_use_after_return

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

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

--- Comment #32 from Sam James  ---
(In reply to Stuart from comment #31)
> I can reproduce this with GCC 14.2 and GCC 15.1 on Debian Sid.
> 
> In my case it was std::memcpy that gave me an issue, but the reproducer here
> is the same issue.

Please file a new bug for us.

[Bug libstdc++/120198] [14/15/16 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

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Last reconfirmed||2025-05-09
 Ever confirmed|0   |1
   Target Milestone|--- |14.3
Summary|std::scoped_lock disabled   |[14/15/16 Regression]
   |for non-gthread |std::scoped_lock disabled
   |environments (such as   |for non-gthread
   |arm-none-eabi)  |environments (such as
   ||arm-none-eabi)

--- Comment #2 from Jonathan Wakely  ---
I think this happened with the introduction of bits/version.def which has:

ftms = {
  name = scoped_lock;
  values = {
v = 201703;
cxxmin = 17;
hosted = yes;
gthread = yes;
  };
};

[Bug target/120203] New: RISC-V: Frm restore missing after call insn (float-point-dynamic-frm-74.c)

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

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

Bug ID: 120203
   Summary: RISC-V: Frm restore missing after call insn
(float-point-dynamic-frm-74.c)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: wrong-code
  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: ---

FRM mode switching is failing to reload a frm after a function call.
The issue happens all the way to when the test was added and thus test
expectation needs to be adjusted as well.

The overall control flow of test is as follows:


|frrma5
|fsrmi   1
|vfadd.vv v1,v8,v9

|fsrma5   <-- call1/call2: restore before call
|beq a1,zero,.L2
|
|callnormalize_vl_1
|frrma5   <-- call1: save after call
|
| .L3:
|fsrmi   3
|vfadd.vv v8,v8,v9
|fsrma5
|jr  ra
|
| .L2:
|callnormalize_vl_2
|frrma5   <-- call2: save after call MISSING
|j   .L3

[Bug c++/87765] Internal compiler error: coerce_template_parms (8.2) or cxx_eval_constant_expression (trunk)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||calvin at cmpct dot info

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

[Bug c++/120202] ICE with constexpr function for constant expression

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

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

--- Comment #2 from Andrew Pinski  ---
I will file the diagnostic issue seperately.

[Bug fortran/119986] Complex array part references are being passed incorrectly to a procedure

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

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

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

https://gcc.gnu.org/g:01324ffac8bcc6813ffbc78993a674bcac7b52ab

commit r15-9645-g01324ffac8bcc6813ffbc78993a674bcac7b52ab
Author: Harald Anlauf 
Date:   Sat May 3 20:35:57 2025 +0200

Fortran: array subreferences and components of derived types [PR119986]

PR fortran/119986

gcc/fortran/ChangeLog:

* expr.cc (is_subref_array): When searching for array references,
do not terminate early so that inquiry references to complex
components work.
* primary.cc (gfc_variable_attr): A substring reference can refer
to either a scalar or array character variable.  Adjust search
accordingly.

gcc/testsuite/ChangeLog:

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

(cherry picked from commit fceb6022798b587c9111d0241aaff72602dcd626)

[Bug fortran/120179] [15 Regression] Failure with do concurrent and semicolon

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

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

--- Comment #6 from GCC Commits  ---
The releases/gcc-15 branch has been updated by Harald Anlauf
:

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

commit r15-9646-gc60183d8265b5bd509007cf494549667c8c08faa
Author: Harald Anlauf 
Date:   Thu May 8 22:21:03 2025 +0200

Fortran: parsing issue with DO CONCURRENT;ENDDO on same line [PR120179]

PR fortran/120179

gcc/fortran/ChangeLog:

* match.cc (gfc_match_do): Do not attempt to match end-of-statement
twice.

gcc/testsuite/ChangeLog:

* gfortran.dg/do_concurrent_basic.f90: Extend testcase.

(cherry picked from commit 6ce73ad4370c143a7d1e6a13b1d353db5884213f)

[Bug fortran/120179] [15 Regression] Failure with do concurrent and semicolon

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
Fixed on mainline and backported to affected 15-branch.  Closing.

Thanks for the report!

[Bug c++/120202] New: ICE with constexpr function for constant expression

[calvin at cmpct dot info via Gcc-bugs]

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

Bug ID: 120202
   Summary: ICE with constexpr function for constant expression
   Product: gcc
   Version: 12.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: calvin at cmpct dot info
  Target Milestone: ---

I was shuffling around definitions in a class for header-only library, and
managed to ICE g++ in 10 and 12. I can reproduce this on GNU/Linux on x86_64
(from Gentoo) as well on AIX, which is why I'm filing upstream. This appears to
no longer ICE in newer GCC (tested with 14), but still gives a somewhat
confusing error message with a "because:" and no reason afterward.

Reduced example:

```
#include 
template  struct ILEArglist {
  using Sizes = std::array;
  static constexpr auto size() {
Sizes &offsets_c = offsets;
return 0;
  }
  std::array offsets();
};
auto arglist = ILEArglist<>()
```

Error:

```
g++-12 -std=c++14 -Wall -Wextra evil.cpp
evil.cpp: In instantiation of ‘static constexpr auto ILEArglist::size()
[with TArgs = {}]’:
evil.cpp:8:24:   required from ‘struct ILEArglist<>’
evil.cpp:10:29:   required from here
evil.cpp:5:12: warning: unused variable ‘offsets_c’ [-Wunused-variable]
5 | Sizes &offsets_c = offsets;
  |^
evil.cpp: In instantiation of ‘struct ILEArglist<>’:
evil.cpp:10:29:   required from here
evil.cpp:8:28: internal compiler error: in coerce_template_parms, at
cp/pt.cc:9219
8 |   std::array offsets();
  |^~~
0x19344d3 internal_error(char const*, ...)
???:0
0x688ffb fancy_abort(char const*, int, char const*)
???:0
0x80b3ff tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x82754f instantiate_class_template(tree_node*)
???:0
0x8600c3 complete_type(tree_node*)
???:0
0x86016b complete_type_or_maybe_complain(tree_node*, tree_node*, int)
???:0
0x87b3af build_functional_cast(unsigned int, tree_node*, tree_node*, int)
???:0
0x7ea94b c_parse_file()
???:0
0x8ca7f7 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
```

I initially simplified the code that ICE'd by hand, then used cvise to reduce
it further; that initial simplification is here:
https://gist.github.com/NattyNarwhal/6923de2ad3428ba33cc1cd9487bdef89

(Apologies if the reduced sample doesn't make as much sense; I'm still learning
modern C++ and I'm not familar with cvise.)

Version:

```
Using built-in specs.
COLLECT_GCC=g++-12
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-unknown-linux-gnu/12/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-12.4.1_p20241219/work/gcc-12-20241219/configure
--host=aarch64-unknown-linux-gnu --build=aarch64-unknown-linux-gnu
--prefix=/usr --bindir=/usr/aarch64-unknown-linux-gnu/gcc-bin/12
--includedir=/usr/lib/gcc/aarch64-unknown-linux-gnu/12/include
--datadir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/12
--mandir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/12/man
--infodir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/12/info
--with-gxx-include-dir=/usr/lib/gcc/aarch64-unknown-linux-gnu/12/include/g++-v12
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/aarch64-unknown-linux-gnu/12/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo
12.4.1_p20241219 p2' --with-gcc-major-version-only --enable-libstdcxx-time
--enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --disable-multilib
--disable-fixed-point --enable-libgomp --disable-libssp --disable-libada
--disable-standard-branch-protection --disable-systemtap
--disable-valgrind-annotations --disable-vtable-verify --disable-libvtv
--with-zstd --without-isl --enable-default-pie --enable-default-ssp
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.4.1 20241219 (Gentoo 12.4.1_p20241219 p2) 
```

[Bug c++/120202] ICE with constexpr function for constant expression

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
dup and just fixed for GCC 13.

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

[Bug c++/120202] ICE with constexpr function for constant expression

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=120204

--- Comment #3 from Andrew Pinski  ---
Filed PR 120204 for the diagnostic issue since it is different from the ICE.

[Bug libgomp/120194] USM offloading vs. 'libgomp.c++/declare_target-1.C'

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

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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #2 from Thomas Schwinge  ---
Are you saying this isn't a defect in GCC, but rather...

(In reply to myself from comment #0)
> If in 'libgomp.c++/declare_target-1.C', I replace
> 'dg-require-effective-target offload_device_shared_as' with
> '#pragma omp requires unified_shared_memory'

... this is ill-formed OpenMP?  (..., and therefore requires source code
changes as you've suggested.)

[Bug c++/120204] New: `is not usable as a 'constexpr' function because` and no reason why

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

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

Bug ID: 120204
   Summary: `is not usable as a 'constexpr' function because` and
no reason why
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

```
template
struct array{};

template  struct ILEArglist {
  using Sizes = array;
  static constexpr auto size() {
Sizes &offsets_c = offsets;
return 0;
  }
  array offsets();
};
auto arglist = ILEArglist<>();
```

GCC gives:
```
: In instantiation of 'struct ILEArglist<>':
:13:29:   required from here
   13 | auto arglist = ILEArglist<>();
  | ^
:11:19: error: 'static constexpr auto ILEArglist::size() [with
TArgs = {}]' called in a constant expression
   11 |   array offsets();
  |   ^~
:7:25: note: 'static constexpr auto ILEArglist::size() [with
TArgs = {}]' is not usable as a 'constexpr' function because:
7 |   static constexpr auto size() {
  | ^~~~
:11:19: note: in template argument for type 'int'
   11 |   array offsets();
  |   ^~
Compiler returned: 1
```

While clang gives:
```

:8:24: error: call to non-static member function without an object
argument
8 | Sizes &offsets_c = offsets;
  |^~~
:8:12: error: declaration of reference variable 'offsets_c' requires an
initializer
8 | Sizes &offsets_c = offsets;
  |^
:11:15: note: in instantiation of member function 'ILEArglist<>::size'
requested here
   11 |   array offsets();
  |   ^
:13:16: note: in instantiation of template class 'ILEArglist<>'
requested here
   13 | auto arglist = ILEArglist<>();
  |^
```

[Bug target/120192] Internal compiler error when building ring Rust crate

[filip.stamcar at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from Filip Štamcar  ---
Created attachment 61381
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61381&action=edit
Output of save-temps

[Bug target/120192] Internal compiler error when building ring Rust crate

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

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

--- Comment #4 from Sam James  ---
(In reply to Sam James from comment #1)
> 1) The full command line for GCC (maybe cargo build --verbose will do it, I
> don't know)

Sorry, I missed this is in the output. Still need preprocessed source though.

[Bug target/120192] Internal compiler error when building ring Rust crate

[filip.stamcar at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from Filip Štamcar  ---
Created attachment 61382
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61382&action=edit
Output of save-temps

[Bug target/120192] Internal compiler error when building ring Rust crate

[filip.stamcar at hotmail dot com via Gcc-bugs]

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

--- Comment #6 from Filip Štamcar  ---
The full GCC command is:

"gcc.exe" "-O0" "-ffunction-sections" "-fdata-sections" "-gdwarf-2"
"-fno-omit-frame-pointer" "-m64" "-I"
"E:\\Cache\\rust\\cargo\\registry\\src\\index.crates.io-1949cf8c6b5b557f\\ring-0.17.14\\include"
"-I"
"E:\\Cache\\rust\\cargo\\registry\\src\\index.crates.io-1949cf8c6b5b557f\\ring-0.17.14\\pregenerated"
"-fvisibility=hidden" "-std=c1x" "-Wall" "-Wbad-function-cast" "-Wcast-align"
"-Wcast-qual" "-Wconversion" "-Wmissing-field-initializers"
"-Wmissing-include-dirs" "-Wnested-externs" "-Wredundant-decls" "-Wshadow"
"-Wsign-compare" "-Wsign-conversion" "-Wstrict-prototypes" "-Wundef"
"-Wuninitialized" "-g3" "-DNDEBUG" "-march=native" "-o"
"E:\\Projects\\School\\SrednjeveskiArhivi\\target\\debug\\build\\ring-2f9bf6e1f47e27e4\\out\\73090ba2100ad232-curve25519.o"
"-c"
"E:\\Cache\\rust\\cargo\\registry\\src\\index.crates.io-1949cf8c6b5b557f\\ring-0.17.14\\crypto/curve25519/curve25519.c"
"-freport-bug"

I've attached 73090ba2100ad232-curve25519.i and 73090ba2100ad232-curve25519.s
after running it with -save-temps.

[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

--- Comment #6 from Jakub Jelinek  ---
Note, the test even with your patch FAILs for -O0 and -Os, first on STOP 17, I
see quite a few invocations still with 6 arguments:
grep maxloc.*,.*,.*,.*,.*,.* pr120191.f90.007t.gimple 
  [pr120191.f90:32:41] _gfortran_mmaxloc1_4_i1
([pr120191.f90:32:41] &atmp.132, D.5276, D.5280, D.5287, D.5291, 0);
[pr120191.f90:33:58] _gfortran_mmaxloc1_4_i1 ([pr120191.f90:33:58]
&atmp.141, D.5315, D.5319, D.5326, D.5330, 0);
[pr120191.f90:34:58] _gfortran_mmaxloc1_4_i1 ([pr120191.f90:34:58]
&atmp.150, D.5353, D.5357, D.5364, D.5368, 1);
[pr120191.f90:39:58] _gfortran_smaxloc1_4_i1 ([pr120191.f90:39:58]
&atmp.185, D.5525, D.5529, D.5530, D.5532, 0);
[pr120191.f90:40:58] _gfortran_smaxloc1_4_i1 ([pr120191.f90:40:58]
&atmp.192, D., D.5559, D.5560, D.5562, 1);
[pr120191.f90:83:58] _gfortran_mmaxloc1_4_i2 ([pr120191.f90:83:58]
&atmp.477, D.6400, D.6404, D.6411, D.6415, 0);
[pr120191.f90:84:58] _gfortran_mmaxloc1_4_i2 ([pr120191.f90:84:58]
&atmp.486, D.6438, D.6442, D.6449, D.6453, 1);
[pr120191.f90:89:58] _gfortran_smaxloc1_4_i2 ([pr120191.f90:89:58]
&atmp.521, D.6610, D.6614, D.6615, D.6617, 0);
[pr120191.f90:90:58] _gfortran_smaxloc1_4_i2 ([pr120191.f90:90:58]
&atmp.528, D.6640, D.6644, D.6645, D.6647, 1);
[pr120191.f90:133:58] _gfortran_mmaxloc1_4_i4
([pr120191.f90:133:58] &atmp.813, D.7485, D.7489, D.7496, D.7500, 0);
[pr120191.f90:134:58] _gfortran_mmaxloc1_4_i4
([pr120191.f90:134:58] &atmp.822, D.7523, D.7527, D.7534, D.7538, 1);
[pr120191.f90:139:58] _gfortran_smaxloc1_4_i4
([pr120191.f90:139:58] &atmp.857, D.7695, D.7699, D.7700, D.7702, 0);
[pr120191.f90:140:58] _gfortran_smaxloc1_4_i4
([pr120191.f90:140:58] &atmp.864, D.7725, D.7729, D.7730, D.7732, 1);
[pr120191.f90:183:58] _gfortran_mmaxloc1_4_i8
([pr120191.f90:183:58] &atmp.1149, D.8570, D.8574, D.8581, D.8585, 0);
[pr120191.f90:184:58] _gfortran_mmaxloc1_4_i8
([pr120191.f90:184:58] &atmp.1158, D.8608, D.8612, D.8619, D.8623, 1);
[pr120191.f90:189:58] _gfortran_smaxloc1_4_i8
([pr120191.f90:189:58] &atmp.1193, D.8780, D.8784, D.8785, D.8787, 0);
[pr120191.f90:190:58] _gfortran_smaxloc1_4_i8
([pr120191.f90:190:58] &atmp.1200, D.8810, D.8814, D.8815, D.8817, 1);
[pr120191.f90:233:58] _gfortran_mmaxloc1_4_r4
([pr120191.f90:233:58] &atmp.1485, D.9655, D.9659, D.9666, D.9670, 0);
[pr120191.f90:234:58] _gfortran_mmaxloc1_4_r4
([pr120191.f90:234:58] &atmp.1494, D.9693, D.9697, D.9704, D.9708, 1);
[pr120191.f90:239:58] _gfortran_smaxloc1_4_r4
([pr120191.f90:239:58] &atmp.1529, D.9865, D.9869, D.9870, D.9872, 0);
[pr120191.f90:240:58] _gfortran_smaxloc1_4_r4
([pr120191.f90:240:58] &atmp.1536, D.9895, D.9899, D.9900, D.9902, 1);
[pr120191.f90:283:58] _gfortran_mmaxloc1_4_r8
([pr120191.f90:283:58] &atmp.1821, D.10776, D.10780, D.10787, D.10791, 0);
[pr120191.f90:284:58] _gfortran_mmaxloc1_4_r8
([pr120191.f90:284:58] &atmp.1830, D.10814, D.10818, D.10825, D.10829, 1);
[pr120191.f90:289:58] _gfortran_smaxloc1_4_r8
([pr120191.f90:289:58] &atmp.1865, D.10986, D.10990, D.10991, D.10993, 0);
[pr120191.f90:290:58] _gfortran_smaxloc1_4_r8
([pr120191.f90:290:58] &atmp.1872, D.11016, D.11020, D.11021, D.11023, 1);

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

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-05-09
 CC||anlauf at gcc dot gnu.org
   Keywords||wrong-code
 Ever confirmed|0   |1

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

Here's a testcase that fails under valgrind:

program p
  implicit none
  character(:), allocatable :: a(:), s
  allocate (character(16) :: a(10), s)
  a(:)(:) = ""
  s(:)= "*"
  print *, findloc (a, s, dim=1, back=.true.)
  deallocate (a, s)
end program p


==25050== Invalid read of size 8
==25050==at 0x484D769: bcmp (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==25050==by 0x4174BA: _gfortran_compare_string (string_intrinsics_inc.c:98)
==25050==by 0x4043B2: _gfortran_findloc2_s1 (findloc2_s1.c:54)
==25050==by 0x402C16: MAIN__ (in /home/anlauf/gcc-bugs/a.out)
==25050==by 0x402D03: main (in /home/anlauf/gcc-bugs/a.out)
==25050==  Address 0x4bae9d0 is 16 bytes before a block of size 160 alloc'd
==25050==at 0x4841744: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==25050==by 0x4029C1: MAIN__ (in /home/anlauf/gcc-bugs/a.out)
==25050==by 0x402D03: main (in /home/anlauf/gcc-bugs/a.out)
==25050== 
==25050== Invalid read of size 1
==25050==at 0x484D7B7: bcmp (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==25050==by 0x4174BA: _gfortran_compare_string (string_intrinsics_inc.c:98)
==25050==by 0x4043B2: _gfortran_findloc2_s1 (findloc2_s1.c:54)
==25050==by 0x402C16: MAIN__ (in /home/anlauf/gcc-bugs/a.out)
==25050==by 0x402D03: main (in /home/anlauf/gcc-bugs/a.out)
==25050==  Address 0x4bae9d0 is 16 bytes before a block of size 160 alloc'd
==25050==at 0x4841744: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==25050==by 0x4029C1: MAIN__ (in /home/anlauf/gcc-bugs/a.out)
==25050==by 0x402D03: main (in /home/anlauf/gcc-bugs/a.out)

[Bug c/120180] [OpenMP] ICE in C (c_parser_consume_token) / C++ cp_parser_skip_to_pragma_eol in error recovery for metadirective

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

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||rejects-valid

--- Comment #3 from Tobias Burnus  ---
> However, clang-20/clang++-20 compile the code.

For completeness, if both conditions - the 'collapse(2)' condition and the
'simd' condition - are true, Clang 20 also shows an error: "expected 2 for
loops after '#pragma omp target parallel for', but found only 1". Otherwise
(and this includes a dynamic selector), Clang will always accept the code -
even though it is invalid when a directive remains.

 * * *

GCC also rejects:

  #pragma omp target parallel for collapse(2) map(qq[:0]) private(i)
  for(k=0; k

[Bug target/120192] Internal compiler error when building ring Rust crate

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

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

--- Comment #7 from Andrew Pinski  ---
[apinski@xeond2 gcc]$ ./xgcc -B. t.c -S -march=skylake-avx512 -w
during RTL pass: expand
In file included from
E:\Cache\rust\cargo\registry\src\index.crates.io-1949cf8c6b5b557f\ring-0.17.14\crypto/curve25519/internal.h:20,
 from
E:\Cache\rust\cargo\registry\src\index.crates.io-1949cf8c6b5b557f\ring-0.17.14\crypto/curve25519/curve25519.c:24:
E:/Cache/rust/cargo/registry/src/index.crates.io-1949cf8c6b5b557f/ring-0.17.14/crypto/internal.h:
In function ‘constant_time_conditional_memxor’:
E:/Cache/rust/cargo/registry/src/index.crates.io-1949cf8c6b5b557f/ring-0.17.14/crypto/internal.h:260:20:
internal compiler error: in expand_one_stack_var_1, at cfgexpand.cc:1771
0x25529df internal_error(char const*, ...)
../../gcc/diagnostic-global-context.cc:517
0x992e1e fancy_abort(char const*, int, char const*)
../../gcc/diagnostic.cc:1815
0x786053 expand_one_stack_var_1
../../gcc/cfgexpand.cc:1771
0xb538fa expand_one_ssa_partition
../../gcc/cfgexpand.cc:1886
0xb538fa expand_used_vars
../../gcc/cfgexpand.cc:2526
0xb57064 execute
../../gcc/cfgexpand.cc:7051
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

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

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

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #1)
> Here's a testcase that fails under valgrind:
> 
> program p
>   implicit none
>   character(:), allocatable :: a(:), s
>   allocate (character(16) :: a(10), s)
>   a(:)(:) = ""
>   s(:)= "*"
>   print *, findloc (a, s, dim=1, back=.true.)
>   deallocate (a, s)
> end program p

It also fails with -fsanitize=address here:

=
==25625==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x7c4060ae0030 at pc 0x7f6061ee5e13 bp 0x7fff5db66110 sp 0x7fff5db658d0
READ of size 16 at 0x7c4060ae0030 thread T0
#0 0x7f6061ee5e12 in MemcmpInterceptorCommon(void*, int (*)(void const*,
void const*, unsigned long), void const*, void const*, unsigned long)
../../../../gcc-trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:847
#1 0x7f6061ee62c1 in memcmp
../../../../gcc-trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:879
#2 0x7f6061ee62c1 in memcmp
../../../../gcc-trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:874
#3 0x004179fa in _gfortrani_compare_string
../../../gcc-trunk/libgfortran/intrinsics/string_intrinsics_inc.c:98
#4 0x00404922 in _gfortran_findloc2_s1
../../../gcc-trunk/libgfortran/generated/findloc2_s1.c:54
#5 0x00403069 in MAIN__ (/home/anlauf/gcc-bugs/a.out+0x403069)
#6 0x0040322d in main (/home/anlauf/gcc-bugs/a.out+0x40322d)
#7 0x7f6061a40e6b in __libc_start_call_main (/lib64/libc.so.6+0x40e6b)
(BuildId: 3c23d9be9ad37c86aafb5d405431f5f140ab0d8e)
#8 0x7f6061a40f34 in __libc_start_main_alias_1 (/lib64/libc.so.6+0x40f34)
(BuildId: 3c23d9be9ad37c86aafb5d405431f5f140ab0d8e)
#9 0x00402c20 in _start ../sysdeps/x86_64/start.S:115

0x7c4060ae0030 is located 16 bytes before 160-byte region
[0x7c4060ae0040,0x7c4060ae00e0)
allocated by thread T0 here:
#0 0x7f6061f1ff7b in malloc
../../../../gcc-trunk/libsanitizer/asan/asan_malloc_linux.cpp:67
#1 0x00402da7 in MAIN__ (/home/anlauf/gcc-bugs/a.out+0x402da7)

SUMMARY: AddressSanitizer: heap-buffer-overflow
../../../gcc-trunk/libgfortran/intrinsics/string_intrinsics_inc.c:98 in
_gfortrani_compare_string
Shadow bytes around the buggy address:
  0x7c4060adfd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7c4060adfe00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7c4060adfe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7c4060adff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7c4060adff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x7c4060ae: fa fa fa fa fa fa[fa]fa 00 00 00 00 00 00 00 00
  0x7c4060ae0080: 00 00 00 00 00 00 00 00 00 00 00 00 fa fa fa fa
  0x7c4060ae0100: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x7c4060ae0180: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x7c4060ae0200: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x7c4060ae0280: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==25625==ABORTING

[Bug target/120192] Internal compiler error when building ring Rust crate

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

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

--- Comment #10 from Andrew Pinski  ---
-mavx is enough to reproduce the ICE.

[Bug target/120192] Internal compiler error when building ring Rust crate

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||16.0

--- Comment #8 from Andrew Pinski  ---
Reduced testcase:
```
typedef char a;
void b() {
  typedef a c __attribute__((vector_size(32), aligned));
  c d = {};
}

```

[Bug target/120192] Internal compiler error when building ring Rust crate

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

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

--- Comment #9 from Andrew Pinski  ---
  /* We handle highly aligned variables in expand_stack_vars.  */
  gcc_assert (byte_align * BITS_PER_UNIT <= MAX_SUPPORTED_STACK_ALIGNMENT);

[Bug analyzer/120201] New: G++ generates a misaligned vector operation for std::memcpy

[stuart.a.hayhurst at gmail dot com via Gcc-bugs]

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

Bug ID: 120201
   Summary: G++ generates a misaligned vector operation for
std::memcpy
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: stuart.a.hayhurst at gmail dot com
  Target Milestone: ---

Created attachment 61385
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61385&action=edit
Reproducer

Creating a new bug, as instructed from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027

Using GCC 14.2 or GCC 15.1 on Debian Sid, GCC is vectorising code with an
incorrect alignment as far as I can tell, only when using -fsanitize=address.

Compiling test.cpp with `g++ test.cpp -O3 -march=native -fsanitize=address
-std=c++23 -g`, I get a segfault when trying to execute it:

```
ratus5@snakeroot:~/Downloads$ ./a.out 
AddressSanitizer:DEADLYSIGNAL
=
==31762==ERROR: AddressSanitizer: SEGV on unknown address (pc 0x557263aa51eb bp
0x7ffedd5db760 sp 0x7ffedd5db4c0 T0)
==31762==The signal is caused by a READ memory access.
==31762==Hint: this fault was caused by a dereference of a high value address
(see register values below).  Disassemble the provided pc to learn which
register was used.
#0 0x557263aa51eb in main /home/ratus5/Downloads/test.cpp:17
#1 0x7fb37de33ca7 in __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
#2 0x7fb37de33d64 in __libc_start_main_impl ../csu/libc-start.c:360
#3 0x557263aa62a0 in _start (/home/ratus5/Downloads/a.out+0x22a0) (BuildId:
71d0702639116c077ef5945e2e031492acefe9de)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /home/ratus5/Downloads/test.cpp:17 in main
==31762==ABORTING
```

Using GDB to inspect:

```
(gdb) run
Starting program: /home/ratus5/Downloads/a.out 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x51eb in main () at test.cpp:22
22  std::memcpy(transformBlockStart + (matSize * face),
&transforms[face][0], matSize * sizeof(float));
(gdb) display /i $pc
1: x/i $pc
=> 0x51eb : vmovdqa64 -0x1c0(%r12),%zmm0
(gdb) p $r12 % 64
$1 = 32
(gdb) exit
```

[Bug target/120192] Internal compiler error when building ring Rust crate

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

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

--- Comment #11 from Andrew Pinski  ---
I can only get it to ICE at -O0.
And it still ICEs after r16-178-gdea7b9a78b11b5 .

[Bug target/120192] Internal compiler error when building ring Rust crate

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

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

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

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

--- Comment #3 from Tobias Burnus  ---
On mainline currently failing (for a GCC configured with nvptx offloading):

libgomp.c-c++-common/metadirective-1.c:10:11:
  error: 'target' construct with nested 'teams' construct contains directives
outside of the 'teams' construct

[Bug libstdc++/120187] Inclusion of ciso646 incorrectly points to using version in C++17 mode

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
If we *don't* change anything here then we should extend the notes at
https://gcc.gnu.org/gcc-15/porting_to.html#deprecated-headers with the
rationale above. 

But I'm leaning towards dropping the warning for  in C++17 (but not
changing the other headers that really were formally deprecated in C++17).
 is a special case because of the conventional use as a makeshift
 header before that existed in the standard.

[Bug modula2/120188] documented example does not work

[bruno at clisp dot org via Gcc-bugs]

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

--- Comment #2 from Bruno Haible  ---
(In reply to Richard Biener from comment #1)
> Do you have the m2rte plugin?

Yes, and it has not been used since I installed it:

$ LC_ALL=C ls -lu
/darch/x86_64-linux-gnu/gnu-inst-gcc/15.1.0/lib/gcc/x86_64-pc-linux-gnu/15.1.0/plugin/m2rte.so
-rwxr-xr-x 1 bruno bruno 305816 May  7 17:46
/darch/x86_64-linux-gnu/gnu-inst-gcc/15.1.0/lib/gcc/x86_64-pc-linux-gnu/15.1.0/plugin/m2rte.so

I installed GCC 15.1.0 from source:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/darch/x86_64-linux-gnu/gnu-inst-gcc/15.1.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/15.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-15.1.0/configure --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--prefix=/darch/x86_64-linux-gnu/gnu-inst-gcc/15.1.0 --enable-shared
--enable-nls --enable-threads=posix --enable-__cxa_atexit
--with-multilib-list=m64 --with-as=/usr/bin/as --with-ld=/usr/bin/ld
--with-gmp=/darch/x86_64-linux-gnu/gnu-inst-gcc/15.1.0
--with-mpfr=/darch/x86_64-linux-gnu/gnu-inst-gcc/15.1.0
--with-mpc=/darch/x86_64-linux-gnu/gnu-inst-gcc/15.1.0
--with-isl=/darch/x86_64-linux-gnu/gnu-inst-gcc/15.1.0
--enable-languages=c,c++,objc,lto,go,d,m2 --enable-host-shared
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.1.0 (GCC)

[Bug ipa/120048] [14/15/16 Regression] ICE on valid code at -O{s,2} with "-fno-tree-vrp -fno-tree-fre" on x86_64-linux-gnu: in type, at value-range.h:982 since r16-244-gce489c870bf28e

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

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

--- Comment #14 from Jakub Jelinek  ---
So fixed for 14.3+/15.2+/16+ ?

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

[daniil2472s at gmail dot com via Gcc-bugs]

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

Bug ID: 120191
   Summary: Functions minloc() and maxloc() ignore the "back"
parameter when "kind" is present.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniil2472s at gmail dot com
  Target Milestone: ---

Created attachment 61378
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61378&action=edit
Patch to remove "kind" parameter.

Greetings!

In the minloc() and maxloc() functions, when the "kind" parameter is present,
the "back" parameter is not working.

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


Simple test.

$ cat test_minmaxloc.f90
program main
  implicit none
  real, dimension(4) :: a

  a = [ 3.0, 1.0, 3.0, 1.0]

  print *, "+++ kind=default +++"

  print *, "back=default:", maxloc(a)
  print *, "back=.true. :", maxloc(a, back=.true.)
  print *, "back=.false.:", maxloc(a, back=.false.)

  print *, "+++ kind=1 +++"

  print *, "back=default:", maxloc(a, kind=1)
  print *, "back=.true. :", maxloc(a, kind=1, back=.true.)
  print *, "back=.false.:", maxloc(a, kind=1, back=.false.)

end program

$ gfortran -Wall -Wextra -fdump-tree-original test_minmaxloc.f90
 +++ kind=default +++
 back=default:   1
 back=.true. :   3
 back=.false.:   1
 +++ kind=1 +++
 back=default:3
 back=.true. :3
 back=.false.:3

If we look at a C-like dump file, we will see a function call with four
parameters:
_gfortran_maxloc0_4_r4 (&atmp.30, D.4403, D.4407, 1);
but the corresponding libgfortran function receives only three parameters:
extern void maxloc0_4_r4 (gfc_array_i4 * const restrict retarray, 
gfc_array_r4 * const restrict array, GFC_LOGICAL_4);

The third parameter in the function call is "kind." Since the "kind" parameter
converts to an intrinsic name for minloc and maxloc functions, it's redundant
in the function call.

As far as I figured it out, the problem is in the following file
  gcc/fortran/trans-intrinsic.cc
in function
  gfc_conv_intrinsic_minmaxloc()

The strip_kind_from_actual() function must be called in any case to remove the
"kind" argument.

For now it's called only with the condition "if (arrayexpr->ts.type ==
BT_CHARACTER)".

Attaching the proposed patch.

[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 #19 from John David Anglin  ---
(In reply to Jørgen Kvalsvik from comment #18)
> Ok, thanks, I pushed a fix for the gcov %zu prints, at least for gcov.

Thanks.

> To recap:
> 
> * gcov-pr86536.c sporadically fails? (which has to be unrelated to these
> prints)
> * -fprofile-update=atomic warns (and fails the test?), is this expected on
> hppa-hpux?

All gcov tests pass if I define TARGET_HAVE_LIBATOMIC on hppa-hpux to true.
https://gcc.gnu.org/pipermail/gcc-testresults/2025-May/846432.html

It's not clear why gcov-30 passes on Linux.  I searched the entire tree and
couldn't find how TARGET_HAVE_LIBATOMIC gets set on Linux.  Also, always
setting TARGET_HAVE_LIBATOMIC to true doesn't seem 100% correct because I
believe it's possible to disable building libatomic.

I believe the gcov-pr86536.c were in some way related to the patch mentioned
in Comment 10.  gcov-pr86536.c hasn't failed when gcov-30.c isn't modified.

[Bug libgomp/120194] USM offloading vs. 'libgomp.c++/declare_target-1.C'

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

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

--- Comment #1 from Tobias Burnus  ---
Without having looked at it in depth, I think part of the problem is that
'varX' and 'varY' are in static memory. Thus, by construction, there is a
device and a host version.

Solution:

(a) Ensure the date is actually mapped:

-  #pragma omp target
+  #pragma omp target map(always, tofrom: varX, varY)

note the 'always'


(b) Try the following (b.1)

-#pragma omp declare target
 struct typeX varX;
 class typeY varY;
-#pragma omp end declare target
+#pragma omp declare target link(varX, varY)

Note the 'link'

And then (b.2)

+  #pragma target enter data (to: varX, varY)
+
   #pragma omp target


I had planned to do (b.2) automatically for USM - to get them auto intialized
to the host version - and add some -f...=... flag to automatically change
'declare target' to 'declare target link', where that flag is enabled by
default at least for 'requires self_maps', possibly also for 'requires
unified_shared_memory'.

[Bug fortran/120193] Incorrect debug info for unsigned(kind=1) and unsigned(kind=4)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 61383
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61383&action=edit
gcc16-pr120193.patch

So far lightly tested patch.

[Bug c++/120195] New: [modules] export using of purview 'extern "C++"' declaration not bound in importers

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

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

Bug ID: 120195
   Summary: [modules] export using of purview 'extern "C++"'
declaration not bound in importers
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nshead at gcc dot gnu.org
Blocks: 103524
  Target Milestone: ---

Consider:

  // a.cpp
  export module M;
  extern "C++" void foo();
  export using ::foo;

  // b.cpp
  import M;
  int main() { foo(); }

$ g++ -fmodules -S a.cpp b.cpp
b.cpp: In function ‘int main()’:
b.cpp:2:14: error: ‘foo’ was not declared in this scope
2 | int main() { foo(); }
  |  ^~~

Note that this works if 'foo' had been defined in the GMF instead of within the
module purview.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
[Bug 103524] [meta-bug] modules issue

[Bug libstdc++/120198] [14/15/16 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

--- Comment #3 from Jonathan Wakely  ---
It doesn't need to require hosted either.

[Bug target/119164] RISC-V: Extra FRM read/writes around call insns

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

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

--- Comment #4 from Vineet Gupta  ---
Fix posted here

https://gcc.gnu.org/pipermail/gcc-patches/2025-May/683159.html

[Bug target/120203] RISC-V: Frm restore missing after call insn (float-point-dynamic-frm-74.c)

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

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

--- Comment #1 from Vineet Gupta  ---
Fix posted here

https://gcc.gnu.org/pipermail/gcc-patches/2025-May/683159.html

[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Christoph Reiter  ---
Thanks. With the latest patch + the patch for binutils, babl builds fine now.

[Bug cobol/119337] cobol: gcobc wrapper should deduce output name

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

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

James K. Lowden  changed:

   What|Removed |Added

 CC||jklowden at gcc dot gnu.org
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2025-05-09
 Ever confirmed|0   |1

--- Comment #1 from James K. Lowden  ---
This is fixed in parser branch.  It should be automatically marked as fixed by
gitlab when it is applied to master+cobol branch.

[Bug cobol/119335] cobol frontend ignores -M

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

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

James K. Lowden  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
 CC||jklowden at gcc dot gnu.org
   Last reconfirmed||2025-05-09

[Bug bootstrap/120068] The new contrib/relpath.sh script should be made executable otherwise the build fails

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |WONTFIX

--- Comment #9 from Andrew Pinski  ---
There are so many other scripts under contrib and other places that are not
called via $SHELL or otherwise either. This is not going to happen.

[Bug bootstrap/120068] The new contrib/relpath.sh script should be made executable otherwise the build fails

[guido2022 at trentalancia dot com via Gcc-bugs]

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

guido2022 at trentalancia dot com changed:

   What|Removed |Added

 Resolution|INVALID |---
 Status|RESOLVED|REOPENED

--- Comment #8 from guido2022 at trentalancia dot com ---
Let's put it this way: suggestion for very easy improvement.

Since the differential patch is a valid way of moving from a given version to
another, I suggest invoking the new "contrib/relpath.sh" script explicitly
through "sh": that bypasses the need of the executable bit being correctly set
on the file.

That's a very easy improvement which I suggest to avoid breaking the gcc build
when using the differential patch to upgrade to version >= 15.1.0.

[Bug middle-end/120205] New: [15/16 regression] unifdef miscompiled

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

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

Bug ID: 120205
   Summary: [15/16 regression] unifdef miscompiled
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: code at musicinmybrain dot net, lschmelting at posteo dot 
com
  Target Milestone: ---

I noticed this test failure some time ago, but I wrongly assumed it was always
failing (as I had never looked at the package before). My bad.

Ben Beasley of Fedora noticed this the other day and it made me take another
look (https://github.com/fanf2/unifdef/pull/19#issuecomment-2863148452).

unifdef fails tests with >= GCC 15 when built with -D_FORTIFY_SOURCE (any
level). Reducing it was a bit awkward and the reduced version is equally
awkward (use of __ctype_b_loc, reliance on fgets alias, ...).

---

unifdef.c:
```
enum { _ISspace }  ;
char tline[4096];
int main_argc;
char parseline_cp;
long parseline_len;
char *__fgets_alias() __asm__("fgets");
extern __inline __attribute__((__gnu_inline__)) char *fgets(char *__s) {
  long __sz = __builtin_dynamic_object_size(__s, 1);
  if (__sz == -1)
return __fgets_alias();
}
int getopt();
int main(char argv) {
  while (getopt(main_argc, argv) != -1)
;
  __builtin_printf("foo\n");
  {
for (; _ISspace;)
  ;
if (fgets(tline + parseline_len) == 0)
  __builtin_abort();
  }
}
```

$ gcc-14 -O1 -o unifdef unifdef.c && ./unifdef
foo
$ gcc-15 -O1 -o unifdef unifdef.c && ./unifdef
foo
Aborted(core dumped) ./unifdef


---

```

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-libphobos --enable-objc-gc
--enable-languages=c,c++,d,objc,obj-c++,fortran,ada,cobol,m2,rust
--enable-obsolete --enable-secureplt --disable-werror --with-system-zlib
--enable-nls --without-included-gettext --disable-libunwind-exceptions
--enable-checking=yes,extra,rtl --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo Hardened 16.0. p, commit
485d5bafcc11703825cb6c3cf7ce2cdd246fb7b1' --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
--enable-libada --disable-cet --disable-systemtap --enable-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 --enable-linker-build-id
--with-build-config='bootstrap-O3 bootstrap-lto'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 16.0.0 20250507 (experimental)
974b079741f902fcf4323dfcecbbffdb9f56f3bf (Gentoo Hardened 16.0. p, commit
485d5bafcc11703825cb6c3cf7ce2cdd246fb7b1)
```

[Bug middle-end/120205] [15/16 regression] unifdef miscompiled

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |15.2
   Keywords||wrong-code

[Bug middle-end/120205] [15/16 regression] unifdef miscompiled

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

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

--- Comment #2 from Sam James  ---
In objsz1:
```
[local count: 118111600]:
   __builtin_puts (&"foo"[0]);
-  parseline_len.1_4 = parseline_len;
-  parseline_len.2_5 = (sizetype) parseline_len.1_4;
-  _20 = MAX_EXPR ;
-  _19 = _20 - parseline_len.2_5;
-  _6 = &tline + parseline_len.2_5;
-  _13 = _19;
-  if (_13 == 18446744073709551615)
-goto ; [11.56%]
-  else
-goto ; [88.44%]
-
-   [local count: 13653701]:
-  _14 = __fgets_alias ();
-
-   [local count: 118111600]:
-  # _16 = PHI <_14(5), _18(D)(4)>
-  if (_16 == 0B)
-goto ; [0.00%]
+  if (_10(D) == 0B)
+goto ; [0.00%]
   else
-goto ; [100.00%]
+goto ; [100.00%]
```

[Bug middle-end/120205] [15/16 regression] unifdef miscompiled

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

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

--- Comment #3 from Jakub Jelinek  ---
The reduction is wrong in many ways.
main shouldn't have a single char argument, fgets inline doesn't return
anything if __bdos is not -1, otherwise it calls fgets without any arguments,
all that is UB.

[Bug middle-end/120205] [15/16 regression] unifdef miscompiled

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

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

--- Comment #4 from Sam James  ---
yes, lemme fix it up

[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0

[bc-info at styx dot cabel.net via Gcc-bugs]

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

--- Comment #12 from Iouri Kharon  ---
FYI: Yet cc1/cc1plus can be linked with --pdb :) - secondary patch for ld added
to https://sourceware.org/bugzilla/show_bug.cgi?id=32942

[Bug middle-end/120205] [15/16 regression] unifdef miscompiled

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

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

--- Comment #1 from Sam James  ---
Needs -std=gnu17.

[Bug target/120186] [pa] internal compiler error: in fail, at selftest.cc:47 during bootstrap with LRA enabled

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

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

--- Comment #3 from John David Anglin  ---
Hi Adrian,

I haven't tested LRA in sometime.  There are are at least two bugs
preventing migration to LRA on hppa, although they didn't previously
break bootstrap.  I don't believe these are problems with backend.

I presume you edited pa.opt to enable LRA.

Would you provide full configure command and relevant environment options.

You might try building with old reload.

My last build of gcc-16 was at revision r16-175-g1c5cf7cc82d.

Probably, we will need to bisect this bug.

I'm currently working on fixing Debian builds of gcc-12 and gcc-13 on hppa.
There is a report that gcc-15 is also broken...

[Bug c++/120204] `is not usable as a 'constexpr' function because` and no reason why

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/120186] [pa] internal compiler error: in fail, at selftest.cc:47 during bootstrap with LRA enabled

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

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

--- Comment #4 from John David Anglin  ---
My last LRA build was at r15-9116-g28751389a68.

[Bug middle-end/120205] [15/16 regression] unifdef miscompiled

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

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

--- Comment #6 from Sam James  ---
Created attachment 61387
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61387&action=edit
whitespace.c

[Bug middle-end/120205] [15/16 regression] unifdef miscompiled

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

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

--- Comment #5 from Sam James  ---
Created attachment 61386
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61386&action=edit
unifdef.c

This is a bit better. It needs 'whitespace.c' as input data.

[Bug middle-end/120205] [15/16 regression] unifdef miscompiled

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

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

--- Comment #7 from Sam James  ---
(In reply to Sam James from comment #5)
> Created attachment 61386 [details]
> unifdef.c
> 
> This is a bit better. It needs 'whitespace.c' as input data.

.. with return added in fgets.

[Bug middle-end/120205] [15/16 regression] unifdef miscompiled

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

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

Sam James  changed:

   What|Removed |Added

  Attachment #61386|0   |1
is obsolete||

--- Comment #8 from Sam James  ---
Created attachment 61388
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61388&action=edit
unidef.c