[Bug ada/119698] gen_il-main: raised PROGRAM_ERROR : finalize/adjust raised exception

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

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

--- Comment #2 from Richard Biener  ---
Building stage1 with gnat-12 - this means the bug is in GCC 12?  Or is this a 
"source error" in the GCC 15 sources?

[Bug target/115259] [15 Regressions] GCN vs. "tree-optimization/115144 - improve sinking destination choice"

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

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

--- Comment #12 from Thomas Schwinge  ---
Andrew P., thanks for having a look!

I tested attachment 61055; terminates normally.  :-|

[Bug tree-optimization/119706] [15 regression] ICE in gimple pass 'dom' for -O3 -mcpu=grace --param=aarch64-autovec-preference=sve-only

[mcccs at gmx dot com via Gcc-bugs]

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

--- Comment #4 from mcccs at gmx dot com ---
Created attachment 61059
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61059&action=edit
This is a reduced testcase, but modified in a way that it gives an error in VRP
stage instead of DOM

While minimizing the testcase, this source code fails in the VRP stage instead
of DOM, which might make it a good testcase. To make it fail again in the DOM
stage, add "noexcept" back to "cr cb()"

[Bug c++/119705] Massive memory use when building Flang (10GB+)

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

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

--- Comment #6 from Richard Biener  ---
Created attachment 61060
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61060&action=edit
-fmem-report with detailed-mem-stats and -fsyntax-only

-fmem-report with details shows

tree_list  7699k
tree_vec 12M

Hash maps   LeakPeak   
 Times Type

cp/cp-gimplify.cc:2989 (cp_fold)   132M: 97.6%  132M   
   35k:  1.7%   ggc

Heap vectors  sizeof(T)   Leak 
  Peak Times   Leak items Peak items 
symtab.cc:635 (create_reference)  8  1713k:16.4%   
 1713k 54847:20.3%   214k   214k
symtab.cc:627 (create_reference) 40  8574k:81.9%   
 8574k 54874:20.3%   214k   214k

GGC memory  Leak  Garbage  
 FreedOverheadTimes
