[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

[Bug target/117978] Optimise 128-bit-predicated SVE loads to Advanced SIMD LDRs

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

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

Richard Sandiford  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Sandiford  ---
Fixed.

[Bug libgomp/120194] New: 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

Bug ID: 120194
   Summary: USM offloading vs. 'libgomp.c++/declare_target-1.C'
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: testsuite-fail, wrong-code
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: tschwinge at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: burnus at gcc dot gnu.org, jakub at gcc dot gnu.org
  Target Milestone: ---

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'
(and run that on a suitable device), the execution test FAILs.  (XFAILed test
case soon to appear.)

In '-fdump-tree-gimple', we've got 'map(tofrom:varY [len: 4]
[runtime_implicit]) map(tofrom:varX [len: 4] [runtime_implicit])', which looks
expected.  But, despite 'unified_shared_memory' being if effect, libgomp still
maps 'varX', 'varY' (verified: I see different addresses from host addresses),
and after the OpenMP 'target', their 'a' members are set to '0' instead of
'100'.  The issue disappears if I remove '#pragma omp declare target' for
'varX', 'varY', so I suspect that (global mapping setup;
'gomp_load_image_to_device'?) is where the problem originates.

I'll have a look.

[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 #3 from Daniil Kochergin  ---
(In reply to Jakub Jelinek from comment #2)
> Created attachment 61380 [details]
> gcc16-pr120191-test.patch
> 
> Perhaps like this?

Sorry for the trivial question, but should I mail the patch along with your
test?

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

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

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

Jason Merrill  changed:

   What|Removed |Added

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

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

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

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

Joel Sherrill  changed:

   What|Removed |Added

 CC||joel at gcc dot gnu.org

--- Comment #16 from Joel Sherrill  ---
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.

[Bug libstdc++/120190] Definition of the primary template of std::format_kind seems IFNDR

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

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

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2025-05-09
 Status|UNCONFIRMED |NEW
Version|unknown |13.3.0
  Known to fail||15.1.0, 9.3.1
   Keywords||wrong-code

[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

Iouri Kharon  changed:

   What|Removed |Added

  Attachment #61364|0   |1
is obsolete||

--- Comment #9 from Iouri Kharon  ---
Created attachment 61379
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61379&action=edit
A complex patch fixed for this (and several similar) problems.

1. ATTENTION! Don't use 'cfun' as a pointer outside of its processing time -
   it is allocated via ggc (garbage collector) and can be moved/deleted.

2. When implementation of structure present without preliminary declaration,
   infinite recursion could occur (when determining the 'this' type for
   member-function and/or pointers to the processed type from nested types,
etc).

3. Also fixed variable size array (thanks for test).

[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 #10 from Iouri Kharon  ---
(In reply to Sam James from comment #6)
> Mark, when you get a chance to work on this, if you haven't tried it before,
> I'd recommend doing a bootstrap w/ -gcodeview enabled by default to see what
> falls out.

With -O0 the compilers got it right (after last patch :).
Only I had to add -Wl,--exclude-all-symbols to LDFLAGS - too many exports
for PE :). And link without debugging (ld "hang" with code 5).

With -Os, there are problems interacting with assembler generation - I'll
see when I have time.

[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 #2 from Jakub Jelinek  ---
Created attachment 61380
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61380&action=edit
gcc16-pr120191-test.patch

Perhaps like this?

[Bug middle-end/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

Sam James  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #1 from Sam James  ---
(The Rust component on our Bugzilla is for GCC's WIP Rust frontend.)

Could you try to get two things for us please?

1) The full command line for GCC (maybe cargo build --verbose will do it, I
don't know)
2) When you have 1), re-run that command with -save-temps and share the
preprocessed source file it creates

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

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Even on the gcc/testsuite/gfortran.dg/pr120152_{1,2}.f90 I see 6 resp. 5
arguments even when the library expects 5 resp. 4:
grep maxloc pr120152_1.f90.007t.gimple 
_gfortran_smaxloc1_4_i8 (&parm.0, D.4708, D.4712, D.4713, D.4715,
1);
_gfortran_smaxloc1_8_i8 (&parm.3, D.4746, D.4750, D.4751, D.4753,
1);
_gfortran_maxloc1_4_i8 (&parm.6, D.4783, D.4787, D.4789, 1);
_gfortran_maxloc1_8_i8 (&parm.9, D.4819, D.4823, D.4825, 1);
_gfortran_mmaxloc1_4_i8 (&parm.15, D.4870, D.4874, D.4881, D.4885,
1);
_gfortran_mmaxloc1_8_i8 (&parm.23, D.4930, D.4934, D.4941, D.4945,
1);

Patches should be posted to the mailing list (fort...@gcc.gnu.org with CC
gcc-patc...@gcc.gnu.org) and should include a testcase which fails without the
actual change and passes with it (dg-do run test, ideally covering the various
min/maxloc forms).

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

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #2 from Jason Merrill  ---
Fixed.

[Bug c++/99599] [12/13 Regression] Concepts requirement falsely reporting cyclic dependency, breaks tag_invoke pattern

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

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

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

https://gcc.gnu.org/g:21842fe301caa5dbc69a69033cdc17bb29b8c399

commit r16-503-g21842fe301caa5dbc69a69033cdc17bb29b8c399
Author: Jason Merrill 
Date:   Fri May 9 11:05:13 2025 -0400

c++: CWG2369 workaround and ... [PR120185]

My r16-479 adjustment to the PR99599 workaround broke on a class with a
varargs constructor.

It also occurred to me that we don't need to do non-dep conversion checking
in two phases when concepts aren't supported.

PR c++/99599
PR c++/120185

gcc/cp/ChangeLog:

* class.cc (type_has_converting_constructor): Handle null parm.
* pt.cc (fn_type_unification): Skip early non-dep checking if
no concepts.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-nondep6.C: New test.

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

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

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

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

https://gcc.gnu.org/g:21842fe301caa5dbc69a69033cdc17bb29b8c399

commit r16-503-g21842fe301caa5dbc69a69033cdc17bb29b8c399
Author: Jason Merrill 
Date:   Fri May 9 11:05:13 2025 -0400

c++: CWG2369 workaround and ... [PR120185]

My r16-479 adjustment to the PR99599 workaround broke on a class with a
varargs constructor.

It also occurred to me that we don't need to do non-dep conversion checking
in two phases when concepts aren't supported.

PR c++/99599
PR c++/120185

gcc/cp/ChangeLog:

* class.cc (type_has_converting_constructor): Handle null parm.
* pt.cc (fn_type_unification): Skip early non-dep checking if
no concepts.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-nondep6.C: New test.

[Bug libstdc++/120198] New: 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

Bug ID: 120198
   Summary: std::scoped_lock disabled for non-gthread environments
(such as arm-none-eabi)
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ajcozzol at us dot ibm.com
  Target Milestone: ---

At some point, the definition for __cpp_lib_scoped_lock in  was changed
to depend on gthread. This check causes std::scoped_lock to be compiled out for
non-gthread environments such as arm-none-eabi.

I believe this is a regression as std::scoped_lock is an RAII wrapper for
std::lock(), which works perfectly fine. The definition of scoped_lock did not
change, simply the #define guarding its inclusion.

Suggested fix: remove the dependency on _GLIBCXX_HAS_GTHREADS in the
__cpp_lib_scoped_lock definition in version.h.

Compiler Explorer link: https://godbolt.org/z/39W3d93fY

[Bug c++/120199] New: ICE in type_dependent_expression_p when using __builtin_addressof on templated function

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

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

Bug ID: 120199
   Summary: ICE in type_dependent_expression_p when using
__builtin_addressof on templated function
   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 __builtin_addressof on a templated function results in an internal
compiler error (ICE) in type_dependent_expression_p, even when the function is
not actually instantiated or used.

If code is slighly change ICE can change, and version where it occurs too.

```
#include 
template
void kernel1() {
__builtin_addressof(kernel1);
}

```

Stack dump

```
: In function 'void kernel1()':
:4:37: internal compiler error: in type_dependent_expression_p, at
cp/pt.cc:29272
4 | __builtin_addressof(kernel1);
  | ^
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
0xd74277 finish_expr_stmt(tree_node*)
???:0
0xcfa203 c_parse_file()
???:0
0xe5cbd9 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.
Compiler returned: 1
```



Example ICE 1 (SINCE 7.1):

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

Example ICE 2 (SINCE 7.1):

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

Example ICE 3 (ONLY IN TRUNK):

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

[Bug target/120200] New: [16 Regression] profiledbootstrap broken on x86_64-linux with -Wstringop-overflow in i386-expand.cc

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

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

Bug ID: 120200
   Summary: [16 Regression] profiledbootstrap broken on
x86_64-linux with -Wstringop-overflow in
i386-expand.cc
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

I tried a profiledbootstrap on x86_64-linux-gnu at
r16-457-g49c44911df72f55e2004ffa9f5eb362de29ca188 and it failed as follows.

Configuration flags: --with-arch=native --enable-multilib
--with-multilib-list=m32,m64

It fails during stageprofile with:

/fast/trunk/src/gcc-worktrees/base-profile/gcc/config/i386/i386-expand.cc: In
function ‘bool expand_vec_perm2_vperm2f128_vblend(expand_vec_perm_d*)’: 
/fast/trunk/src/gcc-worktrees/base-profile/gcc/config/i386/i386-expand.cc:22907:20:
error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=]  
22907 | dthird.perm[i] = i ^ nelt2; 
  | ~~~^~~  
In file included from
/fast/trunk/src/gcc-worktrees/base-profile/gcc/config/i386/i386-expand.cc:95:   
/fast/trunk/src/gcc-worktrees/base-profile/gcc/config/i386/i386-expand.h:29:17:
note: at offset 64 into destination object ‘expand_vec_perm_d::perm’ of size 64 
   29 |   unsigned char perm[MAX_VECT_LEN]; 
  | ^~~~

[Bug c++/120199] ICE when using __builtin_addressof on overload function inside a template

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|ICE when using  |ICE when using
   |__builtin_addressof on  |__builtin_addressof on
   |templated function Leading  |overload function inside a
   |to different ICEs   |template

--- Comment #1 from Andrew Pinski  ---
>Example ICE 3 (ONLY IN TRUNK):

No that happens on other versions just hidden by default (because of an earlier
error):
```
:5: confused by earlier errors, bailing out
```
Means there was an ICE :).

[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 #7 from Jakub Jelinek  ---
Created attachment 61384
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61384&action=edit
gcc16-pr120191.patch

This seems to work even when the kind argument is not named, just doing for
minmaxloc what is done for findloc.
Quickly tested with make -j32 -k check-gfortran, will test it thoroughly next.