[Bug target/79213] FAIL: gcc.target/aarch64/ldp_vec_64_1.c scan-assembler ldp\td[0-9]+, d[0-9]

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||xfail
 CC||pinskia at gcc dot gnu.org
  Component|testsuite   |target

--- Comment #1 from Andrew Pinski  ---
The testcase was xfailed at r7-6341-ge39dd8029d9d18 . And is still xfailed.

[Bug tree-optimization/111407] [11/12/13 Regression] ICE: SSA corruption due to widening_mul opt on conflict across an abnormal edge

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

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

--- Comment #12 from Andrew Pinski  ---
(In reply to qinzhao from comment #10)
> (In reply to Andrew Pinski from comment #6)
> the fix has been in GCC14, shall we backport the patch to previous releases?

Since it is a regression, yes please.

[Bug tree-optimization/111407] [11/12/13 Regression] ICE: SSA corruption due to widening_mul opt on conflict across an abnormal edge

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|aarch64-linux-gnu   |aarch64-linux-gnu
   ||mips64-linux-gnu
   Target Milestone|--- |11.5
  Known to work||14.0, 6.4.0
Summary|ICE: SSA corruption due to  |[11/12/13 Regression] ICE:
   |widening_mul opt on |SSA corruption due to
   |conflict across an abnormal |widening_mul opt on
   |edge|conflict across an abnormal
   ||edge

--- Comment #11 from Andrew Pinski  ---
For aarch64, this has worked in GCC 6.4.0.

s/long/long long/ it also fails for arm starting in GCC 7.x. Likewise for
mips64 and mips.

[Bug target/98877] [AArch64] Inefficient code generated for tbl NEON intrinsics

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

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

--- Comment #12 from Tamar Christina  ---
and it's not the first time we have conditional lowering. We already do so for
e.g. shifts, where shifting by an amount => bitsize of a vector element is
defined behavior or AArch64.

[Bug target/98877] [AArch64] Inefficient code generated for tbl NEON intrinsics

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

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

--- Comment #11 from Tamar Christina  ---
(In reply to Andrew Pinski from comment #10)
> (In reply to Tamar Christina from comment #9)
> > While RA should be able to deal with this,
> > shouldn't we also just lower TBLs in gimple?
> > 
> > This no reason why this can't be a VEC_PERM_EXPR which would also get the
> > copies
> > removed at the gimple level and allows us to optimize this to something else
> > depending on the index.
> 
> Yes there is a reason, `out of range` values for VEC_PERM is undefined while
> tbl is well defined  ( If an index is out of range for the table, the result
> for that lookup is 0.).
> 

I don't think that's not a good reason. The out of range values can be made
implementation defined. i.e. mid-end shouldn't care about them.

not lowering this in gimple means we lose a heck of a lot of optimizations that
are impossible to cover in RTL.

[Bug tree-optimization/114151] [14 Regression] weird and inefficient codegen and addressing modes since g:a0b1798042d033fd2cc2c806afbb77875dd2909b

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #4 from rguenther at suse dot de  ---
On Wed, 28 Feb 2024, tnfchris at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
> 
> --- Comment #3 from Tamar Christina  ---
> > 
> > This was a correctness fix btw, so I'm not sure we can easily recover - we
> > could try using niter information for CHREC_VARIABLE but then there's
> > variable niter here so I don't see a chance.
> > 
> 
> It looks like it's mostly SVE suffering here. Adv. SIMD an scalar codegen 
> seems
> to have vastly improved with it. we see ~10% improvements due to better
> addressing for scalar.
> 
> It also only happens at -O3 but -O2 is fine, which is weird as I was expected
> IVopts to be enabled at -O2 too.

Note the underlying issue, analyzing { a, +, b } * c differently and
thus eventually dependent CHRECs failing to analyze should be independent
on the architecture.

What was definitely missing is consideration of POLY_INT_CSTs (and
variable polys, as I think there's no range info for those).

We do eventually want to improve how ranger behaves here.  I'm not sure
why when we do not provide a context 'stmt' it can't see to compute
a range valid at the SSA names point of definition?  (so basically
compute the global range)

Maybe there's another API to do that.  But I thought it was convenient
to use range_of_expr as that also handles GENERIC expression trees
to some extent and those are common within SCEV.

[Bug target/108174] ICE: tree check: expected function_type or method_type, have ggc_freed in aarch64_resolve_overloaded_memtag, at config/aarch64/aarch64-builtins.cc:3349

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #13 from Andrew Pinski  ---
Fixed for 13.3.0 and 14.1.0.

[Bug target/108174] ICE: tree check: expected function_type or method_type, have ggc_freed in aarch64_resolve_overloaded_memtag, at config/aarch64/aarch64-builtins.cc:3349

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

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

--- Comment #12 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Andrew Pinski
:

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

commit r13-8369-gdf00dc3f38749cf2e3ca39632f97c1ff5d50d810
Author: Andrew Pinski 
Date:   Wed Feb 28 22:39:32 2024 -0800

aarch64: Fix memtag builtins vs GC [PR108174]

The memtag builtins were being GC'ed away so we end up
with a crash sometimes (maybe even wrong code).
This fixes that issue by adding GTY on the variable/struct
aarch64_memtag_builtin_data.

Committed as obvious after a build/test for aarch64-linux-gnu.

PR target/108174

gcc/ChangeLog:

* config/aarch64/aarch64-builtins.cc (aarch64_memtag_builtin_data):
Make
static and mark with GTY.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/acle/memtag_4.c: New test.

Signed-off-by: Andrew Pinski 
(cherry picked from commit 5ec7740496a6908b32cd058c0520a2bd5a689bb5)

[Bug target/108174] ICE: tree check: expected function_type or method_type, have ggc_freed in aarch64_resolve_overloaded_memtag, at config/aarch64/aarch64-builtins.cc:3349

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

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

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

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

commit r14-9235-g5ec7740496a6908b32cd058c0520a2bd5a689bb5
Author: Andrew Pinski 
Date:   Wed Feb 28 22:39:32 2024 -0800

aarch64: Fix memtag builtins vs GC [PR108174]

The memtag builtins were being GC'ed away so we end up
with a crash sometimes (maybe even wrong code).
This fixes that issue by adding GTY on the variable/struct
aarch64_memtag_builtin_data.

Committed as obvious after a build/test for aarch64-linux-gnu.

PR target/108174

gcc/ChangeLog:

* config/aarch64/aarch64-builtins.cc (aarch64_memtag_builtin_data):
Make
static and mark with GTY.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/acle/memtag_4.c: New test.

Signed-off-by: Andrew Pinski 

[Bug target/108174] ICE: tree check: expected function_type or method_type, have ggc_freed in aarch64_resolve_overloaded_memtag, at config/aarch64/aarch64-builtins.cc:3349

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

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

--- Comment #10 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #9)
> (In reply to Andrew Pinski from comment #8)
> > It should also be static too.
> 
> Well the struct is anonymous so it will be static linkage by C++ rules.

But that static is needed for GTY marking :).

So the fix is:
```
diff --git a/gcc/config/aarch64/aarch64-builtins.cc
b/gcc/config/aarch64/aarch64-builtins.cc
index 9b23b6b8c33..2bead96cbd6 100644
--- a/gcc/config/aarch64/aarch64-builtins.cc
+++ b/gcc/config/aarch64/aarch64-builtins.cc
@@ -1839,7 +1839,7 @@ aarch64_init_prefetch_builtin (void)
 }

 /* Initialize the memory tagging extension (MTE) builtins.  */
-struct
+static GTY(()) struct GTY(())
 {
   tree ftype;
   enum insn_code icode;

```

Will commit in a few minutes.

[Bug target/108174] ICE: tree check: expected function_type or method_type, have ggc_freed in aarch64_resolve_overloaded_memtag, at config/aarch64/aarch64-builtins.cc:3349

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

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

--- Comment #9 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #8)
> It should also be static too.

Well the struct is anonymous so it will be static linkage by C++ rules.

[Bug target/114160] New: ICE in dwarf2out_frame_debug_cfa_offset RISCV thead-c906

[nop at unearthly dot dev via Gcc-bugs]

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

Bug ID: 114160
   Summary: ICE in dwarf2out_frame_debug_cfa_offset RISCV
thead-c906
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nop at unearthly dot dev
  Target Milestone: ---

Created attachment 57573
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57573=edit
cvise produced reproduction case

Taking out -O2, -mcpu, or -fPIC out resolves the issue. Additionally, this
doesn't happen on -mtune=thead-c906

This does not happen on gcc 14

mu-loong ~ # gcc -v -O2 -mcpu=thead-c906 -fPIC GBZ.c
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/riscv64-unknown-linux-gnu/13/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/gcc-13-20240210/configure
--host=riscv64-unknown-linux-gnu --build=riscv64-unknown-linux-gnu
--prefix=/usr --bindir=/usr/riscv64-unknown-linux-gnu/gcc-bin/13
--includedir=/usr/lib/gcc/riscv64-unknown-linux-gnu/13/include
--datadir=/usr/share/gcc-data/riscv64-unknown-linux-gnu/13
--mandir=/usr/share/gcc-data/riscv64-unknown-linux-gnu/13/man
--infodir=/usr/share/gcc-data/riscv64-unknown-linux-gnu/13/info
--with-gxx-include-dir=/usr/lib/gcc/riscv64-unknown-linux-gnu/13/include/g++-v13
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/riscv64-unknown-linux-gnu/13/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo
13.2.1_p20240210 p13' --with-gcc-major-version-only --enable-libstdcxx-time
--enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --disable-multilib
--disable-fixed-point --with-abi=lp64d --disable-libgomp --disable-libssp
--disable-libada --disable-cet --disable-systemtap
--disable-valgrind-annotations --disable-vtable-verify --disable-libvtv
--with-zstd --without-isl --enable-default-pie --enable-default-ssp
--disable-fixincludes
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.1 20240210 (Gentoo 13.2.1_p20240210 p13)
COLLECT_GCC_OPTIONS='-v' '-O2' '-mcpu=thead-c906' '-fPIC'
'-march=rv64imafdc_zicsr_xtheadba_xtheadbb_xtheadbs_xtheadcmo_xtheadcondmov_xtheadfmemidx_xtheadmac_xtheadmemidx_xtheadmempair_xtheadsync'
'-mabi=lp64d' '-misa-spec=20191213'
'-march=rv64imafdc_zicsr_xtheadba_xtheadbb_xtheadbs_xtheadcmo_xtheadcondmov_xtheadfmemidx_xtheadmac_xtheadmemidx_xtheadmempair_xtheadsync'
'-dumpdir' 'a-'
 /usr/libexec/gcc/riscv64-unknown-linux-gnu/13/cc1 -quiet -v -imultilib . GBZ.c
-quiet -dumpdir a- -dumpbase GBZ.c -dumpbase-ext .c -mcpu=thead-c906
-march=rv64imafdc_zicsr_xtheadba_xtheadbb_xtheadbs_xtheadcmo_xtheadcondmov_xtheadfmemidx_xtheadmac_xtheadmemidx_xtheadmempair_xtheadsync
-mabi=lp64d -misa-spec=20191213
-march=rv64imafdc_zicsr_xtheadba_xtheadbb_xtheadbs_xtheadcmo_xtheadcondmov_xtheadfmemidx_xtheadmac_xtheadmemidx_xtheadmempair_xtheadsync
-O2 -version -fPIC -o /tmp/cczMFA4n.s
GNU C17 (Gentoo 13.2.1_p20240210 p13) version 13.2.1 20240210
(riscv64-unknown-linux-gnu)
   compiled by GNU C version 13.2.1 20240210, GMP version
6.3.0, MPFR version 4.2.1, MPC version 1.3.1, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/riscv64-unknown-linux-gnu/13/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/riscv64-unknown-linux-gnu/13/../../../../riscv64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/riscv64-unknown-linux-gnu/13/include
 /usr/include
End of search list.
Compiler executable checksum: e5bb685f082cf8fc728c5e3c357fe251
GBZ.c:9:1: warning: no semicolon at end of struct or union 
 9
| } __libc_message(char *fmt, ...) {
  | ^
during RTL pass: dwarf2
GBZ.c: In function ‘__libc_message’:
GBZ.c:19:1: internal compiler error: in dwarf2out_frame_debug_cfa_offset, at
dwarf2cfi.cc:1376 
19 | }
  | ^
0x40c4e9 dwarf2out_frame_debug_cfa_offset
   
/usr/src/debug/sys-devel/gcc-13.2.1_p20240210/gcc-13-20240210/gcc/dwarf2cfi.cc:1376
0x40c4e9 dwarf2out_frame_debug 
   

[Bug target/108174] ICE: tree check: expected function_type or method_type, have ggc_freed in aarch64_resolve_overloaded_memtag, at config/aarch64/aarch64-builtins.cc:3349

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

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

--- Comment #8 from Andrew Pinski  ---
It should also be static too.

[Bug target/108174] ICE: tree check: expected function_type or method_type, have ggc_freed in aarch64_resolve_overloaded_memtag, at config/aarch64/aarch64-builtins.cc:3349

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code,|ice-on-valid-code
   |needs-reduction |
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #7 from Andrew Pinski  ---
3705  tree inittype = aarch64_memtag_builtin_data[
3706fcode - AARCH64_MEMTAG_BUILTIN_START - 1].ftype;
3707  unsigned arg_num = list_length (TYPE_ARG_TYPES (inittype)) - 1;


/* Initialize the memory tagging extension (MTE) builtins.  */
struct
{
  tree ftype;
  enum insn_code icode;
} aarch64_memtag_builtin_data[AARCH64_MEMTAG_BUILTIN_END -
  AARCH64_MEMTAG_BUILTIN_START - 1];


Yes this is definitely missing a GTY on it ...

Mine.

[Bug target/108174] ICE: tree check: expected function_type or method_type, have ggc_freed in aarch64_resolve_overloaded_memtag, at config/aarch64/aarch64-builtins.cc:3349

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-02-29
 Status|UNCONFIRMED |NEW

--- Comment #6 from Andrew Pinski  ---
Reduced testcase:
```
void g(void)
{
  const char *c;
  __builtin_aarch64_memtag_inc_tag(c , 0 );
}
void h(void)
{
  const char *c;
  __builtin_aarch64_memtag_inc_tag( c,0);
}

```

Compile with `-march=armv9-a+memtag  --param ggc-min-expand=0 --param
ggc-min-heapsize=0`.

[Bug target/108174] ICE: tree check: expected function_type or method_type, have ggc_freed in aarch64_resolve_overloaded_memtag, at config/aarch64/aarch64-builtins.cc:3349

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||14.0

--- Comment #5 from Andrew Pinski  ---
This still fails ...

[Bug target/98877] [AArch64] Inefficient code generated for tbl NEON intrinsics

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

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

--- Comment #10 from Andrew Pinski  ---
(In reply to Tamar Christina from comment #9)
> While RA should be able to deal with this,
> shouldn't we also just lower TBLs in gimple?
> 
> This no reason why this can't be a VEC_PERM_EXPR which would also get the
> copies
> removed at the gimple level and allows us to optimize this to something else
> depending on the index.

Yes there is a reason, `out of range` values for VEC_PERM is undefined while
tbl is well defined  ( If an index is out of range for the table, the result
for that lookup is 0.).

For tbx, it is well defined also (If an index is out of range for the table,
the existing value in the vector element of the destination register is left
unchanged. ).

I think for VECTOR_CST we can fold it down to VEC_PERM_EXPR if there is no out
of bounds value though.

[Bug rtl-optimization/96338] [SVE] Unnecessary register saves in exception handler

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-02-29
 Ever confirmed|0   |1

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

[Bug target/96373] [11 Regression] SVE miscompilation on vectorized division loop, leading to FP exception

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||kawakami.k at fujitsu dot com

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

[Bug target/105922] autovectorizer does not handle fp exceptions correctly for SVE

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Andrew Pinski  ---
Dup of bug 96373.

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

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

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

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

Bug 111710 Summary: [modules] ICE when compiling module where a lambda is 
assigned to a field in an exported class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111710

   What|Removed |Added

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

[Bug c++/111710] [modules] ICE when compiling module where a lambda is assigned to a field in an exported class

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

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

Nathaniel Shead  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 Resolution|--- |FIXED
 CC||nshead at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |nshead at gcc dot 
gnu.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Nathaniel Shead  ---
Fixed.

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

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

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

Bug 107398 Summary: ICE in maybe_key_decl, at cp/module.cc:18834
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107398

   What|Removed |Added

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

[Bug c++/107398] ICE in maybe_key_decl, at cp/module.cc:18834

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

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

Nathaniel Shead  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Assignee|unassigned at gcc dot gnu.org  |nshead at gcc dot 
gnu.org
   Target Milestone|--- |14.0
 CC||nshead at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Nathaniel Shead  ---
Fixed for GCC 14.

[Bug c++/111710] [modules] ICE when compiling module where a lambda is assigned to a field in an exported class

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Nathaniel Shead :

https://gcc.gnu.org/g:3685fae23bb00898749dfc155212c9c5cd3a0980

commit r14-9232-g3685fae23bb00898749dfc155212c9c5cd3a0980
Author: Nathaniel Shead 
Date:   Fri Feb 16 15:52:48 2024 +1100

c++: Support lambdas attached to more places in modules [PR111710]

The fix for PR107398 weakened the restrictions that lambdas must belong
to namespace scope. However this was not sufficient: we also need to
allow lambdas attached to FIELD_DECLs, PARM_DECLs, and TYPE_DECLs.

For field decls we key the lambda to its class rather than the field
itself. Otherwise we can run into issues when deduplicating the lambda's
TYPE_DECL, because when loading its context we load the containing field
before we've deduplicated the keyed lambda, causing mismatches; by
keying to the class instead we defer checking keyed declarations until
deduplication has completed.

Additionally, by [basic.link] p15.2 a lambda defined anywhere in a
class-specifier should not be TU-local, which includes base-class
declarations, so ensure that lambdas declared there are keyed
appropriately as well.

Because this now requires 'DECL_MODULE_KEYED_DECLS_P' to be checked on a
fairly large number of different kinds of DECLs, and that in general
it's safe to just get 'false' as a result of a check on an unexpected
DECL type, this patch also removes the tree checking from the accessor.

Finally, to handle deduplicating templated lambda fields, we need to
ensure that we can determine that two lambdas from different field decls
match, so we ensure that we also deduplicate LAMBDA_EXPRs on stream in.

PR c++/111710

gcc/cp/ChangeLog:

* cp-tree.h (DECL_MODULE_KEYED_DECLS_P): Remove tree checking.
(struct lang_decl_base): Update comments and fix whitespace.
* module.cc (trees_out::lang_decl_bools): Always write
module_keyed_decls_p flag...
(trees_in::lang_decl_bools): ...and always read it.
(trees_out::decl_value): Handle all kinds of keyed decls.
(trees_in::decl_value): Likewise.
(trees_in::tree_value): Deduplicate LAMBDA_EXPRs.
(maybe_key_decl): Also support lambdas attached to fields,
parameters, and types. Key lambdas attached to fields to their
class.
(trees_out::get_merge_kind): Likewise.
(trees_out::key_mergeable): Likewise.
(trees_in::key_mergeable): Support keyed decls in a TYPE_DECL
container.
* parser.cc (cp_parser_class_head): Start a lambda scope when
parsing base classes.

gcc/testsuite/ChangeLog:

* g++.dg/modules/lambda-7.h: New test.
* g++.dg/modules/lambda-7_a.H: New test.
* g++.dg/modules/lambda-7_b.C: New test.
* g++.dg/modules/lambda-7_c.C: New test.

Signed-off-by: Nathaniel Shead 
Reviewed-by: Patrick Palka 
Reviewed-by: Jason Merrill 

[Bug target/114130] [11/12/13/14 Regression] RISC-V: `__atomic_compare_exchange` does not use sign-extended value for RV64

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Kito Cheng :

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

commit r14-9231-gfd07a29e39f5347d6cef3e7042a32306f97a1719
Author: Kito Cheng 
Date:   Wed Feb 28 16:01:52 2024 +0800

RISC-V: Fix __atomic_compare_exchange with 32 bit value on RV64

atomic_compare_and_swapsi will use lr.w to do obtain the original value,
which sign extends to DI.  RV64 only has DI comparisons, so we also need
to sign extend the expected value to DI as otherwise the comparison will
fail when the expected value has the 32nd bit set.

gcc/ChangeLog:

PR target/114130
* config/riscv/sync.md (atomic_compare_and_swap): Sign
extend the expected value if needed.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/pr114130.c: New.

Reviewed-by: Palmer Dabbelt 

[Bug fortran/86148] parameterized type compile time error

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Alexander Westbrooks alexanderw
:

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

commit r14-9229-gedfe198084338691d0facc86bf8dfa6ede3ca676
Author: Alexander Westbrooks 
Date:   Wed Feb 28 20:03:46 2024 -0600

Fortran - Error compiling PDT Type-bound Procedures [PR82943/86148/86268]

This patch allows parameterized derived types to compile successfully
when typebound procedures are specified in the type specification.
Furthermore, it allows function calls for PDTs by setting the
f2k_derived space of PDT instances to reference their original template,
thereby giving it referential access to the typebound procedures of the
template. Lastly, it adds a check for deferred length parameters of
PDTs in CLASS declaration statements, and correctly throws an error if
such declarations are missing POINTER or ALLOCATABLE attributes.

2024-02-25  Alexander Westbrooks  

gcc/fortran/ChangeLog:
PR fortran/82943
PR fortran/86148
PR fortran/86268
* decl.cc (gfc_get_pdt_instance): Set the PDT instance field
'f2k_derived', if not set already, to point to the given
PDT template 'f2k_derived' namespace in order to give the
PDT instance referential access to the typebound procedures
of the template.
* gfortran.h (gfc_pdt_is_instance_of): Add prototype.
* resolve.cc (resolve_typebound_procedure): If the derived type
does not have the attribute 'pdt_template' set, compare the
dummy argument to the 'resolve_bindings_derived' type like usual.
If the derived type is a 'pdt_template', then check if the
dummy argument is an instance of the PDT template. If the derived
type is a PDT template, and the dummy argument is an instance of
that template, but the dummy argument 'param_list' is not
SPEC_ASSUMED, check if there are any LEN parameters in the
dummy argument. If there are no LEN parameters, then this implies
that there are only KIND parameters in the dummy argument.
If there are LEN parameters, this would be an error, for all
LEN parameters for the dummy argument MUST be assumed for
typebound procedures of PDTs.
(resolve_pdt): Add a check for ALLOCATABLE and POINTER attributes
for
SPEC_DEFERRED parameters of PDT class symbols.  ALLOCATABLE and
POINTER attributes for a PDT class symbol are stored in the
'class_pointer' and 'allocatable' attributes of the '_data'
component respectively.
* symbol.cc (gfc_pdt_is_instance_of): New function.

gcc/testsuite/ChangeLog:
PR fortran/82943
PR fortran/86148
PR fortran/86268
* gfortran.dg/pdt_4.f03: Update modified error message.
* gfortran.dg/pdt_34.f03: New test.
* gfortran.dg/pdt_35.f03: New test.
* gfortran.dg/pdt_36.f03: New test.
* gfortran.dg/pdt_37.f03: New test.

Signed-off-by: Alexander Westbrooks 

[Bug fortran/82943] [F03] Error with type-bound procedure of parametrized derived type

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

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

--- Comment #18 from GCC Commits  ---
The master branch has been updated by Alexander Westbrooks alexanderw
:

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

commit r14-9229-gedfe198084338691d0facc86bf8dfa6ede3ca676
Author: Alexander Westbrooks 
Date:   Wed Feb 28 20:03:46 2024 -0600

Fortran - Error compiling PDT Type-bound Procedures [PR82943/86148/86268]

This patch allows parameterized derived types to compile successfully
when typebound procedures are specified in the type specification.
Furthermore, it allows function calls for PDTs by setting the
f2k_derived space of PDT instances to reference their original template,
thereby giving it referential access to the typebound procedures of the
template. Lastly, it adds a check for deferred length parameters of
PDTs in CLASS declaration statements, and correctly throws an error if
such declarations are missing POINTER or ALLOCATABLE attributes.

2024-02-25  Alexander Westbrooks  

gcc/fortran/ChangeLog:
PR fortran/82943
PR fortran/86148
PR fortran/86268
* decl.cc (gfc_get_pdt_instance): Set the PDT instance field
'f2k_derived', if not set already, to point to the given
PDT template 'f2k_derived' namespace in order to give the
PDT instance referential access to the typebound procedures
of the template.
* gfortran.h (gfc_pdt_is_instance_of): Add prototype.
* resolve.cc (resolve_typebound_procedure): If the derived type
does not have the attribute 'pdt_template' set, compare the
dummy argument to the 'resolve_bindings_derived' type like usual.
If the derived type is a 'pdt_template', then check if the
dummy argument is an instance of the PDT template. If the derived
type is a PDT template, and the dummy argument is an instance of
that template, but the dummy argument 'param_list' is not
SPEC_ASSUMED, check if there are any LEN parameters in the
dummy argument. If there are no LEN parameters, then this implies
that there are only KIND parameters in the dummy argument.
If there are LEN parameters, this would be an error, for all
LEN parameters for the dummy argument MUST be assumed for
typebound procedures of PDTs.
(resolve_pdt): Add a check for ALLOCATABLE and POINTER attributes
for
SPEC_DEFERRED parameters of PDT class symbols.  ALLOCATABLE and
POINTER attributes for a PDT class symbol are stored in the
'class_pointer' and 'allocatable' attributes of the '_data'
component respectively.
* symbol.cc (gfc_pdt_is_instance_of): New function.

gcc/testsuite/ChangeLog:
PR fortran/82943
PR fortran/86148
PR fortran/86268
* gfortran.dg/pdt_4.f03: Update modified error message.
* gfortran.dg/pdt_34.f03: New test.
* gfortran.dg/pdt_35.f03: New test.
* gfortran.dg/pdt_36.f03: New test.
* gfortran.dg/pdt_37.f03: New test.

Signed-off-by: Alexander Westbrooks 

[Bug fortran/86268] [9.0] Error on correct code with PDTs

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Alexander Westbrooks alexanderw
:

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

commit r14-9229-gedfe198084338691d0facc86bf8dfa6ede3ca676
Author: Alexander Westbrooks 
Date:   Wed Feb 28 20:03:46 2024 -0600

Fortran - Error compiling PDT Type-bound Procedures [PR82943/86148/86268]

This patch allows parameterized derived types to compile successfully
when typebound procedures are specified in the type specification.
Furthermore, it allows function calls for PDTs by setting the
f2k_derived space of PDT instances to reference their original template,
thereby giving it referential access to the typebound procedures of the
template. Lastly, it adds a check for deferred length parameters of
PDTs in CLASS declaration statements, and correctly throws an error if
such declarations are missing POINTER or ALLOCATABLE attributes.

2024-02-25  Alexander Westbrooks  

gcc/fortran/ChangeLog:
PR fortran/82943
PR fortran/86148
PR fortran/86268
* decl.cc (gfc_get_pdt_instance): Set the PDT instance field
'f2k_derived', if not set already, to point to the given
PDT template 'f2k_derived' namespace in order to give the
PDT instance referential access to the typebound procedures
of the template.
* gfortran.h (gfc_pdt_is_instance_of): Add prototype.
* resolve.cc (resolve_typebound_procedure): If the derived type
does not have the attribute 'pdt_template' set, compare the
dummy argument to the 'resolve_bindings_derived' type like usual.
If the derived type is a 'pdt_template', then check if the
dummy argument is an instance of the PDT template. If the derived
type is a PDT template, and the dummy argument is an instance of
that template, but the dummy argument 'param_list' is not
SPEC_ASSUMED, check if there are any LEN parameters in the
dummy argument. If there are no LEN parameters, then this implies
that there are only KIND parameters in the dummy argument.
If there are LEN parameters, this would be an error, for all
LEN parameters for the dummy argument MUST be assumed for
typebound procedures of PDTs.
(resolve_pdt): Add a check for ALLOCATABLE and POINTER attributes
for
SPEC_DEFERRED parameters of PDT class symbols.  ALLOCATABLE and
POINTER attributes for a PDT class symbol are stored in the
'class_pointer' and 'allocatable' attributes of the '_data'
component respectively.
* symbol.cc (gfc_pdt_is_instance_of): New function.

gcc/testsuite/ChangeLog:
PR fortran/82943
PR fortran/86148
PR fortran/86268
* gfortran.dg/pdt_4.f03: Update modified error message.
* gfortran.dg/pdt_34.f03: New test.
* gfortran.dg/pdt_35.f03: New test.
* gfortran.dg/pdt_36.f03: New test.
* gfortran.dg/pdt_37.f03: New test.

Signed-off-by: Alexander Westbrooks 

[Bug target/114158] Wrong FDPIC special-casing in crtstuff produces invalid pointer in init_array

[bugdal at aerifal dot cx via Gcc-bugs]

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

--- Comment #5 from Rich Felker  ---
I don't know how I ended up copying the wrong commit id, but the one I meant to
reference was 9c560cf23996271ee26dfc4a1d8484b85173cd12.

Actually, I do know now. I got it out of the gitweb url which gratuitously ahs
the parent hash in a place where it's easy to accidentally copy instead of the
hash of the commit you're viewing (one of the many reasons I prefer cgit):

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9c560cf23996271ee26dfc4a1d8484b85173cd12;hp=6bcbf80c6e2bd8a60d88bbcac3d70ffb67f4888f

So indeed, the breakage was detected upstream and worked around, as I said.

[Bug tree-optimization/114121] wrong code with _BitInt() arithmetics at -O2

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug fortran/114141] ASSOCIATE and complex part ref when associate target is a function

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

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

--- Comment #9 from Jerry DeLisle  ---
--- snip ---
> % gfcx -o z a.f90
> a.f90:5:6:
> 
> 5 |   x%im = 42
>   |  1
> Error: 'x' at (1) associated to expression cannot be used in
> a variable definition context (assignment)
> 
> Mikael, thanks for the feedback.  I'll see if I can fix
> the parentheses case this weekend.

This is definitely a 42 case, which is why I had three '?' in my reply.

And if you understand this, you are OK in my book. :)

[Bug c++/113976] [11/12/13/14 Regression] explicit instantiation of const variable template following implicit instantiation is assembled in .rodata instead of .bss since r8-2857-g2ec399d8a6c9c2

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

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

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

https://gcc.gnu.org/g:29ac92436aa5c702e9e02c206e7590ebd806398e

commit r14-9227-g29ac92436aa5c702e9e02c206e7590ebd806398e
Author: Jakub Jelinek 
Date:   Wed Feb 28 23:20:13 2024 +0100

c++: Fix explicit instantiation of const variable templates after earlier
implicit instantation [PR113976]

Already previously instantiated const variable templates had
cp_apply_type_quals_to_decl called when they were instantiated,
but if they need runtime initialization, their TREE_READONLY flag
has been subsequently cleared.
Explicit variable template instantiation calls grokdeclarator which
calls cp_apply_type_quals_to_decl on them again, setting TREE_READONLY
flag again, but nothing clears it afterwards, so we emit such
instantiations into rodata sections and segfault when the dynamic
initialization attempts to initialize them.

The following patch fixes that by not calling cp_apply_type_quals_to_decl
on already instantiated variable declarations.

2024-02-28  Jakub Jelinek  
Patrick Palka  

PR c++/113976
* decl.cc (grokdeclarator): Don't call cp_apply_type_quals_to_decl
on DECL_TEMPLATE_INSTANTIATED VAR_DECLs.

* g++.dg/cpp1y/var-templ87.C: New test.

[Bug middle-end/94083] inefficient soft-float x!=Inf code

[harald at gigawatt dot nl via Gcc-bugs]

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

--- Comment #7 from Harald van Dijk  ---
(In reply to Joseph S. Myers from comment #6)
> Contrary to what was claimed in bug 66462, I don't think there ever was a
> fixed patch. Note that in bug 66462 comment 19, "June" is June 2017 but
> "November" is November 2016 - the "November" one is the *older* one.

Ah, sorry, I misunderstood the situation. According to
 the earlier
version of that patch (the November 2016 one) was the one that did not have the
problems that caused it to be reverted. In response to review of that, big
changes were requested and in the process bugs were introduced. The buggy
version was then committed and reverted. The original version that did not have
those bugs could still be committed if a re-review, taking into account the
bugs that the rework introduced, would now see it as acceptable.

[Bug target/114158] Wrong FDPIC special-casing in crtstuff produces invalid pointer in init_array

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

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

--- Comment #4 from jcmvbkbc at gcc dot gnu.org ---
> It seems to have been realized that this was not working, as
> 6bcbf80c6e2bd8a60d88bbcac3d70ffb67f4888f disabled initfini arrays on 
> ARM/FDPIC,
> but didn't identify the root cause.

I believe that 9c560cf23996271ee26dfc4a1d8484b85173cd12 was meant here.

[Bug libgcc/114158] Wrong FDPIC special-casing in crtstuff produces invalid pointer in init_array

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

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

jcmvbkbc at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jcmvbkbc at gcc dot gnu.org

--- Comment #3 from jcmvbkbc at gcc dot gnu.org ---
67b0605494f32811364e25328d3522467aaf0638 is my local fix to the change that was
introduced by the 5d727a4b20257275df59182b00f3bf240772cd0d. I believe that the
changes done in the latter commit to the libgcc/unwind-pe.h and
libstdc++-v3/libsupc++/eh_personality.cc need to be restricted to ARM only, if
needed at all. But that's separate from the crtstuff issue.

[Bug libgcc/114158] Wrong FDPIC special-casing in crtstuff produces invalid pointer in init_array

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> >6bcbf80c6e2bd8a60d88bbcac3d70ffb67f4888f
> 
> that seems unrelated "retain debug stmt order when moving to successors":
> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;
> h=6bcbf80c6e2bd8a60d88bbcac3d70ffb67f4888f

so I think you mean 67b0605494f32811364e25328d3522467aaf0638 but that never was
committed upstream, it is only in the https://github.com/jcmvbkbc/gcc-xtensa
git repo.

[Bug libgcc/114158] Wrong FDPIC special-casing in crtstuff produces invalid pointer in init_array

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

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

--- Comment #1 from Andrew Pinski  ---
>6bcbf80c6e2bd8a60d88bbcac3d70ffb67f4888f

that seems unrelated "retain debug stmt order when moving to successors":
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=6bcbf80c6e2bd8a60d88bbcac3d70ffb67f4888f

[Bug analyzer/114159] New: [13/14 Regression] ICE: in call_info, at analyzer/call-info.cc:143 with -fanalyzer -fanalyzer-call-summaries --param=analyzer-max-svalue-depth=0

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 114159
   Summary: [13/14 Regression] ICE: in call_info, at
analyzer/call-info.cc:143 with -fanalyzer
-fanalyzer-call-summaries
--param=analyzer-max-svalue-depth=0
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 57572
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57572=edit
auto-reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -fanalyzer -fanalyzer-call-summaries
--param=analyzer-max-svalue-depth=0 pr36690-2.i
during IPA pass: analyzer
pr36690-2.i: In function 'main':
pr36690-2.i:13:3: internal compiler error: in call_info, at
analyzer/call-info.cc:143
   13 |   foo();
  |   ^
0xdc029b ana::call_info::call_info(ana::call_details const&)
/repo/gcc-trunk/gcc/analyzer/call-info.cc:143
0xdc029b ana::call_info::call_info(ana::call_details const&)
/repo/gcc-trunk/gcc/analyzer/call-info.cc:139
0x190bf18 ana::call_summary_edge_info::call_summary_edge_info(ana::call_details
const&, function*, ana::call_summary*, ana::extrinsic_state const&)
/repo/gcc-trunk/gcc/analyzer/engine.cc:1619
0x190bf18 std::enable_if::value,
std::unique_ptr > >::type
make_unique(ana::call_details&,
function*&, ana::call_summary*&, ana::extrinsic_state const&)
/repo/gcc-trunk/gcc/make-unique.h:41
0x190bf18 ana::exploded_node::replay_call_summary(ana::exploded_graph&,
ana::supernode const*, gcall const*, ana::program_state*, ana::path_context*,
function*, ana::call_summary*, ana::region_model_context*)
/repo/gcc-trunk/gcc/analyzer/engine.cc:1734
0x190c0bd ana::exploded_node::replay_call_summaries(ana::exploded_graph&,
ana::supernode const*, gcall const*, ana::program_state*, ana::path_context*,
function*, ana::per_function_data*, ana::region_model_context*)
/repo/gcc-trunk/gcc/analyzer/engine.cc:1677
0x19119df ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode
const*, gimple const*, ana::program_state*, ana::uncertainty_t*, bool*,
ana::path_context*)
/repo/gcc-trunk/gcc/analyzer/engine.cc:1499
0x19143ba ana::exploded_graph::process_node(ana::exploded_node*)
/repo/gcc-trunk/gcc/analyzer/engine.cc:4124
0x191532a ana::exploded_graph::process_worklist()
/repo/gcc-trunk/gcc/analyzer/engine.cc:3515
0x1917a85 ana::impl_run_checkers(ana::logger*)
/repo/gcc-trunk/gcc/analyzer/engine.cc:6209
0x1918996 ana::run_checkers()
/repo/gcc-trunk/gcc/analyzer/engine.cc:6300
0x19075f8 execute
/repo/gcc-trunk/gcc/analyzer/analyzer-pass.cc:87
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


$ 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=/repo/gcc-trunk/binary-trunk-r14-9216-20240228150317-g5c01ede02a1-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.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
--disable-bootstrap --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-r14-9216-20240228150317-g5c01ede02a1-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240228 (experimental) (GCC)

[Bug fortran/114141] ASSOCIATE and complex part ref when associate target is a function

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #8 from Steve Kargl  ---
On Wed, Feb 28, 2024 at 08:24:16PM +, sgk at troutmask dot
apl.washington.edu wrote:
> 
> Indeed.  Bit more reading of F2023, 11.1.3 agrees with you.
> 
>11.1.3.1
> 
>The ASSOCIATE construct associates named entities with expressions
>or variables during the execution of its block.  These named construct
>entities (19.4) are associating entities (19.5.1.6).  The names are
>associate names.
> 
>11.1.3.3(5) The associating entity itself is a variable, but ...
> 
> The "but ..." applies to whether the selector is a definable variable.
> 
> So, 'y = x%im' is allowed, but 'x%im = 42' is disallowed because
> the selector is not definable.  Interesting twist.  This then 
> suggests that Jerry's use of parentheses should be accepted.
> 

As a quick follow-up.

program p
   associate(x => sin(cmplx(0.5,0.5)))
  print *, x
  print *, x%im  ! <-- allowed with my patch
  x%im = 42  ! <-- this is an error
  print *, x
   end associate
end

% gfcx -o z a.f90
a.f90:5:6:

5 |   x%im = 42
  |  1
Error: 'x' at (1) associated to expression cannot be used in
a variable definition context (assignment)

Mikael, thanks for the feedback.  I'll see if I can fix
the parentheses case this weekend.

[Bug libgcc/114158] New: Wrong FDPIC special-casing in crtstuff produces invalid pointer in init_array

[bugdal at aerifal dot cx via Gcc-bugs]

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

Bug ID: 114158
   Summary: Wrong FDPIC special-casing in crtstuff produces
invalid pointer in init_array
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugdal at aerifal dot cx
  Target Milestone: ---

Commit 11189793b6ef60645d5d1126d0bd9d0dd83e6583 introduced wrong special-casing
of FDPIC to __do_global_dtors_aux handling in crtstuff.c. For some reason, it
was assumed that, on FDPIC targets, init/fini arrays would contain instruction
addresses rather than function addresses (which are addresses of descriptors,
on FDPIC targets). This is NOT the case. The gABI contract of the init/fini
arrays is that they contain ABI-callable function pointers, and in fact GCC
correctly emits FUNCDESC-type relocations referencing then when translating
ctors/dtors, on ARM as well as sh.

It seems to have been realized that this was not working, as
6bcbf80c6e2bd8a60d88bbcac3d70ffb67f4888f disabled initfini arrays on ARM/FDPIC,
but didn't identify the root cause.

Commit 11189793b6ef60645d5d1126d0bd9d0dd83e6583 should be reverted ASAP, and
backported to all maintained versions, as it's actively breaking other targets
by putting an invalid function pointer in the init_array.

Commit 6bcbf80c6e2bd8a60d88bbcac3d70ffb67f4888f should also be reverted in
theory, but may need coordination with uclibc if they want to work around
binaries built with broken versions.

Further discussion of the issue can be found on the musl mailing list, in this
thread where myself and the author of the in-progress xtensa/fdpic port were
trying to figure out what's going on here:

https://www.openwall.com/lists/musl/2024/02/28/12

[Bug fortran/114141] ASSOCIATE and complex part ref when associate target is a function

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #7 from Steve Kargl  ---
On Wed, Feb 28, 2024 at 07:27:24PM +, mikael at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114141
> 
> --- Comment #6 from Mikael Morin  ---
> (In reply to kargl from comment #5)
> > (In reply to Mikael Morin from comment #4)
> > 
> > > (In reply to kargl from comment #3)
> > > > Yep, agreed.  I went back an re-read the section about ASSOCIATE.
> > > > Not sure how I convinced myself that a constant expression, which
> > > > reduces to a constant is okay.
> > > > 
> > > Not sure how you convinced yourself it isn't. ;-)
> > 
> > x => log(cmplx(-1,0))
> > 
> > R1104 association  is associate-name => selector
> > 
> > R1105 selector is expr
> >or variable
> > 
> > R902 variable  is designator
> >or function-reference
> > 
> > R901 designatoris object-name
> >or array-element
> >or array-section
> >or coindexed-named-object
> >or complex-part-designator
> >or structure-component
> >or substring
> > 
> > log(cmplx(-1,0)) is certainly not a designator.
> > 
> > log(cmplx(-1,0)) is a function-reference.  But this then
> > leads to
> > 
> > C902 (R902) function-reference shall have a data pointer result.
> > 
> > 
> > log(cmplx(-1,0)) violates C902, so this then means that it
> > must be an expr.
> Agreed.
> 
> >  One now needs
> > 
> > 
> > R915 complex-part-designator  is designator % RE
> >   or designator % IM
> > 
> > C922 (R915) The designator shall be of complex type.
> > 
> > which shows that expr%im is invalid; even though log(cmplx(-1,0))
> > reduces to a constant (i.e., it's not a named constant.  This
> > is likely the error [pun intended] in my ways.).
> > 
> This is about x%im, which is a different expression from log(cmplx(-1, 0)).
> x is an associate-name, and thus (I think) an object-name, and a valid
> designator, even if it's associated selector isn't.
> 

Indeed.  Bit more reading of F2023, 11.1.3 agrees with you.

   11.1.3.1

   The ASSOCIATE construct associates named entities with expressions
   or variables during the execution of its block.  These named construct
   entities (19.4) are associating entities (19.5.1.6).  The names are
   associate names.

   11.1.3.3(5) The associating entity itself is a variable, but ...

The "but ..." applies to whether the selector is a definable variable.

So, 'y = x%im' is allowed, but 'x%im = 42' is disallowed because
the selector is not definable.  Interesting twist.  This then 
suggests that Jerry's use of parentheses should be accepted.

[Bug fortran/111781] Fortran compiler complains about variable bound in array dummy argument

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

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

--- Comment #6 from Mikael Morin  ---
Created attachment 57571
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57571=edit
Tentative patch

(In reply to anlauf from comment #5)
> (In reply to anlauf from comment #4)
> > Thus I suggest to fix the testcase by one of the options suggested above.
> 
> Testcase gfortran.dg/pr101026.f is corrected at r14-9220.

Ah, yes, thanks.
I attach above the tentative patch that I tried before.
I need to reevaluate it; there were other regressions if I remember correctly.

[Bug fortran/114141] ASSOCIATE and complex part ref when associate target is a function

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

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

--- Comment #6 from Mikael Morin  ---
(In reply to kargl from comment #5)
> (In reply to Mikael Morin from comment #4)
> 
> > (In reply to kargl from comment #3)
> > > Yep, agreed.  I went back an re-read the section about ASSOCIATE.
> > > Not sure how I convinced myself that a constant expression, which
> > > reduces to a constant is okay.
> > > 
> > Not sure how you convinced yourself it isn't. ;-)
> 
> x => log(cmplx(-1,0))
> 
> R1104 association  is associate-name => selector
> 
> R1105 selector is expr
>or variable
> 
> R902 variable  is designator
>or function-reference
> 
> R901 designatoris object-name
>or array-element
>or array-section
>or coindexed-named-object
>or complex-part-designator
>or structure-component
>or substring
> 
> log(cmplx(-1,0)) is certainly not a designator.
> 
> log(cmplx(-1,0)) is a function-reference.  But this then
> leads to
> 
> C902 (R902) function-reference shall have a data pointer result.
> 
> 
> log(cmplx(-1,0)) violates C902, so this then means that it
> must be an expr.
Agreed.

>  One now needs
> 
> 
> R915 complex-part-designator  is designator % RE
>   or designator % IM
> 
> C922 (R915) The designator shall be of complex type.
> 
> which shows that expr%im is invalid; even though log(cmplx(-1,0))
> reduces to a constant (i.e., it's not a named constant.  This
> is likely the error [pun intended] in my ways.).
> 
This is about x%im, which is a different expression from log(cmplx(-1, 0)).
x is an associate-name, and thus (I think) an object-name, and a valid
designator, even if it's associated selector isn't.

[Bug target/113453] bpf: func_info and line_info missing in .BTF.ext

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Cupertino Miranda :

https://gcc.gnu.org/g:77142bdba485057550c5d849864948b0d20be8af

commit r14-9224-g77142bdba485057550c5d849864948b0d20be8af
Author: Cupertino Miranda 
Date:   Mon Feb 12 17:46:03 2024 +

bpf: implementation of func_info in .BTF.ext.

Kernel verifier complains in some particular cases for missing func_info
implementation in .BTF.ext. This patch implements it.

Strings are cached locally in coreout.cc to avoid adding duplicated
strings in the string list. This string deduplication should eventually
be moved to the CTFC functions such that this happens widely.

With this implementation, the CO-RE relocations information was also
simplified and integrated with the FuncInfo structures.

gcc/Changelog:

PR target/113453
* config/bpf/bpf.cc (bpf_function_prologue): Define target
hook.
* config/bpf/coreout.cc (brf_ext_info_section)
(btf_ext_info): Move from coreout.h
(btf_ext_funcinfo, btf_ext_lineinfo): Add struct.
(bpf_core_reloc): Rename to btf_ext_core_reloc.
(btf_ext): Add static variable.
(btfext_info_sec_find_or_add, SEARCH_NODE_AND_RETURN)
(bpf_create_or_find_funcinfo, bpt_create_core_reloc)
(btf_ext_add_string, btf_funcinfo_type_callback)
(btf_add_func_info_for, btf_validate_funcinfo)
(btf_ext_info_len, output_btfext_func_info): Add function.
(output_btfext_header, bpf_core_reloc_add)
(output_btfext_core_relocs, btf_ext_init, btf_ext_output):
Change to support new structs.
* config/bpf/coreout.h (btf_ext_funcinfo, btf_ext_lineinfo):
Move and change in coreout.cc.
(btf_add_func_info_for, btf_ext_add_string): Add prototypes.

gcc/testsuite/ChangeLog:
PR target/113453
* gcc.target/bpf/btfext-funcinfo-nocore.c: Add.
* gcc.target/bpf/btfext-funcinfo.c: Add.
* gcc.target/bpf/core-attr-5.c: Fix regexp.
* gcc.target/bpf/core-attr-6.c: Fix regexp.
* gcc.target/bpf/core-builtin-fieldinfo-offset-1.c: Fix regexp.
* gcc.target/bpf/core-section-1.c: Fix regexp.

[Bug libstdc++/114153] std::less<> prefers operator const void*() over operator<=>() in C++20 mode

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #2)
> Without looking at the code, we probably just need to check if the type has
> a usable operator<=>.
> 
> We check it out had


Sorry, phone typos. 

"We check if it has..."

> a usable operator< which worked fine in C++17, but in
> C++20 x

[Bug libstdc++/114153] std::less<> prefers operator const void*() over operator<=>() in C++20 mode

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

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

--- Comment #2 from Jonathan Wakely  ---
Without looking at the code, we probably just need to check if the type has a
usable operator<=>.

We check it out had a usable operator< which worked fine in C++17, but in C++20
x

[Bug tree-optimization/114108] [14 regression] ICE when building opencv-4.8.1 (error: type mismatch in binary expression) since r14-1833

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

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

--- Comment #7 from Jakub Jelinek  ---
(In reply to Andrew Pinski from comment #6)
> Though r14-1833 just enables what was added to the vectorizer in r14-1832
> for aarch64.

Sure, the bug is in r14-1832, but bisection was to r14-1833.

[Bug tree-optimization/114108] [14 regression] ICE when building opencv-4.8.1 (error: type mismatch in binary expression) since r14-1833

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #5)
> Close.  Started with r14-1833-gea616f687dccbe42012f786c0ebade5b05850206

Though r14-1833 just enables what was added to the vectorizer in r14-1832 for
aarch64.

[Bug target/114143] Non-thumb arm32 code in thumb multilib for libgcc and in -mthumb build

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

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Hans-Peter Nilsson  ---
(In reply to Christophe Lyon from comment #1)
> What configure flags did you use? Only --target arm-eabi" ?

The exact configure options that were used are (besides --prefix):
--target=arm-eabi --with-gnu-ld --with-gnu-as --with-newlib
--enable-languages=c,c++,lto --enable-checking=release

This particular gcc version was trunk: r14-9089-gb4c88cc717e5
It was built together with newlib as of git 4e77fa9b8bf4 (about 2024-02-13)
Binutils as of about 2024-02-21.  Also seen with binutils-2.42, gcc-13.2.0,
newlib-4.4.0.20231231 so I doubt the exact versions are key.

> What does gcc --print-multi-lib say?

.;
thumb;@mthumb
arm/autofp/v5te/fpu;@marm@mfpu=auto@march=armv5te+fp@mfloat-abi=hard
thumb/autofp/v7/fpu;@mthumb@mfpu=auto@march=armv7+fp@mfloat-abi=hard

> You probably haven't built the correct multilibs.

If that suggestion boils down to incorrect configure options or make
invocation, for the latter:

$ make -j7
then much later
$ make install

If I can't build a whole-thumb binary then why include the thumb multilibs
there at all?

If certain --with-* options are a requirement for that, IMO this should at
least be documented.

[Bug fortran/111781] Fortran compiler complains about variable bound in array dummy argument

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

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #4)
> Thus I suggest to fix the testcase by one of the options suggested above.

Testcase gfortran.dg/pr101026.f is corrected at r14-9220.

[Bug fortran/114141] ASSOCIATE and complex part ref when associate target is a function

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P4  |P5
   Severity|normal  |enhancement

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #4)

> (In reply to kargl from comment #3)
> > Yep, agreed.  I went back an re-read the section about ASSOCIATE.
> > Not sure how I convinced myself that a constant expression, which
> > reduces to a constant is okay.
> > 
> Not sure how you convinced yourself it isn't. ;-)

x => log(cmplx(-1,0))

R1104 association  is associate-name => selector

R1105 selector is expr
   or variable

R902 variable  is designator
   or function-reference

R901 designatoris object-name
   or array-element
   or array-section
   or coindexed-named-object
   or complex-part-designator
   or structure-component
   or substring

log(cmplx(-1,0)) is certainly not a designator.

log(cmplx(-1,0)) is a function-reference.  But this then
leads to

C902 (R902) function-reference shall have a data pointer result.


log(cmplx(-1,0)) violates C902, so this then means that it
must be an expr.  One now needs


R915 complex-part-designator  is designator % RE
  or designator % IM

C922 (R915) The designator shall be of complex type.

which shows that expr%im is invalid; even though log(cmplx(-1,0))
reduces to a constant (i.e., it's not a named constant.  This
is likely the error [pun intended] in my ways.).

Sometimes the trees get in the way of seeing the forest.


Arguably, the error message is wrong
gfortran13 -c a.f90
a.f90:6:13:

6 |   y = x%im
  | 1
Error: Symbol 'x' at (1) has no IMPLICIT type

'x' has the type of COMPLEX.

The version of the code where Jerry wraps log(cmplx(-1,0))
in parentheses.  Generates a better error message


$ gfc pr114141.f90
pr114141.f90:6:14:

6 |   y = x%im
  |  1
Error: The RE or IM part_ref at (1) must be applied to a COMPLEX expression

but this is still wrong in that RE and IM are applied to a designator.

I'll leave the PR open has an enhancement request.

[Bug middle-end/114157] New: during GIMPLE pass: bitintlower ICE: in lower_stmt, at gimple-lower-bitint.cc:5561 with -O with _BitInt(256) / vector memmove

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 114157
   Summary: during GIMPLE pass: bitintlower ICE: in lower_stmt, at
gimple-lower-bitint.cc:5561 with -O with _BitInt(256)
/ vector memmove
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  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 57570
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57570=edit
reduced testcase

This happens even after the PR113988 fix.
I don't know how much is this related to PR114156.

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O testcase.c -Wno-psabi
during GIMPLE pass: bitintlower
testcase.c: In function 'foo':
testcase.c:4:1: internal compiler error: in lower_stmt, at
gimple-lower-bitint.cc:5561
4 | foo (__attribute__((__vector_size__ (64))) long s)
  | ^~~
0xd79d8e lower_stmt
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:5561
0x269e129 gimple_lower_bitint
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:6759
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ 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=/repo/gcc-trunk/binary-trunk-r14-9216-20240228150317-g5c01ede02a1-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.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
--disable-bootstrap --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-r14-9216-20240228150317-g5c01ede02a1-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240228 (experimental) (GCC)

[Bug fortran/114141] ASSOCIATE and complex part ref when associate target is a function

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

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #4 from Mikael Morin  ---
(In reply to Jerry DeLisle from comment #2)
> It looks like the 'selector' in this case is an expr.
> 
Agreed.

> The expr must be a pointer object or a 'designator'
> 
Really?  Can't find the constraint saying that.
The only associate constraint mentioning 'designator' I can see is this:

  C1105 (R1105) expr shall not be a designator of a procedure pointer or a
function reference that returns a procedure pointer.

... but it relates more to procedure pointers (and it is a 'shall NOT be'
constraint).


(In reply to kargl from comment #3)
> Yep, agreed.  I went back an re-read the section about ASSOCIATE.
> Not sure how I convinced myself that a constant expression, which
> reduces to a constant is okay.
> 
Not sure how you convinced yourself it isn't. ;-)

[Bug middle-end/114156] New: during GIMPLE pass: bitintlower ICE: in lower_stmt, at gimple-lower-bitint.cc:5335 with -O -m32 and _BitInt(128) __builtin_memmove()

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 114156
   Summary: during GIMPLE pass: bitintlower ICE: in lower_stmt, at
gimple-lower-bitint.cc:5335 with -O -m32 and
_BitInt(128) __builtin_memmove()
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  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: i686-pc-linux-gnu

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

This happens even after the PR113988 fix.

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -m32 testcase.c
during GIMPLE pass: bitintlower
testcase.c: In function 'foo':
testcase.c:4:1: internal compiler error: in lower_stmt, at
gimple-lower-bitint.cc:5335
4 | foo(void)
  | ^~~
0xd79caa lower_stmt
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:5335
0x269e129 gimple_lower_bitint
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:6759
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ 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=/repo/gcc-trunk/binary-trunk-r14-9216-20240228150317-g5c01ede02a1-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.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
--disable-bootstrap --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-r14-9216-20240228150317-g5c01ede02a1-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240228 (experimental) (GCC)

[Bug tree-optimization/114151] [14 Regression] weird and inefficient codegen and addressing modes since g:a0b1798042d033fd2cc2c806afbb77875dd2909b

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

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

--- Comment #3 from Tamar Christina  ---
> 
> This was a correctness fix btw, so I'm not sure we can easily recover - we
> could try using niter information for CHREC_VARIABLE but then there's
> variable niter here so I don't see a chance.
> 

It looks like it's mostly SVE suffering here. Adv. SIMD an scalar codegen seems
to have vastly improved with it. we see ~10% improvements due to better
addressing for scalar.

It also only happens at -O3 but -O2 is fine, which is weird as I was expected
IVopts to be enabled at -O2 too.

> 
> OTOH the +1 could make it overflow for large size.
> 
> Can you test the above?  It should be an incremental improvement.
> 

Applying the changes does not seem to make a difference for the final codegen
:(

[Bug debug/114015] ICE: in build_abbrev_table, at dwarf2out.cc:9266 with -g -fvar-tracking-assignments -fdebug-types-section

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2024-02-28
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Created attachment 57568
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57568=edit
gcc14-pr114015.patch

Untested fix.

[Bug fortran/114146] REPEATABLE argument of RANDOM_INIT and repeated execution of the program

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P5
   Last reconfirmed||2024-02-28
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Severity|normal  |minor
 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
gfortran's implementation matches the wording of the Fortran 2023 standard.

   Case (i):  CALL RANDOM_INIT (REPEATABLE=true, IMAGE_DISTINCT=true) is
equivalent
  to invoking RANDOM_SEED with a processor-dependent value for PUT that is
  different on every invoking image. In each execution of the program with
the
  same execution environment, if the invoking image index value in the
initial
  team is the same, the value for PUT shall be the same.

Looks like someone needs to update the gfortran manual.

[Bug d/114155] gdc.test/runnable/literal.d FAILs

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

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug d/114155] New: gdc.test/runnable/literal.d FAILs

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

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

Bug ID: 114155
   Summary: gdc.test/runnable/literal.d FAILs
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: sparc*-sun-solaris2.11

gdc.test/runnable/literal.d FAILs on 32 and 64-bit Solaris/SPARC since it
was installed:

+UNRESOLVED: gdc.test/runnable/literal.d   compilation failed to produce
executable
+UNRESOLVED: gdc.test/runnable/literal.d -shared-libphobos   compilation failed
to produce executable

runnable/literal.d:262:5: error: static assert: 
'"x\"1122334455667788AABBCCDDEEFF0099\"" ==
"x\"88776655443322119900FFEEDDCCBBAA\""' is false
compiler exited with status 1

Seems like an endianess to me.

[Bug fortran/114141] ASSOCIATE and complex part ref when associate target is a function

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #2)
> It looks like the 'selector' in this case is an expr.
> 
> The expr must be a pointer object or a 'designator'
> 
> A designator must be:
> 
> R901
> designator
> 
> object-name
> array-element
> array-section
> coindexed-named-object
> complex-part-designator
> structure-component
> substring
> 
> I am not seeing the expr in the example as one of these listed. ???

Yep, agreed.  I went back an re-read the section about ASSOCIATE.
Not sure how I convinced myself that a constant expression, which
reduces to a constant is okay.

I suppose the question is "do we generate a better error message
or simply close the PR?"

[Bug target/112868] GCC passes -many to the assembler for --enable-checking=release builds

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

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

--- Comment #7 from Sam James  ---
(In reply to Peter Bergner from comment #6)

Thanks Peter. We're happy to help with that in Gentoo. If you remember, please
CC me on the patch and we'll give it a spin.

[Bug testsuite/113685] [14 regression] gcc.dg/vect/vect-117.c fails profile checking with Invalid sum after r14-4089-gd45ddc2c04e471

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

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

--- Comment #3 from Rainer Orth  ---
Created attachment 57567
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57567=edit
64-bit sparc-sun-solaris2.11 vect-117.c.265t.optimized

[Bug testsuite/113685] [14 regression] gcc.dg/vect/vect-117.c fails profile checking with Invalid sum after r14-4089-gd45ddc2c04e471

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

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org
   Host|powerpc64le-linux-gnu   |powerpc64le-linux-gnu,
   ||sparc*-sun-solaris2.11
  Build|powerpc64le-linux-gnu   |powerpc64le-linux-gnu,
   ||sparc*-sun-solaris2.11
 Target|powerpc64le-linux-gnu   |powerpc64le-linux-gnu,
   ||sparc*-sun-solaris2.11

--- Comment #2 from Rainer Orth  ---
The same issue exists on 64-bit Solaris/SPARC:

+FAIL: gcc.dg/vect/vect-117.c -flto -ffat-lto-objects  scan-tree-dump-not
optimized "Invalid sum"
+FAIL: gcc.dg/vect/vect-117.c scan-tree-dump-not optimized "Invalid sum"

[Bug testsuite/102954] [12/13/14 regression] gcc.dg/vect/pr33804.c XPASSes

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

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

--- Comment #7 from Rainer Orth  ---
Created attachment 57566
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57566=edit
64-bit sparc-sun-solaris2.11 slp-multitypes-3.c.179t.vect

[Bug testsuite/102954] [12/13/14 regression] gcc.dg/vect/pr33804.c XPASSes

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

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

--- Comment #6 from Rainer Orth  ---
Created attachment 57565
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57565=edit
64-bit sparc-sun-solaris2.11 pr33804.c.179t.vect

The issue persists as of 20240228.

[Bug tree-optimization/114154] gcc.dg/vect/vect-alias-check-1.c XPASSes

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

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

--- Comment #1 from Rainer Orth  ---
Created attachment 57564
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57564=edit
32-bit sparc-sun-solaris2.11 vect-alias-check-1.c.179t.vect

[Bug tree-optimization/114154] New: gcc.dg/vect/vect-alias-check-1.c XPASSes

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

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

Bug ID: 114154
   Summary: gcc.dg/vect/vect-alias-check-1.c XPASSes
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: sparc*-sun-solaris2.11

vect-alias-check-1.c XPASSes on 32 and 64-bit SPARC since 20200614:

XPASS: gcc.dg/vect/vect-alias-check-1.c -flto -ffat-lto-objects  scan-tree-dump
vect "using an address-based overlap test"
XPASS: gcc.dg/vect/vect-alias-check-1.c scan-tree-dump vect "using an
address-based overlap test"

[Bug fortran/62283] basic-block vectorization fails

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

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

--- Comment #32 from Rainer Orth  ---
Created attachment 57563
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57563=edit
32-bit sparc-sun-solaris2.11 vect-33.c.265t.optimized

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

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

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

Bug 62283 Summary: basic-block vectorization fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62283

   What|Removed |Added

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

[Bug fortran/62283] basic-block vectorization fails

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

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

Rainer Orth  changed:

   What|Removed |Added

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

--- Comment #31 from Rainer Orth  ---
gcc.dg/vect/vect-33.c still FAILs on 32 and 64-bit SPARC:

FAIL: gcc.dg/vect/vect-33.c -flto -ffat-lto-objects  scan-tree-dump-not
optimized "Invalid sum"
FAIL: gcc.dg/vect/vect-33.c scan-tree-dump-not optimized "Invalid sum"

[Bug tree-optimization/113431] [14 Regression] Wrong code at -O3

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

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

Rainer Orth  changed:

   What|Removed |Added

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

--- Comment #19 from Rainer Orth  ---
The SPARC dump suggests

/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/pr113431.c:12:15:
missed:   unsupported unaligned access
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/pr113431.c:12:15:
missed:   not vectorized: relevant stmt not supported: a[0][1] = _60;

that the tests needs vect_hw_misalign?

[Bug libstdc++/114152] Wrong exception specifiers for LFTSv3 scope guard destructors

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:80c386cb20d38ebc55f30a79418fabfbed904b87

commit r14-9219-g80c386cb20d38ebc55f30a79418fabfbed904b87
Author: Jonathan Wakely 
Date:   Wed Feb 28 14:45:18 2024 +

libstdc++: Fix noexcept on dtors in  [PR114152]

The PR points out that the destructors all have incorrect
noexcept-specifiers.

libstdc++-v3/ChangeLog:

PR libstdc++/114152
* include/experimental/scope (scope_exit scope_fail): Make
destructor unconditionally noexcept.
(scope_sucess): Fix noexcept-specifier.
* testsuite/experimental/scopeguard/114152.cc: New test.

[Bug libstdc++/114152] Wrong exception specifiers for LFTSv3 scope guard destructors

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

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

--- Comment #3 from Jonathan Wakely  ---
I can take care of it this time, since I think I can figure out how to fix it
just from your detailed report :-) and I've already written a testcase:


// { dg-do compile { target c++20 } }

// PR libstdc++/114152
// Wrong exception specifiers for LFTSv3 scope guard destructors

#include 

using namespace std::experimental;

struct F {
  void operator()() noexcept(false);
};

static_assert( noexcept(std::declval&>().~scope_exit()) );
static_assert( noexcept(std::declval&>().~scope_fail()) );
static_assert( ! noexcept(std::declval&>().~scope_success())
);

struct G {
  void operator()() noexcept(true);
};

static_assert( noexcept(std::declval&>().~scope_exit()) );
static_assert( noexcept(std::declval&>().~scope_fail()) );
static_assert( noexcept(std::declval&>().~scope_success()) );

[Bug tree-optimization/96147] [11 regression] gcc.dg/vect/slp-43.c etc. FAIL

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

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

--- Comment #11 from Rainer Orth  ---
Created attachment 57562
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57562=edit
32-bit sparc-sun-solaris2.11 bb-slp-32.c.191t.slp2

[Bug tree-optimization/96147] [11 regression] gcc.dg/vect/slp-43.c etc. FAIL

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

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

Rainer Orth  changed:

   What|Removed |Added

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

--- Comment #10 from Rainer Orth  ---
Unfortunately, I missed that one of those tests still XPASSes:

XPASS: gcc.dg/vect/bb-slp-32.c -flto -ffat-lto-objects  scan-tree-dump slp2
"vectorization is not profitable"
XPASS: gcc.dg/vect/bb-slp-32.c scan-tree-dump slp2 "vectorization is not
profitable"

[Bug libstdc++/114152] Wrong exception specifiers for LFTSv3 scope guard destructors

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |13.3
 Status|NEW |ASSIGNED

[Bug libstdc++/114152] Wrong exception specifiers for LFTSv3 scope guard destructors

[victor at westerhu dot is via Gcc-bugs]

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

--- Comment #2 from Victor  ---
Will do!

[Bug libstdc++/114152] Wrong exception specifiers for LFTSv3 scope guard destructors

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-02-28

--- Comment #1 from Jonathan Wakely  ---
Thanks - please send patches to the mailing list instead of attaching them
here.

https://gcc.gnu.org/contribute.html#patches

See https://gcc.gnu.org/contribute.html#legal as well.

[Bug tree-optimization/114151] [14 Regression] weird and inefficient codegen and addressing modes since g:a0b1798042d033fd2cc2c806afbb77875dd2909b

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

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

--- Comment #2 from Richard Biener  ---
Yep, it seems to only pick up global ranges that way.

diff --git a/gcc/tree-ssa-loop-ivopts.cc b/gcc/tree-ssa-loop-ivopts.cc
index 7cae5bdefea..626fc5bf5d7 100644
--- a/gcc/tree-ssa-loop-ivopts.cc
+++ b/gcc/tree-ssa-loop-ivopts.cc
@@ -132,6 +132,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "tree-vectorizer.h"
 #include "dbgcnt.h"
 #include "cfganal.h"
+#include "gimple-range.h"

 /* For lang_hooks.types.type_for_mode.  */
 #include "langhooks.h"
@@ -8280,6 +8281,8 @@ tree_ssa_iv_optimize (void)
   tree_ssa_iv_optimize_init ();
   mark_ssa_maybe_undefs ();

+  enable_ranger (cfun);
+
   /* Optimize the loops starting with the innermost ones.  */
   for (auto loop : loops_list (cfun, LI_FROM_INNERMOST))
 {
@@ -8292,6 +8295,8 @@ tree_ssa_iv_optimize (void)
   tree_ssa_iv_optimize_loop (, loop, toremove);
 }

+  disable_ranger (cfun);
+
   /* Remove eliminated IV defs.  */
   release_defs_bitset (toremove);

[Bug tree-optimization/114151] [14 Regression] weird and inefficient codegen and addressing modes since g:a0b1798042d033fd2cc2c806afbb77875dd2909b

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-02-28
 Ever confirmed|0   |1
 CC||amacleod at redhat dot com,
   ||rsandifo at gcc dot gnu.org
   Target Milestone|--- |14.0

--- Comment #1 from Richard Biener  ---
Do we have POLY_INT_CSTs in CHRECs?  Huh, yeah - we do.  So in IVOPTs the
differences are like

 (get_scalar_evolution 
   (scalar = col_i_61)
-  (scalar_evolution = {iftmp.0_11 * _105, +, iftmp.0_11}_2))
+  (scalar_evolution = (int) {(unsigned int) col_stride_10 * (unsigned int)
_105, +, (unsigned int) col_stride_10}_2))

but also

 (set_scalar_evolution 
   instantiated_below = 22 
   (scalar = _58)
-  (scalar_evolution = {(__fp16 *) p_mat_16(D) + ((long unsigned int) _105 +
(long unsigned int) (iftmp.0_11 * _105)) * 2, +, ((long unsigned int)
iftmp.0_11 + 1) * 2}_2))
+  (scalar_evolution = _58))

(that's completely missed)

Likewise, with POLY_INT_CST:

-  (scalar_evolution = {(__fp16 *) p_mat_16(D) + (((long unsigned int)
(iftmp.0_11 * _105) + (long unsigned int) _105) * 2 + POLY_INT_CST [16, 16]),
+, ((long unsigned int) iftmp.0_11 + 1) * 2}_2))
+  (scalar_evolution = _13))

The special-casing of CHREC * x we allow to be expressed works by looking
at value-ranges and signs of INTEGER_CSTs:

+ if (!ANY_INTEGRAL_TYPE_P (type)
+ || TYPE_OVERFLOW_WRAPS (type)
+ || integer_zerop (CHREC_LEFT (op0))
+ || (TREE_CODE (CHREC_LEFT (op0)) == INTEGER_CST
+ && TREE_CODE (CHREC_RIGHT (op0)) == INTEGER_CST
+ && (tree_int_cst_sgn (CHREC_LEFT (op0))
+ == tree_int_cst_sgn (CHREC_RIGHT (op0
+ || (get_range_query (cfun)->range_of_expr (rl, CHREC_LEFT (op0
...

possibly there might be a way to adapt the "same sign" check to also work
for POLY_INT_CSTs which I think have known signs?  Possibly rewriting
that by using poly_int_tree_p () isntead of checking for INTEGER_CST
and then using known_lt (wi::to_poly_wide (), 0) && known_lt (..., 0)
|| known_gt (..., 0) && known_gt (..., 0) helps?

Nope, the following doesn't make a difference here.

diff --git a/gcc/tree-chrec.cc b/gcc/tree-chrec.cc
index 2e6c7356d3b..366ab914c8f 100644
--- a/gcc/tree-chrec.cc
+++ b/gcc/tree-chrec.cc
@@ -442,10 +442,12 @@ chrec_fold_multiply (tree type,
  if (!ANY_INTEGRAL_TYPE_P (type)
  || TYPE_OVERFLOW_WRAPS (type)
  || integer_zerop (CHREC_LEFT (op0))
- || (TREE_CODE (CHREC_LEFT (op0)) == INTEGER_CST
- && TREE_CODE (CHREC_RIGHT (op0)) == INTEGER_CST
- && (tree_int_cst_sgn (CHREC_LEFT (op0))
- == tree_int_cst_sgn (CHREC_RIGHT (op0
+ || (poly_int_tree_p (CHREC_LEFT (op0))
+ && poly_int_tree_p (CHREC_RIGHT (op0))
+ && ((known_lt (wi::to_poly_widest (CHREC_LEFT (op0)), 0)
+  && known_lt (wi::to_poly_widest (CHREC_RIGHT (op0)), 0))
+ || (known_ge (wi::to_poly_widest (CHREC_LEFT (op0)), 0)
+ && known_ge (wi::to_poly_widest (CHREC_RIGHT (op0)),
0
  || (get_range_query (cfun)->range_of_expr (rl, CHREC_LEFT (op0))
  && !rl.undefined_p ()
  && (rl.nonpositive_p () || rl.nonnegative_p ())


This was a correctness fix btw, so I'm not sure we can easily recover - we
could try using niter information for CHREC_VARIABLE but then there's
variable niter here so I don't see a chance.

This is mainly IVs like

  col_i_61 = col_stride_10 * j_73;
  _60 = (long unsigned int) col_i_61;
  _59 = _60 * 2;
  _58 = a_j_69 + _59;
  _54 = MEM <__SVFloat16_t> [(__fp16 *)_58];

where we compose for example the scalar evolution of col_i_61 by
multiplyinig that of j_73 which is {_105, +, 1}_2 with col_stride_10.

Possibly adding a ranger instance to IVOPTs could help, for this instance
since

   [local count: 118111600]:
  # col_stride_10 = PHI 
  if (size_15(D) > 0)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 118111600]:
  return;

so col_stride_10 should be positive, and _105 as well:

  _12 = MAX_EXPR <_103, 0>;
  _3 = (unsigned int) _12;
  _4 = _3 + 1;
  _105 = (int) _4;

OTOH the +1 could make it overflow for large size.

Can you test the above?  It should be an incremental improvement.

Adding enable_ranger (cfun); / disable_ranger (cfun);  around the IVOPTs
pass doesn't seem to help (but see above - there might not be enough
info, also the code added doesn't pass in a context stmt so ranger
might not do much/anything here).

Confirmed.

[Bug c++/92687] decltype of a structured binding to a tuple component is a reference type inside a template function

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 57561
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57561=edit
gcc14-pr92687.patch

So var only very lightly tested fix.

Another possibility would be instead of the cp/*.cc changes in the patch change
lookup_decomp_type such that for NULL get it would return NULL_TREE, and either
always or just if ptds.saved try to call lookup_decomp_type and return its
result if it returned true, regardless of whether DECL_HAS_VALUE_EXPR_P or not.
Guess that would be cleaner, but slower.

[Bug libstdc++/114147] [11/12/13/14 Regression] tuple allocator-extended constructor requires non-explicit default constructor

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

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work|14.0|
Summary|[11/12/13 Regression] tuple |[11/12/13/14 Regression]
   |allocator-extended  |tuple allocator-extended
   |constructor requires|constructor requires
   |non-explicit default|non-explicit default
   |constructor |constructor

--- Comment #5 from Jonathan Wakely  ---
Ah it does include it, but it only affects C++20 and later. For older standards
the original code is still used.

[Bug libstdc++/114153] std::less<> prefers operator const void*() over operator<=>() in C++20 mode

[marc.mutz at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from Marc Mutz  ---
It's only the C++14 "diamond"/is_transparent version of std::less/greater_equal
that is affected. If you replace the return from main with greater_equal{},
then it calls op<=>, too:

// https://godbolt.org/z/cnjssh3ss
return std::greater_equal{}(arr[0], arr[1]) ? 0 : 1;
//^ added

[Bug libstdc++/114153] New: std::less prefers operator const void*() over operator<=>() in C++20 mode

[marc.mutz at hotmail dot com via Gcc-bugs]

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

Bug ID: 114153
   Summary: std::less prefers operator const void*() over
operator<=>() in C++20 mode
   Product: gcc
   Version: 12.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marc.mutz at hotmail dot com
  Target Milestone: ---

std::less (and other related types like std::greater_equal, etc) is implemented
in the following way:
* if `operator<(T, U)` is defined for the argument types, it is called.
* otherwise, if the argument types are convertible to `const volatile void *`,
such conversion is performed, and it boils down to comparing the pointers.

Now, assume a type which has an `operator const void *() const`, and provides
`operator==()` and `operator<=>()` to generate all relational operators, the
same way the std types do.

So std::less will not use `operator<=>()`, but cast to `const void *` and
compare pointers. 
This is wrong, because `operator<=>()` implies all relational operators, so it
can be used to do the proper comparison. libc++ gets this right:

// https://godbolt.org/z/E55eeosP9
// Courtesy of Ivan Solovev 
#include 
#include 
#include 

struct S
{
int val;

S(int v) : val(v) {}

operator const void *() const { std::cout << "cast\n"; return  }

friend bool operator==(S lhs, S rhs) noexcept 
{ std::cout << "op==\n"; return lhs.val == rhs.val; }
friend std::strong_ordering operator<=>(S lhs, S rhs) noexcept 
{ std::cout << "op<=>\n"; return lhs.val <=> rhs.val; }  
};

int main()
{
const S arr[] = {S{2}, S{1}};
// In C++20 mode it compares pointers, and so considers that arr[1] >
arr[0],
// which is wrong!
return std::greater_equal<>{}(arr[0], arr[1]) ? 0 : 1;
}

[Bug libstdc++/114152] New: Wrong exception specifiers for LFTSv3 scope guard destructors

[victor at westerhu dot is via Gcc-bugs]

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

Bug ID: 114152
   Summary: Wrong exception specifiers for LFTSv3 scope guard
destructors
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: victor at westerhu dot is
  Target Milestone: ---

Created attachment 57560
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57560=edit
Patch

According to the (draft) specification of the C++ Extensions for Library
Fundamentals, Version 3
(https://cplusplus.github.io/fundamentals-ts/v3.html#scopeguard.exit), the
destructors of std::experimental::scope_{exit,failure} should be
unconditionally noexcept. The destructor of std::experimental::scope_success
should be noexcept if calling the exit function is noexcept.

The current implementation has noexcept(noexcept(this->_M_exit_function)) for
all three, which is wrong for all. It is even wrong for
std::experimental::scope_success, because it's missing the needed `()' for
actually testing the function call.

This error is present since the first addition of the scope guards. I have
attached the 3-line patch needed to fix this.

[Bug tree-optimization/108355] [13/14 Regression] Dead Code Elimination Regression at -O2 since r13-2772-g9baee6181b4e42

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||xfail
Summary|[13 Regression] Dead Code   |[13/14 Regression] Dead
   |Elimination Regression at   |Code Elimination Regression
   |-O2 since   |at -O2 since
   |r13-2772-g9baee6181b4e42|r13-2772-g9baee6181b4e42
  Known to work|14.0|

--- Comment #9 from Richard Biener  ---
gcc.dg/tree-ssa/ssa-fre-104.c has been XFAILed.

[Bug tree-optimization/114121] wrong code with _BitInt() arithmetics at -O2

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #16 from Richard Biener  ---
Fixed.

[Bug tree-optimization/108355] [13 Regression] Dead Code Elimination Regression at -O2 since r13-2772-g9baee6181b4e42

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

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

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

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

commit r14-9216-g5c01ede02a1f9ba1a58ab8d96a73e46e0484d820
Author: Richard Biener 
Date:   Wed Feb 28 13:45:57 2024 +0100

tree-optimization/113831 - revert original fix

This reverts the original fix for PR113831 which is better fixed by
the PR114121 fix.  I've XFAILed instead of removing the PR108355
testcase again.

PR tree-optimization/113831
PR tree-optimization/108355
* tree-ssa-sccvn.cc (copy_reference_ops_from_ref): Revert
PR113831 fix.

* gcc.dg/tree-ssa/ssa-fre-104.c: XFAIL.

[Bug tree-optimization/113831] [11/12/13 Regression] Wrong VN with structurally identical ref since r9-398

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

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

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

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

commit r14-9216-g5c01ede02a1f9ba1a58ab8d96a73e46e0484d820
Author: Richard Biener 
Date:   Wed Feb 28 13:45:57 2024 +0100

tree-optimization/113831 - revert original fix

This reverts the original fix for PR113831 which is better fixed by
the PR114121 fix.  I've XFAILed instead of removing the PR108355
testcase again.

PR tree-optimization/113831
PR tree-optimization/108355
* tree-ssa-sccvn.cc (copy_reference_ops_from_ref): Revert
PR113831 fix.

* gcc.dg/tree-ssa/ssa-fre-104.c: XFAIL.

[Bug tree-optimization/114121] wrong code with _BitInt() arithmetics at -O2

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

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

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

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

commit r14-9215-gc841144a94363ff26e40ab3f26b14702c32987a8
Author: Richard Biener 
Date:   Wed Feb 28 12:37:07 2024 +0100

tree-optimization/114121 - wrong VN with context sensitive range info

When VN ends up exploiting range-info specifying the ao_ref offset
and max_size we have to make sure to reflect this in the hashtable
entry for the recorded expression.  The PR113831 fix handled the
case where we can encode this in the operands themselves but this
bug shows the issue is more widespread.

So instead of altering the operands the following instead records
this extra info that's possibly used, only throwing it away when
the value-numbering didn't come up with a non-VARYING value which
is an important detail to preserve CSE as opposed to constant
folding which is where all cases currently known popped up.

With this the original PR113831 fix can be reverted.

PR tree-optimization/114121
* tree-ssa-sccvn.h (vn_reference_s::offset,
vn_reference_s::max_size): New fields.
(vn_reference_insert_pieces): Adjust prototype.
* tree-ssa-pre.cc (phi_translate_1): Preserve offset/max_size.
* tree-ssa-sccvn.cc (vn_reference_eq): Compare offset and
size, allow using "don't know" state.
(vn_walk_cb_data::finish): Pass along offset/max_size.
(vn_reference_lookup_or_insert_for_pieces): Take offset and
max_size as argument and use it.
(vn_reference_lookup_3): Properly adjust offset and max_size
according to the adjusted ao_ref.
(vn_reference_lookup_pieces): Initialize offset and max_size.
(vn_reference_lookup): Likewise.
(vn_reference_lookup_call): Likewise.
(vn_reference_insert): Likewise.
(visit_reference_op_call): Likewise.
(vn_reference_insert_pieces): Take offset and max_size
as argument and use it.

* gcc.dg/torture/pr114121.c: New testcase.

[Bug tree-optimization/114151] New: [14 Regression] weird and inefficient codegen and addressing modes since g:a0b1798042d033fd2cc2c806afbb77875dd2909b

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

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

Bug ID: 114151
   Summary: [14 Regression] weird and inefficient codegen and
addressing modes since
g:a0b1798042d033fd2cc2c806afbb77875dd2909b
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64*

Created attachment 57559
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57559=edit
testcase

The attached C++ testcase compiled with: -O3 -mcpu=neoverse-n2

used to compile a nice and simple loop.  But after
g:a0b1798042d033fd2cc2c806afbb77875dd2909b

The codegen is weird and it uses horrible addressing modes.

The first odd part is that it's decided to split the loop, the "main" loop has
a guard after it to branch to the exit is the iteration count is 1.

If not instead of just loop again it falls through the a copy of the main loop,
but has destroyed addressing modes.

The copy of the loop seems to have unshared the address calculations. Before we
had:

  _128 = (void *) ivtmp.11_20;
  _54 = MEM <__SVFloat16_t> [(__fp16 *)_128];
  _10 = MEM <__SVFloat16_t> [(__fp16 *)_128 + POLY_INT_CST [16B, 16B]];
  _75 = MEM <__SVFloat16_t> [(__fp16 *)_128 + POLY_INT_CST [32B, 32B]];

etc, so all as an offset from _128.  Now we have:

  col_i_61 = (int) ivtmp.11_100;
  _60 = (long unsigned int) col_i_61;
  _59 = _60 * 2;
  _58 = a_j_69 + _59;
  _54 = MEM <__SVFloat16_t> [(__fp16 *)_58];
  _53 = _59 + POLY_INT_CST [16, 16];
  _13 = a_j_69 + _53;
  _10 = MEM <__SVFloat16_t> [(__fp16 *)_13];
  _74 = _59 + POLY_INT_CST [32, 32];
  _19 = a_j_69 + _74;
  _75 = MEM <__SVFloat16_t> [(__fp16 *)_19];

and similarly for the stores as well.

it also weirdly creates some very complicated addressing computations. Before
we had:

  _144 = p_mat_16(D) + 6; 
  _64 = MEM <__SVFloat16_t> [(__fp16 *)_144 + ivtmp.10_100 * 2];
  _143 = p_mat_16(D) + 4;
  _84 = MEM <__SVFloat16_t> [(__fp16 *)_143 + ivtmp.10_100 * 2];

and after:

  ivtmp.23_130 = (unsigned long) p_mat_16(D);
  _123 = 2 - ivtmp.23_130;
  _124 =  <__SVFloat16_t> [(__fp16 *)0B + _123 + ivtmp.12_109 * 2];
  _64 = MEM <__SVFloat16_t> [(__fp16 *)_124];

  _122 = -ivtmp.23_130;
  _120 =  <__SVFloat16_t> [(__fp16 *)0B + _122 + ivtmp.12_109 * 2];
  _84 = MEM <__SVFloat16_t> [(__fp16 *)_120];

This results in quite the codesize increase, and a 7-10% performance loss.

[Bug libstdc++/114147] [11/12/13 Regression] tuple allocator-extended constructor requires non-explicit default constructor

[victor.dyachenko at protonmail dot com via Gcc-bugs]

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

--- Comment #4 from __vic  ---
The latest gcc-14-20240225 snapshot doesn't include this fix. Is there any
chance to have this fixed in 14.1 release?

[Bug c++/92687] decltype of a structured binding to a tuple component is a reference type inside a template function

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

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

--- Comment #4 from Jakub Jelinek  ---
finish_decltype_type does:
  /* decltype of a decomposition name drops references in the tuple case
 (unlike decltype of a normal variable) and keeps cv-qualifiers from
 the containing object in the other cases (unlike decltype of a member
 access expression).  */
  if (DECL_DECOMPOSITION_P (expr))
{
  if (DECL_HAS_VALUE_EXPR_P (expr))
/* Expr is an array or struct subobject proxy, handle
   bit-fields properly.  */
return unlowered_expr_type (expr);
  else
/* Expr is a reference variable for the tuple case.  */
return lookup_decomp_type (expr);
}
The problem is that if processing_template_decl (though, finish_decltype_type
has processing_template_decl temporarily cleared here) and expr is not
dependent (otherwise finish_decltype_type would defer handling it)
DECL_HAS_VALUE_EXPR_P is actually set on all the structured binding decls, not
just when it is array/struct/vector/complex etc. subobject proxy.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[lukas.graetz--- via Gcc-bugs]

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

--- Comment #43 from Lukas Grätz  ---
(In reply to Lukas Grätz from comment #42)
> (In reply to Jakub Jelinek from comment #41)
> > 
> > No.  When PR78685 would be fixed by adding artificial hidden uses of
> > variables at the end of their scopes, this bug would trigger far more often.
> > The vars would be live across the calls, so if there would be callee-saved
> > registers available, the compiler
> > would use them to hold the variables across the calls.  And this bug would
> > break that.
> 
> It could be done that way. But I think a better fix for PR78685 would be to
> save the function parameter values to the stack (and than this problem will
> not trigger that often). For the following reasons:
> 


Just to be complete with the arguments:

(5) Artificial hidden uses of variables at the end of their scopes would not
always help when variables are overwritten. For example:

int main (int argc, char **argv) {
if (argc == 42) { h(); }
might_not_return(0);
argc = bar();
// here would be the hidden use of argc and argv
}

The "artificial hidden use" approach would only save the last value of argc,
here the result of bar() in line 4 and not the argument argc. The argument
value of argc is not used from line 3 on. So that approach would still produce
a backtrace with argc=, something like:

#1 might_not_return(i=0)
#2 main (argc=, argv=0x7fffe0)

(6) When the goal is just to have a more helpful gdb bt output, then we don't
need to save any variables other than function parameters. In the original
example in Bug 78685 and Comment 28 here, this seemed to be the main goal, to
get gdb bt more conclusive. If interested in other variable values, too, -O0
might be better then trying hard to patch -Og to save all variable values.

(7) Bug 78685 is for x86-64 with -Og. For 32 bit x86 with -Og, we don't run
into that problem: there are no  function parameters, since they
are already on the stack by the 32 bit calling conventions. So saving
parameters on the stack for -Og on x86-64 and similar targets without
stack-parameters would just be consequent.

[Bug target/114150] New: gcc.target/i386/avx512cd-vpbroadcastmb2q-2.c etc. FAIL

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

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

Bug ID: 114150
   Summary: gcc.target/i386/avx512cd-vpbroadcastmb2q-2.c etc. FAIL
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: ubizjak at gmail dot com
  Target Milestone: ---
Target: i?86-pc-solaris2.11, amd64-pc-solaris2.11

Two tests FAIL on 32 and 64-bit Solaris/x86 with the native asembler in use:

FAIL: gcc.target/i386/avx512cd-vpbroadcastmb2q-2.c (test for excess errors)
UNRESOLVED: gcc.target/i386/avx512cd-vpbroadcastmb2q-2.c compilation failed to
produce executable
FAIL: gcc.target/i386/avx512cd-vpbroadcastmw2d-2.c (test for excess errors)
UNRESOLVED: gcc.target/i386/avx512cd-vpbroadcastmw2d-2.c compilation failed to
produce executable

Excess errors: 
Assembler: avx512cd-vpbroadcastmb2q-2.c
"/var/tmp//ccs_9lod.s", line 42 : Invalid instruction argument
Near line: "vpbroadcastmb2q %k0, %zmm0"

Assembler: avx512cd-vpbroadcastmw2d-2.c
"/var/tmp//ccevT6Rd.s", line 35 : Invalid instruction argument
Near line: "vpbroadcastmw2d %k0, %zmm0"

I suspect this is just an as bug.

While I thought about adding tests for the two vpbroadcastm* insns to
check_effective_target_avx512cd to guard against this, it's probably best to
just xfail the tests on Solaris/x86 with as, especially since the native
assembler isn't seeing any more fixes these days.

[Bug c++/114129] Inaccurate error message

[Theodore.Papadopoulo at inria dot fr via Gcc-bugs]

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

Theodore.Papadopoulo at inria dot fr changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Theodore.Papadopoulo at inria dot fr ---
Wrong report Sorry.

[Bug c++/114129] Inaccurate error message

[Theodore.Papadopoulo at inria dot fr via Gcc-bugs]

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

--- Comment #2 from Theodore.Papadopoulo at inria dot fr ---
OK thank you... I did not realize that. C/C++ sometimes has a weird syntax.
Sorry for the noise

[Bug tree-optimization/114108] [14 regression] ICE when building opencv-4.8.1 (error: type mismatch in binary expression) since r14-1833

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Keywords|needs-bisection |
Summary|[14 regression] ICE when|[14 regression] ICE when
   |building opencv-4.8.1   |building opencv-4.8.1
   |(error: type mismatch in|(error: type mismatch in
   |binary expression)  |binary expression) since
   ||r14-1833

--- Comment #5 from Jakub Jelinek  ---
Close.  Started with r14-1833-gea616f687dccbe42012f786c0ebade5b05850206

[Bug libstdc++/114149] New: lexicographical_compare should use memcmp for C++20 contiguous iterators as well as pointers

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

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

Bug ID: 114149
   Summary: lexicographical_compare should use memcmp for C++20
contiguous iterators as well as pointers
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

__lexicographical_compare_aux1 has:

  const bool __simple =
(__is_memcmp_ordered_with<_ValueType1, _ValueType2>::__value
 && __is_pointer<_II1>::__value
 && __is_pointer<_II2>::__value
#if __cplusplus > 201703L && __glibcxx_concepts
 // For C++20 iterator_traits::value_type is non-volatile
 // so __is_byte could be true, but we can't use memcmp with
 // volatile data.
 && !is_volatile_v>>
 && !is_volatile_v>>
#endif

We should use memcmp for contiguous iterators, not only pointers.

There's a similar condition in ranges::lexicographical_compare.