cp/semantics.cc:511 (perform_or_defer_access_che 0 :  0.0%   40M: 
2.2%  890k:  0.1%   54k:  0.0%  299k
cp/pt.cc:13916 (tsubst_pack_expansion)   0 :  0.0%   65M: 
3.6%0 :  0.0%0 :  0.0% 1671k
cp/pt.cc:14190 (tsubst_argument_pack) 7141k:  0.2%  118M: 
6.5%0 :  0.0%0 :  0.0%  766k
cp/pt.cc:9090 (coerce_template_parameter_pack)  26M:  0.8%   82M: 
4.5%0 :  0.0%0 :  0.0%  663k
cp/pt.cc:9280 (coerce_template_parms)   16M:  0.5%   97M: 
5.4%  200k:  0.0%0 :  0.0% 3204k
...
cp/pt.cc:15441 (tsubst_decl)   136M:  4.0%   34M: 
1.9%0 :  0.0%0 :  0.0% 1281k
tree-inline.cc:5704 (copy_tree_r)  169M:  5.0%   82M: 
4.5%0 :  0.0%   54k:  0.0% 6853k
cp/pt.cc:14832 (tsubst_function_decl)  175M:  5.1%  576 : 
0.0%  288 :  0.0%   19M: 12.4%  623k
cp/class.cc:5162 (copy_fndecl_with_name)   195M:  5.7%  925k: 
0.0%0 :  0.0%   21M: 13.9%  698k
stringpool.cc:43 (stringpool_ggc_alloc)240M:  7.0%0 : 
0.0%0 :  0.0%   53M: 34.3%  197k

template processing tends to create a lot of TREE_VEC garbage.  But it's
done all over the place it seems.

[Bug c++/119705] Massive memory use when building Flang (10GB+)

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

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

--- Comment #7 from Richard Biener  ---
Created attachment 61061
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61061&action=edit
-fmem-report with detailed-mem-stats and -g

Using -g instead of -fsyntax-only (which will bring us to 10GB max RSS) adds
to this

dwarf2out.cc:5825 (new_die_raw)277M:  4.3% 1124k: 
0.0%0 :  0.0%0 :  0.0% 3564k
dwarf2out.cc:4486 (add_dwarf_attr)1004M: 15.6% 2361k: 
0.0%  279M:  5.8%   37M:  3.3% 4881k

but also the hashes

dwarf2out.cc:29790 (dwarf2out_init) 15M: 14.6%   23M   
   18 :  0.0%   ggc
dwarf2out.cc:4736 (find_AT_string)  23M: 21.9%   27M   
   31 :  0.0%   ggc


I'll note that the die->die_attr is inefficient since dw_attr_node is

typedef struct GTY(()) dw_attr_struct {
  enum dwarf_attribute dw_attr;
  dw_val_node dw_attr_val;
}
dw_attr_node;

and

struct GTY(()) dw_val_node {
  enum dw_val_class val_class; 
  struct addr_table_entry * GTY(()) val_entry;
  union dw_val_struct_union
{
...
  GTY ((desc ("%1.val_class"))) v;
};

there's two 4 byte holes after the enums, the whole thing is 40 bytes instead
of 32.  Adding to the GC allocated attr vector with vec_safe_reserve (, 1)
allocates space for 4 elements up-front, statistics on the number of
attributes on DIEs (when there is one) would be nice to have.  A DIE itself
is "only" 80 bytes.

[Bug c++/119710] New: failure demangling std::variant stuff

[jengelh at inai dot de via Gcc-bugs]

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

Bug ID: 119710
   Summary: failure demangling std::variant stuff
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jengelh at inai dot de
  Target Milestone: ---

gcc version 15.0.1 20250408 (experimental) (SUSE Linux) amd64
binutils 2.43

== Input ==

#include 
int main() {
if (std::variant() == std::variant()) ;
}

== Observed output ==

I have verified that binutils nm and a trivial 5-minutes program invoking
__cxa_demangle both produce a list of 20 symbols (ruling out that binutils is
potentially too old on my system):

$ g++ -std=c++20 -c x.cpp && nm -C x.o | grep _Z | cut -b20-
_ZNSt7variantIJiEEC1EvQ26is_default_constructible_vINSt9_Nth_typeILm0EJDpT_EE4typeEE
_ZNSt7variantIJiEEC2EvQ26is_default_constructible_vINSt9_Nth_typeILm0EJDpT_EE4typeEE
_ZNSt7variantIJiEEC5EvQ26is_default_constructible_vINSt9_Nth_typeILm0EJDpT_EE4typeEE
_ZNSt8__detail9__variant15__raw_idx_visitIZNS0_9__compareIbSt7variantIJiEEZSteqIJiEQfraarQRKT__Xeqfp_fp_RSt14convertible_toIbEEEbRKS3_IJDpS6_EESC_EUlOT_OT0_E_EESD_SD_RKSF_SJ_T1_EUlSE_SF_E_JRKS4_EEEvSE_DpOT0_
_ZNSt8__detail9__variant17__gen_vtable_implINS0_12_Multi_arrayIPFNS0_20__variant_idx_cookieEOZNS0_9__compareIbSt7variantIJiEEZSteqIJiEQfraarQRKT__XeqfL0p_fL0p_RSt14convertible_toIbEEEbRKS5_IJDpS8_EESE_EUlOT_OT0_E_EESF_SF_RKSH_SL_T1_EUlSG_SH_E_RKS6_EJEEESt16integer_sequenceImJLm014__visit_invokeESO_SQ_
_ZNSt8__detail9__variant17__gen_vtable_implINS0_12_Multi_arrayIPFNS0_20__variant_idx_cookieEOZNS0_9__compareIbSt7variantIJiEEZSteqIJiEQfraarQRKT__XeqfL0p_fL0p_RSt14convertible_toIbEEEbRKS5_IJDpS8_EESE_EUlOT_OT0_E_EESF_SF_RKSH_SL_T1_EUlSG_SH_E_RKS6_EJEEESt16integer_sequenceImJLm028__element_by_index_or_cookieILm0ESQ_EEDcSI_
_ZNSt8__detail9__variant17__gen_vtable_implINS0_12_Multi_arrayIPFNS0_20__variant_idx_cookieEOZNS0_9__compareIbSt7variantIJiEEZSteqIJiEQfraarQRKT__XeqfL0p_fL0p_RSt14convertible_toIbEEEbRKS5_IJDpS8_EESE_EUlOT_OT0_E_EESF_SF_RKSH_SL_T1_EUlSG_SH_E_RKS6_EJEEESt16integer_sequenceImJLm1844674407370955161514__visit_invokeESO_SQ_
_ZNSt8__detail9__variant17__gen_vtable_implINS0_12_Multi_arrayIPFNS0_20__variant_idx_cookieEOZNS0_9__compareIbSt7variantIJiEEZSteqIJiEQfraarQRKT__XeqfL0p_fL0p_RSt14convertible_toIbEEEbRKS5_IJDpS8_EESE_EUlOT_OT0_E_EESF_SF_RKSH_SL_T1_EUlSG_SH_E_RKS6_EJEEESt16integer_sequenceImJLm1844674407370955161528__element_by_index_or_cookieILm18446744073709551615ESQ_EEDcSI_
_ZNSt8__detail9__variant9__compareIbSt7variantIJiEEZSteqIJiEQfraarQRKT__Xeqfp_fp_RSt14convertible_toIbEEEbRKS2_IJDpS5_EESB_EUlOT_OT0_E_EESC_SC_RKSE_SI_T1_
_ZSt10__do_visitINSt8__detail9__variant20__variant_idx_cookieEZNS1_9__compareIbSt7variantIJiEEZSteqIJiEQfraarQRKT__Xeqfp_fp_RSt14convertible_toIbEEEbRKS4_IJDpS7_EESD_EUlOT_OT0_E_EESE_SE_RKSG_SK_T1_EUlSF_SG_E_JRKS5_EEDcSH_DpOT1_
_ZSt13__invoke_implIvZNSt8__detail9__variant9__compareIbSt7variantIJiEEZSteqIJiEQfraarQRKT__Xeqfp_fp_RSt14convertible_toIbEEEbRKS3_IJDpS6_EESC_EUlOT_OT0_E_EESD_SD_RKSF_SJ_T1_EUlSE_SF_E_JNS1_16__variant_cookieESt17integral_constantImLm18446744073709551615SD_St14__invoke_otherSG_DpOT1_
_ZSt13__invoke_implIvZNSt8__detail9__variant9__compareIbSt7variantIJiEEZSteqIJiEQfraarQRKT__Xeqfp_fp_RSt14convertible_toIbEEEbRKS3_IJDpS6_EESC_EUlOT_OT0_E_EESD_SD_RKSF_SJ_T1_EUlSE_SF_E_JRKiSt17integral_constantImLm0SD_St14__invoke_otherSG_DpOT1_
_ZSt8__invokeIZNSt8__detail9__variant9__compareIbSt7variantIJiEEZSteqIJiEQfraarQRKT__Xeqfp_fp_RSt14convertible_toIbEEEbRKS3_IJDpS6_EESC_EUlOT_OT0_E_EESD_SD_RKSF_SJ_T1_EUlSE_SF_E_JNS1_16__variant_cookieESt17integral_constantImLm18446744073709551615NSt15__invoke_resultISD_JDpT0_EE4typeESE_DpOSQ_
_ZSt8__invokeIZNSt8__detail9__variant9__compareIbSt7variantIJiEEZSteqIJiEQfraarQRKT__Xeqfp_fp_RSt14convertible_toIbEEEbRKS3_IJDpS6_EESC_EUlOT_OT0_E_EESD_SD_RKSF_SJ_T1_EUlSE_SF_E_JRKiSt17integral_constantImLm0NSt15__invoke_resultISD_JDpT0_EE4typeESE_DpOSR_
_ZSteqIJiEQfraarQRKT__Xeqfp_fp_RSt14convertible_toIbEEEbRKSt7variantIJDpS0_EES7_
_ZZNSt8__detail9__variant9__compareIbSt7variantIJiEEZSteqIJiEQfraarQRKT__Xeqfp_fp_RSt14convertible_toIbEEEbRKS2_IJDpS5_EESB_EUlOT_OT0_E_EESC_SC_RKSE_SI_T1_ENUlSD_SE_E_clINS0_16__variant_cookieESt17integral_constantImLm18446744073709551615DaSD_SE_
_ZZNSt8__detail9__variant9__compareIbSt7variantIJiEEZSteqIJiEQfraarQRKT__Xeqfp_fp_RSt14convertible_toIbEEEbRKS2_IJDpS5_EESB_EUlOT_OT0_E_EESC_SC_RKSE_SI_T1_ENUlSD_SE_E_clIRKiSt17integral_constantImLm0DaSD_SE_
_ZZSt10__do_visitINSt8__detail9__variant20__variant_idx_cookieEZNS1_9__compareIbSt7variantIJiEEZSteqIJiEQfraarQRKT__Xeqfp_fp_RSt14convertible_toIbEEEbRKS4_IJDpS7_EESD_EUlOT_OT0_E_EESE_SE_RKSG_SK_T1_EUlSF_SG_E_JRKS5_EEDcSH_DpOT1_ENKUlSO_zE_clESO_z
_ZZSteqIJiEQfraarQRKT__Xeqfp_fp_RSt14convertible_toIbEEEbRKSt7variantIJDpS0_EES7_ENKUlOT

[Bug tree-optimization/119707] wrong code with _BitInt() mask and shift at -O1

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 61062
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61062&action=edit
gcc15-pr119707.patch

So far lightly tested patch.  Not bootstrapped yet, just tested with
make check-gcc -j32 -k GCC_TEST_RUN_EXPENSIVE=1
RUNTESTFLAGS="--target_board=unix\{-m64,-m32\} GCC_TEST_RUN_EXPENSIVE=1
dg.exp='*bitint* pr112673.c builtin-stdc-bit-*.c pr112566-2.c pr112511.c
pr116588.c pr116003.c pr113693.c pr113602.c flex-array-counted-by-7.c'
dg-torture.exp='*bitint* pr116480-2.c pr114312.c pr114121.c' dfp.exp=*bitint*
i386.exp='pr118017.c pr117946.c apx-ndd-x32-2a.c'
vect.exp='vect-early-break_99-pr113287.c' tree-ssa.exp=pr113735.c"

[Bug libstdc++/115285] [12/13 Regression] std::unordered_set can have duplicate value

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

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

--- Comment #21 from Jonathan Wakely  ---
Fixed for 15 and 14.3 so far.

[Bug debug/119711] New: dw_attr_struct and dw_loc_descr_node are wasteful with padding

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

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

Bug ID: 119711
   Summary: dw_attr_struct and dw_loc_descr_node are wasteful with
padding
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

typedef struct GTY(()) dw_attr_struct {
  enum dwarf_attribute dw_attr;
  dw_val_node dw_attr_val;
}
dw_attr_node;

struct GTY(()) dw_val_node {
  enum dw_val_class val_class; 
  struct addr_table_entry * GTY(()) val_entry;
  union dw_val_struct_union
{
...
  GTY ((desc ("%1.val_class"))) v;
};

there's two 4 byte holes after the enums, the whole thing is 40 bytes instead
of 32.  It's also dw_val_node::val_entry is only ever != NULL with
-gsplit-dwarf.

dw_loc_descr_node has pointer, then 8+1+1 bitfields, then 
int dw_loc_addr and then 2 dw_val_node elts.

At least naming the padding in dw_val_node for outside use can improve things.

[Bug tree-optimization/119351] [15 Regression] Wrong code in GROMACS for AArch64 generic SVE VLS target since r15-6807-g68326d5d1a593d

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

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

--- Comment #16 from Tamar Christina  ---
Ok, found the bug and c-vise is running for a testcase.

The issue is as follows:

For early break we need to know which value to start the scalar loop with if we
take an early exit.

Historically this means that we take the first element of every induction.
this is because there's an assumption in place, that even with masked loops the
masks come from a whilel* instruction.

As such we reduce using a BIT_FIELD_REF <, 0>.

When PFA was added this assumption was correct for non-masked loop, however we
assumed that PFA for VLA wouldn't work for now, and disabled it using the
alignment requirement checks.  We also expected VLS to PFA using scalar loops.

However as this PR shows, for VLS the vectorizer can, and does in some
circumstances choose to peel using masks by masking the first iteration of the
loop.

When this is done, the first elements of the predicate can be inactive. In this
example element 1 is inactive based on the dynamically calculated misalignment.
 hence the -1 value in the first vector element.

When we reduce using BIT_FIELD_REF we get the wrong value.

vectorizable_live_operation_1 needs to in the case of
LOOP_VINFO_MASK_SKIP_NITERS reduce using the mask, rather than a BIT_FIELD_REF
otherwise PFA for VLS is broken.

Working on patch.

[Bug fortran/104826] [12/13/14 Regression] ICE in gimple_range_global, at value-query.cc:424 – with deferred-length character variable

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

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

Andre Vehreschild  changed:

   What|Removed |Added

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

--- Comment #12 from Andre Vehreschild  ---
Fixed! Testcase added. Nothing to do any more. Closing.

[Bug c++/119175] [14/15 Regression] ICE segfault on lambda in requires clause of generic lambda in requires clause

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

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

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

https://gcc.gnu.org/g:39892d9618ee0f06dd09271589878b0df7b1e75d

commit r15-9362-g39892d9618ee0f06dd09271589878b0df7b1e75d
Author: Jason Merrill 
Date:   Wed Apr 9 13:22:56 2025 -0400

c++: lambda in constraint of lambda [PR119175]

Here when we went to mangle the constraints of from<0>, the outer lambda
has
no mangling scope, but the inner one was treated as having the outer one as
its scope.  And mangling the outer one means mangling its constraints,
which
include the inner one.  So infinite recursion.

But a lambda closure type isn't a scope that anything should have for
mangling, the inner lambda should also have no mangling scope.

PR c++/119175

gcc/cp/ChangeLog:

* mangle.cc (decl_mangling_context): Look through lambda type.

gcc/testsuite/ChangeLog:

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

[Bug fortran/66681] [Coarray] Wrong result in assigning this_image() to a complex coarray

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

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

Andre Vehreschild  changed:

   What|Removed |Added

 CC||vehre at gcc dot gnu.org
 Status|NEW |WAITING

--- Comment #13 from Andre Vehreschild  ---
Seems to be fixed at least with the patches for teams support:
https://gcc.gnu.org/pipermail/fortran/2025-April/062016.html

Will close with them once those patches get merged or objections are voiced.

[Bug fortran/103001] missing simplify of (CAF) get_team

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

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

Andre Vehreschild  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #1 from Andre Vehreschild  ---
Patch proposed at: https://gcc.gnu.org/pipermail/fortran/2025-April/062019.html
Awaiting review.

[Bug tree-optimization/119707] wrong code with _BitInt() mask and shift at -O1

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

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

--- Comment #3 from Jakub Jelinek  ---
__attribute__((noipa)) unsigned _BitInt(256)
foo (_BitInt(129) x)
{
  return (unsigned _BitInt(255)) x;
}

int
main ()
{
  if (foo (-1) !=
0x7fffuwb)
__builtin_abort ();
}
works though, there it copies the two lowest limbs, for the third one sign
extends the single bit and for the last one masks the previous value to 63
unsigned bits.

I think the bug is in
   [local count: 1073741824]:
  # _8 = PHI <0(2), _9(12)>
  # _10 = PHI <0(2), _11(12)>
  # _22 = PHI <0(2), _23(12)>
...
  # _20 = PHI <0(5), _10(3), _18(6)>
  _11 = _20;
...
   [local count: 214748360]:
  _30 = () _10;
  _31 = (unsigned long) _30;
where _10 is the PHI tracking the bits from sign extension, _18 is what is set
in the
idx == 2 handling in the first half of the loop and bb 11 is the handling of
idx == 3
for the outer cast (u255 -> u256), where in this case it should be using _11
rather than _10.
I think this was caused by PR112941 r14-6742 change, but now to figure out when
to use m_data[save_data_cnt] and when to use m_data[save_date_cnt + 1]...

[Bug tree-optimization/119393] [15 Regression] Worse vectorization of imagick_r hot loop on aarch64 since r15-5024-g2a2e6784074e1f

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

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

--- Comment #6 from Alex Coplan  ---
Alright, so after some digging through the dumps I realised that adding
-fno-early-inlining is enough to get a non-LTO testcase.  So the following
testcase reproduces the different codegen before/after the above commit with
just -Ofast -fno-early-inlining (no LTO required):

long g_y, MorphologyApply_changed, g_v;
int g_kernel, MorphologyApply_work_image, g_t, g_img, MorphologyApply_verbose,
gapcn_t1, gapcn_cache_info_0;
typedef short Quantum;
double MorphologyPrimitive_bias, g_k, g_r2, g_r1;
Quantum g_r0;
int *gapcn_cache_info;
void *gapcn_image_0;
int *GetAuthenticPixelCacheNexus();
int *GetCacheViewAuthenticPixels() { return GetAuthenticPixelCacheNexus(); }
void ThrowMagickException();
int *GetAuthenticPixelCacheNexus() {
  gapcn_cache_info = gapcn_image_0;
  if (gapcn_cache_info_0 || 0 >= (long)gapcn_image_0)
ThrowMagickException();
  return &gapcn_t1;
}
typedef struct {
  Quantum blue, green, red, opacity;
} PixelPacket;
PixelPacket *MorphologyPrimitive_p;
long MorphologyPrimitive(int channel) {
  GetCacheViewAuthenticPixels();
  for (; g_y < g_img; g_y++) {
double result_0 = MorphologyPrimitive_bias;
if (channel == 0)
  for (g_v = 0; g_v < g_kernel; g_v++) {
result_0 += g_k * MorphologyPrimitive_p->red;
g_r1 += g_k * MorphologyPrimitive_p->green;
g_r2 += g_k * MorphologyPrimitive_p->blue;
MorphologyPrimitive_p++;
  }
g_r0 = result_0;
  }
  return 0;
}
int *MorphologyImage() {
  while (MorphologyApply_changed) {
if (MorphologyApply_work_image)
  goto error_cleanup;
MorphologyPrimitive(0);
if (MorphologyApply_verbose)
  ThrowMagickException();
  }
  goto exit_cleanup;
error_cleanup:
exit_cleanup:
  return &g_t;
}

[Bug translation/119684] [15 Regression] Severe bug in german translation

[bruno at clisp dot org via Gcc-bugs]

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

--- Comment #22 from Bruno Haible  ---
(In reply to Joseph S. Myers from comment #21)
> If we want such checking, it should be done in CI (similar to the CI that
> verifies generated files that are checked in have been correctly
> regenerated), not at .pot regeneration time or .po commit time.

OK.

Who are the people who manage this CI, and could
- add an "msgmt -c" check on the *.po files,
- make sure that shortly before a GCC release, the newest GNU gettext release
binaries are installed on the CI machine, so as to get the newest
GCC/GFC-format string checkers?

[Bug other/119712] New: compiler hang at -O{1,2,3,s} since 14.1

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

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

Bug ID: 119712
   Summary: compiler hang at -O{1,2,3,s} since 14.1
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chopra.kavya04 at gmail dot com
  Target Milestone: ---

The compiler seems to hang and not produce an executable for this for -O1 and
above. This has been there since v 14.1. 

Godbolt link: https://godbolt.org/z/dbqWh15do


kchopra@su-lee:/local/home/kchopra$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/local/home/kchopra/.gcclocal/libexec/gcc/x86_64-pc-linux-gnu/15.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/local/home/kchopra/.gcclocal/
--with-local-prefix=/local/home/kchopra/.gcclocal/
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.1 20250404 (experimental) (GCC) 
kchopra@su-lee:/local/home/kchopra$ timeout 5 gcc -o hang hang.c
kchopra@su-lee:/local/home/kchopra$ ./hang
kchopra@su-lee:/local/home/kchopra$ rm -f hang
kchopra@su-lee:/local/home/kchopra$ timeout 5 gcc -o hang -O3 hang.c 
kchopra@su-lee:/local/home/kchopra$ ./hang
-bash: ./hang: No such file or directory
kchopra@su-lee:/local/home/kchopra$ cat hang.c
int a, b, c, d, e, f;
int main() {
  f--;
  goto q;
j:
  if (-1642776935 * c + 7 >= 0)
goto l;
m:
  if (4 * a - c - 21 >= 0)
goto i;
  return 0;
i:
  if (d)
goto l;
q:
  c = 4 * c - 3;
  if (c - f)
 goto m;
  goto j;
l:
  e = b + 1958960196 * c - 1016458303;
  if (20 * e + 1 >= 0)
  return 0;
  goto j;
}

[Bug target/119629] mismatch between [power9-64] builtins and their instructions

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

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

--- Comment #14 from Alexandre Oliva  ---
ack, patch combining the patchlets in commits 7 and 9 looking good in gcc-14
ppc-elf test results.

I'll point out that this report was not so much about this specific mismatch
between ppc builtins and their corresponding expanders, but about the more
general problem that clearly affects many more ppc builtins.

I'm happy to take your version of the fix for cmpeqb over mine for this
specific problem, silencing the one visible test failure, but I'd like to
suggest keeping the PR open until the more general problem is addressed.

Perhaps the builtins should test the expander condition, if there is a direct
expander, and either disable themselves, or report a mismatch, or something. 
Ignoring the expander condition and leaving it for the compiler to detect it
and ICE is quite undesirable IMHO.

In a perfect world, we'd have a selftest that iterated over the various
available user-controllable configurations and checked that the conditions for
builtin expanders follow from the conditions for the builtins or somesuch.  I'm
not sure that's feasible.

[Bug translation/119684] [15 Regression] Severe bug in german translation

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

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

--- Comment #21 from Joseph S. Myers  ---
If we want such checking, it should be done in CI (similar to the CI that
verifies generated files that are checked in have been correctly regenerated),
not at .pot regeneration time or .po commit time.

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

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
Summary|[14/15 Regression] compiler |[14/15 Regression] compiler
   |hang at -O{1,2,3,s} since   |hang at -O{1,2,3,s} since
   |14.1|r14-5109

--- Comment #2 from Jakub Jelinek  ---
Started with r14-5109-ga291237b628f419d7f7ac264dd7b42947b565222

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

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/113524] FAIL: gcc.dg/torture/pr113026-1.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for bogus messages, line 10)

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

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

--- Comment #7 from Alexandre Oliva  ---
... and riscv*-elf, powerpc-elf.

[Bug tree-optimization/119393] [15 Regression] Worse vectorization of imagick_r hot loop on aarch64 since r15-5024-g2a2e6784074e1f

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

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

--- Comment #7 from Andrew Pinski  ---
I don't see any difference between 14 and 15 with your reduced testcase at
`-Ofast -fno-early-inlining -mcpu=neoverse-v1+nosve ` .

[Bug fortran/87326] [F18] Support the NEW_INDEX= specifier in the FORM TEAM statement

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

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

Andre Vehreschild  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #10 from Andre Vehreschild  ---
Patch proposed at: https://gcc.gnu.org/pipermail/fortran/2025-April/062017.html
and https://gcc.gnu.org/pipermail/fortran/2025-April/062021.html . Awaiting
review.

[Bug tree-optimization/119706] [12/13/14 regression] ICE in gimple pass 'dom' for -O3 -mcpu=grace --param=aarch64-autovec-preference=sve-only

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

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

--- Comment #7 from Jennifer Schmitz  ---
Great, thanks a lot for the quick fix!

[Bug target/116591] internal compiler error: in extract_insn when compiling for risc-v xtheadvector

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

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

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

https://gcc.gnu.org/g:07d4c264a000b6448d6b519110c05c3b8a64d23b

commit r14-11581-g07d4c264a000b6448d6b519110c05c3b8a64d23b
Author: Jin Ma 
Date:   Wed Nov 13 15:19:29 2024 -0700

[PATCH] RISC-V: Bugfix for unrecognizable insn for XTheadVector

error: unrecognizable insn:

(insn 35 34 36 2 (set (subreg:RVVM1SF (reg/v:RVVM1x4SF 142 [ _r ]) 0)
(unspec:RVVM1SF [
(const_vector:RVVM1SF repeat [
(const_double:SF 0.0 [0x0.0p+0])
])
(reg:DI 0 zero)
(const_int 1 [0x1])
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_TH_VWLDST)) -1
 (nil))
during RTL pass: mode_sw

PR target/116591

gcc/ChangeLog:

* config/riscv/vector.md: Add restriction to call
pred_th_whole_mov.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/xtheadvector/pr116591.c: New test.

(cherry picked from commit 8564d0948c72df0a66d7eb47e15c6ab43e9b25ce)

[Bug fortran/87556] FORM TEAM statement team-number argument interpreted incorrectly when function

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

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

Andre Vehreschild  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #4 from Andre Vehreschild  ---
Patch proposed at: https://gcc.gnu.org/pipermail/fortran/2025-April/062021.html
Awaiting review.

[Bug fortran/87939] [F18] Support STAT= and ERRMSG= specifiers to CRITICAL and TEAM statements

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

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

Andre Vehreschild  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #3 from Andre Vehreschild  ---
Patch proposed at: https://gcc.gnu.org/pipermail/fortran/2025-April/062018.html
Awaiting review.

[Bug fortran/88154] [F18] ICE: Intrinsic function '_gfortran_caf_get_team' (119) not recognized

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

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

Andre Vehreschild  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #4 from Andre Vehreschild  ---
Patch at: https://gcc.gnu.org/pipermail/fortran/2025-April/062019.html Awaiting
review.

[Bug fortran/88254] [F18] Support construct name for CHANGE TEAM & END TEAM

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

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

Andre Vehreschild  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #2 from Andre Vehreschild  ---
Patch at: https://gcc.gnu.org/pipermail/fortran/2025-April/062021.html Awaiting
review.

[Bug fortran/88960] [F18] ISO_FORTRAN_ENV: add INITIAL_TEAM, PARENT_TEAM, and CURRENT_TEAM

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

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

Andre Vehreschild  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #3 from Andre Vehreschild  ---
Patch at: https://gcc.gnu.org/pipermail/fortran/2025-April/062019.html Awaiting
review.

[Bug fortran/97210] Intrinsic function get_team() does not work

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

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

Andre Vehreschild  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #2 from Andre Vehreschild  ---
Patch proposed at: https://gcc.gnu.org/pipermail/fortran/2025-April/062019.html
Awaiting review.

[Bug fortran/103796] form-team-spec-list is unsupported

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

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

Andre Vehreschild  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #11 from Andre Vehreschild  ---
Patch at: https://gcc.gnu.org/pipermail/fortran/2025-April/062021.html Awaiting
review.

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|compiler hang at|[14/15 Regression] compiler
   |-O{1,2,3,s} since 14.1  |hang at -O{1,2,3,s} since
   ||14.1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-04-10
   Target Milestone|--- |14.3
  Component|middle-end  |tree-optimization
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
(gdb) bt
#0  0x00ecfba8 in wi::bit_and,
generic_wide_int > (x=..., y=...) at
../../gcc/wide-int.h:2757
#1  0x00ecf8ba in operator&,
generic_wide_int > (x=..., y=...) at
../../gcc/wide-int.h:3854
#2  0x01a92298 in irange_bitmask::intersect (this=0x7fff9e10,
src=...) at ../../gcc/value-range.h:263
#3  0x01a863af in irange::intersect_bitmask (this=0x7fffb268,
r=warning: RTTI symbol not found for class 'int_range<3u, true>'
...) at ../../gcc/value-range.cc:2419
#4  0x01a848a5 in irange::intersect (this=0x7fffb268, v=warning:
RTTI symbol not found for class 'int_range<3u, true>'
...) at ../../gcc/value-range.cc:1978
#5  0x01a85b95 in irange_bitmask::adjust_range (this=0x7fffb280,
r=warning: RTTI symbol not found for class 'int_range<3u, true>'
...) at ../../gcc/value-range.cc:2281
#6  0x01a86499 in irange::intersect_bitmask (this=0x7fffb268,
r=warning: RTTI symbol not found for class 'int_range<3u, true>'
...) at ../../gcc/value-range.cc:2433
#7  0x01a84c99 in irange::intersect (this=0x7fffb268, v=warning:
RTTI symbol not found for class 'int_range<3u, true>'
...) at ../../gcc/value-range.cc:2061
#8  0x027d08ab in gori_compute::compute_operand1_range (this=0x4074e30,
r=warning: RTTI symbol not found for class 'int_range<3u, true>'
..., handler=..., lhs=warning: RTTI symbol not found for class 'int_range<3u,
true>'
..., src=..., rel=0x0) at ../../gcc/gimple-range-gori.cc:1192
#9  0x027cec3b in gori_compute::compute_operand_range (this=0x4074e30,
r=warning: RTTI symbol not found for class 'int_range<3u, true>'
..., stmt=0x77567268, lhs=warning: RTTI symbol not found for class
'int_range<3u, true>'
..., name=0x77568048, src=..., rel=0x0) at
../../gcc/gimple-range-gori.cc:747
#10 0x027cedba in gori_compute::compute_operand_range (this=0x4074e30,
r=warning: RTTI symbol not found for class 'int_range<3u, true>'
..., stmt=0x775672c0, lhs=warning: RTTI symbol not found for class
'int_range<3u, true>'
..., name=0x77568048, src=..., rel=0x0) at
../../gcc/gimple-range-gori.cc:762
#11 0x027cedba in gori_compute::compute_operand_range (this=0x4074e30,
r=warning: RTTI symbol not found for class 'int_range<3u, true>'
..., stmt=0x77567318, lhs=warning: RTTI symbol not found for class
'int_range<3u, true>'
..., name=0x77568048, src=..., rel=0x0) at
../../gcc/gimple-range-gori.cc:762
#12 0x027cedba in gori_compute::compute_operand_range (this=0x4074e30,
r=warning: RTTI symbol not found for class 'int_range<3u, true>'
..., stmt=0x77569410, lhs=warning: RTTI symbol not found for class
'int_range<3u, true>'
..., name=0x77568048, src=..., rel=0x0) at
../../gcc/gimple-range-gori.cc:762
#13 0x027d17c3 in gori_compute::edge_range_p (this=0x4074e30,
r=warning: RTTI symbol not found for class 'int_range<3u, true>'
..., e=0x77563780, name=0x77568048, q=...) at
../../gcc/gimple-range-gori.cc:1420
#14 0x027c147d in ranger_cache::edge_range (this=0x407b2c0, r=warning:
RTTI symbol not found for class 'int_range<3u, true>'
..., e=0x77563780, name=0x77568048, mode=ranger_cache::RFD_READ_ONLY)
at ../../gcc/gimple-range-cache.cc:1181
#15 0x027c1a09 in ranger_cache::propagate_cache (this=0x407b2c0,
name=0x77568048) at ../../gcc/gimple-range-cache.cc:1301
#16 0x027c1ffb in ranger_cache::propagate_updated_value
(this=0x407b2c0, name=0x77568048, bb=0x7754c9c0) at
../../gcc/gimple-range-cache.cc:1391
#17 0x027b9dee in gimple_ranger::range_of_stmt (this=0x407b280,
r=warning: RTTI symbol not found for class 'int_range<3u, true>'
..., s=0x77569410, name=0x0) at ../../gcc/gimple-range.cc:314
#18 0x01af29ea in simplify_using_ranges::fold_cond
(this=0x7fffd380, cond=0x77569410) at ../../gcc/vr-values.cc:1064
#19 0x01808b12 in dom_opt_dom_walker::fold_cond (this=0x7fffd680,
cond=0x77569410) at ../../gcc/tree-ssa-dom.cc:2283

