[Bug driver/120985] Possible memory leak in read_specs at gcc.cc

[shuhaofu.g at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Shuhao  ---
I'm relatively new to GCC code bases. Are files like `gcc/*.cc` also parts of
the short-lived driver code? If so, I'll then stop reporting memory leak issues
within these source files.

[Bug debug/120227] Incorrect debug info generation with options -gcodeview -g

[tanksherman27 at gmail dot com via Gcc-bugs]

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

Julian Waters  changed:

   What|Removed |Added

 CC||tanksherman27 at gmail dot com

--- Comment #2 from Julian Waters  ---
Is it worth mentioning here that using a mingw-w64 crt compiled with LTO causes
a huge amount of assembler errors as well? Particularly if user code is
compiled with -flto as well or if -ffunction-sections is used. Errors increase
dramatically if codeview debugging is enabled.

[Bug c/120991] New: ICE on x86_64-linux-gnu: in composite_type, at c/c-typeck.cc:1006 with transaction_safe

[jiangchangwu at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 120991
   Summary: ICE on x86_64-linux-gnu: in composite_type, at
c/c-typeck.cc:1006 with transaction_safe
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jiangchangwu at smail dot nju.edu.cn
  Target Milestone: ---

Compiler Explorer: https://gcc.godbolt.org/z/j55f6M5E5

***
gcc version:
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/16.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++ --prefix=/home/software/gcc-trunk --enable-coverage
--disable-werror --enable-checking=yes
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 16.0.0 20250613 (experimental) (GCC)

***
Program:
$ cat mutant.c
float a();
__attribute__((transaction_safe)) float a(b)

***
Command Lines:
$ gcc mutant.c
mutant.c:2:1: internal compiler error: in composite_type, at c/c-typeck.cc:1006
2 | __attribute__((transaction_safe)) float a(b)
  | ^
0x5554b38 internal_error(char const*, ...)
../../gcc/gcc/diagnostic-global-context.cc:517
0x54d2d0a fancy_abort(char const*, int, char const*)
../../gcc/gcc/diagnostic.cc:1803
0xf55b06 composite_type(tree_node*, tree_node*)
../../gcc/gcc/c/c-typeck.cc:1006
0xf13a81 start_function(c_declspecs*, c_declarator*, tree_node*)
../../gcc/gcc/c/c-decl.cc:10726
0xffa60c c_parser_declaration_or_fndef
../../gcc/gcc/c/c-parser.cc:3117
0xff59fd c_parser_external_declaration
../../gcc/gcc/c/c-parser.cc:2155
0xff4ea2 c_parser_translation_unit
../../gcc/gcc/c/c-parser.cc:2009
0x10a17ee c_parse_file()
../../gcc/gcc/c/c-parser.cc:30153
0x11d7aeb c_common_parse_file()
../../gcc/gcc/c-family/c-opts.cc:1385
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 target/118891] [14/15/16 regression] gcc 14 fails to build from source on aarch64_be: "error: ‘dynamic_cast’ not permitted with ‘-fno-rtti’"

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

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

--- Comment #27 from GCC Commits  ---
The trunk branch has been updated by Richard Sandiford :

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

commit r16-2049-gcb2b5471516c3c469f65d927a2a30eb15357e429
Author: Richard Sandiford 
Date:   Mon Jul 7 09:10:37 2025 +0100

aarch64: Fix ZIP1 order in aarch64_expand_vector_init [PR118891]

aarch64_expand_vector_init contains some divide-and-conquer code
that tries to load the odd and even elements into 64-bit registers
and then ZIP them together.  On big-endian targets, the even elements
are more significant than the odd elements and so should come second
in the ZIP.

This fixes many execution failures on aarch64_be-elf, including
gcc.c-torture/execute/pr28982a.c.

gcc/
PR target/118891
* config/aarch64/aarch64.cc (aarch64_expand_vector_init): Fix the
ZIP1 operand order for big-endian targets.

[Bug target/118891] [14/15/16 regression] gcc 14 fails to build from source on aarch64_be: "error: ‘dynamic_cast’ not permitted with ‘-fno-rtti’"

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

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

--- Comment #28 from GCC Commits  ---
The trunk branch has been updated by Richard Sandiford :

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

commit r16-2052-gec54a14239b12d03c600c14f3ce9710e65cd33f1
Author: Richard Sandiford 
Date:   Mon Jul 7 09:10:38 2025 +0100

vect: Fix VEC_WIDEN_PLUS_HI/LO choice for big-endian [PR118891]

In the tree codes and optabs, the "hi" in a vector hi/lo pair means
"most significant" and the "lo" means "least significant", with
sigificance following GCC's normal endian expectations.  Thus on
big-endian targets, the hi part handles the first half of the elements
in memory order and the lo part handles the second half.

For tree codes, supportable_widening_operation first chooses hi/lo
pairs based on little-endian order and then uses:

  if (BYTES_BIG_ENDIAN && c1 != VEC_WIDEN_MULT_EVEN_EXPR)
std::swap (c1, c2);

to adjust.  However, the handling for internal functions was missing
an equivalent fixup.  This led to several execution failures in vect.exp
on aarch64_be-elf.

If the hi/lo code fails, the internal function handling goes on to try
even/odd.  But I couldn't see anything obvious that would put the even/
odd results back into the right order later, so there might be a latent
bug there too.

gcc/
PR tree-optimization/118891
* tree-vect-stmts.cc (supportable_widening_operation): Swap the
hi and lo internal functions on big-endian targets.

[Bug target/118891] [14/15 regression] gcc 14 fails to build from source on aarch64_be: "error: ‘dynamic_cast’ not permitted with ‘-fno-rtti’"

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

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

Richard Sandiford  changed:

   What|Removed |Added

Summary|[14/15/16 regression] gcc   |[14/15 regression] gcc 14
   |14 fails to build from  |fails to build from source
   |source on aarch64_be:   |on aarch64_be: "error:
   |"error: ‘dynamic_cast’ not  |‘dynamic_cast’ not
   |permitted with ‘-fno-rtti’" |permitted with ‘-fno-rtti’"
  Known to work||16.0

--- Comment #29 from Richard Sandiford  ---
Thanks for the testing.

Fixed on trunk.  I'll backport to release branches.

[Bug tree-optimization/120972] restrict does not work for not-parameter pointer

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2025-07-07
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Richard Biener  ---
Yes, it's not possible to implement the standards restrict qualification
constraints reliably for pointers not in the outermost scope of a function
and after the compiler was allowed to do CSE or other code transforms.

For simplicity only function parameters (and select "global" cases)
are handled in the implementation which resides in points-to analysis.

In principle 'restrict' should be handled in the C/C++ language frontends
instead.

[Bug fortran/120958] tree-sra "miscompiles" asynchronous MPI (mpi_irecv) in Fortran 77 because of wrong fnspec

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

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

--- Comment #7 from Martin Jambor  ---
(In reply to kargls from comment #5)
> 
> So, if I understand, you want an fnspec of ". . w w w w w w w".
> Can you show f->sym and f->sym-attr from gdb?
> 

(gdb) p *f->sym
$5 = {name = 0x7fffbe64a100 "_formal_70", module = 0x0, declared_at = {nextc =
0x4c006a4, u = {lb = 0x4c00620, location = 79693344}}, ts = {type = BT_REAL,
kind = 8, u = {derived = 0x0,
  cl = 0x0, pad = 0}, interface = 0x0, is_c_interop = 0, is_iso_c = 0,
f90_type = BT_UNKNOWN, deferred = false, interop_kind = 0x0}, attr =
{allocatable = 0, dimension = 0,
codimension = 0, external = 0, intrinsic = 0, optional = 0, pointer = 0,
target = 0, value = 0, volatile_ = 0, temporary = 0, dummy = 1, result = 0,
assign = 0, threadprivate = 0,
not_always_present = 0, implied_index = 0, subref_array_pointer = 0,
proc_pointer = 0, asynchronous = 0, contiguous = 0, fe_temp = 0, automatic = 0,
class_pointer = 0, save = SAVE_NONE,
data = 0, is_protected = 0, use_assoc = 0, used_in_submodule = 0, use_only
= 0, use_rename = 0, imported = 0, host_assoc = 0, in_namelist = 0, in_common =
0, in_equivalence = 0,
function = 0, subroutine = 0, procedure = 0, generic = 0, generic_copy = 0,
implicit_type = 0, untyped = 0, is_bind_c = 0, extension = 0, is_class = 0,
class_ok = 0, vtab = 0,
vtype = 0, is_c_interop = 0, is_iso_c = 0, sequence = 0, elemental = 0,
pure = 0, recursive = 0, unmaskable = 0, masked = 0, contained = 0, mod_proc =
0, abstract = 0,
module_procedure = 0, public_used = 0, implicit_pure = 0,
array_outer_dependency = 0, noreturn = 0, entry = 0, entry_master = 0,
mixed_entry_master = 0, always_explicit = 0,
artificial = 1, referenced = 0, is_main_program = 0, access =
ACCESS_UNKNOWN, intent = INTENT_UNKNOWN, flavor = FL_VARIABLE, if_source =
IFSRC_UNKNOWN, proc = PROC_UNKNOWN,
cray_pointer = 0, cray_pointee = 0, alloc_comp = 0, pointer_comp = 0,
proc_pointer_comp = 0, private_comp = 0, zero_comp = 0, coarray_comp = 0,
lock_comp = 0, event_comp = 0,
defined_assign_comp = 0, unlimited_polymorphic = 0, has_dtio_procs = 0,
caf_token = 0, select_type_temporary = 0, select_rank_temporary = 0,
associate_var = 0, pdt_kind = 0,
pdt_len = 0, pdt_type = 0, pdt_template = 0, pdt_array = 0, pdt_string = 0,
omp_udr_artificial_var = 0, omp_declare_target = 0, omp_declare_target_link =
0,
omp_declare_target_indirect = 0, omp_device_type = OMP_DEVICE_TYPE_UNSET,
omp_allocate = 0, oacc_declare_create = 0, oacc_declare_copyin = 0,
oacc_declare_deviceptr = 0,
oacc_declare_device_resident = 0, oacc_declare_link = 0, oacc_routine_lop =
OACC_ROUTINE_LOP_NONE, oacc_routine_nohost = 0, ext_attr = 0, volatile_ns =
0x0, asynchronous_ns = 0x0},
  generic = 0x0, component_access = ACCESS_UNKNOWN, formal = 0x0, formal_ns =
0x0, f2k_derived = 0x0, param_list = 0x0, value = 0x0, as = 0x0, result = 0x0,
components = 0x0,
  cp_pointer = 0x0, entry_id = 0, hash_value = 0, common_next = 0x0,
common_head = 0x0, decl_order = 0, namelist = 0x0, namelist_tail = 0x0, tlink =
0x0, old_symbol = 0x0, mark = 0,
  comp_mark = 0, data_mark = 0, dev_mark = 0, gen_mark = 0, reduc_mark = 0,
gfc_new = 0, equiv_built = 0, forall_index = 0, fn_result_spec = 0,
fn_result_dep = 0, resolve_symbol_called = 0,
  abr_modproc_decl = 0, error = 0, maybe_array = 0, pass_as_value = 0,
allocated_in_scope = 0, ext_dummy_arglist_mismatch = 0, formal_resolved = 0,
refs = 1, ns = 0x4dda330,
  backend_decl = NULL_TREE, from_intmod = INTMOD_NONE, intmod_sym_id = 0,
binding_label = 0x0, common_block = 0x0, assoc = 0x0, dt_next = 0x0, formal_at
= {nextc = 0x0, u = {lb = 0x0,
  location = 0}}}



(gdb) p f->sym->attr
$6 = {allocatable = 0, dimension = 0, codimension = 0, external = 0, intrinsic
= 0, optional = 0, pointer = 0, target = 0, value = 0, volatile_ = 0, temporary
= 0, dummy = 1, result = 0,
  assign = 0, threadprivate = 0, not_always_present = 0, implied_index = 0,
subref_array_pointer = 0, proc_pointer = 0, asynchronous = 0, contiguous = 0,
fe_temp = 0, automatic = 0,
  class_pointer = 0, save = SAVE_NONE, data = 0, is_protected = 0, use_assoc =
0, used_in_submodule = 0, use_only = 0, use_rename = 0, imported = 0,
host_assoc = 0, in_namelist = 0,
  in_common = 0, in_equivalence = 0, function = 0, subroutine = 0, procedure =
0, generic = 0, generic_copy = 0, implicit_type = 0, untyped = 0, is_bind_c =
0, extension = 0, is_class = 0,
  class_ok = 0, vtab = 0, vtype = 0, is_c_interop = 0, is_iso_c = 0, sequence =
0, elemental = 0, pure = 0, recursive = 0, unmaskable = 0, masked = 0,
contained = 0, mod_proc = 0,
  abstract = 0, module_procedure = 0, public_used = 0, implicit_pure = 0,
array_outer_dependency = 0, noreturn = 0, entry = 0, entry_master = 0,
mixed_entry_master = 0, always_explicit = 0,
  artificial = 1, referenced = 0, is_main_program = 0, access = ACCESS_UNKNOWN,
intent = INTENT_UNKNOWN, flavor = FL_VARIABLE, if_source = IFSRC_UNKNOWN, proc
= PROC_UNK

[Bug target/120957] [16 Regression] 6-9% slowdown of 503.bwaves_r on Zen{2,3} since r16-1647-gc06979ff957485

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

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

--- Comment #3 from Filip Kastl  ---
I've bisected this on Zen2.  It is possible that this is actually two different
slowdowns and only the Zen2 slowdown is caused by r16-1647.  I'll bisect on
Zen3.

[Bug c++/120955] [15/16 Regression] 50 % increase in data segment size on avr-gcc for -Os

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

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

--- Comment #7 from Georg-Johann Lay  ---
(In reply to fiesh from comment #6)
> Am I doing something wrong?
Maybe it has to do with LTO.  When you are still using -flto, then the object
files only contain LTO byte code except with -ffat-lto-objects.  Notice that
even with -ffat-lto-objects, LTO uses only the LTO byte code from the object
files.

[Bug target/120725] [meta] Poor memcpy/memset inline strategies for -mtune=generic

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

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

Bug 108585 Summary: memset uses SSE stores but afterwards does not but if used 
"" will use them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108585

   What|Removed |Added

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

[Bug tree-optimization/120358] [15/16 regression] qtbase-6.9.0 miscompiled since r15-580-gf3e5f4c58591f5

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

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

--- Comment #30 from Alexander Monakov  ---
Forgot to mention that the offending match.pd rule is

/* Simplify pointer equality compares using PTA.  */
(for neeq (ne eq)
 (simplify
  (neeq @0 @1)
  (if (POINTER_TYPE_P (TREE_TYPE (@0))
   && ptrs_compare_unequal (@0, @1))
   { constant_boolean_node (neeq != EQ_EXPR, type); })))

and ptrs_compare_unequal unexpectedly returns true (as already hinted in
comment #5)

[Bug tree-optimization/120358] [15/16 regression] qtbase-6.9.0 miscompiled since r15-580-gf3e5f4c58591f5

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed|2025-05-19 00:00:00 |2025-07-07
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #31 from Richard Biener  ---
(In reply to Alexander Monakov from comment #28)
> Created attachment 61811 [details]
> standalone testcase
> 
> A standalone variant of the comment #22 testcase, preprocessed and with
> enough noipa stubs added to avoid linking with QtBase.

Thanks, this produces with -O2 -std=gnu++20

> ./a.out 
test2: 1 2 3 

while -O3 -std=gnu++20

> ./a.out 
test2: 1 2 3 18446744073709551615 

it also reproduces with -O3 -fno-tree-vectorize, the main difference seems
to be IPA and inline differences.  -fno-tree-pta fixes it.

There are exactly two(!) comparisons eliminated with the added path, the
2nd triggers the issue in VRP1:

Folding statement: if (e_137 != n_142)
 Registering value_relation (e_137 != n_142) on (33->35)
 Registering value_relation (e_137 == n_142) on (33->34)

Visiting conditional with predicate: if (e_137 != n_142)

With known ranges
e_137: [prange] const char16_t * [1, +INF]  n_142: [prange] const
char16_t * VARYING

Predicate evaluates to: DON'T KNOW
***dbgcnt: lower limit 2 reached for prefetch.***
***dbgcnt: upper limit 2 reached for prefetch.***
gimple_simplified to if (1 != 0)
Folded into: if (1 != 0)


We have

  # PT = null
  e_137 = _130 + _136;
...
  # PT = nonlocal escaped null const-pool { D.189684 } (escaped)
  # USE = nonlocal escaped null const-pool { D.189684 } (escaped)
  n_142 = QtPrivate::qustrchr (D.206385, 46);
  D.206385 ={v} {CLOBBER(eos)};
  if (e_137 != n_142)

the interesting thing is that VRP computes

e_137  : [prange] const char16_t * [1, +INF]


VRP clears PT = null on the pointer and thus makes the compare compare
'nothing' with 'something'.  points-to computes

  # PT = null
  _130 = str.m_data;

the last initilizer is

   [local count: 1034442871]:
  _104 = state$start_100 + state$extra_101;
  MEM[(struct QChar *)&D.206374 clique 15 base 1] ={v} {CLOBBER(bob)};
  MEM[(struct QChar *)&D.206374 clique 15 base 1].ucs = 46;
  str = MEM[(const struct QStringView &)&tok2 + 32];

PTA has

tok2.128+192 = __old_val_8
tok2.128+192 = &NONLOCAL
tok2.128+192 = &NONLOCAL
tok2.128+192 = __old_val_8
str.0+64 = tok2.128+192
_130 = str.64+64

for some reason the

  str = MEM[(const struct QStringView &)&tok2 + 32];

assignment does not generate a

str.64+64 = tok2.192+64

constraint, that is, the source and dest varinfos do not seem to overlap.

We end up with

(gdb) p lhsc
$3 = {> = {m_vec = 0x5219080 = {{
type = SCALAR, var = 145, offset = 0}, {type = SCALAR, var = 146, 
offset = 0}}}, }
(gdb) p rhsc
$6 = {> = {m_vec = 0x5824f60 = {{
type = SCALAR, var = 29, offset = 0}}}, }

where for the RHS that's the third var from 'tok2'.  Having the copy
offset by 32 is a bit odd sice that puts us inside the third subobject
that we have not sub-setted.

In any case the issue seems to be that do_structure_copy applies
the offset "twice" here, it does

  if (!get_ref_base_and_extent_hwi (lhsop, &lhsoffset, &lhssize, &reverse)
  || !get_ref_base_and_extent_hwi (rhsop, &rhsoffset, &rhssize,
   &reverse))
{
  process_all_all_constraints (lhsc, rhsc);
  return;

computing 256 for rhsoffset (from the MEM_REF offset of 32 bytes) and
then checking overlap of two varinfos with

  || ranges_overlap_p (lhsv->offset + rhsoffset, lhsv->size,
   rhsv->offset + lhsoffset, rhsv->size)))

the 2nd var of the LHS does not satisfy overlap.

I think the logic might only work when the offset computed by
get_ref_base_and_extent_hwi aligns with any of the fields offsets.

[Bug c++/120955] [15/16 Regression] 50 % increase in data segment size on avr-gcc for -Os

[fiesh at zefix dot tv via Gcc-bugs]

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

--- Comment #8 from fiesh at zefix dot tv ---
No, I deactivated lto completely.

[Bug libstdc++/120976] error: static_assert( !is_same_v<__float128, long double> failed

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
(In reply to Tomasz Kamiński from comment #3)
> I have posted this patch in May, that will fix the issue:
> https://gcc.gnu.org/pipermail/libstdc++/2025-May/061450.html
> I think we should merge it.
> 
> The only architecture where __float128 exists and is different from long
> double, that I am aware of is x86_64. However, this patch covers that case,
> via formatting it using _Float128.

powerpc as well (at least with some options), one can have long double as IEEE
double, IBM double double and IEEE quad depending on options.
s390 as well (again, long double can be IEEE double or IEEE quad depending on
options).
sparc too.

[Bug tree-optimization/120817] [13/14/15/16 regression] Wrong code when compiled with -O1 -ftree-loop-vectorize for AArch64 target

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #14 from Richard Biener  ---
(In reply to Richard Biener from comment #13)
> (In reply to Tamar Christina from comment #12)
> > Looks like the problem is that during ao_ref_init_from_ptr_and_range when
> > initializing vectp_target.14_54 = &targetD.4595 + _55;
> > 
> > we don't enter the block splitting apart POINTER_PLUS_EXPR.
> > 
> > So it ends up creating a ref with the base being MEM_REF <&targetD.4595 +
> > _55>
> > 
> > later on when checking of &targetD.4595 and MEM_REF <&targetD.4595 + _55>
> > could alias in refs_may_alias_p it doesn't think these two can alias, even
> > though
> > 
> >   # _38 = PHI 
> >   # RANGE [irange] sizetype [0, 0][32, 4294967264] MASK 0xffe0 VALUE 0x0
> >   _55 = (sizetype) _38;
> > 
> > 
> > so clearly they can alias. Need to look into how tree-ssa-alias normally
> > handles PHI offsets.
> 
> The problem is that _55 is negative.  But the alias oracle does not consider
> negative offsets but only the 8B positive offset which makes the access
> clearly out of bounds of &targetD.4595.
> 
> Do not use POINTER_PLUS_EXPR to "advance" a pointer to sth outside of
> [&object, &object + sizeof(object)], since such a pointer is UB.

In fact it might not even help to perform this addition in uintptr_t since
points-to analysis is smart enough to see through those.  And if you
cast that back to a pointer that pointer still cannot alias &target.

That means we currently do not have any means to do a .MASK_{LOAD,STORE}
that's correct to perform the alignment peeling with mask.  And there's
no standards compliant way to do this using intrinsics either (you have
to form the pointer for this as well).

IVOPTs has a similar issue with computing &a - &b and offsetting that, but
in the end the pointer values computed in uintptr_t always point to where
the original program pointed to, so there uintptr_t computation + casting
back to a pointer works.  But this is different - we are creating an
access that, from an alias perspective, starts before the object.

I guess a temporary way out would be to hide the constant negative offset, the
one that creeps in into

  .MASK_STORE (vectp_target.14_54, 8B, max_mask_63, { 0, ... });

I'm not sure this will avoid points-to smarts, but at least the offset
tracking it does isn't reflected into the points-to sets.  And we are
not re-running points-to analysis after vectorization (we just have that
pointer def following smarts).

[Bug bootstrap/119430] profiledbootstrap fails on armv7a-unknown-linux-gnueabhif (crashes in elists__append_elmt during stagefeedback)

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

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

--- Comment #14 from Eric Botcazou  ---
FWIW the "force functions and their inner functions to remain in a single unit"
approach for LTO was already discussed a few times in the past because of very
similar issues pertaining to the static chain, but these issues were internal
to the compiler and it was agreed that it would be better to address them
rather than using this approach, which was done AFAIK.  But this looks more
complicated to do in this case because the linker comes into play.

[Bug sanitizer/120984] New: [16 Regression] Bunch of 'insufficient space for an object of type...' errors during ubsan bootstrap

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

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

Bug ID: 120984
   Summary: [16 Regression] Bunch of 'insufficient space for an
object of type...' errors during ubsan bootstrap
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Keywords: diagnostic, needs-bisection
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pheeck at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

When I do ubsan bootstrap of GCC (--with-build-config=bootstrap-ubsan), I get a
ton of errors like this:

/home/worker/buildworker/tiber-gcc-ubsan/build/gcc/genmodes.cc:975:21: runtime
error: store to address 0x0f9fc0c8 with insufficient space for an object of
type 'struct mode_data *'
0x0f9fc0c8: note: pointer points here
 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  d0 df 9f 0f 00
00 00 00  00 00 00 00
  ^ 

/home/worker/buildworker/tiber-gcc-ubsan/build/gcc/genmodes.cc:2064:7: runtime
error: load of address 0x085ffb84 with insufficient space for an object of
type 'unsigned int'
0x085ffb84: note: pointer points here
  00 00 00 00 80 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  91
00 00 00 00 00 00 00
  ^ 

I see these errors for ~130 different locations in GCC's sources, so I assume
these must be false positives.

This began somewhere between
r16-1757-ge7fb2459b00cde (the newest commit I know, where this doesn't happen)
r16-1999-g6c472b330ac4fc

[Bug lto/120987] gdb build with lto triggers use after free

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

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

--- Comment #4 from Tom de Vries  ---
The problem scenario is as follows.

An error is thrown in symtabs_from_filename:
...
throw_error (NOT_FOUND_ERROR,
 _("No symbol table is loaded.  "
   "Use the \"file\" command."));
...

The error is caught and saved in parse_linespec:
...
  catch (gdb_exception_error &ex)
{
  file_exception = std::move (ex);
}
...
and then rethrown:
...
  if (file_exception.reason < 0)
throw_exception (std::move (file_exception));
...

The gdb_exception class contains a message member:
...
  std::shared_ptr message;
...
and the std::move should leave file_exception.message in a "valid but
unspecified state" but gcc seems optimize that away.

Upon exiting the parse_linespec scope, the file_exception destructor is called.
Since file_exception.message still points to the string, the string is freed.

The exception is caught by create_breakpoint, and the exception is printed:
...
  catch (const gdb_exception_error &e)
{
  ...
  exception_print (gdb_stderr, e);
...

In the process, it accesses the string, which has already been freed, and now
contains random stuff.

[Bug target/55212] [SH] Switch to LRA

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

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

--- Comment #460 from John Paul Adrian Glaubitz  ---
Oleg, would it make sense to rebase your branch on git.gcc.org with master, add
all the tests from your tree on Github and then bootstrap gcc natively to run
the full testsuite to see whether any of the workarounds are redundant with the
current tree?

I would expect that all the tests you added could help verify whether the
workarounds are still necessary, can't they?

[Bug target/120977] [16 Regression] ICE on Cortex-M23/M33/M55/M85 with -mcmse

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

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2025-07-07

--- Comment #1 from Christophe Lyon  ---
I suppose you all the regressions we also reported in
https://linaro.atlassian.net/browse/GNU-1596 ?

[Bug lto/120987] [14/15/16 regression] gdb build with lto triggers use after free since r14-5831-gaae723d360ca26

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

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

Sam James  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org
   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=32571
Summary|gdb build with lto triggers |[14/15/16 regression] gdb
   |use after free  |build with lto triggers use
   ||after free since
   ||r14-5831-gaae723d360ca26
   Target Milestone|--- |14.4
   Keywords||wrong-code

--- Comment #5 from Sam James  ---
(In reply to Tom de Vries from comment #3)
> First bad commit:
> - commit aae723d360c
>   ("sra: SRA of non-escaped aggregates passed by reference to calls")
> 

r14-5831-gaae723d360ca26

> First good commit after first bad commit:
> - commit cee7d080d5c
>   ("Ignore conditions guarding __builtin_unreachable in inliner metrics")
> 

r15-5336-gcee7d080d5c2a5

> It's not clear whether the problem has been fixed, or just no longer
> triggers.

It'll be latent after that second commit, unfortunately.

[Bug tree-optimization/120358] [15/16 regression] qtbase-6.9.0 miscompiled since r15-580-gf3e5f4c58591f5

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

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

--- Comment #29 from Alexander Monakov  ---
The above is bisectable on the 'match' dbgcnt, which ends on this transform in
vrp1:

Folding statement: if (e_137 != n_142)
 Registering value_relation (e_137 != n_142) on (33->35)
 Registering value_relation (e_137 == n_142) on (33->34)

Visiting conditional with predicate: if (e_137 != n_142)

With known ranges
e_137: [prange] const char16_t * [1, +INF]  n_142: [prange] const
char16_t * VARYING

Predicate evaluates to: DON'T KNOW
Matching expression match.pd:2934, gimple-match-8.cc:90
Matching expression match.pd:2938, gimple-match-4.cc:77
***dbgcnt: upper limit 22638 reached for match.***
Applying pattern match.pd:7956, gimple-match-9.cc:4682
gimple_simplified to if (1 != 0)
Folded into: if (1 != 0)

which looks highly suspicious as it eliminates this branch:

  # PT = nonlocal escaped null const-pool { D.189389 } (escaped)
  # USE = nonlocal escaped null const-pool { D.189389 } (escaped)
  n_142 = QtPrivate::qustrchr (D.204906, 46);
  D.204906 ={v} {CLOBBER(eos)};
  if (e_137 != n_142)
goto ; [98.33%]
  else
goto ; [1.67%]


above that, for e_137 we have

  # PT =
  e_137 = _130 + _136;

and for _130

  # PT = null
  _130 = str.m_data;

which is wrong?

[Bug c++/120917] warning: use of 'auto' in template argument only available with '-fconcepts-ts'

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

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

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

https://gcc.gnu.org/g:8abc2e66be72a34db8c3cc97e4fbd90b7abae61d

commit r16-2065-g8abc2e66be72a34db8c3cc97e4fbd90b7abae61d
Author: Jason Merrill 
Date:   Wed Jul 2 05:15:01 2025 -0400

c++: -Wno-abbreviated-auto-in-template-arg [PR120917]

In r14-1659 I added a missing error for a Concepts TS feature that we were
failing to diagnose, but this PR requests a way to disable that error for
code written thinking it was valid.  Which seems reasonable, since it
doesn't require any work beyond that and is a plausible extension by
itself.

While looking at this, I also noticed we were still not giving the
diagnostic in a few cases, and fixing that affected a few of our old
concepts testcases.

PR c++/120917

gcc/ChangeLog:

* doc/invoke.texi: Add -Wno-abbreviated-auto-in-template-arg.

gcc/c-family/ChangeLog:

* c.opt: Add -Wno-abbreviated-auto-in-template-arg.
* c.opt.urls: Regenerate.

gcc/cp/ChangeLog:

* parser.cc (cp_parser_simple_type_specifier): Attach
auto in targ in parameter to -Wabbreviated-auto-in-template-arg.
(cp_parser_placeholder_type_specifier): Diagnose constrained auto
in
template arg.

gcc/testsuite/ChangeLog:

* g++.dg/concepts/auto7a.C: Add diagnostic.
* g++.dg/concepts/auto7b.C: New test.
* g++.dg/concepts/auto7c.C: New test.
* g++.dg/cpp1y/pr85076.C: Expect 'auto' error.
* g++.dg/concepts/pr67249.C: Likewise.
* g++.dg/cpp1y/lambda-generic-variadic.C: Likewise.
* g++.dg/cpp2a/concepts-pr67210.C: Likewise.
* g++.dg/concepts/pr67249a.C: New test.
* g++.dg/cpp1y/lambda-generic-variadic-a.C: New test.
* g++.dg/cpp2a/concepts-pr67210a.C: New test.

[Bug c++/120917] warning: use of 'auto' in template argument only available with '-fconcepts-ts'

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

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

Jason Merrill  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
   Last reconfirmed||2025-07-07
 Resolution|INVALID |---
 Ever confirmed|0   |1

--- Comment #20 from Jason Merrill  ---
(In reply to Frank Heckenbach from comment #18)
> So, could this be a viable workaround?

If you're going to modify your code to address this, it seems more
straightforward to add the explicit template-head.

[Bug target/120977] [16 Regression] ICE on Cortex-M23/M33/M55/M85 with -mcmse

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

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

--- Comment #2 from Torbjorn SVENSSON  ---
(In reply to Christophe Lyon from comment #1)
> I suppose you all the regressions we also reported in
> https://linaro.atlassian.net/browse/GNU-1596 ?

Looks like it's the same regression yes.

[Bug c++/120988] New: -Wconversion warning for uint /= ulong makes no sense

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

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

Bug ID: 120988
   Summary: -Wconversion warning for uint /= ulong makes no sense
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

void f(unsigned int ui, unsigned long ul)
{
  ui /= ul;
}

div.cc:3:6: warning: conversion from ‘long unsigned int’ to ‘unsigned int’ may
change value [-Wconversion]
3 |   ui /= ul;
  |   ~~~^


This warning is wrong, there is no way for this to change the value.

[Bug tree-optimization/120817] [13/14/15 Regression] Wrong code when compiled with -O1 -ftree-loop-vectorize for AArch64 target

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Known to work||16.0
Summary|[13/14/15/16 regression]|[13/14/15 Regression] Wrong
   |Wrong code when compiled|code when compiled with -O1
   |with -O1|-ftree-loop-vectorize for
   |-ftree-loop-vectorize for   |AArch64 target
   |AArch64 target  |

[Bug tree-optimization/120358] [15/16 regression] qtbase-6.9.0 miscompiled since r15-580-gf3e5f4c58591f5

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

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

--- Comment #32 from Richard Biener  ---
Hmm, or rather the logic is fine, there's simply no field at that offset in the
set of RHS constraints.  There's the missing field

$21 = {id = 30, is_artificial_var = 0, is_special_var = 0, 
  is_unknown_size_var = 0, is_full_var = 0, is_heap_var = 0, is_reg_var = 0, 
  may_have_pointers = 1, only_restrict_pointers = 0, is_restrict_var = 0, 
  is_global_var = 0, is_ipa_escape_point = 0, is_fn_info = 0, 
  address_taken = 0, ruid = 0, next = 31, head = 27, offset = 320, size = 64, 
  fullsize = 448, shadow_var_uid = 0, name = 0x7fffee90d3e0 "tok2.320+64", 
  decl = , solution = 0x586ee50, 
  oldsolution = 0x0}

and the issue is in get_constraint_for_1 which doesn't take into account
the case where the offset doesn't align with the first field that is
accessed.

diff --git a/gcc/tree-ssa-structalias.cc b/gcc/tree-ssa-structalias.cc
index deca44ae0bf..0215243d5be 100644
--- a/gcc/tree-ssa-structalias.cc
+++ b/gcc/tree-ssa-structalias.cc
@@ -3690,7 +3690,10 @@ get_constraint_for_1 (tree t, vec *results, bool
address_p,
size = -1;
  for (; curr; curr = vi_next (curr))
{
- if (curr->offset - vi->offset < size)
+ /* The start of the access might happen anywhere
+within vi, so conservatively assume it was
+at its end.  */
+ if (curr->offset - (vi->offset + vi->size - 1) < size)
{
  cs.var = curr->id;
  results->safe_push (cs);

Mail delivery failed: returning message to sender

[Mail Delivery System via Gcc-bugs]

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  connorweston...@yahoo.com
host cleanserver.mxserver.ro [89.44.139.128]
SMTP error from remote mail server after end of data:
550 High probability of spam
Reporting-MTA: dns; cloud332.mxserver.ro

Action: failed
Final-Recipient: rfc822;connorweston833@yahoo.com
Status: 5.0.0
Remote-MTA: dns; cleanserver.mxserver.ro
Diagnostic-Code: smtp; 550 High probability of spam

[Bug tree-optimization/120817] [13/14/15/16 regression] Wrong code when compiled with -O1 -ftree-loop-vectorize for AArch64 target

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

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

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

https://gcc.gnu.org/g:439b14e222571da76da2bfec04b9035fb9f1862d

commit r16-2062-g439b14e222571da76da2bfec04b9035fb9f1862d
Author: Richard Biener 
Date:   Mon Jul 7 09:56:50 2025 +0200

tree-optimization/120817 - bogus DSE of .MASK_STORE

DSE used ao_ref_init_from_ptr_and_size for .MASK_STORE but
alias-analysis will use the specified size to disambiguate
against smaller objects.  For .MASK_STORE we instead have to
make the access size unspecified but we can still constrain
the access extent based on the maximum size possible.

PR tree-optimization/120817
* tree-ssa-dse.cc (initialize_ao_ref_for_dse): Use
ao_ref_init_from_ptr_and_range with unknown size for
.MASK_STORE and .MASK_LEN_STORE.

* gcc.dg/vect/pr120817.c: New testcase.

[Bug tree-optimization/120982] Incorrect alignment after (early exit) vectorization

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

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Keywords||wrong-code
   Last reconfirmed||2025-07-07
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed also on x86_64.  We have

  vect__1.10_24 = __MEM  ((long int
*)vectp_a.8_22);
  # PT = anything
  # ALIGN = 32, MISALIGN = 0
  vectp_a.8_25 = vectp_a.8_22 + 16ul;
  vect__1.11_26 = __MEM  ((long int
*)vectp_a.8_25);

so it seems we set wrong alignment info on the SSA name after the increment.

It's possibly harmless since we are going to propagate those stmts out
and the information will get lost.

[Bug tree-optimization/120817] [13/14/15/16 regression] Wrong code when compiled with -O1 -ftree-loop-vectorize for AArch64 target

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

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

--- Comment #15 from Tamar Christina  ---
(In reply to Richard Biener from comment #13)
> (In reply to Tamar Christina from comment #12)
> > Looks like the problem is that during ao_ref_init_from_ptr_and_range when
> > initializing vectp_target.14_54 = &targetD.4595 + _55;
> > 
> > we don't enter the block splitting apart POINTER_PLUS_EXPR.
> > 
> > So it ends up creating a ref with the base being MEM_REF <&targetD.4595 +
> > _55>
> > 
> > later on when checking of &targetD.4595 and MEM_REF <&targetD.4595 + _55>
> > could alias in refs_may_alias_p it doesn't think these two can alias, even
> > though
> > 
> >   # _38 = PHI 
> >   # RANGE [irange] sizetype [0, 0][32, 4294967264] MASK 0xffe0 VALUE 0x0
> >   _55 = (sizetype) _38;
> > 
> > 
> > so clearly they can alias. Need to look into how tree-ssa-alias normally
> > handles PHI offsets.
> 
> The problem is that _55 is negative.  But the alias oracle does not consider
> negative offsets but only the 8B positive offset which makes the access
> clearly out of bounds of &targetD.4595.
> 
> Do not use POINTER_PLUS_EXPR to "advance" a pointer to sth outside of
> [&object, &object + sizeof(object)], since such a pointer is UB.

Why do you think _55 is negative? It's 0 or 32. It's the amount of bytes
processed in the earlier loops. So can't be negative.

The problem to me seems that we build a MEM_REF over the POINTER_PLUS_EXPR as a
whole when the offset
isn't a constant.

This fixes it for me

diff --git a/gcc/tree-ssa-alias.cc b/gcc/tree-ssa-alias.cc
index 9dd1780867d..b3cd4fa65a5 100644
--- a/gcc/tree-ssa-alias.cc
+++ b/gcc/tree-ssa-alias.cc
@@ -890,11 +890,11 @@ ao_ref_init_from_ptr_and_range (ao_ref *ref, tree ptr,
  && gimple_assign_rhs_code (stmt) == ADDR_EXPR)
ptr = gimple_assign_rhs1 (stmt);
   else if (is_gimple_assign (stmt)
-  && gimple_assign_rhs_code (stmt) == POINTER_PLUS_EXPR
-  && ptrdiff_tree_p (gimple_assign_rhs2 (stmt), &extra_offset))
+  && gimple_assign_rhs_code (stmt) == POINTER_PLUS_EXPR)
{
  ptr = gimple_assign_rhs1 (stmt);
- extra_offset *= BITS_PER_UNIT;
+ if (ptrdiff_tree_p (gimple_assign_rhs2 (stmt), &extra_offset))
+   extra_offset *= BITS_PER_UNIT;
}
 }

because it allows alias analysis to compare &object and &object + _55
correctly.
With the bolded MEM_REF it compares &object and MEM<&object +_55> and so
doesn't check the components of the address.

[Bug tree-optimization/120903] Alias information not used to optimize out hand-written buffer aliasing checks

[andreser-gccbugs at mit dot edu via Gcc-bugs]

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

andreser-gccbugs at mit dot edu changed:

   What|Removed |Added

 CC||andreser-gccbugs at mit dot edu

--- Comment #6 from andreser-gccbugs at mit dot edu ---
The use case we minimized this test case from has the pointer a distinct from
&r. Here is a new minimized version: https://godbolt.org/z/MqjKTc18M

 int main() { 
   uint32_t r = 1, a = 0;
   funny_memcpy(&r, &a, sizeof(r));
   return r;
 }

GCC still emits 6 instructions of overlap test.

[Bug c++/120989] New: Shouldn't warn about the use of deprecated non-static data members in implicit special member functions

[iamsupermouse at mail dot ru via Gcc-bugs]

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

Bug ID: 120989
   Summary: Shouldn't warn about the use of deprecated non-static
data members in implicit special member functions
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iamsupermouse at mail dot ru
  Target Milestone: ---

Here's the testcase:

struct A
{
[[deprecated]] int x = 42;
};

int main()
{
A a;
A b = a;
a = b;
}

Here GCC warns about `A::x` being deprecated a few times, when it's used in the
implicitly generated special member functions.

I don't think it should warn here, only the manual uses of `x` should be
diagnosed. Clang has the same bug:
https://github.com/llvm/llvm-project/issues/147293 , while MSVC doesn't warn
about this.

[Bug tree-optimization/120817] [13/14/15/16 regression] Wrong code when compiled with -O1 -ftree-loop-vectorize for AArch64 target

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

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

--- Comment #17 from Tamar Christina  ---
(In reply to Richard Biener from comment #16)
> No, that cannot be required for correct operation.  I think DSE is wrong in
> assessing that the store covers more than 5 bytes.  The following fixes it
> for me
> 
> diff --git a/gcc/tree-ssa-dse.cc b/gcc/tree-ssa-dse.cc
> index 5ac4280ee36..51a572316cd 100644
> --- a/gcc/tree-ssa-dse.cc
> +++ b/gcc/tree-ssa-dse.cc
> @@ -181,10 +181,10 @@ initialize_ao_ref_for_dse (gimple *stmt, ao_ref
> *write, bool may_def_ok = false)
>can provide a may-def variant.  */
> if (may_def_ok)
>   {
> -   ao_ref_init_from_ptr_and_size (
> - write, gimple_call_arg (stmt, 0),
> - TYPE_SIZE_UNIT (
> -   TREE_TYPE (gimple_call_arg (stmt, stored_value_index;
> +   ao_ref_init_from_ptr_and_range (
> + write, gimple_call_arg (stmt, 0), true, 0, -1,
> + tree_to_poly_int64 (TYPE_SIZE (
> +   TREE_TYPE (gimple_call_arg (stmt,
> stored_value_index);
> return true;
>   }
> break;
> 

That's the same as I was suggesting on IRC, the only difference is that I
handled it in the called, since the rang *is* known if the value is a poly
constant.  So I think this change is overzealous as it does block vectp_+
POLY_INT_CST where we do know the offset.

[Bug tree-optimization/120982] Incorrect alignment after (early exit) vectorization

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

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org
 CC||rguenth at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org,
   ||tnfchris at gcc dot gnu.org
 Status|ASSIGNED|NEW

--- Comment #2 from Richard Biener  ---
This is

  /* 2. Create the vector-load in the loop.  */
  switch (alignment_support_scheme)
{
case dr_aligned:
case dr_unaligned_supported:
...
align = known_alignment (DR_TARGET_ALIGNMENT (first_dr_info));
if (alignment_support_scheme == dr_aligned)
  misalign = 0;
...
if (dataref_offset == NULL_TREE
&& TREE_CODE (dataref_ptr) == SSA_NAME)
  set_ptr_info_alignment (get_ptr_info (dataref_ptr), align,
  misalign);

the issue is that early break vectorization "abuses" DR_TARGET_ALIGNMENT
here.  But that only specifies alignment of the whole group, not that
of the individual accesses.

[Bug driver/120985] New: Possible memory leak in read_specs at gcc.cc

[shuhaofu.g at gmail dot com via Gcc-bugs]

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

Bug ID: 120985
   Summary: Possible memory leak in read_specs at gcc.cc
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shuhaofu.g at gmail dot com
  Target Milestone: ---

Affected Commit: 559ddecabef9c23210c84fdb05fceaf9cee81bd9 @ github mirror
Affected Function: read_specs @ gcc.cc

1. `save_string` executes and returns a heap-allocated buffer to `suffix`
Line:
https://github.com/gcc-mirror/gcc/blob/559ddecabef9c23210c84fdb05fceaf9cee81bd9/gcc/gcc.cc#L2559)

2. selects true branch here `suffix[0] == '*'`
Line:
https://github.com/gcc-mirror/gcc/blob/559ddecabef9c23210c84fdb05fceaf9cee81bd9/gcc/gcc.cc#L2592

After the above branch, `suffix` is neither saved into a global variable nor
freed manually. Given that such a leak lies in a while loop, it seems worth
fixing. 

If confirmed, it may also be easily fixed by inserting `free(suffix)` before
https://github.com/gcc-mirror/gcc/blob/559ddecabef9c23210c84fdb05fceaf9cee81bd9/gcc/gcc.cc#L2616,
without hurting the readability.

[Bug target/120888] [16 regression] promotion of unsigned char and short function arguments sign extends them since r16-170-ga670ebde3995

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

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

--- Comment #7 from jcmvbkbc at gcc dot gnu.org ---
(In reply to H.J. Lu from comment #6)
> You can update xtensa_promote_function_mode to control how to promote
> return value.

I don't think I need to change anything there because the patch that you posted
promotes the return values the same way as arguments, i.e. zero extends
unsigned and sign extends signed.

The gfortran.dg/c_char_tests_5.f90 started failing not since the
r16-170-ga670ebde3995, but right before it, since r16-169-g78db4753c964.

The regression in gcc.dg/tree-ssa/pr84436-5.c has two parts. The first part is
that the signed value that becomes the return value of the function foo() is
not sign extended. This is not new, but it looks like a separate issue, it also
wasn't sign extended before the r16-170-ga670ebde3995. The second part is that
now the main() doesn't sign extend the result returned by the function foo(),
exposing the first issue.

I guess I should apply your fix and deal with these failures separately.

[Bug driver/120985] Possible memory leak in read_specs at gcc.cc

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

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

--- Comment #1 from Jonathan Wakely  ---
The memory use and ownership in gcc.cc is a mess. I tried to rewrite everything
to use standard library types and gave up.

[Bug tree-optimization/120929] [16 Regression] file-5.45 triggers _FORTIFY_SOURCE false positives since r16-1905-g7165ca43caf470

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

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

Sam James  changed:

   What|Removed |Added

 CC||pheeck at gcc dot gnu.org

--- Comment #22 from Sam James  ---
*** Bug 120984 has been marked as a duplicate of this bug. ***

[Bug sanitizer/120984] [16 Regression] Bunch of 'insufficient space for an object of type...' errors during ubsan bootstrap

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #1 from Sam James  ---
I'm 99% sure this is the same thing as PR120929.

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

[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined

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

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

Bug 120984 Summary: [16 Regression] Bunch of 'insufficient space for an object 
of type...' errors during ubsan bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120984

   What|Removed |Added

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

[Bug tree-optimization/120358] [15/16 regression] qtbase-6.9.0 miscompiled since r15-580-gf3e5f4c58591f5

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

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

--- Comment #33 from Richard Biener  ---
Something like the following might be a testcase, needs -fno-tree-sra
but it fails to demonstrate the particular sub-field layout for Y.

struct X { int *p; int *q; };
struct Y { struct X a; struct { unsigned pad : 1; struct X b; } b; };
static int i, j, k, l;
int foo (int c)
{
  struct Y y;
  y.b.b.p = &i;
  y.b.b.q = &j;
  char *p = (char *)&y;
  struct X z;
  z = *(struct X *)(p + sizeof (struct X) + sizeof (unsigned));
  return *z.q;
}

so no nice small testcase for now.

[Bug c++/120988] -Wconversion warning for uint /= ulong makes no sense

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug libstdc++/117214] chrono format error for time point using %c: D_T_FMT cannot be directly used as chrono-specs

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

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

--- Comment #10 from GCC Commits  ---
The master branch has been updated by Tomasz Kaminski :

https://gcc.gnu.org/g:8ad5968a8dcb472cbff8e4c48217fd65e125b2f2

commit r16-2063-g8ad5968a8dcb472cbff8e4c48217fd65e125b2f2
Author: XU Kailiang 
Date:   Wed Jul 2 15:10:29 2025 +0800

libstdc++: Format chrono %a/%A/%b/%h/%B/%p using locale's time_put
[PR117214]

C++ formatting locale could have a custom time_put that performs
differently from the C locale, so do not use __timepunct directly,
instead all of above specifiers use _M_locale_fmt.

For %a/%A/%b/%h/%B, the code handling the exception is now moved
to the _M_check_ok function, that is invoked before handling of the
conversion specifier. For time_points the values of months/weekday
are computed, and thus are always ok(), this information is indicated
by new _M_time_point member of the _ChronoSpec.

The different behavior of j specifier for durations and
time_points/calendar
types, is now handled using only _ChronoParts, and _M_time_only in
_ChronoSpec
is no longer needed, thus it was removed.

PR libstdc++/117214

libstdc++-v3/ChangeLog:

* include/bits/chrono_io.h (_ChronoSpec::_M_time_only): Remove.
(_ChronoSpec::_M_time_point): Define.
(__formatter_chrono::_M_parse): Use __parts to determine
interpretation of j.
(__formatter_chrono::_M_check_ok): Define.
(__formatter_chrono::_M_format_to): Invoke _M_check_ok.
(__formatter_chrono::_M_a_A, __formatter_chrono::_M_b_B): Move
exception throwing to _M_check_ok.
(__formatter_chrono::_M_j): Use _M_needs to define interpretation.
(__formatter_duration::_S_spec_for): Set _M_time_point.
* testsuite/std/time/format/format.cc: Test for exception for !ok()
months/weekday.
* testsuite/std/time/format/pr117214_custom_timeput.cc: New
test.

Co-authored-by: Tomasz Kaminski 
Reviewed-by: Jonathan Wakely 
Signed-off-by: XU Kailiang 
Signed-off-by: Tomasz Kaminski 

[Bug c++/84009] No diagnostic issued if the decl-specifier in the decl-specifier-seq of a for-range-declaration is register, static,or thread_local

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

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

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

https://gcc.gnu.org/g:66455591fac1e80b5acc615598cbf556d565e080

commit r16-2046-g66455591fac1e80b5acc615598cbf556d565e080
Author: Jakub Jelinek 
Date:   Mon Jul 7 09:17:34 2025 +0200

c++: Pedwarn on invalid decl specifiers for for-range-declaration [PR84009]

https://eel.is/c++draft/stmt.ranged#2
says that in for-range-declaration only type-specifier or constexpr
can appear.  As the following testcases show, we've emitted some
diagnostics in most cases, but not for static/thread_local (the patch
handles __thread too) and register in the non-sb case.
For extern there was an error that it is both extern and has an
initializer (again, non-sb only, sb errors on extern).

The following patch diagnoses those cases with pedwarn.
I've used for-range-declaration in the diagnostics wording (there was
already a case of that for the typedef), so that in the future
we don't need to differentiate it between range for and expansion
statements.

2025-07-07  Jakub Jelinek  

PR c++/84009
* parser.cc (cp_parser_decomposition_declaration): Pedwarn
on thread_local, __thread or static in decl_specifiers for
for-range-declaration.
(cp_parser_init_declarator): Likewise, and also for extern
or register.

* g++.dg/cpp0x/range-for40.C: New test.
* g++.dg/cpp0x/range-for41.C: New test.
* g++.dg/cpp0x/range-for42.C: New test.
* g++.dg/cpp0x/range-for43.C: New test.

[Bug tree-optimization/120980] Vectorizer (early exit) introduces out-of-bounds memory access

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

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

--- Comment #2 from Richard Biener  ---
Hmm, I didn't consider the case where the access as the vectorizer views it
(the 4 element "vector") has to be split due to target implementation concerns.
We do not want to introduce additional code generation overhead to avoid a
fully out-of-bounds but known not trapping because it's known to fall into
the same page as a previous partly not out-of-bounds access.  But I realize
this altered constraint might be difficult to implement in the
analysis tool?

This might also happen outside of early break vectorization.

[Bug target/119703] x86: spurious branches for inlined memset in ranges (40; 64) when requesting unrolled loops without simd

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

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #2 from H.J. Lu  ---
Fixed for GCC 16.

[Bug tree-optimization/120979] Missed strdup to malloc + memcpy for known strings

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

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

--- Comment #4 from Richard Biener  ---
I guess we miss a memdup, using strndup instead of strdup might be a small
improvement.

I don't think inlining it is a good thing to do, this should be addressed
at the library level.

[Bug c++/120968] Using global C name with import std recommends using the same undeclared name

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug lto/120987] gdb build with lto triggers use after free

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

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

--- Comment #1 from Tom de Vries  ---
Created attachment 61812
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61812&action=edit
valgrind log

[Bug target/120986] ICE when expanding svdot_lane_fpm intrinsic with compile time know FPMR

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

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

--- Comment #2 from Alfie Richards  ---
Final reproducer:

```c
#include 

svfloat16_t test (svfloat16_t a, svmfloat8_t b, svmfloat8_t c)
{
return svdot_lane_fpm (a, b, c, 0, 0);
}
```

Compiled with `-O2 -march=armv8-a+sve2+fp8dot2`

[Bug lto/120987] gdb build with lto triggers use after free

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

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

--- Comment #2 from Tom de Vries  ---
Workaround:
...
diff --git a/gdb/linespec.c b/gdb/linespec.c
index b59c0553c34..46b25a0047d 100644
--- a/gdb/linespec.c
+++ b/gdb/linespec.c
@@ -2615,7 +2615,7 @@ parse_linespec (linespec_parser *parser, const ch
ar *arg,
   /* The linespec didn't parse.  Re-throw the file exception if
 there was one.  */
   if (file_exception.reason < 0)
-   throw_exception (std::move (file_exception));
+   throw_exception (gdb_exception (file_exception));

   /* Otherwise, the symbol is not found.  */
   symbol_not_found_error
...

[Bug lto/120987] gdb build with lto triggers use after free

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

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

--- Comment #3 from Tom de Vries  ---
The investigation in the gdb PR has identified a range of bad commits.

First bad commit:
- commit aae723d360c
  ("sra: SRA of non-escaped aggregates passed by reference to calls")

First good commit after first bad commit:
- commit cee7d080d5c
  ("Ignore conditions guarding __builtin_unreachable in inliner metrics")

It's not clear whether the problem has been fixed, or just no longer triggers.

[Bug tree-optimization/120817] [13/14/15/16 regression] Wrong code when compiled with -O1 -ftree-loop-vectorize for AArch64 target

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

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

--- Comment #13 from Richard Biener  ---
(In reply to Tamar Christina from comment #12)
> Looks like the problem is that during ao_ref_init_from_ptr_and_range when
> initializing vectp_target.14_54 = &targetD.4595 + _55;
> 
> we don't enter the block splitting apart POINTER_PLUS_EXPR.
> 
> So it ends up creating a ref with the base being MEM_REF <&targetD.4595 +
> _55>
> 
> later on when checking of &targetD.4595 and MEM_REF <&targetD.4595 + _55>
> could alias in refs_may_alias_p it doesn't think these two can alias, even
> though
> 
>   # _38 = PHI 
>   # RANGE [irange] sizetype [0, 0][32, 4294967264] MASK 0xffe0 VALUE 0x0
>   _55 = (sizetype) _38;
> 
> 
> so clearly they can alias. Need to look into how tree-ssa-alias normally
> handles PHI offsets.

The problem is that _55 is negative.  But the alias oracle does not consider
negative offsets but only the 8B positive offset which makes the access
clearly out of bounds of &targetD.4595.

Do not use POINTER_PLUS_EXPR to "advance" a pointer to sth outside of
[&object, &object + sizeof(object)], since such a pointer is UB.

[Bug tree-optimization/120954] [13/14/15 Regression] False positive -Warray-bounds=2 warning

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
Summary|[12/13/14/15 Regression]|[13/14/15 Regression] False
   |False positive  |positive -Warray-bounds=2
   |-Warray-bounds=2 warning|warning
   Target Milestone|12.5|13.5

--- Comment #7 from Jakub Jelinek  ---
PR120471 fix has been reverted on 12 branch in r12-11254 and r12-11255

[Bug tree-optimization/120817] [13/14/15/16 regression] Wrong code when compiled with -O1 -ftree-loop-vectorize for AArch64 target

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

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|tnfchris at gcc dot gnu.org|rguenth at gcc dot 
gnu.org

--- Comment #16 from Richard Biener  ---
No, that cannot be required for correct operation.  I think DSE is wrong in
assessing that the store covers more than 5 bytes.  The following fixes it
for me

diff --git a/gcc/tree-ssa-dse.cc b/gcc/tree-ssa-dse.cc
index 5ac4280ee36..51a572316cd 100644
--- a/gcc/tree-ssa-dse.cc
+++ b/gcc/tree-ssa-dse.cc
@@ -181,10 +181,10 @@ initialize_ao_ref_for_dse (gimple *stmt, ao_ref *write,
bool may_def_ok = false)
   can provide a may-def variant.  */
if (may_def_ok)
  {
-   ao_ref_init_from_ptr_and_size (
- write, gimple_call_arg (stmt, 0),
- TYPE_SIZE_UNIT (
-   TREE_TYPE (gimple_call_arg (stmt, stored_value_index;
+   ao_ref_init_from_ptr_and_range (
+ write, gimple_call_arg (stmt, 0), true, 0, -1,
+ tree_to_poly_int64 (TYPE_SIZE (
+   TREE_TYPE (gimple_call_arg (stmt, stored_value_index);
return true;
  }
break;

but eventually this boils down to DSE not correctly assessing how alias
analysis works, in particular when we run into indirect_ref_may_alias_decl_p
we do

  /* If the pointer based access is bigger than the variable they cannot
 alias.  This is similar to the check below where we use TBAA to
 increase the size of the pointer based access based on the dynamic
 type of a containing object we can infer from it.  */
  poly_int64 dsize2;
  if (known_size_p (size1)
  && poly_int_tree_p (DECL_SIZE (base2), &dsize2)
  && known_lt (dsize2, size1))
return false;

and clearly DSE claimed the access was of a size that's larger than the
decl.  DSE thought there are cases where "may_def_ok", but clearly this
wasn't anticipated.

[Bug go/120670] vector_loop caused FAIL: go.test/test/fixedbugs/issue13160.go execution, -O2 -g

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:401199377c50045ede560daf3f6e8b51749c2a87

commit r16-2047-g401199377c50045ede560daf3f6e8b51749c2a87
Author: H.J. Lu 
Date:   Tue Jun 17 10:17:17 2025 +0800

x86: Improve vector_loop/unrolled_loop for memset/memcpy

1. Don't generate the loop if the loop count is 1.
2. For memset with vector on small size, use vector if small size supports
vector, otherwise use the scalar value.
3. Always expand vector-version of memset for vector_loop.
4. Always duplicate the promoted scalar value for vector_loop if not 0 nor
-1.
5. Use misaligned prologue if alignment isn't needed.  When misaligned
prologue is used, check if destination is actually aligned and update
destination alignment if aligned.
6. Use move_by_pieces and store_by_pieces for memcpy and memset epilogues
with the fixed epilogue size to enable overlapping moves and stores.

The included tests show that codegen of vector_loop/unrolled_loop for
memset/memcpy are significantly improved.  For

void
foo (void *p1, size_t len)
{
  __builtin_memset (p1, 0, len);
}

with

-O2 -minline-all-stringops
-mmemset-strategy=vector_loop:256:noalign,libcall:-1:noalign -march=x86-64

we used to generate

foo:
.LFB0:
.cfi_startproc
movq%rdi, %rax
pxor%xmm0, %xmm0
cmpq$64, %rsi
jnb .L18
.L2:
andl$63, %esi
je  .L1
xorl%edx, %edx
testb   $1, %sil
je  .L5
movl$1, %edx
movb$0, (%rax)
cmpq%rsi, %rdx
jnb .L19
.L5:
movb$0, (%rax,%rdx)
movb$0, 1(%rax,%rdx)
addq$2, %rdx
cmpq%rsi, %rdx
jb  .L5
.L1:
ret
.p2align 4,,10
.p2align 3
.L18:
movq%rsi, %rdx
xorl%eax, %eax
andq$-64, %rdx
.L3:
movups  %xmm0, (%rdi,%rax)
movups  %xmm0, 16(%rdi,%rax)
movups  %xmm0, 32(%rdi,%rax)
movups  %xmm0, 48(%rdi,%rax)
addq$64, %rax
cmpq%rdx, %rax
jb  .L3
addq%rdi, %rax
jmp .L2
.L19:
ret
.cfi_endproc

with very poor prologue/epilogue.  With this patch, we now generate:

foo:
.LFB0:
.cfi_startproc
pxor%xmm0, %xmm0
cmpq$64, %rsi
jnb .L2
testb   $32, %sil
jne .L19
testb   $16, %sil
jne .L20
testb   $8, %sil
jne .L21
testb   $4, %sil
jne .L22
testq   %rsi, %rsi
jne .L23
.L1:
ret
.p2align 4,,10
.p2align 3
.L2:
movups  %xmm0, -64(%rdi,%rsi)
movups  %xmm0, -48(%rdi,%rsi)
movups  %xmm0, -32(%rdi,%rsi)
movups  %xmm0, -16(%rdi,%rsi)
subq$1, %rsi
cmpq$64, %rsi
jb  .L1
andq$-64, %rsi
xorl%eax, %eax
.L9:
movups  %xmm0, (%rdi,%rax)
movups  %xmm0, 16(%rdi,%rax)
movups  %xmm0, 32(%rdi,%rax)
movups  %xmm0, 48(%rdi,%rax)
addq$64, %rax
cmpq%rsi, %rax
jb  .L9
ret
.p2align 4,,10
.p2align 3
.L23:
movb$0, (%rdi)
testb   $2, %sil
je  .L1
xorl%eax, %eax
movw%ax, -2(%rdi,%rsi)
ret
.p2align 4,,10
.p2align 3
.L19:
movups  %xmm0, (%rdi)
movups  %xmm0, 16(%rdi)
movups  %xmm0, -32(%rdi,%rsi)
movups  %xmm0, -16(%rdi,%rsi)
ret
.p2align 4,,10
.p2align 3
.L20:
movups  %xmm0, (%rdi)
movups  %xmm0, -16(%rdi,%rsi)
ret
.p2align 4,,10
.p2align 3
.L21:
movq$0, (%rdi)
movq$0, -8(%rdi,%rsi)
ret
.p2align 4,,10
.p2align 3
.L22:
movl$0, (%rdi)
movl$0, -4(%rdi,%rsi)
ret
.cfi_endproc

gcc/

PR target/120670
PR target/120683
* config/i386/i386-expand.cc (expand_set_or_cpymem_via_loop):
Don't generate the loop if the loop count is 1.
(expand_cpymem_epilogue): Use move_by_pieces.
(setmem_epilogue_gen_val): New.
(expand_setmem_epilogue): Use store_by_pieces.
(exp

[Bug target/120683] vector_loop/unrolled_loop generates poor codes on memset/memcpy

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:401199377c50045ede560daf3f6e8b51749c2a87

commit r16-2047-g401199377c50045ede560daf3f6e8b51749c2a87
Author: H.J. Lu 
Date:   Tue Jun 17 10:17:17 2025 +0800

x86: Improve vector_loop/unrolled_loop for memset/memcpy

1. Don't generate the loop if the loop count is 1.
2. For memset with vector on small size, use vector if small size supports
vector, otherwise use the scalar value.
3. Always expand vector-version of memset for vector_loop.
4. Always duplicate the promoted scalar value for vector_loop if not 0 nor
-1.
5. Use misaligned prologue if alignment isn't needed.  When misaligned
prologue is used, check if destination is actually aligned and update
destination alignment if aligned.
6. Use move_by_pieces and store_by_pieces for memcpy and memset epilogues
with the fixed epilogue size to enable overlapping moves and stores.

The included tests show that codegen of vector_loop/unrolled_loop for
memset/memcpy are significantly improved.  For

void
foo (void *p1, size_t len)
{
  __builtin_memset (p1, 0, len);
}

with

-O2 -minline-all-stringops
-mmemset-strategy=vector_loop:256:noalign,libcall:-1:noalign -march=x86-64

we used to generate

foo:
.LFB0:
.cfi_startproc
movq%rdi, %rax
pxor%xmm0, %xmm0
cmpq$64, %rsi
jnb .L18
.L2:
andl$63, %esi
je  .L1
xorl%edx, %edx
testb   $1, %sil
je  .L5
movl$1, %edx
movb$0, (%rax)
cmpq%rsi, %rdx
jnb .L19
.L5:
movb$0, (%rax,%rdx)
movb$0, 1(%rax,%rdx)
addq$2, %rdx
cmpq%rsi, %rdx
jb  .L5
.L1:
ret
.p2align 4,,10
.p2align 3
.L18:
movq%rsi, %rdx
xorl%eax, %eax
andq$-64, %rdx
.L3:
movups  %xmm0, (%rdi,%rax)
movups  %xmm0, 16(%rdi,%rax)
movups  %xmm0, 32(%rdi,%rax)
movups  %xmm0, 48(%rdi,%rax)
addq$64, %rax
cmpq%rdx, %rax
jb  .L3
addq%rdi, %rax
jmp .L2
.L19:
ret
.cfi_endproc

with very poor prologue/epilogue.  With this patch, we now generate:

foo:
.LFB0:
.cfi_startproc
pxor%xmm0, %xmm0
cmpq$64, %rsi
jnb .L2
testb   $32, %sil
jne .L19
testb   $16, %sil
jne .L20
testb   $8, %sil
jne .L21
testb   $4, %sil
jne .L22
testq   %rsi, %rsi
jne .L23
.L1:
ret
.p2align 4,,10
.p2align 3
.L2:
movups  %xmm0, -64(%rdi,%rsi)
movups  %xmm0, -48(%rdi,%rsi)
movups  %xmm0, -32(%rdi,%rsi)
movups  %xmm0, -16(%rdi,%rsi)
subq$1, %rsi
cmpq$64, %rsi
jb  .L1
andq$-64, %rsi
xorl%eax, %eax
.L9:
movups  %xmm0, (%rdi,%rax)
movups  %xmm0, 16(%rdi,%rax)
movups  %xmm0, 32(%rdi,%rax)
movups  %xmm0, 48(%rdi,%rax)
addq$64, %rax
cmpq%rsi, %rax
jb  .L9
ret
.p2align 4,,10
.p2align 3
.L23:
movb$0, (%rdi)
testb   $2, %sil
je  .L1
xorl%eax, %eax
movw%ax, -2(%rdi,%rsi)
ret
.p2align 4,,10
.p2align 3
.L19:
movups  %xmm0, (%rdi)
movups  %xmm0, 16(%rdi)
movups  %xmm0, -32(%rdi,%rsi)
movups  %xmm0, -16(%rdi,%rsi)
ret
.p2align 4,,10
.p2align 3
.L20:
movups  %xmm0, (%rdi)
movups  %xmm0, -16(%rdi,%rsi)
ret
.p2align 4,,10
.p2align 3
.L21:
movq$0, (%rdi)
movq$0, -8(%rdi,%rsi)
ret
.p2align 4,,10
.p2align 3
.L22:
movl$0, (%rdi)
movl$0, -4(%rdi,%rsi)
ret
.cfi_endproc

gcc/

PR target/120670
PR target/120683
* config/i386/i386-expand.cc (expand_set_or_cpymem_via_loop):
Don't generate the loop if the loop count is 1.
(expand_cpymem_epilogue): Use move_by_pieces.
(setmem_epilogue_gen_val): New.
(expand_setmem_epilogue): Use store_by_pieces.
(exp

[Bug target/120725] [meta] Poor memcpy/memset inline strategies for -mtune=generic

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

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

Bug 120683 Summary: vector_loop/unrolled_loop generates poor codes on 
memset/memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120683

   What|Removed |Added

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

[Bug target/120683] vector_loop/unrolled_loop generates poor codes on memset/memcpy

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

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #6 from H.J. Lu  ---
Fixed.

[Bug c++/120471] [12/13/14 regression] -fsanitize=undefined causes read of uninitialized variable when accessing element in an array at -O0 level

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|12.5|13.5

--- Comment #22 from Jakub Jelinek  ---
Fix reverted for 12.5 because it causes PR120954 and it is too late before
release to deal with that.

[Bug target/120957] [16 Regression] 6-9% slowdown of 503.bwaves_r on Zen{2,3} since r16-1647-gc06979ff957485

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

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

--- Comment #2 from Hongtao Liu  ---
I've tested my commit(r16-1647) and the previous commit(r16-1646) with
-march=native -Ofast on zen3 server, and didn't find any regression for
503.bwaves_r.(we don't have zen2 machine.)

[Bug tree-optimization/120358] [15/16 regression] qtbase-6.9.0 miscompiled since r15-580-gf3e5f4c58591f5

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #28 from Alexander Monakov  ---
Created attachment 61811
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61811&action=edit
standalone testcase

A standalone variant of the comment #22 testcase, preprocessed and with enough
noipa stubs added to avoid linking with QtBase.

[Bug c++/120962] " XXX references internal linkage entity YYY" when compiling a module interface

[markus.parker at arcor dot de via Gcc-bugs]

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

--- Comment #3 from Markus  ---
I tried version 15.1. In this case the code compiles.

[Bug driver/120985] Possible memory leak in read_specs at gcc.cc

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||memory-hog

--- Comment #2 from Richard Biener  ---
It's also a short-lived and small binary, not worth the trouble of fixing (and
making the code more complicated because it's largely C and obstacks and manual
memory management).

[Bug libstdc++/120976] error: static_assert( !is_same_v<__float128, long double> failed

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Tomasz Kaminski :

https://gcc.gnu.org/g:2a82d4c859bd0eca4fe31fc79d234abd05e6a9d8

commit r16-2056-g2a82d4c859bd0eca4fe31fc79d234abd05e6a9d8
Author: Tomasz KamiÅski 
Date:   Fri May 16 07:12:36 2025 +0200

libstdc++: Format __float128 as _Float128 only when long double is not 128
IEEE [PR120976]

For powerpc64 and sparc architectures that both have __float128 and 128bit
long double,
the __float128 is same type as long double/__ieee128 and already
formattable.

The remaining specialization makes __float128 formattable on x86_64 via
_Float128,
however __float128 is now not formattable on x86_32 (-m32) with
-mlong-double-128,
where __float128 is distinct type from long double that is 128bit IEEE.

PR libstdc++/120976

libstdc++-v3/ChangeLog:

* include/std/format (formatter<__float128, _Char_T): Define if
_GLIBCXX_FORMAT_F128 == 2.

Reviewed-by: Jonathan Wakely 
Signed-off-by: Tomasz KamiÅski 

[Bug libstdc++/120976] error: static_assert( !is_same_v<__float128, long double> failed

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

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

--- Comment #7 from Tomasz Kamiński  ---
The issue should be addressed now.

[Bug target/120986] ICE when expanding svcreate2 intrinsic with compile time know FPMR

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

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

--- Comment #1 from Alfie Richards  ---
Improved reproducer (https://godbolt.org/z/axcc4vzxn)

[Bug lto/120987] New: gdb build with lto triggers use after free

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

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

Bug ID: 120987
   Summary: gdb build with lto triggers use after free
   Product: gcc
   Version: 14.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

[ First reported at gdb bugzilla:
https://sourceware.org/bugzilla/show_bug.cgi?id=32571 ]

Take gdb sources, either current trunk (f.i. commit 87c1293c7d4), or tag
gdb-16.3-release.

Build the sources using:
...
#!/bin/sh

pwd=$(pwd -P)
src=$pwd/src

build=$pwd/build
install=$pwd/install

rm -Rf $build $install
mkdir -p $build $install

cd $build

CFLAGS="-O2"
CXXFLAGS="$CFLAGS"
LDFLAGS=""
LTOFLAGS="-flto=auto"

$src/configure \
CC=gcc-14 \
CXX=g++-14 \
CFLAGS="$CFLAGS $LTOFLAGS -g" \
CXXFLAGS="$CXXFLAGS $LTOFLAGS -g" \
LDFLAGS="$LDFLAGS $LTOFLAGS -g" \
--without-expat \
--disable-nls \
--disable-source-highlight \
--disable-tui \
--with-system-readline \
--with-python=no \
--with-guile=no \
--prefix=$install \
--disable-sim \
--disable-threading \
--without-debuginfod \
--without-xxhash \
--without-lzma \
2>&1 \
| tee CONFIGURELOG

make \
-j 9 \
V=1 \
all-gdb \
2>&1 \
| tee MAKELOG
...

Gdb misbehaves:
...
$ gdb -q -batch -ex "b bla.c:100"   
�
Make breakpoint pending on future shared library load? (y or [n]) [answered N;
input not from terminal]
$ gdb -q -batch -ex "b bla.c:100"
;�
Make breakpoint pending on future shared library load? (y or [n]) [answered N;
input not from terminal]
$ gdb -q -batch -ex "b bla.c:100"
�
Make breakpoint pending on future shared library load? (y or [n]) [answered N;
input not from terminal]
...

Expected:
...
$ gdb -q -batch -ex "b bla.c:100"
No symbol table is loaded.  Use the "file" command.
Make breakpoint pending on future shared library load? (y or [n]) [answered N;
input not from terminal]
...

Used gcc:
...
gcc version 14.3.0 (SUSE Linux) 
...
on openSUSE Tumbleweed 20250627.

[Bug c++/120917] warning: use of 'auto' in template argument only available with '-fconcepts-ts'

[f.heckenbach--- via Gcc-bugs]

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

--- Comment #22 from Frank Heckenbach  ---
(In reply to Frank Heckenbach from comment #21)
> (In reply to Jason Merrill from comment #20)
> > (In reply to Frank Heckenbach from comment #18)
> > > So, could this be a viable workaround?
> > 
> > If you're going to modify your code to address this, it seems more
> > straightforward to add the explicit template-head.
> 
> I don't think so. My workaround, if it's viable, is localized and can be
> done with text substitution (sed), the explicit template-head is not
> localized (often affecting multiple lines) and cannot easily be automated
> AFAICS.
> 
> So my question stands.

PS: I also think the explicit template-head makes the code harder to read
because one has to mentally match the template parameter declarations and
usage. I think that's a general disadvantage of C++ template syntax. 
would have alleviated it to some extent, but alas.

[Bug c++/120917] warning: use of 'auto' in template argument only available with '-fconcepts-ts'

[f.heckenbach--- via Gcc-bugs]

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

--- Comment #21 from Frank Heckenbach  ---
(In reply to Jason Merrill from comment #20)
> (In reply to Frank Heckenbach from comment #18)
> > So, could this be a viable workaround?
> 
> If you're going to modify your code to address this, it seems more
> straightforward to add the explicit template-head.

I don't think so. My workaround, if it's viable, is localized and can be done
with text substitution (sed), the explicit template-head is not localized
(often affecting multiple lines) and cannot easily be automated AFAICS.

So my question stands.

[Bug libstdc++/60662] simple use of call_once throws a system_error exception, but not if sleep_for is called beforehand

[pitrou at free dot fr via Gcc-bugs]

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

Antoine Pitrou  changed:

   What|Removed |Added

 CC||pitrou at free dot fr

--- Comment #7 from Antoine Pitrou  ---
I wanted to chime in to say that we've encountered this on the Apache Arrow CI:
https://github.com/apache/arrow/issues/47015#issuecomment-3045686189

It seems this comment is mistaken as GCC 13.3, at least, still uses
pthread_once for std::call_once:

> This should be fixed in GCC 11 which no longer uses pthread_once for 
> std::call_once.

[Bug target/120920] RISC-V: Possible optimization of bswap when zbb is enabled

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

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

--- Comment #1 from Jeffrey A. Law  ---
This looks fairly painful to capture in a backend pattern; I didn't see any
particular attempt by combine that looked like a promising target pattern.

I suspect you'll need to look at a simplify-rtx simplification of some kind.

[Bug driver/120985] Possible memory leak in read_specs at gcc.cc

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Richard Biener from comment #2)
> It's also a short-lived and small binary, not worth the trouble of fixing
> (and making the code more complicated because it's largely C and obstacks
> and manual memory management).

Note the driver code is reused by the GCC JIT library so it is not exactly
short lived any more.

[Bug target/120930] [16 Regression] RISC-V: Miscompile at -O[23] with zvl256b -mrvv-vector-bits=zvl since r16-1645-g309dbcea2ca

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

[Bug target/120922] [16 Regression] RISC-V: ICE during GIMPLE pass: vect in verify_range with -mrvv-max-lmul=m8

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

[Bug middle-end/120987] [14/15/16 regression] gdb build with lto triggers use after free since r14-5831-gaae723d360ca26

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

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

--- Comment #9 from Martin Jambor  ---
(In reply to Andrew Pinski from comment #6)
> I suspect this just exposes the latent issue. This pushes for more SRA on
> some arguments.

Specifically those where ipa-modref says it is safe - that can be
because of various things, like (strict) alias violation or fnspec.

Can you use tree_sra dbgcount to find the function where things go
wrong?  The next step, apart from looking at dump differences, would
be to look at all functions called from this one (with all the
inlining done too) and look for issues.

[Bug cobol/119331] cobol: unimplemented exceptions abort compilation - even if requested to NOT use them

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

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

--- Comment #3 from James K. Lowden  ---
This patch awaits work on the command-line interface for warnings and options.
As of now, ECs can be turns on and off via CDF, but can be enabled only via the
command-line.  That puts the compiler in compliance with ISO but out of
compliance with GCC convention.  

As a workaround, ECs can be turned on and off as COBOL CDF text in a prepended
file with the -include option.  

If the program (or command line) attempts to enable an unimplemented EC, the
compiler really has no choice but to issue an error.  The user can decide if
the program is correct with the EC disabled, and make the necessary adjustment.
 The compiler is not so privileged.  :-)

[Bug cobol/120730] parse.cc doesn't compile with bison 3.5.1

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

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

James K. Lowden  changed:

   What|Removed |Added

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

--- Comment #1 from James K. Lowden  ---
Corrected by 007392c0f93cf46b9e87aebdd04e123e3381fc07. Fri Jun 20 12:43:51 2025
-0400.

[Bug target/120642] ICE: in validate_change_or_fail, at config/riscv/riscv-v.cc:5705 with -O -mcpu=xt-c920 -mrvv-vector-bits=zvl

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Assignee|rdapp.gcc at gmail dot com |law at gcc dot gnu.org
 CC||majin at gcc dot gnu.org
   Last reconfirmed||2025-07-07

--- Comment #1 from Jeffrey A. Law  ---
So if I'm reading everything correctly, xtheadvector can't take a constant avl.
 We had this:

(set (reg:RVVM1DI 148)
(unspec:RVVM1DI [
(unspec:RVVMF64BI [
(const_vector:RVVMF64BI [
(const_int 1 [0x1]) repeated x2
])
(reg:DI 149)
(const_int 2 [0x2]) repeated x2
(const_int 1 [0x1])
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)
(unspec:RVVM1DI [
(reg:DI 0 zero)
] UNSPEC_VUNDEF)
(subreg:RVVM1DI (reg:RVVM1SI 144 [ _6 ]) 0)
(reg:DI 150)
] UNSPEC_VSLIDEDOWN))

And we wanted to replace (reg:DI 149) with (const_int 2) resulting in:

(set (reg:RVVM1DI 148)
(unspec:RVVM1DI [
(unspec:RVVMF64BI [
(const_vector:RVVMF64BI [
(const_int 1 [0x1]) repeated x2
])
(const_int 2 [0x2]) repeated x3
(const_int 1 [0x1])
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)
(unspec:RVVM1DI [
(reg:DI 0 zero)
] UNSPEC_VUNDEF)
(subreg:RVVM1DI (reg:RVVM1SI 144 [ _6 ]) 0)
(reg:DI 150)
] UNSPEC_VSLIDEDOWN))

Which doesn't match because the vector_length_operand predicate rejects nonzero
constants for XTHEADVECTOR.

I think the right fix here is to just guard the transformation in AVL
propagation like this:

```
diff --git a/gcc/config/riscv/riscv-avlprop.cc
b/gcc/config/riscv/riscv-avlprop.cc
index bb4aceb75064..3031c29ae63c 100644
--- a/gcc/config/riscv/riscv-avlprop.cc
+++ b/gcc/config/riscv/riscv-avlprop.cc
@@ -508,7 +508,7 @@ pass_avlprop::execute (function *fn)
   simplify_replace_vlmax_avl (rinsn, prop.second);
 }

-  if (rvv_vector_bits == RVV_VECTOR_BITS_ZVL)
+  if (rvv_vector_bits == RVV_VECTOR_BITS_ZVL && !TARGET_XTHEADVECTOR)
 {
   /* Simplify VLMAX AVL into immediate AVL.
 E.g. Simplify this following case:


```

But I've never really worked on theadvector.

Jin Ma -- any thoughts here?

[Bug c++/120917] warning: use of 'auto' in template argument only available with '-fconcepts-ts'

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

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

--- Comment #23 from Jason Merrill  ---
(In reply to Frank Heckenbach from comment #21)
> So my question stands.

Then yes, it does look like it should work; libstdc++ uses that 'requires
function call' pattern in

  template
concept __is_derived_from_optional = requires (const _Tp& __t) {
  [](const optional<_Up>&){ }(__t);
};

[Bug c++/119498] Incompatible FMV functions not diagnosed

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

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

Alfie Richards  changed:

   What|Removed |Added

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

--- Comment #2 from Alfie Richards  ---
Closing as fixed.

[Bug tree-optimization/120929] [16 Regression] file-5.45 triggers _FORTIFY_SOURCE false positives since r16-1905-g7165ca43caf470

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

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

--- Comment #23 from qinzhao at gcc dot gnu.org ---
(In reply to Siddhesh Poyarekar from comment #21)
> (In reply to Richard Biener from comment #20)
> > so for
> > 
> >  _1 = _2;
> > 
> > we merge from _2.  For
> > 
> >  _1 = *_2;
> > 
> > we _also_ merge from _2.  But those are semantically not the same!
> 
> Yes, it only "makes sense" in the context of .ACCESS_WITH_SIZE as Qing
> originally conjectured, because .ACCESS_WITH_SIZE for _1 is stored in the
> context of &_1.

that's right, this propagation is NOT correct in general. It's only correct for
the case when the pointers with counted_by attribute as you explained in the
above.  And this propagation is Needed for such cases to enable _bdos to use
the counted_by information attached to pointer. 
> 
> > IMO this change was bogus and should be reverted.
> 
> I'm testing a simple fix that constrains this to just .ACCESS_WITH_SIZE. 
> Hopefully that should avoid the need to revert.

thanks a lot.

[Bug tree-optimization/117385] Move phiopt away from doing a COND_EXPR with a comparison as first operand

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

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

--- Comment #7 from Andrew Pinski  ---
Note fold_build_cond_expr in tree-ifconv.cc also does this same thing. Though
in that case we won't need the comparison afterwards.

[Bug c++/120917] warning: use of 'auto' in template argument only available with '-fconcepts-ts'

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

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

--- Comment #25 from Jason Merrill  ---
(In reply to Frank Heckenbach from comment #24)
> auto f (S );

Right, this is one of the cases fixed for GCC 16 by my commit above.

[Bug tree-optimization/116332] -O2 makes c++ std::regex give zero-alloc warnings

[f.heckenbach--- via Gcc-bugs]

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

Frank Heckenbach  changed:

   What|Removed |Added

 CC||f.heckenb...@fh-soft.de

--- Comment #3 from Frank Heckenbach  ---
It's not only std::regex. This strange code gives a bogus warning, too, but
only under very peculiar circumstances (e.g. c must have ", 0", d must not, a
must be there, as well as the loop etc.).

(I hope that's the same problem, or should I file a separate bug report?)

% cat test.cpp
#include 

void f (int m = 0)
{
  std::vector  a (m), b;
  do
{
  b.push_back (0);
  std::vector  c (m, 0);
  std::vector  d (m);
}
  while (m);
}

int main ()
{
  f ();
}
% g++-14 -O2 -Walloc-zero test.cpp
In file included from
/usr/include/x86_64-linux-gnu/c++/14/bits/c++allocator.h:33,
 from /usr/include/c++/14/bits/allocator.h:46,
 from /usr/include/c++/14/vector:63,
 from test.cpp:1:
In member function ‘_Tp* std::__new_allocator<_Tp>::allocate(size_type, const
void*) [with _Tp = int]’,
inlined from ‘static _Tp* std::allocator_traits
>::allocate(allocator_type&, size_type) [with _Tp = int]’ at
/usr/include/c++/14/bits/alloc_traits.h:515:28,
inlined from ‘std::_Vector_base<_Tp, _Alloc>::pointer
std::_Vector_base<_Tp, _Alloc>::_M_allocate(std::size_t) [with _Tp = int;
_Alloc = std::allocator]’ at /usr/include/c++/14/bits/stl_vector.h:380:33,
inlined from ‘void std::_Vector_base<_Tp,
_Alloc>::_M_create_storage(std::size_t) [with _Tp = int; _Alloc =
std::allocator]’ at /usr/include/c++/14/bits/stl_vector.h:398:44,
inlined from ‘std::_Vector_base<_Tp, _Alloc>::_Vector_base(std::size_t,
const allocator_type&) [with _Tp = int; _Alloc = std::allocator]’ at
/usr/include/c++/14/bits/stl_vector.h:334:26,
inlined from ‘std::vector<_Tp, _Alloc>::vector(size_type, const
allocator_type&) [with _Tp = int; _Alloc = std::allocator]’ at
/usr/include/c++/14/bits/stl_vector.h:557:47,
inlined from ‘void f(int)’ at test.cpp:10:29:
/usr/include/c++/14/bits/new_allocator.h:151:55: warning: argument 1 value is
zero [-Walloc-zero]
  151 | return static_cast<_Tp*>(_GLIBCXX_OPERATOR_NEW(__n *
sizeof(_Tp)));
  |   ^
In file included from /usr/include/c++/14/bits/new_allocator.h:34:
/usr/include/c++/14/new: In function ‘void f(int)’:
/usr/include/c++/14/new:131:26: note: in a call to allocation function ‘void*
operator new(std::size_t)’ declared here
  131 | _GLIBCXX_NODISCARD void* operator new(std::size_t) _GLIBCXX_THROW
(std::bad_alloc)
  |  ^~~~

[Bug c++/120989] Shouldn't warn about the use of deprecated non-static data members in implicit special member functions

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||106847

--- Comment #1 from Andrew Pinski  ---
I suspect this is a dup of bug 106847.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106847
[Bug 106847] deprecated class data member makes the class generate diagnostics
even when the member is not used

[Bug tree-optimization/120929] [16 Regression] file-5.45 triggers _FORTIFY_SOURCE false positives since r16-1905-g7165ca43caf470

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

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

--- Comment #24 from qinzhao at gcc dot gnu.org ---
I have reverted the patches that triggered the issue.
will fix this issue in the next commit with the new patch set.

[Bug tree-optimization/120929] [16 Regression] file-5.45 triggers _FORTIFY_SOURCE false positives since r16-1905-g7165ca43caf470

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #25 from Sam James  ---
Thanks Qing! I'll close it as the issue is gone now. We should include the
testcase in the next patch series.

[Bug cobol/120621] COBOL isn't built with STRICT_WARN

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #11 from James K. Lowden  ---
> Please advise if this PR can be closed, or if not what flags to use as a
> standard.

There are more errors on 32-bit Darwin.  I've posted a (yet unreviewed)
patch for them:

cobol: Fix build on 32-bit Darwin [PR120621]
https://gcc.gnu.org/pipermail/gcc-patches/2025-June/687385.html

[Bug tree-optimization/119920] Missed vectorization for conditioned adds

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #6)
> Created attachment 61814 [details]
> First prototype
> 
> Has some rough edges (extra dumps for quick debugging; it also does not
> handle commutative operations yet so it might not detect everything). But it
> looks like it works for this case.

s/new_op.ops[0] = new_res;/new_op.ops[opnum] = new_res;/

That is needed to fix the patch; otherwise you get wrong code :). Noticed while
testing the patch.

[Bug c/120978] Punctuators that contain # or %: are incorrectly rejected within attributes

[corentinjabot at gmail dot com via Gcc-bugs]

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

corentinjabot at gmail dot com changed:

   What|Removed |Added

 CC||corentinjabot at gmail dot com

--- Comment #10 from corentinjabot at gmail dot com ---
There is divergence between C and C++, I sent a mail to core
https://lists.isocpp.org/liaison/2025/07/1549.php

[Bug go/120670] vector_loop caused FAIL: go.test/test/fixedbugs/issue13160.go execution, -O2 -g

[ian at airs dot com via Gcc-bugs]

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

--- Comment #6 from Ian Lance Taylor  ---
FYI I'm going to shortly commit a patch to change to always use C code when
clearing memory. It seems like the only reliable way to avoid the possible use
of "rep stosb", which is valid for C but not always valid for Go's concurrent
garbage collector.

[Bug lto/120987] [14/15/16 regression] gdb build with lto triggers use after free since r14-5831-gaae723d360ca26

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-reduction

--- Comment #6 from Andrew Pinski  ---
(In reply to Tom de Vries from comment #3)
> The investigation in the gdb PR has identified a range of bad commits.
> 
> First bad commit:
> - commit aae723d360c
>   ("sra: SRA of non-escaped aggregates passed by reference to calls")

I suspect this just exposes the latent issue. This pushes for more SRA on some
arguments.

> 
> First good commit after first bad commit:
> - commit cee7d080d5c
>   ("Ignore conditions guarding __builtin_unreachable in inliner metrics")

And this one just make the latent issue go away. This one just changes inlining
heurstics and would not have fixed the latent issue.

[Bug middle-end/120987] [14/15/16 regression] gdb build with lto triggers use after free since r14-5831-gaae723d360ca26

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-linux-gnu

--- Comment #7 from Andrew Pinski  ---
Question does it just happen on x86_64-linux-gnu or can it be reproduce on
aarch64-linux-gnu or powerpc64-linux-gnu too?

[Bug fortran/120958] tree-sra "miscompiles" asynchronous MPI (mpi_irecv) in Fortran 77 because of wrong fnspec

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

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
(In reply to Martin Jambor from comment #7)
> (In reply to kargls from comment #5)
> > 
> > So, if I understand, you want an fnspec of ". . w w w w w w w".
> > Can you show f->sym and f->sym-attr from gdb?
> > 
> 
> (gdb) p *f->sym
> $5 = {name = 0x7fffbe64a100 "_formal_70", module = 0x0, declared_at = {nextc
> = 0x4c006a4, u = {lb = 0x4c00620, location = 79693344}}, ts = {type =
> BT_REAL, kind = 8, u = {derived = 0x0,

The interface is guessed by gfc_get_formal_from_actual_arglist, which
creates the artifical symbol "_formal_%d".  Can we use that information?

[Bug tree-optimization/119930] [15/16 regression] g++.dg/coroutines/torture/pr103953.C FAILs with -O3

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

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

Jason Merrill  changed:

   What|Removed |Added

  Component|c++ |tree-optimization

--- Comment #13 from Jason Merrill  ---
(In reply to Sam James from comment #10)
> It goes back to r15-5595-g27778979c9a1e3 (i.e.
> -fno-assume-sane-operators-new-delete works).

Ah, you mean -fno-assume-sane-operators-new-delete makes the testcase succeed,
as indeed it does; I initially read that as a description of the commit.

Looking at the difference in tree dumps, modref1 is notably different with that
flag.

It looks like initializing the coroutineA capture in coroutineB is discarded
with -fassume-sane:

+ - Analyzing store: D.9530.__coroutine_A
+   - Read-only or local, ignoring.

and so when we call coroutineB op() and it tries to resume coroutineA, the
pointer to it is missing.

Changing component to tree-optimization.

[Bug c++/119498] Incompatible FMV functions not diagnosed

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Alfie Richards
:

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

commit r16-2066-g5abac04ffc7cc877ff5e1fa6562923b7b05b8289
Author: Alfie Richards 
Date:   Thu Feb 13 15:59:43 2025 +

c++: Fix FMV return type ambiguation

Add logic for the case of two FMV annotated functions with identical
signature other than the return type.

Previously this was ignored, this changes the behavior to emit a
diagnostic.

gcc/cp/ChangeLog:
PR c++/119498
* decl.cc (duplicate_decls): Change logic to not always exclude FMV
annotated functions in cases of return type non-ambiguation.

gcc/testsuite/ChangeLog:
PR c++/119498
* g++.target/aarch64/pr119498.C: New test.