[Bug translation/119684] [15 Regression] Severe bug in german translation

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

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

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

https://gcc.gnu.org/g:1f32b87117b0e2ecc33b844d929d723de3fe8085

commit r15-9366-g1f32b87117b0e2ecc33b844d929d723de3fe8085
Author: Jakub Jelinek 
Date:   Thu Apr 10 18:39:52 2025 +0200

c++: Use G_ instead of _ around cp/errors.cc gcc-internal-format strings
[PR119684]

These pp_printf/pp_verbatim format strings should be gcc-internal-format,
they use the pretty-print.cc format specifier handling rather than libc
*printf, but pp_printf/pp_verbatim are intentionally not handled through
exgettext because not everything done through them should be translated
(e.g. its use for dump files shouldn't be).
In addition, composing translatable messages from
"in requirements " and later on "with " might make it harder to be
translated.

I've verified these strings (at least those which don't use format
specifiers added post GCC 4.3 which gettext doesn't handle) are properly
marked as gcc-internal-format in gcc.pot.  The lack of that caused
ICEs on German translation of the "%s%s%sIn instantiation of %q#D:\n"
message because it contained too many %s.

2025-04-10  Jakub Jelinek  

PR translation/119684
* error.cc (cp_print_error_function): Use G_ instead of _ for
pp_printf arguments.
(function_category): Use G_ instead of _.
(print_instantiation_full_context): Use G_ instead of _ in
pp_verbatim
arguments.
(print_location): Likewise.
(print_instantiation_partial_context): Likewise.
(maybe_print_constexpr_context): Likewise.
(print_constrained_decl_info): Use G_() around pp_verbatim
argument.
(print_concept_check_info): Likewise.
(print_constraint_context_head): Likewise.
(print_requires_expression_info): Likewise.  Merge separate
pp_verbatim
"in requirements " and "with " into one with conditional messages.

[Bug target/106671] aarch64: BTI instruction are not inserted for cross-section direct calls

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
   See Also||https://github.com/llvm/llv
   ||m-project/pull/135043
 Status|WAITING |RESOLVED

--- Comment #20 from Andrew Pinski  ---
The AAELF64 ABI now documents this as what GCC does. And LLVM changed behaviors
as of today (https://github.com/llvm/llvm-project/pull/135043). So closing as
invalid.

[Bug libstdc++/119708] New: : \00 should be rejected

[blubban at gmail dot com via Gcc-bugs]

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

Bug ID: 119708
   Summary: : \00 should be rejected
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: blubban at gmail dot com
  Target Milestone: ---

#include 
#include 

int main() {
try {
std::regex r{"\\00"};
puts("valid");
} catch (const std::exception& e) {
printf("not valid: %s\n", e.what());
}
try {
std::regex r{"\\01"};
puts("valid");
} catch (const std::exception& e) {
printf("not valid: %s\n", e.what());
}
}


Expected: Reject them. 00 and 01 do not match DecimalIntegerLiteral in the JS
spec, and lookahead can't be a digit either.

Actual: Both are valid. (Can't find what they're actually parsed as, though.)

https://godbolt.org/z/heM1o1aGe

libc++ has the same bug. https://github.com/llvm/llvm-project/issues/135048

[Bug target/115259] [15 Regressions] GCN vs. "tree-optimization/115144 - improve sinking destination choice"

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

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

--- Comment #9 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #8)
> Created attachment 61054 [details]
> Maybe a testcase
> 
> I tried this on x86_64 with:
> -O2 -fdisable-tree-cselim -march=skylake-avx512 -fno-vect-cost-model
> 
> And it seems to work there.

I mean by works it does not cause the failure and we get the correct results
and the path which uses MASK_STORE is used. Note -fdisable-tree-cselim is
needed on x86_64 because otherwise the undoing of the sink happens.

[Bug tree-optimization/119707] New: wrong code with _BitInt() mask and shift at -O1

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 119707
   Summary: wrong code with _BitInt() mask and shift at -O1
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 61058
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61058&action=edit
reduced testcase

Output:
$ x86_64-pc-linux-gnu-gcc -O testcase.c
$ ./a.out 
Aborted

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/mnt/main-repo/repo/gcc-trunk/binary-trunk-20250324142439-gf775bb892cb-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/15.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-20250324142439-gf775bb892cb-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.1 20250324 (experimental) (GCC)

[Bug tree-optimization/119706] [15 regression] ICE in gimple pass 'dom' for -O3 -mcpu=grace --param=aarch64-autovec-preference=sve-only

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||ktkachov at gcc dot gnu.org
   Last reconfirmed||2025-04-10

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed. On GCC 14 this compiles successfully with the equivalent flags:
-O3 -mcpu=neoverse-v2 --param=aarch64-autovec-preference=2

[Bug c++/119692] C++ 'typeinfo', 'vtable' vs. OpenACC, OpenMP 'target' offloading

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

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

--- Comment #3 from Thomas Schwinge  ---
Jakub, could you please quickly describe the approach you'd take to get the
relevant 'DECL_TINFO_P' and 'DECL_VTABLE_OR_VTT_P' (correct, and complete list
of predicates?) into 'offload_vars' (via the usual 'symtab_node::get', 'omp
declare target' attribute etc. thing, I assume)?  ..., but I suppose only those
'typeinfo', 'vtable' that are actually used in offloaded regions, or do (we
have to?) simply do it for all of them?

For example, in 'gcc/cp/decl.cc:cp_finish_decl', I wouldn't necessarily already
know whether used in offloading region?  Ah, or do I tag all of them 'omp
declare target implicit', and then just let 'cp_finish_decl' do its thing?

Or, transform the 'gcc/gimplify.cc:gimplify_bind_expr' handling of "Static
locals inside of target construct" into a langhook, and extend for
'DECL_TINFO_P' and 'DECL_VTABLE_OR_VTT_P'?

Or, do we have to do à la
'gcc/omp-offload.cc:omp_discover_implicit_declare_target',
'omp_discover_declare_target_var_r'?

Also, have to make sure that we don't synthesize any 'map' clauses for
'DECL_TINFO_P' and 'DECL_VTABLE_OR_VTT_P'; in
'gcc/gimplify.cc:omp_notice_variable', need to achieve 'is_declare_target ==
true'.  (..., and in 'omp_predetermined_mapping' langhook, 'assert' we don't
see these variables?)

[Bug tree-optimization/119614] [15 regression] protobuf-29.4 fails to build with -O2 (error: cannot tail-call: call and return value are different)

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

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

--- Comment #25 from Jakub Jelinek  ---
As a temporary fix for GCC 15, I think we could always do something like
--- gcc/cgraph.h.jj 2025-04-08 14:08:48.517319926 +0200
+++ gcc/cgraph.h2025-04-10 10:07:19.059246243 +0200
@@ -896,8 +896,8 @@ struct GTY((tag ("SYMTAB_FUNCTION"))) cg
   indirect_calls (NULL),
   next_sibling_clone (NULL), prev_sibling_clone (NULL), clones (NULL),
   clone_of (NULL), call_site_hash (NULL), former_clone_of (NULL),
-  simdclone (NULL), simd_clones (NULL), ipa_transforms_to_apply (vNULL),
-  inlined_to (NULL), rtl (NULL),
+  singleton_retval (NULL), simdclone (NULL), simd_clones (NULL),
+  ipa_transforms_to_apply (vNULL), inlined_to (NULL), rtl (NULL),
   count (profile_count::uninitialized ()),
   count_materialization_scale (REG_BR_PROB_BASE), profile_id (0),
   unit_id (0), tp_first_run (0), thunk (false),
@@ -1408,6 +1408,9 @@ struct GTY((tag ("SYMTAB_FUNCTION"))) cg
   hash_table *GTY(()) call_site_hash;
   /* Declaration node used to be clone of. */
   tree former_clone_of;
+  /* If ipa_return_value_sum range for this function is a CONSTANT_CLASS_P
+ singleton, store it here.  */
+  tree singleton_retval;

   /* If this is a SIMD clone, this points to the SIMD specific
  information for it.  */
--- gcc/lto-cgraph.cc.jj2025-04-08 14:08:51.978271745 +0200
+++ gcc/lto-cgraph.cc   2025-04-10 10:29:12.536028532 +0200
@@ -474,6 +474,8 @@ lto_output_node (struct lto_simple_outpu
   FOR_EACH_VEC_ELT (node->ipa_transforms_to_apply, i, pass)
 streamer_write_hwi_stream (ob->main_stream, pass->static_pass_number);

+//  stream_write_tree (ob, node->singleton_retval, true);
+
   if (tag == LTO_symtab_analyzed_node)
 {
   if (node->inlined_to)
@@ -1334,6 +1336,8 @@ input_node (struct lto_file_decl_data *f
   node->ipa_transforms_to_apply.safe_push ((ipa_opt_pass_d *) pass);
 }

+//  node->singleton_retval = stream_read_tree (...);
+
   if (tag == LTO_symtab_analyzed_node)
 ref = streamer_read_hwi (ib);

--- gcc/ipa-prop.cc.jj  2025-04-08 14:08:51.869273262 +0200
+++ gcc/ipa-prop.cc 2025-04-10 11:20:37.071218021 +0200
@@ -6158,6 +6158,13 @@ ipa_record_return_value_range (value_ran
   ipa_return_value_sum->disable_insertion_hook ();
 }
   ipa_return_value_sum->get_create (n)->vr = ipa_get_value_range (val);
+  tree valr;
+  if (val.singleton_p (&valr)
+  && CONSTANT_CLASS_P (valr)
+  && !tree_expr_nan_p (valr))
+n->singleton_retval = valr;
+  else
+n->singleton_retval = NULL_TREE;
   if (dump_file && (dump_flags & TDF_DETAILS))
 {
   fprintf (dump_file, "Recording return range ");
@@ -6172,7 +6179,7 @@ bool
 ipa_return_value_range (value_range &range, tree decl)
 {
   cgraph_node *n = cgraph_node::get (decl);
-  if (!n || !ipa_return_value_sum)
+  if (!n)
 return false;
   enum availability avail;
   n = n->ultimate_alias_target (&avail);
@@ -6180,11 +6187,21 @@ ipa_return_value_range (value_range &ran
 return false;
   if (n->decl != decl && !useless_type_conversion_p (TREE_TYPE (decl),
TREE_TYPE (n->decl)))
 return false;
-  ipa_return_value_summary *v = ipa_return_value_sum->get (n);
-  if (!v)
-return false;
-  v->vr->get_vrange (range);
-  return true;
+  if (ipa_return_value_sum)
+if (ipa_return_value_summary *v = ipa_return_value_sum->get (n))
+  {
+   v->vr->get_vrange (range);
+   return true;
+  }
+  if (n->singleton_retval)
+{
+  value_range vr (n->singleton_retval, n->singleton_retval);
+  if (is_a  (vr))
+   (as_a  (vr)).clear_nan ();
+  range = vr;
+  return true;
+}
+  return false;
 }

 /* Reset all state within ipa-prop.cc so that we can rerun the compiler

except that I'd need help with the lto-cgraph.cc stuff how to stream
node->singleton_retval out and then back in.
Tested with non-LTO (and doing the n->singleton_retval handling in the last
hunk in precedence over ipa_return_value_sum).

[Bug tree-optimization/119706] New: [15 regression] ICE in gimple pass 'dom' for -O3 -mcpu=grace --param=aarch64-autovec-preference=sve-only

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

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

Bug ID: 119706
   Summary: [15 regression] ICE in gimple pass 'dom' for -O3
-mcpu=grace
--param=aarch64-autovec-preference=sve-only
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jschmitz at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

Created attachment 61057
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61057&action=edit
Test case for reproducing the ICE

For the attached test case (reduced from the RAJAPerf kernel
Basic_MULTI_REDUCE), there is an ICE when compiling it with
-O3 -mcpu=grace --param=aarch64-autovec-preference=sve-only:

during GIMPLE pass: dom
testcase.i: In member function ‘void a::basic::u::v(cd, a::b)’:
testcase.i:170:6: internal compiler error: in maybe_canonicalize_mem_ref_addr,
at gimple-fold.cc:6394
  170 | void u::v(cd, b) {
  |  ^
0x2622a9b internal_error(char const*, ...)
.././../../src/gcc/diagnostic-global-context.cc:517
0x844b57 fancy_abort(char const*, int, char const*)
.././../../src/gcc/diagnostic.cc:1749
0xf4ff5b maybe_canonicalize_mem_ref_addr
.././../../src/gcc/gimple-fold.cc:6394
0xf5c117 fold_stmt_1
.././../../src/gcc/gimple-fold.cc:6499
0x1497cd7 dom_opt_dom_walker::optimize_stmt(basic_block_def*,
gimple_stmt_iterator*, bool*)
.././../../src/gcc/tree-ssa-dom.cc:2352
0x149951f dom_opt_dom_walker::before_dom_children(basic_block_def*)
.././../../src/gcc/tree-ssa-dom.cc:1747
0x22f08e3 dom_walker::walk(basic_block_def*)
.././../../src/gcc/domwalk.cc:311
0x1499e13 execute
.././../../src/gcc/tree-ssa-dom.cc:939

The gimple expression
MEM  [(double *)POLY_INT_CST [16B, 16B] + ivtmp_97 * 8]
does not pass the assertion
gcc_checking_assert (TREE_CODE (TREE_OPERAND (*t, 0)) == DEBUG_EXPR_DECL ||
is_gimple_mem_ref_addr (TREE_OPERAND (*t, 0))).

[Bug ada/119701] Ada.Calendar.Formatting.Day_Of_Week returns wrong value after Ada.Calendar.Time is incremented via Ada.Calendar.Arithmetic."+".

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||ebotcazou at gcc dot gnu.org
   Last reconfirmed||2025-04-10
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Eric Botcazou  ---
You're mixing apples and oranges though: Ada.Calendar takes into account the
timezone whereas Ada.Calendar.Formatting does not (by default).  Therefore, you
need to either call ACF.Time_Of or pass Ada.Calendar.Time_Zones.Time_Offset to
ACF.Image.

Are you positive that you get twice the same day though (I don't)?  That seems
hard to believe given the implementation.

[Bug tree-optimization/119690] [12/13/14/15 regression] wrong code at -O{s,1,2,3} on x86_64-linux-gnu since r12-4871

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

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

--- Comment #5 from Jakub Jelinek  ---
Already -O1 fails:
int a, b = -__INT_MAX__, c;

int
main ()
{
d:
  c = a + b + __INT_MAX__;
  if (-c >= 0)
goto e;
  goto f;
e:
  a = c + 1;
  goto d;
f:
  if (a != 1)
__builtin_abort ();
}

[Bug target/119610] [12/13/14/15 regression] aarch64: Wrong unwind info with -fstack-clash-protection -fstack-protector-strong since r14-3900-g3e4afea3b192c2

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

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

Richard Sandiford  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Sandiford  ---
Mine.

[Bug tree-optimization/119706] [15 regression] ICE in gimple pass 'dom' for -O3 -mcpu=grace --param=aarch64-autovec-preference=sve-only

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

  Known to fail||15.0
   Target Milestone|--- |15.0
  Known to work||14.2.0
   Keywords||aarch64-sve,
   ||ice-on-valid-code

[Bug c++/119692] C++ 'typeinfo', 'vtable' vs. OpenACC, OpenMP 'target' offloading

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

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

--- Comment #2 from Thomas Schwinge  ---
When still 'map'ping C++ 'typeinfo', 'vtable' at the OpenACC compute, OpenMP
'target' construct (as 'firstprivate', or 'map(to)'), there's an additional
issue.  With attachment 61052 altered as follows:

   {
 C1 c1;
-bool a = false;
-asm volatile ("" : : "r" (&a) : "memory");
-if (a)
-  {
-   [[maybe_unused]]
-   C2 &c2 = dynamic_cast(c1);
-  }
+C1 *c1p = &c1;
+asm volatile ("" : : "r" (&c1p) : "memory");
+C2 *c2 = dynamic_cast(c1p);
+if (c2)
+  __builtin_abort();
   }

..., this should execute and terminate normally -- and it does, for host as
well as GCN, nvptx target execution.  But for GCN, nvptx offloading execution,
we get device-side SIGSEGV.

I suppose we have to properly (deep-)initialize the device-side data
structures?  Will this go away once we're no longer 'map'ping C++ 'typeinfo',
'vtable' at the OpenACC compute, OpenMP 'target' construct, or is additional
effort necessary?

[Bug middle-end/119507] only the comdat functions before normal functions get their own gcc_except_table section (unless using -ffunction-sections)

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #6 from chenglulu  ---
Ping?

[Bug libstdc++/105926] Using a spaceship operator on an optional of a type derived from optional causes infinite constraint recursion

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
It might be worth backporting this to 14.

[Bug tree-optimization/119399] [12/13/14 Backport] Overlap check in vectorized code may invoke UB

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

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

Richard Sandiford  changed:

   What|Removed |Added

Summary|Overlap check in vectorized |[12/13/14 Backport] Overlap
   |code may invoke UB  |check in vectorized code
   ||may invoke UB

--- Comment #7 from Richard Sandiford  ---
Fixed on trunk, will backport after a settling-in period.

[Bug cobol/119244] cobol/libgcobol should allow libquadmath to provide 128b floating support.

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

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

--- Comment #30 from GCC Commits  ---
The master branch has been updated by Iain D Sandoe :

https://gcc.gnu.org/g:95f10974a9190e345776604480a2df0191104308

commit r15-9357-g95f10974a9190e345776604480a2df0191104308
Author: Iain Sandoe 
Date:   Sat Mar 15 22:58:46 2025 +

libgcobol: Allow libgcobol to use libquadmath [PR119244].

Many of the changes are mechanical:
 1. 'GCOB_FP128' in place of _Float128.
 2. Using FP128_FUNC to represent the spelling of intrinsics.
 3. Using GCOB_FP128_LITERAL() to choose the suffix for literals.

This allows for:
  __float128 and 'q' as the suffix when libquadmath is configured.
   _Float128 / 'f128' when IEC-60559 is available in libc
 long double / 'l' when long double is ieee753 128b.

Add libquadmath to libgcobol.spec and its dependencies  where the
platform needs it.

PR cobol/119244

libgcobol/ChangeLog:

* Makefile.am: Add support for libquadmath.
* Makefile.in: Regenerate.
* acinclude.m4: Add support for libquadmath.
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Configure libquadmath support.
* gmath.cc: Use GCOB_FP128 to represent the configured
128b floating point type.  Use FP128_FUNC to represent
the naming of intrinsics in the configure 128b floating
point type. Render literals with GCOB_FP128_LITERAL.
* intrinsic.cc: Likewise.
* libgcobol.cc: Likewise.
* libgcobol.h: Likewise.
* libgcobol-fp.h: New file.
* gfileio.cc: Include libgcobol-fp.h.
* libgcobol.spec.in: Add libquadmath configure output.

Signed-off-by: Iain Sandoe 

[Bug tree-optimization/119690] [12/13/14/15 regression] wrong code at -O{s,1,2,3} on x86_64-linux-gnu since r12-4871

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

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

--- Comment #6 from Jakub Jelinek  ---
I think at -O1 in *.sra it is still correct, we have
   [local count: 118111600]:
  a.0_12 = a;
  b.1_13 = b;
  _14 = a.0_12 + b.1_13;
  _15 = _14 + 2147483647;
  c = _15;
  if (_15 <= 0)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 955630224]:
  # _18 = PHI <_3(3), _14(2)>
  _5 = _18 - -2147483648;
  a = _5;
  a.0_1 = a;
  b.1_2 = b;
  _3 = a.0_1 + b.1_2;
  _4 = _3 + 2147483647;
  c = _4;
  if (_4 <= 0)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 118111600]:
  # a.0_17 = PHI 
  if (a.0_17 != 1)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  # USE = nonlocal escaped
  # CLB = nonlocal escaped
  __builtin_abort ();

   [local count: 118111600]:
  return 0;
where _14 for non-UB should be [-INF, 0] (it is -__INT_MAX__, so ok),
and in bb3 from that edge because _15 <= 0 it implies _14 is in [-INF,
-INT_MAX].
For that _5 has [0, 1] range.  For _4 <= 0 the same applies for _3.
So the ranges from dom2 look reasonable to me:
Global Exported: _4 = [irange] int [-1, +INF]
Global Exported: _5 = [irange] int [0, 1] MASK 0x8001 VALUE 0x0
Global Exported: _15 = [irange] int [-1, +INF]
Global Exported: _18 = [irange] int [-INF, -2147483647]

[Bug tree-optimization/119706] [15 regression] ICE in gimple pass 'dom' for -O3 -mcpu=grace --param=aarch64-autovec-preference=sve-only

[mcccs at gmx dot com via Gcc-bugs]

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

mcccs at gmx dot com changed:

   What|Removed |Added

 CC||mcccs at gmx dot com

--- Comment #2 from mcccs at gmx dot com ---
O2 doesn't cause ICE but O3 does because of -fvect-cost-model=dynamic

[Bug tree-optimization/119690] [12/13/14/15 regression] wrong code at -O{s,1,2,3} on x86_64-linux-gnu since r12-4871

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

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

--- Comment #7 from Jakub Jelinek  ---
I think this is ivopts bug (or at least that pass introduces UB into the IL
that wasn't there before).
In particular on the c <= 0 guarded edge it adds
[local count: 105119324]:
+  _26 = b.1_13 + -2147483648;
+  _1 = (unsigned int) _26;
+  _8 = (unsigned int) _14;
+  ivtmp.17_11 = _8 + 2147483648;
where b.1_13 at runtime is -2147483647 and both b.1_13 and _26 have int type.
So, the addition invokes UB.  Given that previously all that was there was (a +
b) + 2147483647, nothing was known about b's range, only about a + b, so I
think it certainly should have been unsigned _26:
  _26 = (unsigned int) b.1_13;
  _1 = _26 + 2147483648;

[Bug ada/119698] gen_il-main: raised PROGRAM_ERROR : finalize/adjust raised exception

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

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org
 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Eric Botcazou  ---
Expected as explained in the quoted comment, although this generally works even
with the error.  Try with another base compiler.

[Bug c++/119692] C++ 'typeinfo', 'vtable' vs. OpenACC, OpenMP 'target' offloading

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

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

--- Comment #4 from Tobias Burnus  ---
Some generic remarks - regarding OpenMP to:

> When still 'map'ping C++ 'typeinfo', 'vtable' at the OpenACC compute,
> OpenMP 'target' construct


Obviously, the type info etc. is required for all work on that class on
a device side, like:

  MyClass *x = new MyClass();
  MyClass *y = new InheritFromMyClass();


However, on the OpenMP side, there are the following
RESTRICTIONS related to MAPPING:

* The run-time type information (RTTI) of an object can only be accessed
  from the device on which it was constructed.

* Invoking a virtual member function of an object on a device other
  than the device on which the object was constructed results in unspecified
  behavior, unless the object is accessible and was constructed on the host
  device.

The latter relates to the following; assume that 'func' is a virtual function
of the base class:

  #pragma omp requires self_maps /* or/and */ unified_shared_memory
...
  MyClass *y = new InheritFromMyClass();

  #pragma omp target
   {
 y->func (123);
   }

where 'y->vtable' is the host vtable and, hence, 'vtable->func' points to the
host function.

Similar to 'omp declare target(some_func) indirect' and using device function
pointers, the compiler has to insert the lookup, i.e.

the user's
   y->func (123);
becomes internally
   (GOMP_target_map_indirect_ptr (y->vtable->func) (123);


The function returns the device ptr, if the mapping has been found,
and otherwise the original pointer. Thus, it only works if the
function is 'declare target'; for virtual functions, the 'indirect'
clause is then implied, for other functions the 'indirect' is must
be specified by the user.


Regarding mainline support for USM, see 'unified_shared_memory' entry at
https://gcc.gnu.org/onlinedocs/libgomp/Offload-Target-Specifics.html

And note that the automatic insertion of the GOMP_target_map_indirect_ptr call
for virtual functions is an OpenMP 5.2 feature, which is not yet implemented in
GCC 15.


And regarding the example above: If actual mapping happens (i.e. no self map)
and the vtable exists on the device, it is of course permitted to update the
vtable pointer in the mapped class instance to the device's one. But that's not
required.

* * *

OpenMP 6.1 will (tentatively) add support for mapping polymorphic types in
Fortran, starting with having the Fortran's vtable also accessible (= USM
case).

[Bug tree-optimization/119399] Overlap check in vectorized code may invoke UB

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

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

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

https://gcc.gnu.org/g:4c8c373495d7d863dfb7102726ac3b4b41685df4

commit r15-9355-g4c8c373495d7d863dfb7102726ac3b4b41685df4
Author: Richard Sandiford 
Date:   Thu Apr 10 11:03:04 2025 +0100

Avoid using POINTER_DIFF_EXPR for overlap checks [PR119399]

In r10-4803-g8489e1f45b50600c I'd used POINTER_DIFF_EXPR to subtract
the two pointers involved in an overlap test.  I'm not sure whether
I'd specifically chosen that over MINUS_EXPR or not; if so, the only
reason I can think of is that it is probably faster on targets with
PSImode pointers.  Regardless, as the PR points out, subtracting
unrelated pointers using POINTER_DIFF_EXPR is undefined behaviour.

gcc/
PR tree-optimization/119399
* tree-data-ref.cc (create_waw_or_war_checks): Use a MINUS_EXPR
on two converted pointers, rather than converting a
POINTER_DIFF_EXPR
on the pointers.

gcc/testsuite/
PR tree-optimization/119399
* gcc.dg/vect/pr119399.c: New test.

[Bug target/116593] internal compiler error: in get_attr_type, at config/riscv/riscv.md:28048 with -O2 -O3 when compiling for risc-v xtheadvector

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

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

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

https://gcc.gnu.org/g:2631ac38d9b2a9def13a04c1e1fefb3871e420ab

commit r14-11583-g2631ac38d9b2a9def13a04c1e1fefb3871e420ab
Author: Jin Ma 
Date:   Tue Jan 21 10:46:37 2025 -0700

RISC-V: Add a new constraint to ensure that the vl of XTheadVector does not
get a non-zero immediate

Although we have handled the vl of XTheadVector correctly in the
expand phase and predicates, the results show that the work is
still insufficient.

In the curr_insn_transform function, the insn is transformed from:
(insn 69 67 225 12 (set (mem:RVVM8SF (reg/f:DI 218 [ _77 ]) [0  S[128, 128]
A32])
(if_then_else:RVVM8SF (unspec:RVVMF4BI [
(const_vector:RVVMF4BI repeat [
(const_int 1 [0x1])
])
(reg:DI 209)
(const_int 0 [0])
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)
(reg/v:RVVM8SF 143 [ _xx ])
(mem:RVVM8SF (reg/f:DI 218 [ _77 ]) [0  S[128, 128] A32])))
 (expr_list:REG_DEAD (reg/v:RVVM8SF 143 [ _xx ])
(nil)))
to
(insn 69 284 225 11 (set (mem:RVVM8SF (reg/f:DI 18 s2 [orig:218 _77 ]
[218]) [0  S[128, 128] A32])
(if_then_else:RVVM8SF (unspec:RVVMF4BI [
(const_vector:RVVMF4BI repeat [
(const_int 1 [0x1])
])
(const_int 1 [0x1])
(const_int 0 [0])
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)
(reg/v:RVVM8SF 104 v8 [orig:143 _xx ] [143])
(mem:RVVM8SF (reg/f:DI 18 s2 [orig:218 _77 ] [218]) [0  S[128,
128] A32])))
 (nil))

Looking at the log for the reload pass, it is found that "Changing pseudo
209 in
operand 3 of insn 69 on equiv 0x1".
It converts the vl operand in insn from the expected register(reg:DI 209)
to the
constant 1(const_int 1 [0x1]).

This conversion occurs because, although the predicate for the vl operand
is
restricted by "vector_length_operand" in the pattern, the constraint is
still
"rK", which allows the transformation.

The issue is that changing the "rK" constraint to "rJ" for the constraint
of vl
operand in the pattern would prevent this conversion, But unfortunately
this will
conflict with RVV (RISC-V Vector Extension).

Based on the review's recommendations, the best solution for now is to
create
a new constraint to distinguish between RVV and XTheadVector, which is
exactly
what this patch does.

PR target/116593

gcc/ChangeLog:

* config/riscv/constraints.md (vl): New.
* config/riscv/thead-vector.md: Replacing rK with rvl.
* config/riscv/vector.md: Likewise.

gcc/testsuite/ChangeLog:

* g++.target/riscv/rvv/rvv.exp: Enable testsuite of XTheadVector.
* g++.target/riscv/rvv/xtheadvector/pr116593.C: New test.

(cherry picked from commit 3024b12f2cde5db3bf52b49b07e32ef3065929fb)

[Bug target/118601] [15] RISC-V: unrecognizable insn ICE in xtheadvector/pr114194.c on 32bit targets

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

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

--- Comment #3 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Ma Jin :

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

commit r14-11584-gf2e2e255004dc35beef9d8b5800d69d228f7eec1
Author: Jin Ma 
Date:   Tue Feb 11 21:28:05 2025 +0800

RISC-V: unrecognizable insn ICE in xtheadvector/pr114194.c on 32bit targets

This is a follow-up to the patch below to avoid generating unrecognized
vsetivl instructions for XTheadVector.

https://gcc.gnu.org/pipermail/gcc-patches/2025-January/674185.html

PR target/118601

gcc/ChangeLog:

* config/riscv/riscv-string.cc (expand_block_move): Check with new
constraint 'vl' instead of 'K'.
(expand_vec_setmem): Likewise.
(expand_vec_cmpmem): Likewise.
* config/riscv/riscv-v.cc (force_vector_length_operand): Likewise.
(expand_load_store): Likewise.
(expand_strided_load): Likewise.
(expand_strided_store): Likewise.
(expand_lanes_load_store): Likewise.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/xtheadvector/pr114194.c: Move to...
* gcc.target/riscv/rvv/xtheadvector/pr114194-rv64.c: ...here.
* gcc.target/riscv/rvv/xtheadvector/pr114194-rv32.c: New test.
* gcc.target/riscv/rvv/xtheadvector/pr118601.c: New test.

Reported-by: Edwin Lu 
(cherry picked from commit 580f571be6ce80aa71fb80e7b16e01824f088229)

[Bug tree-optimization/119706] [15 regression] ICE in gimple pass 'dom' for -O3 -mcpu=grace --param=aarch64-autovec-preference=sve-only

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Confirmed.  We have a POLY_INT_CST in the base address of a TARGET_MEM_REF:

MEM  [(double *)POLY_INT_CST [16B, 16B] + ivtmp_97 * 8]

but is_gimple_mem_ref_addr only allows:

bool
is_gimple_mem_ref_addr (tree t)
{
  return (is_gimple_reg (t)
  || TREE_CODE (t) == INTEGER_CST
  || (TREE_CODE (t) == ADDR_EXPR
  && (CONSTANT_CLASS_P (TREE_OPERAND (t, 0))
  || decl_address_invariant_p (TREE_OPERAND (t, 0);
}

A POLY_INT_CST "base" is a bit odd, GIMPLE IL verification would also
reject this but it could trivially happen via constant propagation
from

 _1 = POLY_INT_CST [16B, 16B];
 MEM [_1 + ivtmp_97 * 8] = ...

as it does here indirectly, after jump threading:

LKUP STMT _57 = POLY_INT_CST [16B, 16B]
 ASGN _57 = POLY_INT_CST [16B, 16B]
Optimizing statement MEM  [(double *)_57 + ivtmp_97 * 8]
= vect__26.60_90;
  Replaced '_57' with constant 'POLY_INT_CST [16B, 16B]'

[Bug c/119709] New: RISC-V: Why volatile int16_t variables generate extra shift instructions in compiler output

[bigmagicreadsun at gmail dot com via Gcc-bugs]

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

Bug ID: 119709
   Summary: RISC-V: Why volatile int16_t variables generate extra
shift instructions in compiler output
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bigmagicreadsun at gmail dot com
  Target Milestone: ---

When compiling the following code with RISC-V GCC:


#include 
volatile int16_t x;
int get() {
  return x;
}
The generated assembly is:


get:
lui a5,%hi(x)
lhu a0,%lo(x)(a5)
sllia0,a0,16
sraia0,a0,16
ret
x:
.zero   2
(Full example: Godbolt link: https://godbolt.org/z/Y93T4c7M7)

Why does the compiler generate redundant shift operations (slli + srai) instead
of directly using lh?

When I change x to volatile uint16_t x, GCC correctly generates an lhu
instruction without shifts. Why does this behavior occur?

[Bug c++/119705] Massive memory use when building Flang (10GB+)

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

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

--- Comment #4 from Richard Biener  ---
>From the profile it looks like using that much memory (creating that much
garbage) is the main issue, due to GC that always eats at compile-time.

[Bug tree-optimization/119707] wrong code with _BitInt() mask and shift at -O1

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
-O2 -fno-inline is miscompiled too, or
unsigned _BitInt(256) g;

__attribute__((noipa)) unsigned long
foo (_BitInt(129) k)
{
  unsigned _BitInt(255) a = -1;
  unsigned _BitInt(256) m = g - (k & a);
  unsigned __int128 e = m >> 128;
  unsigned long long r = e >> 64;
  return r;
}

int
main ()
{
  unsigned long long x = foo (-1);
  if (x != 0x8000ULL)
__builtin_abort ();
}
at any opt level other than -O0.

[Bug tree-optimization/119707] wrong code with _BitInt() mask and shift at -O1

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

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

--- Comment #2 from Jakub Jelinek  ---
Further simplified
__attribute__((noipa)) unsigned _BitInt(256)
foo (unsigned _BitInt(256) x, _BitInt(129) y)
{
  return x - (unsigned _BitInt(255)) y;
}

int
main ()
{
  if (foo (0, -1) !=
0x8001uwb)
__builtin_abort ();
}

[Bug libstdc++/115285] [12/13/14 Regression] std::unordered_set can have duplicate value

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

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

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

https://gcc.gnu.org/g:6343a0fef382a6f37f50755beb239f4e1e9e83cb

commit r14-11586-g6343a0fef382a6f37f50755beb239f4e1e9e83cb
Author: François Dumont 
Date:   Tue Oct 22 19:13:34 2024 +0200

libstdc++: Always instantiate key_type to compute hash code [PR115285]

Even if it is possible to compute a hash code from the inserted arguments
we need to instantiate the key_type to guaranty hash code consistency.

Preserve the lazy instantiation of the mapped_type in the context of
associative containers.

libstdc++-v3/ChangeLog:

PR libstdc++/115285
* include/bits/hashtable.h (_S_forward_key<_Kt>): Always return a
temporary
key_type instance.
* testsuite/23_containers/unordered_map/96088.cc: Adapt to
additional instanciation.
Also check that mapped_type is not instantiated when there is no
insertion.
* testsuite/23_containers/unordered_multimap/96088.cc: Adapt to
additional
instanciation.
* testsuite/23_containers/unordered_multiset/96088.cc: Likewise.
* testsuite/23_containers/unordered_set/96088.cc: Likewise.
* testsuite/23_containers/unordered_set/pr115285.cc: New test case.

(cherry picked from commit ee030b28004eade3da872e7ae62a526a2940a705)

[Bug libstdc++/115285] [12/13/14 Regression] std::unordered_set can have duplicate value

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

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

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

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

commit r14-11589-g5cfe086bea29799c2d4eff59d2d43e30a162bf9c
Author: Jonathan Wakely 
Date:   Tue Nov 5 17:19:06 2024 +

libstdc++: Fix conversions to key/value types for hash table insertion
[PR115285]

The conversions to key_type and value_type that are performed when
inserting into _Hashtable need to be fixed to do any required
conversions explicitly. The current code assumes that conversions from
the parameter to the key_type or value_type can be done implicitly,
which isn't necessarily true.

Remove the _S_forward_key function which doesn't handle all cases and
either forward the parameter if it already has type cv key_type, or
explicitly construct a temporary of type key_type.

Similarly, the _ConvertToValueType specialization for maps doesn't
handle all cases either, for std::pair arguments only some value
categories are handled. Remove _ConvertToValueType and for the _M_insert
function for unique keys, either forward the argument unchanged or
explicitly construct a temporary of type value_type.

For the _M_insert overload for non-unique keys we don't need any
conversion at all, we can just forward the argument directly to where we
construct a node.

libstdc++-v3/ChangeLog:

PR libstdc++/115285
* include/bits/hashtable.h (_Hashtable::_S_forward_key): Remove.
(_Hashtable::_M_insert_unique_aux): Replace _S_forward_key with
a static_cast to a type defined using conditional_t.
(_Hashtable::_M_insert): Replace _ConvertToValueType with a
static_cast to a type defined using conditional_t.
* include/bits/hashtable_policy.h (_ConvertToValueType): Remove.
* testsuite/23_containers/unordered_map/insert/115285.cc: New test.
* testsuite/23_containers/unordered_set/insert/115285.cc: New test.
* testsuite/23_containers/unordered_set/96088.cc: Adjust
expected number of allocations.

(cherry picked from commit 90c578654a2c96032aa6621449859243df5f641b)

[Bug tree-optimization/119690] [12/13/14/15 regression] wrong code at -O{s,1,2,3} on x86_64-linux-gnu since r12-4871

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #7)
> I think this is ivopts bug (or at least that pass introduces UB into the IL
> that wasn't there before).
> In particular on the c <= 0 guarded edge it adds
> [local count: 105119324]:
> +  _26 = b.1_13 + -2147483648;
> +  _1 = (unsigned int) _26;
> +  _8 = (unsigned int) _14;
> +  ivtmp.17_11 = _8 + 2147483648;
> where b.1_13 at runtime is -2147483647 and both b.1_13 and _26 have int type.
> So, the addition invokes UB.  Given that previously all that was there was
> (a + b) + 2147483647, nothing was known about b's range, only about a + b,
> so I think it certainly should have been unsigned _26:
>   _26 = (unsigned int) b.1_13;
>   _1 = _26 + 2147483648;

I guess this is one of the more long-standing SCEV issues, we analyze the
evolution of the loop PHI as:

(get_scalar_evolution
  (scalar = _18)
  (scalar_evolution = {_14, +, b.1_13 + -2147483648(OVF)}_1))

and from that

(get_scalar_evolution
  (scalar = _5)
  (scalar_evolution = {_14 - -2147483648, +, b.1_13 + -2147483648(OVF)}_1))
)

IVOPTs in the end selects

Selected IV set for loop 1 at t.c:8, 10 avg niters, 1 IVs:
Candidate 8:
  Depend on inv.exprs: 1
  Var befor: ivtmp.17_22
  Var after: ivtmp.17_21
  Incr POS: before exit test
  IV struct:
Type:   unsigned int
Base:   (unsigned int) _14 + 2147483648
Step:   (unsigned int) (b.1_13 + -2147483648(OVF))
Biv:N
Overflowness wrto loop niter:   Overflow

but it's really the association done by SCEV where things go downhill from.
I think this is another instance of PR114074 and friends.

[Bug demangler/78564] cp-demangle fails to decode Ul+auto/anon

[jengelh at inai dot de via Gcc-bugs]

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

Jan Engelhardt  changed:

   What|Removed |Added

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

--- Comment #3 from Jan Engelhardt  ---
This seems fixed in at least binutils 2.43, which suggests it was fixed in
gcc's cp-demangle too at some point.

$ c++filt -n _ZZ4mainENKUlOT_E_clIRZ4mainE5NAMEDEEDaS0_
auto main::{lambda(auto:1&&)#1}::operator()(main::NAMED&) const

[Bug demangler/60354] fails to demangle _Z3fooIPUlvE_EvT_

[jengelh at inai dot de via Gcc-bugs]

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

--- Comment #3 from Jan Engelhardt  ---
Issue persists as of
gcc version 15.0.1 20250408 (experimental) (SUSE Linux)

[Bug tree-optimization/119706] [15 regression] ICE in gimple pass 'dom' for -O3 -mcpu=grace --param=aarch64-autovec-preference=sve-only

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

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

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

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

commit r15-9358-gbf812c6ad83ec0b241bb3fecc7e68f883b6083df
Author: Richard Biener 
Date:   Thu Apr 10 13:30:42 2025 +0200

middle-end/119706 - allow POLY_INT_CST as is_gimple_mem_ref_addr

We currently only INTEGER_CST, but not POLY_INT_CST, which leads
to the situation that when the POLY_INT_CST is only indrectly
present via a SSA def the IL is valid but when propagated it's not.
That's unsustainable.

PR middle-end/119706
* gimple-expr.cc (is_gimple_mem_ref_addr): Also allow
POLY_INT_CST.

[Bug tree-optimization/119706] [12/13/14 regression] ICE in gimple pass 'dom' for -O3 -mcpu=grace --param=aarch64-autovec-preference=sve-only

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail|15.0|
Summary|[15 regression] ICE in  |[12/13/14 regression] ICE
   |gimple pass 'dom' for -O3   |in gimple pass 'dom' for
   |-mcpu=grace |-O3 -mcpu=grace
   |--param=aarch64-autovec-pre |--param=aarch64-autovec-pre
   |ference=sve-only|ference=sve-only
   Target Milestone|15.0|12.5
  Known to work||15.0
   Priority|P3  |P2

--- Comment #6 from Richard Biener  ---
Fixed, this is latent though so will backport.

[Bug c++/119705] Massive memory use when building Flang (10GB+)

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
I can confirm (with release checking) 5GB use with -fsyntax-only, 6.2GB with
-O2
and 15GB with -O2 -g.

[Bug rtl-optimization/116294] -O2 -gno-statement-frontiers -fcompare-debug failure when building duktape-2.7.0

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

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

--- Comment #10 from Sam James  ---
It fails at -O1 only with statement-frontiers, so another bug again (but who
cares about frontiers).

Reducing -O2 with -gno-statement-frontiers.

[Bug c++/119687] [14/15 Regression] ICE when building kwin-6.3.4 against qt-6.9 (in operator*, at cp/cp-tree.h:876) (deduction guides related) since r14-10655

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

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

Sam James  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #15 from Sam James  ---
Thanks,
https://inbox.sourceware.org/gcc-patches/20250409151104.2600656-1-ppa...@redhat.com/
works on the original too.

[Bug tree-optimization/119399] Overlap check in vectorized code may invoke UB

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

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

--- Comment #5 from Richard Sandiford  ---
(In reply to rguent...@suse.de from comment #4)
> >, so for a 4-element
> > vector, the only problem cases are p==q+4, p==q+8 and p==q+12.  That's
> > equivalent to testing whether the unsigned value p-(q+4) <= 8.
> 
> So the reasoning is that for p == q + 12 iff q + 12 wraps then
> it has to be outside of the object, thus n is low enough that
> we don't reach that point?
Yeah.

> w/o alignment knowledge problematic cases would include p == q + 1
> to p == q + 15, but that would still be no problem I think, the
> same wrapping argument can be used to simplify the
> p == q + 15 compare to p - (q + 4) <= 11?  What was the reason
> to not do p - q <= 15 (or 12)?
p - q <= 15 would include p == q, but we should use the vector loop for that.

FWIW, the current condition for unaligned pointers is:

  _46 = q_11(D) + 4;
  _15 = p_12(D) - _46;
  _54 = (sizetype) _15;
  _32 = _54 + 3;
  if (_32 > 14)
goto ; [89.44%]
  else
goto ; [10.56%]

[https://godbolt.org/z/6ra5o4Wj9] but the forthcoming patch will make it:

  _46 = (sizetype) p_12(D);
  _15 = (sizetype) q_11(D);
  _34 = _46 + 18446744073709551615;
  _35 = _34 - _15;
  if (_35 > 14)
goto ; [89.44%]
  else
goto ; [10.56%]

[Bug target/119596] x86: too eager use of rep movsq/rep stosq for inlined ops

[mjguzik at gmail dot com via Gcc-bugs]

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

--- Comment #21 from Mateusz Guzik  ---
Given the issues outline in 119703 and 119704 I decided to microbench 2 older 
uarchs with select sizes. Note a better quality test which does not merely
microbenchmark memset or memcpy is above for one reasonably recent AMD and one
reasonably recent Intel uarch.

I found that rep stosq is still highly penalized on both variants, while rep
movsq suffers less on AMD but it is still faster to use regular stores at least
up to 256 bytes. I fully concede it may happen to be that on a very new AMD
arch this equation changes, but that's not true on Intel (new or old).

Borrowing from contrib/bench-stringop I'm rolling over a 16M buffer.

memcpy 256 bytes:

AMD Ryzen Threadripper 2990WX

testcase:256_rep8
min:27762317 max:27762317 total:27762317
min:27739493 max:27739493 total:27739493
min:27727869 max:27727869 total:27727869

testcase:256_unrolled
min:28374940 max:28374940 total:28374940
min:28371060 max:28371060 total:28371060
min:28358297 max:28358297 total:28358297

Haswell:

testcase:256_rep8
min:14209786 max:14209786 total:14209786
min:14192041 max:14192041 total:14192041
min:14282288 max:14282288 total:14282288

testcase:256_unrolled
min:57857624 max:57857624 total:57857624
min:58826876 max:58826876 total:58826876
min:57539739 max:57539739 total:57539739

==

memset 256 bytes:

AMD Ryzen Threadripper 2990WX

testcase:256_rep8
min:32776195 max:32776195 total:32776195
min:32784246 max:32784246 total:32784246
min:32838932 max:32838932 total:32838932

testcase:256_unrolled
min:34131140 max:34131140 total:34131140
min:34088875 max:34088875 total:34088875
min:34076293 max:34076293 total:34076293

Haswell:

testcase:256_rep8
min:24953563 max:24953563 total:24953563
min:24905210 max:24905210 total:24905210
min:24877085 max:24877085 total:24877085

testcase:256_unrolled
min:58712755 max:58712755 total:58712755
min:58853415 max:58853415 total:58853415
min:58626856 max:58626856 total:58626856

==

memset 56 bytes:

AMD Ryzen Threadripper 2990WX

testcase:56_rep8
min:115632478 max:115632478 total:115632478
min:115848126 max:115848126 total:115848126
min:115762251 max:115762251 total:115762251

testcase:56_unrolled
min:152329392 max:152329392 total:152329392
min:152526437 max:152526437 total:152526437
min:152496941 max:152496941 total:152496941

Repro instructions:
https://people.freebsd.org/~mjg/.junk/will-it-scale.tgz

sh compile-copy-rolling.sh
sh compile-zero-rolling.sh

then e.g., ./copy_256_unrolled

I can't stress enough this is a little bit naive, but should be good enough
here. A non-naive test was done in previous comments where the kernel was
recompiled and the benchmark consisted on actually doing something.

I am not in position to do the same thing for these 2 older archs, hence the
other test.

Hopefully this is enough to augment the default for -mno-sse: don't rep for
sizes 256 or lower.

[Bug tree-optimization/119614] [15 regression] protobuf-29.4 fails to build with -O2 (error: cannot tail-call: call and return value are different)

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

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

--- Comment #24 from Sam James  ---
(In reply to Martin Jambor from comment #21)
> I'll look at implementing the required IPA-VR streaming for return values
> this Friday.

If this ends up being too difficult (or has too high risk of fallout), is it an
option to punt on ipa-vrp for musttail? It's pretty new anyway (only in 14 and
somewhat limited).

Though I guess we're not at that point yet anyway as we have some other P1s
left.

[Bug c++/119705] New: Massive memory use when building Flang (10GB+)

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

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

Bug ID: 119705
   Summary: Massive memory use when building Flang (10GB+)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: compile-time-hog, memory-hog
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: amonakov at gcc dot gnu.org, mgorny at gentoo dot org,
ppalka at gcc dot gnu.org
  Target Milestone: ---

Originally reported by Michał Górny downstream at
https://bugs.gentoo.org/953484: "As discussed on IRC, when compiling
llvm-core/flang, GCC may end up using ~10G for some files (effectively capping
the package at -j3 on systems with 32G RAM)" with GCC 14. Trunk doesn't fare
much better.


At r15-9352-g6284f555e877c7 with --enable-checking=release:
```
$ g++ -c DataSharingProcessor.cpp.ii -fsyntax-only

real0m46.318s
user0m42.178s
sys 0m3.983s
```

With that, perf report says:
```
   6.11%  cc1plus  cc1plus   [.] gt_ggc_mx_lang_tree_node
   5.51%  cc1plus  cc1plus   [.] ggc_set_mark
   3.07%  cc1plus  cc1plus   [.] find_substitution
   3.02%  cc1plus  cc1plus   [.] variably_modified_type_p
   2.16%  cc1plus  cc1plus   [.] ggc_internal_alloc_no_dtor
   2.06%  cc1plus  cc1plus   [.] hash_tree_cons
   1.98%  cc1plus  cc1plus   [.] walk_tree_1
   1.45%  cc1plus  cc1plus   [.] cp_fold
   1.33%  cc1plus  cc1plus   [.] tsubst
   0.86%  cc1plus  cc1plus   [.] add_candidates
   0.82%  cc1plus  cc1plus   [.] spec_hasher::equal
   0.76%  cc1plus  cc1plus   [.] cp_type_quals
   0.76%  cc1plus  cc1plus   [.] member_vec_binary_search
[...]
```

That find_substitution was mentioned by richi at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119387#c19.

With `-ftime-report -ftime-report-details -fsyntax-only`:
```
Time variable  wall   GGC
 phase setup:   0.00 (  0%)  1948k (  0%)
 phase parsing  :  15.20 ( 31%)  2436M ( 42%)
 phase lang. deferred   :  33.60 ( 69%)  3430M ( 58%)
 |name lookup   :   2.42 (  5%)   129M (  2%)
 |overload resolution   :  19.78 ( 41%)  2216M ( 38%)
 garbage collection :   6.51 ( 13%) 0  (  0%)
 preprocessing  :   0.20 (  0%)  3799k (  0%)
 parser (global):   0.97 (  2%)   164M (  3%)
 `- garbage collection  :   4.43 (  9%) 0  (  0%)
 `- parser struct body  :   0.01 (  0%)  1832k (  0%)
 `- template instantiation  :   7.29 ( 15%)   958M ( 16%)
 `- preprocessing   :   0.20 (  0%)  3799k (  0%)
 `- constant expression evaluation  :   0.01 (  0%)  1565k (  0%)
 `- parser function body:   0.05 (  0%)  4351k (  0%)
 `- parser inl. func. body  :   0.07 (  0%)14M (  0%)
 parser struct body :   1.76 (  4%)   342M (  6%)
 `- template instantiation  :   0.06 (  0%)  7177k (  0%)
 `- varconst:   0.01 (  0%) 0  (  0%)
 `- parser struct body  :   0.01 (  0%)  2315k (  0%)
 `- parser inl. meth. body  :   0.92 (  2%)   119M (  2%)
 `- constant expression evaluation  :   0.01 (  0%)  1434k (  0%)
 parser function body   :   0.10 (  0%)  8264k (  0%)
 parser inl. func. body :   0.15 (  0%)22M (  0%)
 `- template instantiation  :   0.01 (  0%)   587k (  0%)
 `- constant expression evaluation  :   0.02 (  0%)  2697k (  0%)
 parser inl. meth. body :   2.09 (  4%)   235M (  4%)
 `- template instantiation  :   0.08 (  0%)10M (  0%)
 `- garbage collection  :   2.08 (  4%) 0  (  0%)
 `- constant expression evaluation  :   0.05 (  0%)  4740k (  0%)
 template instantiation :  35.92 ( 74%)  5051M ( 86%)
 `- template instantiation  :   5.34 ( 11%)   715M ( 12%)
 `- constant expression evaluation  :   0.86 (  2%)21M (  0%)
 `- symout  :   0.02 (  0%) 0  (  0%)
 `- varconst:   0.02 (  0%) 0  (  0%)
 constant expression evaluation :   1.04 (  2%)36M (  1%)
 `- template instantiation  :   0.50 (  1%)58M (  1%)
 varconst   :   0.04 (  0%)82k (  0%)
 symout :   0.02 (  0%) 0  (  0%)
 TOTAL  :  48.81 5868M
```

[Bug c++/119705] Massive memory use when building Flang (10GB+)

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

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

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

[Bug c++/119705] Massive memory use when building Flang (10GB+)

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

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

--- Comment #2 from Sam James  ---
Patrick, would you be able to take a look with reducing it (or offer some
advice)? We've tried but it's challenging.

[Bug c++/119705] Massive memory use when building Flang (10GB+)

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

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

--- Comment #3 from Sam James  ---
(Clang fares far better on this, and takes > 50% less memory. I think it's far
quicker as well.)

[Bug target/119691] gcc does not build for powerpc64-apple-darwin9: ld: bl out of range (-16845644 max is +/-16M) from __ZN10hash_tableI19default_hash_traitsIP11cgraph_edgeELb0E11xcallocatorED1Ev at 0

[vital.had at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Sergey Fedorov  ---
(In reply to Iain Sandoe from comment #5)
> Lets take this discussion elsewhere - e.g. to my Darwin toolchains - there
> is no upstream solution to this on any of the components (cctools, ld64,
> gcc, llvm).

Fair enough, opened an issue here first (re general approach):
https://github.com/iains/gcc-14-branch/issues/20

[Bug debug/119711] dw_attr_struct and dw_loc_descr_node are wasteful with padding

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Created attachment 61064
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61064&action=edit
gcc15-pr119711.patch

Untested fix.

[Bug fortran/119669] [15 Regression] ICE in compare_parameter since r15-7449

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #1 from anlauf at gcc dot gnu.org ---
I cannot reproduce this at r15-9359.  Does it still fail for you?

(There have been fixes for e.g. pr118884 and pr118845 which might have
covered this one, too.)

[Bug rtl-optimization/60749] combine is overly cautious when operating on volatile memory references

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||bigmagicreadsun at gmail dot 
com

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

[Bug rtl-optimization/119709] RISC-V: Why volatile int16_t variables generate extra shift instructions in compiler output

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

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

--- Comment #2 from Andrew Pinski  ---
I should mention this is a known issue and not one easily solvable. bug 60749
describes the internals of GCC on what is going wrong which is why it might not
read as a duplicate.
But this is the jist:
In particular, if any narrow memory location is read (...), the zero/sign
extension can't be combined.

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

[makovick at gmail dot com via Gcc-bugs]

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

Bug ID: 119714
   Summary: Failure when using == operator on a class derived from
std::expected
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: makovick at gmail dot com
  Target Milestone: ---

Created attachment 61065
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61065&action=edit
Minimal example

Latest libcxx in GCC 15 master fails to compile when using an equality operator
on a class derived from std::expected.

The convertible_to requirement at include/c++/expected:1174 seems to be
the culprit.

We actually use custom equality (and spaceship) operators for the derived
class, but this does not seem to make a difference regarding this error.

A simple test case is attached.

GCC 15 output:

/usr/lib/gcc/x86_64-conda-linux-gnu/15.0.1/include/c++/expected: In
substitution of 'template  requires !(__is_expected<_Up>) &&
requires(const _Tp& __t, const _Up& __u) {{__t == __u} -> decltype(auto)
[requires std::convertible_to<, bool>];} constexpr bool
std::operator==(const expected >&, const _Up&)
[with _Up = int]':
/usr/lib/gcc/x86_64-conda-linux-gnu/15.0.1/include/c++/expected:1175:12:  
required by substitution of 'template  requires
!(__is_expected<_Up>) && requires(const _Tp& __t, const _Up& __u) {{__t == __u}
-> decltype(auto) [requires std::convertible_to<, bool>];}
constexpr bool std::operator==(const expected
>&, const _Up&) [with _Up = int]'
 1175 | { __t == __u } -> convertible_to;
  |   ^~
test.cc:15:22:   required from here
   15 |   std::cerr << (e == 10) << std::endl;
  |  ^~
/usr/lib/gcc/x86_64-conda-linux-gnu/15.0.1/include/c++/expected:1178:2:  
required by the constraints of 'template template  requires !(__is_expected<_Up>) && requires(const _Tp& __t, const _Up&
__u) {{__t == __u} -> decltype(auto) [requires
std::convertible_to<, bool>];} constexpr bool
std::operator==(const expected<_Tp, _Er>&, const _Up&)'
/usr/lib/gcc/x86_64-conda-linux-gnu/15.0.1/include/c++/expected:1174:7:   in
requirements with 'const _Tp& __t', 'const _Up& __u' [with _Tp = int; _Up =
Expected,
std::allocator > >]
/usr/lib/gcc/x86_64-conda-linux-gnu/15.0.1/include/c++/expected:1174:14: error:
satisfaction of atomic constraint 'requires(const _Tp& __t, const _Up& __u)
{{__t == __u} -> decltype(auto) [requires std::convertible_to<,
bool>];} [with _Tp = _Tp; _Up = _Up]' depends on itself
 1174 |   && requires (const _Tp& __t, const _Up& __u) {
  |  ^~~
 1175 | { __t == __u } -> convertible_to;
  | ~~~
 1176 |   }
  |   ~   
test.cc: In function 'int main()':
test.cc:15:22: warning: C++20 says that these are ambiguous, even though the
second is reversed:
   15 |   std::cerr << (e == 10) << std::endl;
  |  ^~
/usr/lib/gcc/x86_64-conda-linux-gnu/15.0.1/include/c++/expected:1178:9: note:
candidate 1: 'constexpr bool std::operator==(const expected<_Tp, _Er>&, const
_Up&) [with _Up = int; _Tp = int; _Er = __cxx11::basic_string]'
 1178 | operator==(const expected& __x, const _Up& __v)
  | ^~~~
/usr/lib/gcc/x86_64-conda-linux-gnu/15.0.1/include/c++/expected:1178:9: note:
candidate 2: 'constexpr bool std::operator==(const expected<_Tp, _Er>&, const
_Up&) [with _Up = Expected >; _Tp = int; _Er =
__cxx11::basic_string]' (reversed)

[Bug libstdc++/119708] : \00 should be rejected

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Hmm, PR 84110 seems the exact opposite here ...

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

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

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

--- Comment #1 from Andrew Pinski  ---
https://en.cppreference.com/w/cpp/utility/expected/operator_cmp

This mentions that it is invalid for C++23 but would be valid for C++26. Looks
like we have not implemented the 26 rules either.

[Bug c/119713] RISC-V: -march=rv64gcv gives an internal compiler error in a_as

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #1 from Sam James  ---
Dupe but I'm going to backport the fix on the Gentoo side in a minute.

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

[Bug fortran/119669] [15 Regression] ICE in compare_parameter since r15-7449

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

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

--- Comment #2 from Jakub Jelinek  ---
I can:
/opt/notnfs/gcc-bisect/obj/gcc/f951.r15-9357 -quiet pr119669.f90
f951.r15-9357: internal compiler error: in compare_parameter, at
fortran/interface.cc:2537
0x2d42e37 internal_error(char const*, ...)
../../gcc/diagnostic-global-context.cc:517
0x2d11f8d fancy_abort(char const*, int, char const*)
../../gcc/diagnostic.cc:1749
0x473ce0 compare_parameter
../../gcc/fortran/interface.cc:2537
0x476d0b gfc_compare_actual_formal(gfc_actual_arglist**, gfc_formal_arglist*,
int, int, bool, locus*)
../../gcc/fortran/interface.cc:3494
0x6a3a55 check_externals_procedure
../../gcc/fortran/frontend-passes.cc:5712
0x6a3c24 check_externals_code
../../gcc/fortran/frontend-passes.cc:5759
0x6a1a1a gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int
(*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.cc:5317
0x6a3f8e gfc_check_externals0
../../gcc/fortran/frontend-passes.cc:5840
0x6a4022 gfc_check_externals(gfc_namespace*)
../../gcc/fortran/frontend-passes.cc:5862
0x5054fa gfc_parse_file()
../../gcc/fortran/parse.cc:7660
0x572deb gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:241
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.

It is an assertion failure, so might not reproduce with --disable-checking.

[Bug fortran/119669] [15 Regression] ICE in compare_parameter since r15-7449

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

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

--- Comment #3 from Jakub Jelinek  ---
Note, removing the ! character makes it work.

[Bug debug/119711] dw_attr_struct and dw_loc_descr_node are wasteful with padding

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
.

[Bug rtl-optimization/119672] [15 regression] RISC-V: ICE during RTL pass: cse1 in as_a, at machmode.h:391

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

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

Sam James  changed:

   What|Removed |Added

 CC||negge at dgql dot org

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

[Bug fortran/119669] [15 Regression] ICE in compare_parameter since r15-7449

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

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org

--- Comment #4 from Thomas Koenig  ---
Mine.

[Bug c/119713] New: RISC-V: -march=rv64gcv gives an internal compiler error in a_as

[negge at dgql dot org via Gcc-bugs]

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

Bug ID: 119713
   Summary: RISC-V: -march=rv64gcv gives an internal compiler
error in a_as
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: negge at dgql dot org
  Target Milestone: ---

Created attachment 61063
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61063&action=edit
min.c

Building kmod-33 with gcc-15.0.1_pre20250406 gives an internal compiler error.
I have attached a reduced input file min.c. Note, it compiles with
-march=rv64gc.

# riscv64-unknown-linux-gnu-gcc --version
riscv64-unknown-linux-gnu-gcc (Gentoo 15.0.1_pre20250406 p53) 15.0.1 20250406
(experimental)
Copyright (C) 2025 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

# riscv64-unknown-linux-gnu-gcc -O3 -march=rv64gcv -pipe /tmp/min.c -c -o
/dev/null
during RTL pass: cse1
/tmp/min.c: In function ‘array_append_unique’:
/tmp/min.c:45:1: internal compiler error: in as_a, at machmode.h:391
   45 | }
  | ^
0xc90bf153 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, std::__va_list*,
diagnostic_t)
???:0
0xc90d6d7f internal_error(char const*, ...)
???:0
0xc6ac4fe7 fancy_abort(char const*, int, char const*)
???:0
0xc72819fb wi::to_poly_wide(rtx_def const*, machine_mode)
???:0
0xc72ba5fb simplify_context::simplify_binary_operation_1(rtx_code,
machine_mode, rtx_def*, rtx_def*, rtx_def*, rtx_def*)
???:0
0xc72be683 simplify_context::simplify_binary_operation(rtx_code,
machine_mode, rtx_def*, rtx_def*)
???:0
0xc72c7c0f simplify_const_relational_operation(rtx_code, machine_mode,
rtx_def*, rtx_def*)
???:0
0xc72c1daf simplify_context::simplify_relational_operation(rtx_code,
machine_mode, machine_mode, rtx_def*, rtx_def*)
???:0
0xc72c0feb simplify_context::simplify_relational_operation_1(rtx_code,
machine_mode, machine_mode, rtx_def*, rtx_def*)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug debug/119711] dw_attr_struct and dw_loc_descr_node are wasteful with padding

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

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

--- Comment #2 from Andrew Pinski  ---
dw_discr_value has a similar issue too.

I wonder if dw_loc_descr_node fields (dw_loc_oprnd1 dw_loc_oprnd2) could use
the no_unique_address attribute? Since there is some padding inbetween them
too.

[Bug fortran/119669] [15 Regression] ICE in compare_parameter since r15-7449

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org
 Status|ASSIGNED|NEW

--- Comment #5 from anlauf at gcc dot gnu.org ---
OK, pilot error on my side.  I now see it too.

We have:

  gcc_assert (formal->attr.function);

(gdb) p formal->attr.subroutine
$3 = 0
(gdb) p formal->attr.function
$4 = 0

Not good.