[Bug middle-end/110660] conditional length reduction optimization

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

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

--- Comment #1 from Richard Biener  ---
The vectorizer itself could do the merging which means it could also more
accurately cost things.

Otherwise think about whether/how such a situation might arise from people
using RVV intrinsics - how are those exposed to GIMPLE / RTL and at which
level could that be optimized?  Is it possible to write an intrinsic
testcase with such opportunity?

[Bug middle-end/110659] Error from linker: .eh_frame_hdr refers to overlapping FDEs

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

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-linux-gnu

--- Comment #8 from Richard Biener  ---
yes

[Bug c/110662] Segmentation fault with '-O3'

[19373742 at buaa dot edu.cn via Gcc-bugs]

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

--- Comment #1 from CTC <19373742 at buaa dot edu.cn> ---
Created attachment 55540
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55540=edit
The compiler output

[Bug c/110662] New: Segmentation fault with '-O3'

[19373742 at buaa dot edu.cn via Gcc-bugs]

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

Bug ID: 110662
   Summary: Segmentation fault with '-O3'
   Product: gcc
   Version: 11.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 19373742 at buaa dot edu.cn
  Target Milestone: ---

Created attachment 55539
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55539=edit
The preprocessed file

***
OS and Platform:
CentOS Linux release 7.9.2009 (Core), x86_64 GNU/Linux
***
gcc version:
gcc -v
Using built-in specs.
COLLECT_GCC=/home/new-gcc/gcc-11-0706/bin/gcc
COLLECT_LTO_WRAPPER=/home/new-gcc/gcc-11-0706/libexec/gcc/x86_64-pc-linux-gnu/11.4.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --prefix=/home/new-gcc/gcc-11-0706/
--disable-multilib --enable-language=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.4.1 20230706 (GCC)
***
Command Lines:
# /home/new-gcc/gcc-11-0706/bin/gcc -I /home/csmith/include/csmith-2.3.0/ -O3
-fno-aggressive-loop-optimizations -fno-align-functions -fno-align-jumps
-fno-align-labels -fno-align-loops -fno-allocation-dce
-fno-asynchronous-unwind-tables -fno-auto-inc-dec -fno-bit-tests
-fno-branch-count-reg -fno-caller-saves -fno-code-hoisting
-fno-combine-stack-adjustments -fno-compare-elim -fno-cprop-registers
-fno-crossjumping -fno-cse-follow-jumps -fno-dce -fno-defer-pop
-fno-delete-null-pointer-checks -fno-devirtualize
-fno-devirtualize-speculatively -fno-dse -fno-early-inlining
-fno-expensive-optimizations -fno-forward-propagate -fno-fp-int-builtin-inexact
-fno-function-cse -fno-gcse -fno-gcse-after-reload -fno-gcse-lm
-fno-guess-branch-probability -fno-hoist-adjacent-loads -fno-if-conversion
-fno-if-conversion2 -fno-indirect-inlining -fno-inline -fno-inline-atomics
-fno-inline-functions -fno-inline-functions-called-once
-fno-inline-small-functions -fno-ipa-bit-cp -fno-ipa-cp -fno-ipa-cp-clone
-fno-ipa-icf -fno-ipa-icf-functions -fno-ipa-icf-variables -fno-ipa-modref
-fno-ipa-profile -fno-ipa-pure-const -fno-ipa-ra -fno-ipa-reference
-fno-ipa-reference-addressable -fno-ipa-sra -fno-ipa-stack-alignment
-fno-ipa-vrp -fno-ira-hoist-pressure -fno-ira-share-save-slots
-fno-ira-share-spill-slots -fno-isolate-erroneous-paths-dereference -fno-ivopts
-fno-jump-tables -fno-lifetime-dse -fno-loop-interchange
-fno-loop-unroll-and-jam -fno-lra-remat -fno-math-errno
-fno-move-loop-invariants -fno-omit-frame-pointer -fno-optimize-sibling-calls
-fno-optimize-strlen -fno-partial-inlining -fno-peel-loops -fno-peephole
-fno-peephole2 -fno-plt -fno-predictive-commoning -fno-prefetch-loop-arrays
-fno-printf-return-value -fno-ree -fno-reg-struct-return -fno-rename-registers
-fno-reorder-blocks -fno-reorder-blocks-and-partition -fno-reorder-functions
-fno-rerun-cse-after-loop -fno-sched-critical-path-heuristic
-fno-sched-dep-count-heuristic -fno-sched-group-heuristic -fno-sched-interblock
-fno-sched-last-insn-heuristic -fno-sched-rank-heuristic -fno-sched-spec
-fno-sched-spec-insn-heuristic -fno-sched-stalled-insns-dep
-fno-schedule-fusion -fno-schedule-insns2 -fno-short-enums -fno-shrink-wrap
-fno-shrink-wrap-separate -fno-signed-zeros -fno-split-ivs-in-unroller
-fno-split-loops -fno-split-paths -fno-split-wide-types -fno-ssa-backprop
-fno-ssa-phiopt -fno-stdarg-opt -fno-store-merging -fno-strict-aliasing
-fno-strict-volatile-bitfields -fno-thread-jumps -fno-toplevel-reorder
-fno-trapping-math -fno-tree-bit-ccp -fno-tree-builtin-call-dce -fno-tree-ccp
-fno-tree-ch -fno-tree-coalesce-vars -fno-tree-copy-prop -fno-tree-cselim
-fno-tree-dce -fno-tree-dominator-opts -fno-tree-dse -fno-tree-forwprop
-fno-tree-fre -fno-tree-loop-distribute-patterns -fno-tree-loop-distribution
-fno-tree-loop-if-convert -fno-tree-loop-im -fno-tree-loop-ivcanon
-fno-tree-loop-optimize -fno-tree-loop-vectorize -fno-tree-partial-pre
-fno-tree-phiprop -fno-tree-pre -fno-tree-pta -fno-tree-reassoc
-fno-tree-scev-cprop -fno-tree-sink -fno-tree-slp-vectorize -fno-tree-slsr
-fno-tree-sra -fno-tree-switch-conversion -fno-tree-tail-merge -fno-tree-ter
-fno-tree-vrp -fno-unroll-completely-grow-size -fno-unswitch-loops
-fno-unwind-tables -fno-var-tracking -fno-var-tracking-assignments
-fno-version-loops-for-strides -fno-web -fno-allow-store-data-races
-fno-associative-math -fno-branch-probabilities -fno-conserve-stack
-fno-cx-fortran-rules -fno-cx-limited-range -fno-delayed-branch
-fno-delete-dead-exceptions -fno-exceptions -fno-finite-loops
-fno-finite-math-only -fno-float-store -fno-gcse-las -fno-gcse-sm -fno-graphite
-fno-graphite-identity -fno-ipa-pta -fno-ira-loop-pressure
-fno-isolate-erroneous-paths-attribute 

[PATCH] Implement Bit-field lowering

[naveenh--- via Gcc-patches]

From: Naveen H S 

This patch adds lowering bit-field and opposite endian accesses pass.
The patch addresses many issues in:-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19466

2023-07-14  Andrew Pinski   
Co-authored-by: Naveen H S 

gcc/ChangeLog:

* Makefile.in (OBJS): Add gimple-lower-accesses.o.
* gimple-lower-accesses.cc: New file.
* passes.def (pass_lower_accesses): Add.
* tree-pass.h (make_pass_lower_accesses): Define.

gcc/testsuite/ChangeLog:

* gcc.dg/store_merging_14.c: Modify the pattern found as per new code.
* gcc.dg/store_merging_16.c: Likewise.
* gcc.dg/store_merging_20.c: Likewise.
* gcc.dg/store_merging_21.c: Likewise.
* gcc.dg/store_merging_24.c: Likewise.
* gcc.dg/store_merging_25.c: Likewise.
* gcc.dg/store_merging_6.c: Likewise.
* gcc.dg/tree-ssa/20030729-1.c: Likewise.
* gcc.dg/tree-ssa/20030814-6.c: Likewise.
* gcc.dg/tree-ssa/loop-interchange-14.c: Likewise.
* gcc.dg/tree-ssa/20030714-1.c: Remove.
---
 gcc/Makefile.in   |   1 +
 gcc/gimple-lower-accesses.cc  | 463 ++
 gcc/passes.def|   4 +
 gcc/testsuite/gcc.dg/store_merging_10.c   |   2 +-
 gcc/testsuite/gcc.dg/store_merging_14.c   |   2 +-
 gcc/testsuite/gcc.dg/store_merging_16.c   |   4 +-
 gcc/testsuite/gcc.dg/store_merging_20.c   |   2 +-
 gcc/testsuite/gcc.dg/store_merging_21.c   |   2 +-
 gcc/testsuite/gcc.dg/store_merging_24.c   |   4 +-
 gcc/testsuite/gcc.dg/store_merging_25.c   |   4 +-
 gcc/testsuite/gcc.dg/store_merging_6.c|   2 +-
 gcc/testsuite/gcc.dg/tree-ssa/20030714-1.c|  45 --
 gcc/testsuite/gcc.dg/tree-ssa/20030729-1.c|   5 +-
 gcc/testsuite/gcc.dg/tree-ssa/20030814-6.c|   5 +-
 .../gcc.dg/tree-ssa/loop-interchange-14.c |   2 +-
 gcc/tree-pass.h   |   1 +
 16 files changed, 485 insertions(+), 63 deletions(-)
 create mode 100644 gcc/gimple-lower-accesses.cc
 delete mode 100644 gcc/testsuite/gcc.dg/tree-ssa/20030714-1.c

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index c478ec85201..50bd28f4d04 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1338,6 +1338,7 @@ OBJS = \
$(GIMPLE_MATCH_PD_SEQ_O) \
gimple-match-exports.o \
$(GENERIC_MATCH_PD_SEQ_O) \
+   gimple-lower-accesses.o \
insn-attrtab.o \
insn-automata.o \
insn-dfatab.o \
diff --git a/gcc/gimple-lower-accesses.cc b/gcc/gimple-lower-accesses.cc
new file mode 100644
index 000..9d87acfba56
--- /dev/null
+++ b/gcc/gimple-lower-accesses.cc
@@ -0,0 +1,463 @@
+/* GIMPLE lowering bit-field and opposite endian accesses pass.
+
+   Copyright (C) 2017-2023 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "backend.h"
+#include "rtl.h"
+#include "tree.h"
+#include "gimple.h"
+#include "cfghooks.h"
+#include "tree-pass.h"
+#include "ssa.h"
+#include "fold-const.h"
+#include "stor-layout.h"
+#include "tree-eh.h"
+#include "gimplify.h"
+#include "gimple-iterator.h"
+#include "gimplify-me.h"
+#include "tree-cfg.h"
+#include "tree-dfa.h"
+#include "tree-ssa.h"
+#include "tree-ssa-propagate.h"
+#include "tree-hasher.h"
+#include "cfgloop.h"
+#include "cfganal.h"
+#include "alias.h"
+#include "expr.h"
+#include "tree-pretty-print.h"
+
+namespace {
+
+class lower_accesses
+{
+  function *fn;
+public:
+  lower_accesses (function *f) : fn(f) {}
+  unsigned int execute (void);
+};
+
+
+/* Handle reference to a bitfield EXPR.
+   If BITPOS_P is non-null assume that reference is LHS and set *BITPOS_P
+   to bit position of the field.
+   If REF_P is non-null set it to the memory reference for the encompassing
+   allocation unit.
+   Note *BITPOS_P is suitable only for BIT_FIELD_REF/BIT_FIELD_INSERT.  */
+
+tree
+extract_bitfield (tree expr, tree *bitpos_p, tree *bitsize_p,
+ bool *preversep)
+{
+  tree base, addr, ref;
+  tree base_type;
+  tree bytepos;
+  machine_mode mode1;
+  int unsignedp = false, volatilep = false, reversep = false;
+
+  poly_int64 bitsize, bitpos;
+  HOST_WIDE_INT ibitsize = 0, ibitpos = 0;
+
+  poly_uint64 bitregion_start = 0;
+  poly_uint64 bitregion_end = 0;
+
+  if (dump_file && (dump_flags & TDF_DETAILS))
+{
+  fprintf (dump_file, "Trying to expand bitfield reference: \n");
+ 

Re: [PATCH v3] Implement new RTL optimizations pass: fold-mem-offsets.

[Jeff Law via Gcc-patches]

On 7/13/23 09:05, Manolis Tsamis wrote:

In this version I have made f-m-o able to also eliminate constant
moves in addition to the add constant instructions.
This increases the number of simplified/eliminated instructions and is
a good addition for RISC style ISAs where these are more common.

This has led to pr52146.c failing in x86, which I haven't been able to
find a way to fix.
This involves directly writing to a constant address with -mx32

The code
 movl$-18874240, %eax
 movl$0, (%eax)

is 'optimized' to
 movl$0, %eax
 movl$0, -18874240(%eax)

Which is actually
 movl$0, -18874240

which is wrong per the ticket.
The fix for the ticket involved changes to legitimate_address_p which
f-m-o does call but it doesn't reject due to the existence of (%eax)
which in turn is actually zero.
I believe this is not strictly an f-m-o issue since the pass calls all
the required functions to test whether the newly synthesized memory
instruction is valid.

Any ideas on how to solve this issue is appreciated.
I wonder if costing might be useful here.  I would expect the 2nd 
sequence is the most costly of the three if address costing models are 
reasonably accurate.


Another way would be to look at the length of the memory reference insn. 
 If it's larger, then it's likely more costly.


That's what I've got off the top of my head.

Jeff

[Bug tree-optimization/110652] [14 Regression] bootstrap failure on tree-vect-stmts.cc with --enable-checking=release: error: 'new_temp' may be used uninitialized

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

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

--- Comment #4 from Kewen Lin  ---
I can't reproduce this on ppc64le with both the default bootstrapping checking
option --enable-checking=yes,extra and the reported --enable-checking=release.
I'm going to test it on cfarm x86 machine.

If the error message lineno is correct, it complains on line 10962:

  /* Collect vector loads and later create their permutation in
 vect_transform_grouped_load ().  */
  if (!costing_p && (grouped_load || slp_perm))
dr_chain.quick_push (new_temp); // line 10962

It's guarded with !costing_p and we have:

  /* One common place to cost the above vect load for different
 alignment support schemes.  */
  if (costing_p)
{
 ...
}
  else
{
  vec_dest = vect_create_destination_var (scalar_dest,
vectype);
  ...
  new_temp = make_ssa_name (vec_dest, new_stmt);  // line 10911
  ...
}

at line 10911, new_temp is always initialized for !costing_p. It looks like a
false positive.

Anyway, I'll reproduce it first on x86.

[PATCH] Initial Lunar Lake, Arrow Lake and Arrow Lake S Support

[Mo, Zewei via Gcc-patches]

Hi all,

This patch is to add initial support for Lunar Lake, Arrow Lake and Arrow Lake
S for GCC.

This link of related information is listed below:
https://www.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html

This has been tested on x86_64-pc-linux-gnu. Is this ok for trunk? Thank you.

gcc/ChangeLog:

* common/config/i386/cpuinfo.h (get_intel_cpu): Handle Lunar Lake,
Arrow Lake and Arrow Lake S.
* common/config/i386/i386-common.cc:
(processor_name): Add arrowlake.
(processor_alias_table): Add arrow lake, arrow lake s and lunar
lake.
* common/config/i386/i386-cpuinfo.h (enum processor_subtypes):
Add INTEL_COREI7_ARROWLAKE and INTEL_COREI7_ARROWLAKE_S.
* config.gcc: Add -march=arrowlake and -march=arrowlake-s.
* config/i386/driver-i386.cc (host_detect_local_cpu): Handle
arrowlake-s.
* config/i386/i386-options.cc (m_ARROWLAKE): New.
(processor_cost_table): Add arrowlake.
* config/i386/i386.h (enum processor_type):
Add PROCESSOR_ARROWLAKE.
* doc/extend.texi: Add arrowlake and arrowlake-s.
* doc/invoke.texi: Ditto.

gcc/testsuite/ChangeLog:

* g++.target/i386/mv16.C: Add arrowlake and arrowlake-s.
* gcc.target/i386/funcspec-56.inc: Handle new march.
---
 gcc/common/config/i386/cpuinfo.h  | 18 
 gcc/common/config/i386/i386-common.cc |  7 ++
 gcc/common/config/i386/i386-cpuinfo.h |  2 +
 gcc/config.gcc|  2 +-
 gcc/config/i386/driver-i386.cc|  5 +-
 gcc/config/i386/i386-c.cc |  7 ++
 gcc/config/i386/i386-options.cc   |  2 +
 gcc/config/i386/i386.h|  4 +
 gcc/config/i386/x86-tune.def  | 92 +++
 gcc/doc/extend.texi   |  6 ++
 gcc/doc/invoke.texi   | 17 
 gcc/testsuite/g++.target/i386/mv16.C  | 12 +++
 gcc/testsuite/gcc.target/i386/funcspec-56.inc |  2 +
 13 files changed, 135 insertions(+), 41 deletions(-)

diff --git a/gcc/common/config/i386/cpuinfo.h b/gcc/common/config/i386/cpuinfo.h
index 159e5f03f0b..e6f1a0ac0a1 100644
--- a/gcc/common/config/i386/cpuinfo.h
+++ b/gcc/common/config/i386/cpuinfo.h
@@ -579,6 +579,24 @@ get_intel_cpu (struct __processor_model *cpu_model,
   CHECK___builtin_cpu_is ("grandridge");
   cpu_model->__cpu_type = INTEL_GRANDRIDGE;
   break;
+case 0xc5:
+  /* Arrow Lake.  */
+  cpu = "arrowlake";
+  CHECK___builtin_cpu_is ("corei7");
+  CHECK___builtin_cpu_is ("arrowlake");
+  cpu_model->__cpu_type = INTEL_COREI7;
+  cpu_model->__cpu_subtype = INTEL_COREI7_ARROWLAKE;
+  break;
+case 0xc6:
+  /* Arrow Lake S.  */
+case 0xbd:
+  /* Lunar Lake.  */
+  cpu = "arrowlake-s";
+  CHECK___builtin_cpu_is ("corei7");
+  CHECK___builtin_cpu_is ("arrowlake-s");
+  cpu_model->__cpu_type = INTEL_COREI7;
+  cpu_model->__cpu_subtype = INTEL_COREI7_ARROWLAKE_S;
+  break;
 case 0x17:
 case 0x1d:
   /* Penryn.  */
diff --git a/gcc/common/config/i386/i386-common.cc 
b/gcc/common/config/i386/i386-common.cc
index 9b45ad61239..541f1441db8 100644
--- a/gcc/common/config/i386/i386-common.cc
+++ b/gcc/common/config/i386/i386-common.cc
@@ -2044,6 +2044,7 @@ const char *const processor_names[] =
   "alderlake",
   "rocketlake",
   "graniterapids",
+  "arrowlake",
   "intel",
   "lujiazui",
   "geode",
@@ -2167,6 +2168,12 @@ const pta processor_alias_table[] =
 M_CPU_SUBTYPE (INTEL_COREI7_ALDERLAKE), P_PROC_AVX2},
   {"graniterapids", PROCESSOR_GRANITERAPIDS, CPU_HASWELL, PTA_GRANITERAPIDS,
 M_CPU_SUBTYPE (INTEL_COREI7_GRANITERAPIDS), P_PROC_AVX512F},
+  {"arrowlake", PROCESSOR_ARROWLAKE, CPU_HASWELL, PTA_ARROWLAKE,
+M_CPU_SUBTYPE (INTEL_COREI7_ARROWLAKE), P_PROC_AVX2},
+  {"arrowlake-s", PROCESSOR_ARROWLAKE, CPU_HASWELL, PTA_ARROWLAKE_S,
+M_CPU_SUBTYPE (INTEL_COREI7_ARROWLAKE_S), P_PROC_AVX2},
+  {"lunarlake", PROCESSOR_ARROWLAKE, CPU_HASWELL, PTA_ARROWLAKE_S,
+M_CPU_SUBTYPE (INTEL_COREI7_ARROWLAKE_S), P_PROC_AVX2},
   {"bonnell", PROCESSOR_BONNELL, CPU_ATOM, PTA_BONNELL,
 M_CPU_TYPE (INTEL_BONNELL), P_PROC_SSSE3},
   {"atom", PROCESSOR_BONNELL, CPU_ATOM, PTA_BONNELL,
diff --git a/gcc/common/config/i386/i386-cpuinfo.h 
b/gcc/common/config/i386/i386-cpuinfo.h
index e6385dd56a3..b371fb792ec 100644
--- a/gcc/common/config/i386/i386-cpuinfo.h
+++ b/gcc/common/config/i386/i386-cpuinfo.h
@@ -98,6 +98,8 @@ enum processor_subtypes
   ZHAOXIN_FAM7H_LUJIAZUI,
   AMDFAM19H_ZNVER4,
   INTEL_COREI7_GRANITERAPIDS,
+  INTEL_COREI7_ARROWLAKE,
+  INTEL_COREI7_ARROWLAKE_S,
   CPU_SUBTYPE_MAX
 };
 
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 93b6e0709af..6c373a478e6 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -683,7 +683,7 @@ silvermont knl knm skylake-avx512 

Re: [PATCH] RISC-V: Remove the redundant expressions in the and3.

[Jeff Law via Gcc-patches]

On 7/13/23 20:41, Kito Cheng via Gcc-patches wrote:

Expanding without DONE or FAIL will leave the pattern as well, so this
patch is fine IMO, so this patch LGTM, but anyway I will test this and
commit if passed :)
THanks.  I looked fine to me, but I wasn't going to have the time to 
commit/push it tonight.


jeff

Re: [PATCH] RISC-V: Remove the redundant expressions in the and3.

[Jeff Law via Gcc-patches]

On 7/13/23 20:44, Palmer Dabbelt wrote:

On Thu, 13 Jul 2023 19:41:08 PDT (-0700), gcc-patches@gcc.gnu.org wrote:

Expanding without DONE or FAIL will leave the pattern as well, so this
patch is fine IMO, so this patch LGTM, but anyway I will test this and
commit if passed :)


Ah, thanks, I guess I didn't know that.  This is probably fine then, but 
we might have some code floating around we could toss...
Yea, if you fall off the end the original pattern stays in place. 
It's always been that way.


And yes, we may have a bit of redundant code and more importantly 
useless RTL generation.


jeff

[PATCH v1] RISC-V: Support basic floating-point dynamic rounding mode

[Pan Li via Gcc-patches]

From: Pan Li 

This patch would like to support the basic floating-point dynamic
rounding modes for the RVV.

We implement the dynamic rounding mode by below steps.
1. Set entry to DYN and exit to DYN_EXIT.
2. Add one rtl variable into machine_function for backup/restore.
3. Backup frm value when entry.
4. Restore frm value when exit and prev mode is not DYN.
5. Restore frm when mode switching to DYN.
6. Set frm when mode switching to STATIC.

Take one flow to describe the scenarios.

   +-+
   | Entry (DYN) | <- frrm a5
   +-+
  /   \
+---++---+
| VFADD | <- fsrm a5 | VFADD RTZ | <- fsrmi 1(RTZ)
+---++---+
  ||
+---++---+
| VFADD || VFADD RTZ |
+---++---+
  |   |
+---+ +---+
| VFADD RUP | <- fsrmi 3(RUP) | VFADD | <- fsrm a5
+---+ +---+
  |  /
+---+   /
| VFADD RUP |  /
+---+ /
   \ /
+-+
| Exit (DYN_EXIT) | <- fsrm a5
+-+

Please *NOTE* inline asm and call during the cfun will be implemented
in another PATCH(s).

Signed-off-by: Pan Li 
Co-Authored-By: Juzhe-Zhong 

gcc/ChangeLog:

* config/riscv/riscv.cc (struct machine_function): Add new field.
(riscv_static_frm_mode_p): New function.
(riscv_emit_frm_mode_set): New function for emit FRM.
(riscv_emit_mode_set): Extract function for FRM.
(riscv_mode_needed): Fix the TODO.
(riscv_mode_entry): Initial dynamic frm RTL.
(riscv_mode_exit): Return DYN_EXIT.
* config/riscv/riscv.md: Add rdfrm.
* config/riscv/vector-iterators.md (unspecv): Add DYN_EXIT unspecv.
* config/riscv/vector.md (frm_modee): Add new mode dyn_exit.
(fsrm): Removed.
(fsrmsi_backup): New pattern for swap.
(fsrmsi_restore): New pattern for restore.
(fsrmsi_restore_exit): New pattern for restore exit.
(frrmsi): New pattern for backup.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/float-point-frm-insert-1.c: Adjust
 test cases.
* gcc.target/riscv/rvv/base/float-point-frm-insert-10.c: Ditto.
* gcc.target/riscv/rvv/base/float-point-frm-insert-2.c: Ditto.
* gcc.target/riscv/rvv/base/float-point-frm-insert-3.c: Ditto.
* gcc.target/riscv/rvv/base/float-point-frm-insert-4.c: Ditto.
* gcc.target/riscv/rvv/base/float-point-frm-insert-5.c: Ditto.
* gcc.target/riscv/rvv/base/float-point-frm-insert-6.c: Ditto.
* gcc.target/riscv/rvv/base/float-point-frm-insert-7.c: Ditto.
* gcc.target/riscv/rvv/base/float-point-frm-insert-8.c: Ditto.
* gcc.target/riscv/rvv/base/float-point-frm-insert-9.c: Ditto.
* gcc.target/riscv/rvv/base/float-point-frm-run-1.c: Ditto.
* gcc.target/riscv/rvv/base/float-point-frm-run-2.c: Ditto.
* gcc.target/riscv/rvv/base/float-point-frm-run-3.c: Ditto.
* gcc.target/riscv/rvv/base/float-point-dynamic-frm-1.c: New test.
* gcc.target/riscv/rvv/base/float-point-dynamic-frm-10.c: New test.
* gcc.target/riscv/rvv/base/float-point-dynamic-frm-11.c: New test.
* gcc.target/riscv/rvv/base/float-point-dynamic-frm-12.c: New test.
* gcc.target/riscv/rvv/base/float-point-dynamic-frm-13.c: New test.
* gcc.target/riscv/rvv/base/float-point-dynamic-frm-14.c: New test.
* gcc.target/riscv/rvv/base/float-point-dynamic-frm-15.c: New test.
* gcc.target/riscv/rvv/base/float-point-dynamic-frm-16.c: New test.
* gcc.target/riscv/rvv/base/float-point-dynamic-frm-17.c: New test.
* gcc.target/riscv/rvv/base/float-point-dynamic-frm-18.c: New test.
* gcc.target/riscv/rvv/base/float-point-dynamic-frm-19.c: New test.
* gcc.target/riscv/rvv/base/float-point-dynamic-frm-2.c: New test.
* gcc.target/riscv/rvv/base/float-point-dynamic-frm-20.c: New test.
* gcc.target/riscv/rvv/base/float-point-dynamic-frm-21.c: New test.
* gcc.target/riscv/rvv/base/float-point-dynamic-frm-22.c: New test.
* gcc.target/riscv/rvv/base/float-point-dynamic-frm-23.c: New test.
* gcc.target/riscv/rvv/base/float-point-dynamic-frm-24.c: New test.
* gcc.target/riscv/rvv/base/float-point-dynamic-frm-25.c: New test.
* gcc.target/riscv/rvv/base/float-point-dynamic-frm-26.c: New test.
* gcc.target/riscv/rvv/base/float-point-dynamic-frm-27.c: New test.
* gcc.target/riscv/rvv/base/float-point-dynamic-frm-28.c: New test.
* gcc.target/riscv/rvv/base/float-point-dynamic-frm-29.c: New test.
* gcc.target/riscv/rvv/base/float-point-dynamic-frm-3.c: New test.
* 

[Bug middle-end/110659] Error from linker: .eh_frame_hdr refers to overlapping FDEs

[townsend at astro dot wisc.edu via Gcc-bugs]

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

--- Comment #7 from Rich Townsend  ---
(In reply to Andrew Pinski from comment #6)
> GCC 13 won't build with anything older than GCC 4.8.x as documented at
> https://gcc.gnu.org/install/prerequisites.html (which is right now for the
> trunk but that requirement has not changed yet).

The plot thickens -- I misidentified the compiler, here's the correct id:

[user@0ec987449fdf gcc-build]$ x86_64-pc-linux-gnu-g++ -v
Using built-in specs.
COLLECT_GCC=x86_64-pc-linux-gnu-g++
COLLECT_LTO_WRAPPER=/opt/bootstrap/mesasdk/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/user/sdk2-tmp/build/gcc/configure CC= CXX=
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --prefix=/home/user/sdk2-tmp/mesasdk
--with-gmp=/home/user/sdk2-tmp/mesasdk --with-mpfr=/home/user/sdk2-tmp/mesasdk
--with-mpc=/home/user/sdk2-tmp/mesasdk --enable-languages=c,c++,fortran
--disable-multilib --disable-nls --disable-libsanitizer
--enable-clocale=generic
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.1.0 (GCC) 

So, 12.1.0 should be perfectly capable of building 13.1, right?

RE: [x86 PATCH] Fix FAIL of gcc.target/i386/pr91681-1.c

[Jiang, Haochen via Gcc-patches]

> The recent change in TImode parameter passing on x86_64 results in the FAIL
> of pr91681-1.c.  The issue is that with the extra flexibility, the combine 
> pass is
> now spoilt for choice between using either the
> *add3_doubleword_concat or the *add3_doubleword_zext
> patterns, when one operand is a *concat and the other is a zero_extend.
> The solution proposed below is provide an
> *add3_doubleword_concat_zext define_insn_and_split, that can
> benefit both from the register allocation of *concat, and still avoid the xor
> normally required by zero extension.
> 
> I'm investigating a follow-up refinement to improve register allocation
> further by avoiding the early clobber in the =, and handling (custom)
> reloads explicitly, but this piece resolves the testcase failure.
> 
> This patch has been tested on x86_64-pc-linux-gnu with make bootstrap and
> make -k check, both with and without --target_board=unix{-m32} with no
> new failures.  Ok for mainline?
> 
> 
> 2023-07-11  Roger Sayle  
> 
> gcc/ChangeLog
> PR target/91681
> * config/i386/i386.md (*add3_doubleword_concat_zext): New
> define_insn_and_split derived from *add3_doubleword_concat
> and *add3_doubleword_zext.

Hi Roger,

This commit currently changed the codegen of testcase p443644-2.c from:

movq%rdx, %rax
xorl%edx, %edx
addq%rdi, %rax
adcq%rsi, %rdx
to:

movq%rdx, %rcx
movq%rdi, %rax
movq%rsi, %rdx
addq%rcx, %rax
adcq$0, %rdx

which causes the testcase fail under -m64.

Is this within your expectation?

BRs,
Haochen

> 
> 
> Thanks,
> Roger
> --

Re: [PATCH] RISC-V: Remove the redundant expressions in the and3.

[Palmer Dabbelt]

On Thu, 13 Jul 2023 19:41:08 PDT (-0700), gcc-patches@gcc.gnu.org wrote:

Expanding without DONE or FAIL will leave the pattern as well, so this
patch is fine IMO, so this patch LGTM, but anyway I will test this and
commit if passed :)


Ah, thanks, I guess I didn't know that.  This is probably fine then, but 
we might have some code floating around we could toss...



On Fri, Jul 14, 2023 at 10:34 AM Palmer Dabbelt  wrote:


On Thu, 13 Jul 2023 19:02:05 PDT (-0700), li...@eswincomputing.com wrote:
> When generating the gen_and3 function based on the and3
> template, it produces the expression emit_insn (gen_rtx_SET (operand0,
> gen_rtx_AND (, operand1, operand2)));, which is identical to the
> portion I removed in this patch. Therefore, the redundant portion can be
> deleted.
>
> Signed-off-by: Die Li 
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.md: Remove redundant portion in and3.
> ---
>  gcc/config/riscv/riscv.md | 5 -
>  1 file changed, 5 deletions(-)
>
> diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
> index 7988026d129..c4f8eb9488e 100644
> --- a/gcc/config/riscv/riscv.md
> +++ b/gcc/config/riscv/riscv.md
> @@ -1491,11 +1491,6 @@
> DONE;
>   }
>  }
> -  else
> -{
> -  emit_move_insn (operands[0], gen_rtx_AND (mode, operands[1], 
operands[2]));
> -  DONE;
> -}
>  })
>
>  (define_insn "*and3"

Unless I'm missing something, this will just result in no emitted
instructions for this "and" pattern?  That seems wrong, it would at
least have to put the source into the dest -- but
"arith_operand_or_mode_mask" can contain values that don't just result
in an extension (like arbitrary register values, for example), so I
think we need the "and" operation.

Does this pass the regression suite?

Either way, if this branch of the conditional can't trigger we should
tighten the constraint (or at a bare minimum add a comment as to why).

Re: [PATCH] RISC-V: Remove the redundant expressions in the and3.

[Kito Cheng via Gcc-patches]

Expanding without DONE or FAIL will leave the pattern as well, so this
patch is fine IMO, so this patch LGTM, but anyway I will test this and
commit if passed :)

On Fri, Jul 14, 2023 at 10:34 AM Palmer Dabbelt  wrote:
>
> On Thu, 13 Jul 2023 19:02:05 PDT (-0700), li...@eswincomputing.com wrote:
> > When generating the gen_and3 function based on the and3
> > template, it produces the expression emit_insn (gen_rtx_SET (operand0,
> > gen_rtx_AND (, operand1, operand2)));, which is identical to the
> > portion I removed in this patch. Therefore, the redundant portion can be
> > deleted.
> >
> > Signed-off-by: Die Li 
> >
> > gcc/ChangeLog:
> >
> > * config/riscv/riscv.md: Remove redundant portion in and3.
> > ---
> >  gcc/config/riscv/riscv.md | 5 -
> >  1 file changed, 5 deletions(-)
> >
> > diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
> > index 7988026d129..c4f8eb9488e 100644
> > --- a/gcc/config/riscv/riscv.md
> > +++ b/gcc/config/riscv/riscv.md
> > @@ -1491,11 +1491,6 @@
> > DONE;
> >   }
> >  }
> > -  else
> > -{
> > -  emit_move_insn (operands[0], gen_rtx_AND (mode, operands[1], 
> > operands[2]));
> > -  DONE;
> > -}
> >  })
> >
> >  (define_insn "*and3"
>
> Unless I'm missing something, this will just result in no emitted
> instructions for this "and" pattern?  That seems wrong, it would at
> least have to put the source into the dest -- but
> "arith_operand_or_mode_mask" can contain values that don't just result
> in an extension (like arbitrary register values, for example), so I
> think we need the "and" operation.
>
> Does this pass the regression suite?
>
> Either way, if this branch of the conditional can't trigger we should
> tighten the constraint (or at a bare minimum add a comment as to why).

Re: [PATCH] RISC-V: Remove the redundant expressions in the and3.

[Palmer Dabbelt]

On Thu, 13 Jul 2023 19:02:05 PDT (-0700), li...@eswincomputing.com wrote:

When generating the gen_and3 function based on the and3
template, it produces the expression emit_insn (gen_rtx_SET (operand0,
gen_rtx_AND (, operand1, operand2)));, which is identical to the
portion I removed in this patch. Therefore, the redundant portion can be
deleted.

Signed-off-by: Die Li 

gcc/ChangeLog:

* config/riscv/riscv.md: Remove redundant portion in and3.
---
 gcc/config/riscv/riscv.md | 5 -
 1 file changed, 5 deletions(-)

diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
index 7988026d129..c4f8eb9488e 100644
--- a/gcc/config/riscv/riscv.md
+++ b/gcc/config/riscv/riscv.md
@@ -1491,11 +1491,6 @@
  DONE;
}
 }
-  else
-{
-  emit_move_insn (operands[0], gen_rtx_AND (mode, operands[1], 
operands[2]));
-  DONE;
-}
 })

 (define_insn "*and3"


Unless I'm missing something, this will just result in no emitted 
instructions for this "and" pattern?  That seems wrong, it would at 
least have to put the source into the dest -- but 
"arith_operand_or_mode_mask" can contain values that don't just result 
in an extension (like arbitrary register values, for example), so I 
think we need the "and" operation.


Does this pass the regression suite?

Either way, if this branch of the conditional can't trigger we should 
tighten the constraint (or at a bare minimum add a comment as to why).

[r14-2462 Regression] FAIL: libgomp.c++/../libgomp.c-c++-common/alloc-12.c execution test on Linux/x86_64

[Jiang, Haochen via Gcc-patches]

On Linux/x86_64,

450b05ce54d3f08c583c3b5341233ce0df99725b is the first bad commit commit 
450b05ce54d3f08c583c3b5341233ce0df99725b
Author: Tobias Burnus 
Date:   Wed Jul 12 13:50:21 2023 +0200

libgomp: Use libnuma for OpenMP's partition=nearest allocation trait

caused


with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r14-2462/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check 
RUNTESTFLAGS="c++.exp=libgomp.c-c++-common/alloc-11.c 
--target_board='unix{-m32}'"
$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check 
RUNTESTFLAGS="c++.exp=libgomp.c-c++-common/alloc-11.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check 
RUNTESTFLAGS="c++.exp=libgomp.c-c++-common/alloc-12.c 
--target_board='unix{-m32}'"
$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check 
RUNTESTFLAGS="c++.exp=libgomp.c-c++-common/alloc-12.c 
--target_board='unix{-m32\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at haochen dot jiang at intel.com.) (If you met problems with cascadelake 
related, disabling AVX512F in command line might save that.) (However, please 
make sure that there is no potential problems with AVX512.)

[Bug target/101469] wrong code with "-O2 -fPIE" for SH

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

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

Oleg Endo  changed:

   What|Removed |Added

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

--- Comment #15 from Oleg Endo  ---
Fixed on master, GCC 13, GCC 12, GCC 11.

Should also be applied to older release branches that are maintained elsewhere.

[SH][committed] Fix PR 101469

[Oleg Endo]

Hi,

The attached patch fixes PR 101469.
Tested by the original reporter Rin Okuyama on NetBSD with GCC 10.5.
Applied to master, GCC 11, GCC 12, GCC 13 after 'make all' sanity check.

Cheers,
Oleg


gcc/ChangeLog:

PR target/101469
* config/sh/sh.md (peephole2): Handle case where eliminated reg
is also used by the address of the following memory
operand.

diff --git a/gcc/config/sh/sh.md b/gcc/config/sh/sh.md
index 4622dba0121..76e7774cef3 100644
--- a/gcc/config/sh/sh.md
+++ b/gcc/config/sh/sh.md
@@ -10680,6 +10680,45 @@
&& peep2_reg_dead_p (2, operands[1]) && peep2_reg_dead_p (3, operands[0])"
   [(const_int 0)]
 {
+  if (MEM_P (operands[3]) && reg_overlap_mentioned_p (operands[0], operands[3]))
+{
+  // Take care when the eliminated operand[0] register is part of
+  // the destination memory address.
+  rtx addr = XEXP (operands[3], 0);
+
+  if (REG_P (addr))
+	operands[3] = replace_equiv_address (operands[3], operands[1]);
+
+  else if (GET_CODE (addr) == PLUS && REG_P (XEXP (addr, 0))
+	   && CONST_INT_P (XEXP (addr, 1))
+	   && REGNO (operands[0]) == REGNO (XEXP (addr, 0)))
+	operands[3] = replace_equiv_address (operands[3],
+			gen_rtx_PLUS (SImode, operands[1], XEXP (addr, 1)));
+
+  else if (GET_CODE (addr) == PLUS && REG_P (XEXP (addr, 0))
+	   && REG_P (XEXP (addr, 1)))
+{
+  // register + register address  @(R0, Rn)
+  // can change only the Rn in the address, not R0.
+  if (REGNO (operands[0]) == REGNO (XEXP (addr, 0))
+	  && REGNO (XEXP (addr, 0)) != 0)
+	{
+	  operands[3] = replace_equiv_address (operands[3],
+			gen_rtx_PLUS (SImode, operands[1], XEXP (addr, 1)));
+	}
+  else if (REGNO (operands[0]) == REGNO (XEXP (addr, 1))
+		   && REGNO (XEXP (addr, 1)) != 0)
+{
+	  operands[3] = replace_equiv_address (operands[3],
+			gen_rtx_PLUS (SImode, XEXP (addr, 0), operands[1]));
+}
+  else
+FAIL;
+}
+  else
+FAIL;
+}
+
   emit_insn (gen_addsi3 (operands[1], operands[1], operands[2]));
   sh_peephole_emit_move_insn (operands[3], operands[1]);
 })

[Bug target/101469] wrong code with "-O2 -fPIE" for SH

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

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

--- Comment #14 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Oleg Endo
:

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

commit r13-7563-gef4b6d29d9801c970bee1b3e8675b19ef5f61d2a
Author: Oleg Endo 
Date:   Fri Jul 14 09:54:20 2023 +0900

SH: Fix PR101469 peephole bug

gcc/ChangeLog:

PR target/101469
* config/sh/sh.md (peephole2): Handle case where eliminated reg
is also used by the address of the following memory operand.

[PATCH] RISC-V: Remove the redundant expressions in the and3.

[Die Li]

When generating the gen_and3 function based on the and3
template, it produces the expression emit_insn (gen_rtx_SET (operand0,
gen_rtx_AND (, operand1, operand2)));, which is identical to the
portion I removed in this patch. Therefore, the redundant portion can be
deleted.

Signed-off-by: Die Li 

gcc/ChangeLog:

* config/riscv/riscv.md: Remove redundant portion in and3.
---
 gcc/config/riscv/riscv.md | 5 -
 1 file changed, 5 deletions(-)

diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
index 7988026d129..c4f8eb9488e 100644
--- a/gcc/config/riscv/riscv.md
+++ b/gcc/config/riscv/riscv.md
@@ -1491,11 +1491,6 @@
  DONE;
}
 }
-  else
-{
-  emit_move_insn (operands[0], gen_rtx_AND (mode, operands[1], 
operands[2]));
-  DONE;
-}
 })
 
 (define_insn "*and3"
-- 
2.17.1

[Bug c++/110661] New: Weird handing for deleting a void* pointer

[de34 at live dot cn via Gcc-bugs]

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

Bug ID: 110661
   Summary: Weird handing for deleting a void* pointer
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: de34 at live dot cn
  Target Milestone: ---

GCC accepts the following code snipped and says that " warning: deleting
'void*' is undefined". Godbolt link: https://godbolt.org/z/xKWTGrfPc

```
constexpr int test_delete_pvoid()
{
delete static_cast(new int);
return 0;
}

constexpr int n = test_delete_pvoid();
```

It's contradictory that GCC considers this undefined but accepts it in constant
evaluation.

Moreover, https://eel.is/c++draft/expr.delete#1 seemingly states that deleting
a void* pointer is ill-formed.

[Bug c/110660] New: conditional length reduction optimization

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

Bug ID: 110660
   Summary: conditional length reduction optimization
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juzhe.zhong at rivai dot ai
  Target Milestone: ---

Consider this following test:

#include 
int __attribute__((noipa))
add_loop (int32_t * __restrict x, int32_t n, int res, int * __restrict cond)
{
  for (int i = 0; i < n; ++i)
if (cond[i])
  res += x[i];
  return res;
}


Current GCC can do vectorize reduction for RVV:

   [local count: 630715945]:
  ...

  _59 = .SELECT_VL (ivtmp_57, POLY_INT_CST [4, 4]);
  ivtmp_40 = _59 * 4;
  vect__4.10_43 = .LEN_MASK_LOAD (vectp_cond.8_41, 32B, _59, 0, { -1, ... });
  mask__18.11_45 = vect__4.10_43 != { 0, ... };
  vect__7.14_49 = .LEN_MASK_LOAD (vectp_x.12_47, 32B, _59, 0, mask__18.11_45);

  vect__ifc__33.15_51 = .VCOND_MASK (mask__18.11_45, vect__7.14_49, { 0, ...
});

  vect__34.16_52 = .COND_LEN_ADD ({ -1, ... }, vect_res_19.7_38, 
  vect__ifc__33.15_51, vect_res_19.7_38, _59, 0);

  ...

   [local count: 105119324]:
  _54 = .REDUC_PLUS (vect__34.16_52);
  _55 = res_11(D) + _54;


Actually, we can optmize "VCOND_MASK + COND_LEN_ADD" into single "COND_LEN_ADD"
with replacing the argument of "COND_LEN_ADD". 

Consider this following pattern:

dummy_mask = { -1, ... }
dummy_else_value = { 0, ... } ;; This is dummy for PLUS, since a + 0 = a

op1_2 = .VCOND_MASK (control_mask, op1_1, dummy_else_value);
result = .COND_LEN_ADD (dummy_mask, op0, op1_2, op2, loop_len, bias)

Since it is using dummy_mask and dummy_else_value, we can simplify this
operation into:

result = .COND_LEN_ADD (control_mask, op0, op1_1, op2, loop_len, bias)

To do this optimization, we can either do this optimization either in
middle-end
"match.pd" or in backend "combine pass" to handle this.

Which approach is better?

Thanks.

[Bug target/101469] wrong code with "-O2 -fPIE" for SH

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

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Oleg Endo
:

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

commit r12-9772-g5f20f736c1144dd9f2ae2f99099b7f7b21a3ab4e
Author: Oleg Endo 
Date:   Fri Jul 14 09:54:20 2023 +0900

SH: Fix PR101469 peephole bug

gcc/ChangeLog:

PR target/101469
* config/sh/sh.md (peephole2): Handle case where eliminated reg
is also used by the address of the following memory operand.

[Bug target/101469] wrong code with "-O2 -fPIE" for SH

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Oleg Endo
:

https://gcc.gnu.org/g:75b8353e4b61566f7e8ac627204e2bcd6bfe60a6

commit r11-10909-g75b8353e4b61566f7e8ac627204e2bcd6bfe60a6
Author: Oleg Endo 
Date:   Fri Jul 14 09:54:20 2023 +0900

SH: Fix PR101469 peephole bug

gcc/ChangeLog:

PR target/101469
* config/sh/sh.md (peephole2): Handle case where eliminated reg
is also used by the address of the following memory operand.

[Bug target/101469] wrong code with "-O2 -fPIE" for SH

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Oleg Endo :

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

commit r14-2511-g4dbb3af1efe55174a714d15c2994cf2842ef8c28
Author: Oleg Endo 
Date:   Fri Jul 14 09:54:20 2023 +0900

SH: Fix PR101496 peephole bug

gcc/ChangeLog:

PR target/101469
* config/sh/sh.md (peephole2): Handle case where eliminated reg is
also
used by the address of the following memory operand.

[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs

[dave.anglin at bell dot net via Gcc-bugs]

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

--- Comment #8 from dave.anglin at bell dot net ---
On 2023-07-13 2:16 p.m., dave.anglin at bell dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
>
> --- Comment #7 from dave.anglin at bell dot net ---
> On 2023-07-13 1:57 p.m., dave.anglin at bell dot net wrote:
>> ./hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h:4161:36: 
>> error:
>> 'strtold' is not a member of 'std'; did you mean 'strtoll'?
> That's a problem with stdlib.h header.
I thought this was because we lack _NAMESPACE_STD_START and _NAMESPACE_STD_END
statements
around the strtold declaration in stdlib.h, but this didn't help. Maybe we lack
a define for _NAMESPACE_STD

/* ANSI C++ namespace std support */
#ifdef _NAMESPACE_STD
#define _NAMESPACE_STD_START namespace std {
#define _NAMESPACE_STD_END }

or maybe "using::strtold" additions are needed to various cstdlib files in gcc.

[Bug tree-optimization/110652] [14 Regression] bootstrap failure on tree-vect-stmts.cc with --enable-checking=release: error: 'new_temp' may be used uninitialized

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

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

Kewen Lin  changed:

   What|Removed |Added

   Last reconfirmed||2023-07-14
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #3 from Kewen Lin  ---
Thanks for reporting and I'll have a look.

[Bug target/54089] [SH] Refactor shift patterns

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

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

--- Comment #101 from Oleg Endo  ---
(In reply to Alexander Klepikov from comment #100)
> Created attachment 55513 [details]
> Arithmetic right shift late expanding
> 
> (In reply to Oleg Endo from comment #99)
> > Meanwhile, here's my iteration on your patch.
> 
> Thank you! I did all checks I did before, added testcases, and edited to fit
> the code style.

Looks OK.  Just 3 things:

> +++ gcc-13.1.0/gcc/testsuite/gcc.target/sh/pr54089-11.c   2023-07-07 
> 08:56:41.212345982 +0300
> @@ -0,0 +1,37 @@
> +/* Check that 'tst #64,r0' genrated.  */
> +/* { dg-do compile }  */
> +/* { dg-options "-O2" }  */

Please rename this test to pr49263... to have all tst #imm,r0 related tests in
one place.

Also:
  - 'genrated' -> 'generated'
  - space before opening paren of function args
  - 2 spaces indention
  - similarly, check code style of other added tests

> --- gcc-13.1.0.orig/gcc/testsuite/gcc.target/sh/pr54089-12.c  1970-01-01 
> 03:00:00.0 +0300

Can you try out Segher's suggestion in #c88 to make the regex look less
cluttered?

[Bug tree-optimization/94094] [meta-bug] store-merging and/or bswap load/store-merging missed optimizations

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
.

gcc-11-20230713 is now available

[GCC Administrator via Gcc]

Snapshot gcc-11-20230713 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/11-20230713/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-11 revision b1aa00e3b46d994a332c1570d461b4b5c696bd30

You'll find:

 gcc-11-20230713.tar.xz   Complete GCC

  SHA256=642b0141e662b0ea20cb448188108178ce3034da71538b8cdabe7b19a80c3169
  SHA1=09f0fdc183f85c6fb4b713d4a7492b75809742fd

Diffs from 11-20230706 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-11
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: Re: [PATCH] RISC-V: Enable COND_LEN_FMA auto-vectorization

[钟居哲]

Ok. Comments added:
in V2:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624476.html 




juzhe.zh...@rivai.ai
 
From: Robin Dapp
Date: 2023-07-13 23:25
To: juzhe.zhong; Kito Cheng
CC: rdapp.gcc; gcc-patches; jeffreyalaw; kito.cheng; palmer; palmer
Subject: Re: [PATCH] RISC-V: Enable COND_LEN_FMA auto-vectorization
 
> Is COND _LEN FMA ok for trunk?  I can commit it without changing
> scatter store testcase fix.
> 
> It makes no sense block cond Len fma support. The middle end support
> has already been merged.
 
Then just add a TODO or so that says e.g. "For some reason we exceed
the default code model's +-2 GiB limits.  We should investigate why and
add a proper description here.  For now just make sure the test case
compiles properly".
 
Regards
Robin
 
 

[PATCH V2] RISC-V: Enable COND_LEN_FMA auto-vectorization

[Juzhe-Zhong]

Add comments as Robin's suggestion in scatter_store_run-7.c

Enable COND_LEN_FMA auto-vectorization for floating-point FMA 
auto-vectorization **NO** ffast-math.

Since the middle-end support has been approved and I will merge it after I 
finished bootstrap && regression on X86.
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624395.html

Now, it's time to send this patch.

Consider this following case:

#define TEST_TYPE(TYPE)\
  __attribute__ ((noipa)) void ternop_##TYPE (TYPE *__restrict dst,\
  TYPE *__restrict a,  \
  TYPE *__restrict b, int n)   \
  {\
for (int i = 0; i < n; i++)\
  dst[i] += a[i] * b[i];   \
  }

#define TEST_ALL() TEST_TYPE (double)

TEST_ALL ()

Before this patch:

ternop_double:
ble a3,zero,.L5
mv  a6,a0
.L3:
vsetvli a5,a3,e64,m1,tu,ma
sllia4,a5,3
vle64.v v1,0(a0)
vle64.v v2,0(a1)
vle64.v v3,0(a2)
sub a3,a3,a5
vfmul.vvv2,v2,v3
vfadd.vvv1,v1,v2
vse64.v v1,0(a6)
add a0,a0,a4
add a1,a1,a4
add a2,a2,a4
add a6,a6,a4
bne a3,zero,.L3
.L5:
ret

After this patch:

ternop_double:
ble a3,zero,.L5
mv  a6,a0
.L3:
vsetvli a5,a3,e64,m1,tu,ma
sllia4,a5,3
vle64.v v1,0(a0)
vle64.v v2,0(a1)
vle64.v v3,0(a2)
sub a3,a3,a5
vfmacc.vv   v1,v3,v2
vse64.v v1,0(a6)
add a0,a0,a4
add a1,a1,a4
add a2,a2,a4
add a6,a6,a4
bne a3,zero,.L3
.L5:
ret

Notice: This patch only supports COND_LEN_FMA, **NO** COND_LEN_FNMA, ... etc 
since I didn't support them
in the middle-end yet.

Will support them in the following patches soon.

gcc/ChangeLog:

* config/riscv/autovec.md (cond_len_fma): New pattern.
* config/riscv/riscv-protos.h (enum insn_type): New enum.
(expand_cond_len_ternop): New function.
* config/riscv/riscv-v.cc (emit_nonvlmax_fp_ternary_tu_insn): Ditto.
(expand_cond_len_ternop): Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/gather-scatter/scatter_store_run-7.c: 
Adapt testcase for link fail.
* gcc.target/riscv/rvv/autovec/ternop/ternop_nofm-1.c: New test.
* gcc.target/riscv/rvv/autovec/ternop/ternop_nofm-2.c: New test.
* gcc.target/riscv/rvv/autovec/ternop/ternop_nofm-3.c: New test.
* gcc.target/riscv/rvv/autovec/ternop/ternop_nofm_run-1.c: New test.
* gcc.target/riscv/rvv/autovec/ternop/ternop_nofm_run-2.c: New test.
* gcc.target/riscv/rvv/autovec/ternop/ternop_nofm_run-3.c: New test.

---
 gcc/config/riscv/autovec.md   | 23 +
 gcc/config/riscv/riscv-protos.h   |  2 +
 gcc/config/riscv/riscv-v.cc   | 49 +++
 .../gather-scatter/scatter_store_run-7.c  |  6 ++-
 .../riscv/rvv/autovec/ternop/ternop_nofm-1.c  |  7 +++
 .../riscv/rvv/autovec/ternop/ternop_nofm-2.c  | 11 +
 .../riscv/rvv/autovec/ternop/ternop_nofm-3.c  |  9 
 .../rvv/autovec/ternop/ternop_nofm_run-1.c|  4 ++
 .../rvv/autovec/ternop/ternop_nofm_run-2.c|  4 ++
 .../rvv/autovec/ternop/ternop_nofm_run-3.c|  4 ++
 10 files changed, 118 insertions(+), 1 deletion(-)
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/ternop/ternop_nofm-1.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/ternop/ternop_nofm-2.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/ternop/ternop_nofm-3.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/ternop/ternop_nofm_run-1.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/ternop/ternop_nofm_run-2.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/ternop/ternop_nofm_run-3.c

diff --git a/gcc/config/riscv/autovec.md b/gcc/config/riscv/autovec.md
index 0476b1dea45..64a41bd7101 100644
--- a/gcc/config/riscv/autovec.md
+++ b/gcc/config/riscv/autovec.md
@@ -1531,3 +1531,26 @@
   riscv_vector::expand_cond_len_binop (, operands);
   DONE;
 })
+
+;; -
+;;  [FP] Conditional ternary operations
+;; -
+;; Includes:
+;; - vfmacc/...
+;; -
+
+(define_expand "cond_len_fma"
+  [(match_operand:VF 0 "register_operand")
+   (match_operand: 1 "vector_mask_operand")
+   (match_operand:VF 2 "register_operand")
+   

[Bug middle-end/97968] [11/12/13/14 Regression] Unnecessary mov instruction with comparison and cmov

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection
  Known to work||13.1.0

--- Comment #7 from Andrew Pinski  ---
In GCC 13+ we produce:
f:
xorl%eax, %eax
cmpl%esi, %edi
cmovg   %edi, %eax
ret

[Bug rtl-optimization/97756] [11/12/13/14 Regression] Inefficient handling of 128-bit arguments

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com

--- Comment #11 from Andrew Pinski  ---
This seems to be improved on trunk ...

[Bug target/110657] BPF verifier rejects generated code due to invalid stack access

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

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

--- Comment #4 from Jose E. Marchesi  ---
Looks like `combine' is generating paradoxical subregs of mems, which seem to
confuse LRA and these weird incorrect reloads end up being generated.  The
easiest fix for this is to make the backend to use the instruction scheduler,
which makes `combine' to not generate such subregs.

[Bug tree-optimization/109112] [[assume(...)]] is not taken into account for structs

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

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

--- Comment #7 from Jason Merrill  ---
In an email thread Jakub wrote:

Only the simplest assumptions in [[assume(cond)]] where there clearly aren't
any
side-effects no risks of them are lowered to if (!cond) __builtin_unreachable
();
in the IL, anything else goes into the condition being outlined in a
separate artificial function and an internal function recording the
assumption in the IL.
The optimizers then can optimize both the artificial function and the
caller.
The missed optimization thing is that currently only the value range
propagation is able to take advantage of the assumptions, and VRP
is only able to deal with scalars.
We have interprocedural optimizations like IPA scalar replacement of
aggregates etc., where we can optimize passing aggregates at function
boundaries to passing just some scalars from them if the rest isn't needed
etc., but because the assumptions aren't normal calls they'd need tweaks to
be able to optimize the assumptions too so that VRP could take advantage of
those.


Why don't the existing optimizations work on the artificial function the same
as any other function?  i.e. like

struct S { bool x; };
void do_something();
inline void assumption_1 (const S& s) noexcept {
  if (s.x) __builtin_unreachable ();
}
void fn(S s) {
  assumption_1 (s);
  if (s.x) do_something();
}

which is also optimized as expected.

[PATCH v6 2/2] libstdc++: Use new built-in trait __is_pointer

[Ken Matsui via Gcc-patches]

This patch lets libstdc++ use new built-in trait __is_pointer.

libstdc++-v3/ChangeLog:

* include/bits/cpp_type_traits.h (__is_ptr): Use __is_pointer
built-in trait.
* include/std/type_traits (is_pointer): Likewise. Optimize its
implementation.
(is_pointer_v): Likewise.

Co-authored-by: Jonathan Wakely 
Signed-off-by: Ken Matsui 
---
 libstdc++-v3/include/bits/cpp_type_traits.h |  8 
 libstdc++-v3/include/std/type_traits| 44 +
 2 files changed, 44 insertions(+), 8 deletions(-)

diff --git a/libstdc++-v3/include/bits/cpp_type_traits.h 
b/libstdc++-v3/include/bits/cpp_type_traits.h
index 3711e4be526..4da1e7c407c 100644
--- a/libstdc++-v3/include/bits/cpp_type_traits.h
+++ b/libstdc++-v3/include/bits/cpp_type_traits.h
@@ -363,6 +363,13 @@ __INT_N(__GLIBCXX_TYPE_INT_N_3)
   //
   // Pointer types
   //
+#if __has_builtin(__is_pointer)
+  template
+struct __is_ptr : __truth_type<__is_pointer(_Tp)>
+{
+  enum { __value = __is_pointer(_Tp) };
+};
+#else
   template
 struct __is_ptr
 {
@@ -376,6 +383,7 @@ __INT_N(__GLIBCXX_TYPE_INT_N_3)
   enum { __value = 1 };
   typedef __true_type __type;
 };
+#endif
 
   //
   // An arithmetic type is an integer type or a floating point type
diff --git a/libstdc++-v3/include/std/type_traits 
b/libstdc++-v3/include/std/type_traits
index 0e7a9c9c7f3..16b2f6de536 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -515,19 +515,33 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 struct is_array<_Tp[]>
 : public true_type { };
 
-  template
-struct __is_pointer_helper
+  /// is_pointer
+#if __has_builtin(__is_pointer)
+  template
+struct is_pointer
+: public __bool_constant<__is_pointer(_Tp)>
+{ };
+#else
+  template
+struct is_pointer
 : public false_type { };
 
   template
-struct __is_pointer_helper<_Tp*>
+struct is_pointer<_Tp*>
 : public true_type { };
 
-  /// is_pointer
   template
-struct is_pointer
-: public __is_pointer_helper<__remove_cv_t<_Tp>>::type
-{ };
+struct is_pointer<_Tp* const>
+: public true_type { };
+
+  template
+struct is_pointer<_Tp* volatile>
+: public true_type { };
+
+  template
+struct is_pointer<_Tp* const volatile>
+: public true_type { };
+#endif
 
   /// is_lvalue_reference
   template
@@ -3168,8 +3182,22 @@ template 
 template 
   inline constexpr bool is_array_v<_Tp[_Num]> = true;
 
+#if __has_builtin(__is_pointer)
+template 
+  inline constexpr bool is_pointer_v = __is_pointer(_Tp);
+#else
 template 
-  inline constexpr bool is_pointer_v = is_pointer<_Tp>::value;
+  inline constexpr bool is_pointer_v = false;
+template 
+  inline constexpr bool is_pointer_v<_Tp*> = true;
+template 
+  inline constexpr bool is_pointer_v<_Tp* const> = true;
+template 
+  inline constexpr bool is_pointer_v<_Tp* volatile> = true;
+template 
+  inline constexpr bool is_pointer_v<_Tp* const volatile> = true;
+#endif
+
 template 
   inline constexpr bool is_lvalue_reference_v = false;
 template 
-- 
2.41.0

[PATCH v6 1/2] c++, libstdc++: Implement __is_pointer built-in trait

[Ken Matsui via Gcc-patches]

This patch implements built-in trait for std::is_pointer.

gcc/cp/ChangeLog:

* cp-trait.def: Define __is_pointer.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_POINTER.
* semantics.cc (trait_expr_value): Likewise.
(finish_trait_expr): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/ext/has-builtin-1.C: Test existence of __is_pointer.
* g++.dg/ext/is_pointer.C: New test.
* g++.dg/tm/pr46567.C (__is_pointer): Rename to ...
(__is_ptr): ... this.
* g++.dg/torture/20070621-1.C: Likewise.
* g++.dg/torture/pr57107.C: Likewise.

libstdc++-v3/ChangeLog:

* include/bits/cpp_type_traits.h (__is_pointer): Rename to ...
(__is_ptr): ... this.
* include/bits/deque.tcc: Use __is_ptr instead.
* include/bits/stl_algobase.h: Likewise.

Signed-off-by: Ken Matsui 
---
 gcc/cp/constraint.cc|  3 ++
 gcc/cp/cp-trait.def |  1 +
 gcc/cp/semantics.cc |  4 ++
 gcc/testsuite/g++.dg/ext/has-builtin-1.C|  3 ++
 gcc/testsuite/g++.dg/ext/is_pointer.C   | 51 +
 gcc/testsuite/g++.dg/tm/pr46567.C   | 22 -
 gcc/testsuite/g++.dg/torture/20070621-1.C   |  4 +-
 gcc/testsuite/g++.dg/torture/pr57107.C  |  4 +-
 libstdc++-v3/include/bits/cpp_type_traits.h |  6 +--
 libstdc++-v3/include/bits/deque.tcc |  6 +--
 libstdc++-v3/include/bits/stl_algobase.h|  6 +--
 11 files changed, 86 insertions(+), 24 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/ext/is_pointer.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index 8cf0f2d0974..30266204eb5 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -3751,6 +3751,9 @@ diagnose_trait_expr (tree expr, tree args)
 case CPTK_IS_UNION:
   inform (loc, "  %qT is not a union", t1);
   break;
+case CPTK_IS_POINTER:
+  inform (loc, "  %qT is not a pointer", t1);
+  break;
 case CPTK_IS_AGGREGATE:
   inform (loc, "  %qT is not an aggregate", t1);
   break;
diff --git a/gcc/cp/cp-trait.def b/gcc/cp/cp-trait.def
index 8b7fece0cc8..b7c263e9a77 100644
--- a/gcc/cp/cp-trait.def
+++ b/gcc/cp/cp-trait.def
@@ -82,6 +82,7 @@ DEFTRAIT_EXPR (IS_TRIVIALLY_ASSIGNABLE, 
"__is_trivially_assignable", 2)
 DEFTRAIT_EXPR (IS_TRIVIALLY_CONSTRUCTIBLE, "__is_trivially_constructible", -1)
 DEFTRAIT_EXPR (IS_TRIVIALLY_COPYABLE, "__is_trivially_copyable", 1)
 DEFTRAIT_EXPR (IS_UNION, "__is_union", 1)
+DEFTRAIT_EXPR (IS_POINTER, "__is_pointer", 1)
 DEFTRAIT_EXPR (REF_CONSTRUCTS_FROM_TEMPORARY, 
"__reference_constructs_from_temporary", 2)
 DEFTRAIT_EXPR (REF_CONVERTS_FROM_TEMPORARY, 
"__reference_converts_from_temporary", 2)
 /* FIXME Added space to avoid direct usage in GCC 13.  */
diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 8fb47fd179e..68f8a4fe85b 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -12118,6 +12118,9 @@ trait_expr_value (cp_trait_kind kind, tree type1, tree 
type2)
 case CPTK_IS_UNION:
   return type_code1 == UNION_TYPE;
 
+case CPTK_IS_POINTER:
+  return TYPE_PTR_P (type1);
+
 case CPTK_IS_ASSIGNABLE:
   return is_xible (MODIFY_EXPR, type1, type2);
 
@@ -12296,6 +12299,7 @@ finish_trait_expr (location_t loc, cp_trait_kind kind, 
tree type1, tree type2)
 case CPTK_IS_ENUM:
 case CPTK_IS_UNION:
 case CPTK_IS_SAME:
+case CPTK_IS_POINTER:
   break;
 
 case CPTK_IS_LAYOUT_COMPATIBLE:
diff --git a/gcc/testsuite/g++.dg/ext/has-builtin-1.C 
b/gcc/testsuite/g++.dg/ext/has-builtin-1.C
index f343e153e56..9dace5cbd48 100644
--- a/gcc/testsuite/g++.dg/ext/has-builtin-1.C
+++ b/gcc/testsuite/g++.dg/ext/has-builtin-1.C
@@ -146,3 +146,6 @@
 #if !__has_builtin (__remove_cvref)
 # error "__has_builtin (__remove_cvref) failed"
 #endif
+#if !__has_builtin (__is_pointer)
+# error "__has_builtin (__is_pointer) failed"
+#endif
diff --git a/gcc/testsuite/g++.dg/ext/is_pointer.C 
b/gcc/testsuite/g++.dg/ext/is_pointer.C
new file mode 100644
index 000..d6e39565950
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/is_pointer.C
@@ -0,0 +1,51 @@
+// { dg-do compile { target c++11 } }
+
+#define SA(X) static_assert((X),#X)
+
+SA(!__is_pointer(int));
+SA(__is_pointer(int*));
+SA(__is_pointer(int**));
+
+SA(__is_pointer(const int*));
+SA(__is_pointer(const int**));
+SA(__is_pointer(int* const));
+SA(__is_pointer(int** const));
+SA(__is_pointer(int* const* const));
+
+SA(__is_pointer(volatile int*));
+SA(__is_pointer(volatile int**));
+SA(__is_pointer(int* volatile));
+SA(__is_pointer(int** volatile));
+SA(__is_pointer(int* volatile* volatile));
+
+SA(__is_pointer(const volatile int*));
+SA(__is_pointer(const volatile int**));
+SA(__is_pointer(const int* volatile));
+SA(__is_pointer(volatile int* const));
+SA(__is_pointer(int* const volatile));
+SA(__is_pointer(const int** volatile));
+SA(__is_pointer(volatile int** const));
+SA(__is_pointer(int** const volatile));

Re: [PATCH] c++: redundant targ coercion for var/alias tmpls

[Jason Merrill via Gcc-patches]

On 7/13/23 11:48, Patrick Palka wrote:

On Wed, 28 Jun 2023, Patrick Palka wrote:


On Wed, Jun 28, 2023 at 11:50 AM Jason Merrill  wrote:


On 6/23/23 12:23, Patrick Palka wrote:

On Fri, 23 Jun 2023, Jason Merrill wrote:


On 6/21/23 13:19, Patrick Palka wrote:

When stepping through the variable/alias template specialization code
paths, I noticed we perform template argument coercion twice: first from
instantiate_alias_template / finish_template_variable and again from
tsubst_decl (during instantiate_template).  It should suffice to perform
coercion once.

To that end patch elides this second coercion from tsubst_decl when
possible.  We can't get rid of it completely because we don't always
specialize a variable template from finish_template_variable: we could
also be doing so directly from instantiate_template during variable
template partial specialization selection, in which case the coercion
from tsubst_decl would be the first and only coercion.


Perhaps we should be coercing in lookup_template_variable rather than
finish_template_variable?


Ah yes, there's a patch for that at
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617377.html :)


So after that patch, can we get rid of the second coercion completely?


On second thought it should be possible to get rid of it, if we
rearrange things to always pass the primary arguments to tsubst_decl,
and perform partial specialization selection from there instead of
instantiate_template.  Let me try...


Like so?  Bootstrapped and regtested on x86_64-pc-linux-gnu.

-- >8 --

When stepping through the variable/alias template specialization code
paths, I noticed we perform template argument coercion twice: first from
instantiate_alias_template / finish_template_variable and again from
tsubst_decl (during instantiate_template).  It'd be good to avoid this
redundant coercion.

It turns out that this coercion could be safely elided whenever
specializing a primary variable/alias template, because we can rely on
lookup_template_variable and instantiate_alias_template to already have
coerced the arguments.

The other situation to consider is when fully specializing a partial
variable template specialization (from instantiate_template), in which
case the passed 'args' are the (already coerced) arguments relative to
the partial template and 'argvec', the result of substitution into
DECL_TI_ARGS, are the (uncoerced) arguments relative to the primary
template, so coercion is still necessary.  We can still avoid this
coercion however if we always pass the primary variable template to
tsubst_decl from instantiate_template, and instead perform partial
specialization selection directly from tsubst_decl.  This patch
implements this approach.


The relationship between instantiate_template and tsubst_decl is pretty 
tangled.  We use the former to substitute (often deduced) template 
arguments into a template, and the latter to substitute template 
arguments into a use of a template...and also to implement the former.


For substitution of uses of a template, we expect to need to coerce the 
arguments after substitution.  But we avoid this issue for variable 
templates by keeping them as TEMPLATE_ID_EXPR until substitution time, 
so if we see a VAR_DECL in tsubst_decl it's either a non-template 
variable or under instantiate_template.


So it seems like the current coercion for variable templates is only 
needed in this case to support the redundant hash table lookup that we 
just did in instantiate_template.  Perhaps instead of doing coercion 
here or moving the partial spec lookup, we could skip the hash table 
lookup for the case of a variable template?



gcc/cp/ChangeLog:

* pt.cc (tsubst_decl) : Don't call
coerce_template_parms.  Call most_specialized_partial_spec
when fully specializing a variable template here ...
(instantiate_template): ... instead of here.  Always pass
the primary variable template pattern to tsubst_decl.
---
  gcc/cp/pt.cc | 62 +++-
  1 file changed, 27 insertions(+), 35 deletions(-)

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index fa15b75b9c5..53968b823d5 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -15194,6 +15194,7 @@ tsubst_decl (tree t, tree args, tsubst_flags_t complain)
/* Check to see if we already have the specialization we
   need.  */
tree spec = NULL_TREE;
+   tree partial_ti = NULL_TREE;
bool local_p = false;
tree ctx = DECL_CONTEXT (t);
if (!(VAR_P (t) && DECL_LOCAL_DECL_P (t))
@@ -15230,17 +15231,29 @@ tsubst_decl (tree t, tree args, tsubst_flags_t 
complain)
tmpl = DECL_TI_TEMPLATE (t);
gen_tmpl = most_general_template (tmpl);
argvec = tsubst (DECL_TI_ARGS (t), args, complain, in_decl);
-   if (argvec != error_mark_node
-   && PRIMARY_TEMPLATE_P (gen_tmpl)
-   && TMPL_ARGS_DEPTH (args) >= 

[Bug target/96050] PDP-11: 32-bit MOV from offset(Rn) overrides Rn

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

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

--- Comment #1 from pkoning at gcc dot gnu.org ---
There certainly are some missing earlyclobbers in the MD file.  Someone else
reported bad code from this and a patch to add the missing "&" fixed those. 
Curious that it doesn't for your test case; it suggests that there is an
additional issue that needs to be understood.

[Bug c++/103806] internal compiler error: in vague_linkage_p, at cp/decl2.c:2192 for pdp11-aout target

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

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

pkoning at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED

--- Comment #3 from pkoning at gcc dot gnu.org ---
At the moment there is no support for other than C.  It would be nice for that
to change; it's not particularly practical without first doing ELF.  That has
been prototyped but that work is not available, but it can probably be redone
with a reasonable amount of effort.

[Bug libstdc++/103801] Link tests are not allowed after GCC_NO_EXECUTABLES. for pdp11-aout target

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

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

pkoning at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED

Re: [V1][PATCH 0/3] New attribute "element_count" to annotate bounds for C99 FAM(PR108896)

[Kees Cook via Gcc-patches]

On Thu, Jul 06, 2023 at 06:56:21PM +, Qing Zhao wrote:
> Hi, Kees,
> 
> I have updated my V1 patch with the following changes:
> A. changed the name to "counted_by"
> B. changed the argument from a string to an identifier
> C. updated the documentation and testing cases accordingly.

Sounds great!

> 
> And then used this new gcc to test 
> https://github.com/kees/kernel-tools/blob/trunk/fortify/array-bounds.c (with 
> the following change)
> [opc@qinzhao-ol8u3-x86 Kees]$ !1091
> diff array-bounds.c array-bounds.c.org
> 32c32
> < # define __counted_by(member)   __attribute__((counted_by (member)))
> ---
> > # define __counted_by(member)   
> > __attribute__((__element_count__(#member)))
> 34c34
> < # define __counted_by(member)   __attribute__((counted_by (member)))
> ---
> > # define __counted_by(member)   /* 
> > __attribute__((__element_count__(#member))) */
> 
> Then I got the following result:
> [opc@qinzhao-ol8u3-x86 Kees]$ ./array-bounds 2>&1 | grep -v ^'#'
> TAP version 13
> 1..12
> ok 1 global.fixed_size_seen_by_bdos
> ok 2 global.fixed_size_enforced_by_sanitizer
> not ok 3 global.unknown_size_unknown_to_bdos
> not ok 4 global.unknown_size_ignored_by_sanitizer
> ok 5 global.alloc_size_seen_by_bdos
> ok 6 global.alloc_size_enforced_by_sanitizer
> not ok 7 global.element_count_seen_by_bdos
> ok 8 global.element_count_enforced_by_sanitizer
> not ok 9 global.alloc_size_with_smaller_element_count_seen_by_bdos
> not ok 10 global.alloc_size_with_smaller_element_count_enforced_by_sanitizer
> ok 11 global.alloc_size_with_bigger_element_count_seen_by_bdos
> ok 12 global.alloc_size_with_bigger_element_count_enforced_by_sanitizer
> 
> The same as your previous results. Then I took a look at all the failed 
> testing: 3, 4, 7, 9, and 10. And studied the reasons for all of them.
> 
>  in a summary, there are two major issues:
> 1.  The reason for the failed testing 7 is the same issue as I observed in 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
> Which is not a bug, it’s an expected behavior. 

In the bug, the problem is that "p" isn't known to be allocated, if I'm
reading that correctly? I'm not sure this is a reasonable behavior, but
let me get into the specific test, which looks like this:

TEST(counted_by_seen_by_bdos)
{
struct annotated *p;
int index = MAX_INDEX + unconst;

p = alloc_annotated(index);

REPORT_SIZE(p->array);
/* 1 */ EXPECT_EQ(sizeof(*p), offsetof(typeof(*p), array));
/* Check array size alone. */
/* 2 */ EXPECT_EQ(__builtin_object_size(p->array, 1), SIZE_MAX);
/* 3 */ EXPECT_EQ(__builtin_dynamic_object_size(p->array, 1), p->foo * 
sizeof(*p->array));
/* Check check entire object size. */
/* 4 */ EXPECT_EQ(__builtin_object_size(p, 1), SIZE_MAX);
/* 5 */ EXPECT_EQ(__builtin_dynamic_object_size(p, 1), sizeof(*p) + p->foo * 
sizeof(*p->array));
}

Test 1 trivially passes -- this is just a sanity check.

Test 2 should be SIZE_MAX because __bos only knows compile-time sizes.

Test 3 should pass: counted_by knows the allocation size and can be
queried as part of the "p" object.

Test 4 should be SIZE_MAX because __bos only knows compile-time sizes.

Test 5 should pass as well, since, again, p can be examined. Passing p
to __bdos implies it is allocated and the __counted_by annotation can be
examined.

If "return p->array[index];" would be caught by the sanitizer, then
it follows that __builtin_dynamic_object_size(p, 1) must also know the
size. i.e. both must examine "p" and its trailing flexible array and
__counted_by annotation.

> 
> 2. The common issue for  the failed testing 3, 4, 9, 10 is:
> 
> for the following annotated structure: 
> 
> 
> struct annotated {
> unsigned long flags;
> size_t foo;
> int array[] __attribute__((counted_by (foo)));
> };
> 
> 
> struct annotated *p;
> int index = 16;
> 
> p = malloc(sizeof(*p) + index * sizeof(*p->array));  // allocated real size 
> 
> p->foo = index + 2;  // p->foo was set by a different value than the real 
> size of p->array as in test 9 and 10

Right, tests 9 and 10 are checking that the _smallest_ possible value of
the array is used. (There are two sources of information: the allocation
size and the size calculated by counted_by. The smaller of the two
should be used when both are available.)

> or
> p->foo was not set to any value as in test 3 and 4

For tests 3 and 4, yes, this was my mistake. I have fixed up the tests
now. Bill noticed the same issue. Sorry for the think-o!

> 
> 
> i.e, the value of p->foo is NOT synced with the number of elements allocated 
> for the array p->array.  
> 
> I think that this should be considered as an user error, and the 
> documentation of the attribute should include
> this requirement.  (In the LLVM’s RFC, such requirement was included in the 
> programing model: 
> 

[Bug tree-optimization/105834] [13/14 Regression] Dead Code Elimination Regression at -O2 (trunk vs. 12.1.0)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection
  Known to work||14.0

--- Comment #4 from Andrew Pinski  ---
Looks to be fixed on the trunk.

We also now get from evrp:
Global Exported: c_5 = [irange] int [0, 0][3, 3]

[Bug tree-optimization/96945] unused std::vector is not always optimized away

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |tree-optimization
   Last reconfirmed||2023-07-13
 Status|UNCONFIRMED |NEW
Summary|optimizations regression|unused std::vector is not
   |when defaulting copy|always optimized away
   |constructor |
 Ever confirmed|0   |1
   Severity|normal  |enhancement

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

In the case of having a move constructor, there is a loop generated for the
constructor (and since this is an empty struct, the loop is empty).
In the case of not having a move constructo, we get:
  MEM  [(char * {ref-all})_30] = MEM 
[(char * {ref-all})];



In the end DSE does not remove that store even though it is dead right before
the operator delete.

  _30 = operator new (3);
  MEM  [(char * {ref-all})_30] = MEM 
[(char * {ref-all})];
  D.26026 ={v} {CLOBBER(eol)};
  operator delete (_30, 3); [tail call]

Also if we add an field and initialize it to 0, we get a memcpy:
  __builtin_memcpy (_40, , 12);
Which is also not DSEd:
  _40 = operator new (12);
  __builtin_memcpy (_40, , 12);
  D.26033 ={v} {CLOBBER(eol)};
  operator delete (_40, 12); [tail call]

Maybe the clobber is getting in the way here 

Re: [PATCH V4, rs6000] Disable generation of scalar modulo instructions

[Pat Haugen via Gcc-patches]

Ping.

On 6/30/23 2:26 PM, Pat Haugen via Gcc-patches wrote:

Updated from prior version to address latest review comment (simplify
umod3).

Disable generation of scalar modulo instructions.

It was recently discovered that the scalar modulo instructions can suffer
noticeable performance issues for certain input values. This patch disables
their generation since the equivalent div/mul/sub sequence does not suffer
the same problem.

Bootstrapped and regression tested on powerpc64/powerpc64le.
Ok for master and backports after burn in?

-Pat


2023-06-30  Pat Haugen  

gcc/
     * config/rs6000/rs6000.cc (rs6000_rtx_costs): Check if disabling
     scalar modulo.
     * config/rs6000/rs6000.h (RS6000_DISABLE_SCALAR_MODULO): New.
     * config/rs6000/rs6000.md (mod3, *mod3): Disable.
     (define_expand umod3): New.
     (define_insn umod3): Rename to *umod3 and disable.
     (umodti3, modti3): Disable.

gcc/testsuite/
     * gcc.target/powerpc/clone1.c: Add xfails.
     * gcc.target/powerpc/clone3.c: Likewise.
     * gcc.target/powerpc/mod-1.c: Update scan strings and add xfails.
     * gcc.target/powerpc/mod-2.c: Likewise.
     * gcc.target/powerpc/p10-vdivq-vmodq.c: Add xfails.

[Bug libstdc++/103801] Link tests are not allowed after GCC_NO_EXECUTABLES. for pdp11-aout target

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

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

pkoning at gcc dot gnu.org changed:

   What|Removed |Added

 CC||pkoning at gcc dot gnu.org

--- Comment #5 from pkoning at gcc dot gnu.org ---
There is no pdp11 support in newlib (and never was as far as I know; it's not a
matter of it having been "removed").  I've played with creating one, but not
enough to submit the result.

But that doesn't make the pdp11 target meaningless or say it needs to be
removed.  The only consequence of the lack of an off the shelf library package
is that you can't run the execution testsuite.  But you can, for example, run
the compile part of the testsuite.

[Bug target/107841] Incorrect generation of the function's epilogue code when there is a _builtin_alloca call.

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

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

pkoning at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from pkoning at gcc dot gnu.org ---
Fixed by the patch from Mikael Petterson.

Re: [PATCH] fix pdp11_expand_epilogue (PR target/107841)

[Paul Koning via Gcc-patches]

> On Jul 13, 2023, at 12:47 PM, Mikael Pettersson  wrote:
> 
> If the stack frame only contains an alloca area, then
> pdp11_expand_epilogue fails to deallocate it, resulting
> in callee-saved registers and the return address being
> restored from the wrong stack slots.  Fixed by adding
> || cfun->calls_alloca to the condition for deallocating
> the frame.
> 
> Tested with a cross to pdp11-unknown-aout.
> 
> Ok for master? (Note: I don't have commit rights.)
> 
> gcc/
> 
>   PR target/107841
>   * config/pdp11/pdp11.c (pdp11_expand_epilogue): Also
>   deallocate alloca-only frame.
> 
> gcc/testsuite/
> 
>   PR target/107841
>   * gcc.target/pdp11/pr107841.c: New test.
> ---
> gcc/config/pdp11/pdp11.cc |  2 +-
> gcc/testsuite/gcc.target/pdp11/pr107841.c | 12 
> 2 files changed, 13 insertions(+), 1 deletion(-)
> create mode 100644 gcc/testsuite/gcc.target/pdp11/pr107841.c
> 
> diff --git a/gcc/config/pdp11/pdp11.cc b/gcc/config/pdp11/pdp11.cc
> index f6dd841f184..311a1d225e0 100644
> --- a/gcc/config/pdp11/pdp11.cc
> +++ b/gcc/config/pdp11/pdp11.cc
> @@ -393,7 +393,7 @@ pdp11_expand_epilogue (void)
>   rtx x, reg, via_ac = NULL;
> 
>   /* Deallocate the local variables.  */
> -  if (fsize)
> +  if (fsize || cfun->calls_alloca)
> {
>   if (frame_pointer_needed)
>   {
> diff --git a/gcc/testsuite/gcc.target/pdp11/pr107841.c 
> b/gcc/testsuite/gcc.target/pdp11/pr107841.c
> new file mode 100644
> index 000..a363c468b0b
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/pdp11/pr107841.c
> @@ -0,0 +1,12 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2" } */
> +
> +/* Verify that the stack frame is deallocated using the frame pointer.  */
> +
> +void qq (int a)
> +{
> +char *s = __builtin_alloca (128);
> +__builtin_sprintf (s, "qq %d", 3);
> +}
> +
> +/* { dg-final { scan-assembler "mov\tr5,sp" } } */
> -- 
> 2.41.0
> 


Thanks Mikael.  I committed this fix.

paul

[Bug target/107841] Incorrect generation of the function's epilogue code when there is a _builtin_alloca call.

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Paul Koning :

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

commit r14-2509-g8f1a26ee259f72e42405b9c5f2b161042ec4014b
Author: Mikael Pettersson 
Date:   Thu Jul 13 16:06:39 2023 -0400

pdp11: Fix epilogue generation [PR107841]

gcc/

PR target/107841
* config/pdp11/pdp11.cc (pdp11_expand_epilogue): Also
deallocate alloca-only frame.

gcc/testsuite/

PR target/107841
* gcc.target/pdp11/pr107841.c: New test.

[Bug c++/96533] ICE with three-way comparison when error occurs in templated operator< overload and -Wunused-parameter

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #11 from Patrick Palka  ---
Thus fixed.  Adding a testcase for this issue doesn't seem super worthwhile.

Re: [PATCH v2 1/2] c++, libstdc++: implement __is_pointer built-in trait

[Ken Matsui via Gcc-patches]

On Thu, Jul 13, 2023 at 2:22 AM Jonathan Wakely  wrote:
>
> On Wed, 12 Jul 2023 at 21:42, Ken Matsui  wrote:
> >
> > On Wed, Jul 12, 2023 at 3:01 AM Jonathan Wakely  wrote:
> > >
> > > On Mon, 10 Jul 2023 at 06:51, Ken Matsui via Libstdc++
> > >  wrote:
> > > >
> > > > Hi,
> > > >
> > > > Here is the benchmark result for is_pointer:
> > > >
> > > > https://github.com/ken-matsui/gcc-benches/blob/main/is_pointer.md#sun-jul--9-103948-pm-pdt-2023
> > > >
> > > > Time: -62.1344%
> > > > Peak Memory Usage: -52.4281%
> > > > Total Memory Usage: -53.5889%
> > >
> > > Wow!
> > >
> > > Although maybe we could have improved our std::is_pointer_v anyway, like 
> > > so:
> > >
> > > template 
> > >   inline constexpr bool is_pointer_v = false;
> > > template 
> > >   inline constexpr bool is_pointer_v<_Tp*> = true;
> > > template 
> > >   inline constexpr bool is_pointer_v<_Tp* const> = true;
> > > template 
> > >   inline constexpr bool is_pointer_v<_Tp* volatile> = true;
> > > template 
> > >   inline constexpr bool is_pointer_v<_Tp* const volatile> = true;
> > >
> > > I'm not sure why I didn't already do that.
> > >
> > > Could you please benchmark that? And if it is better than the current
> > > impl using is_pointer<_Tp>::value then we should do this in the
> > > library:
> > >
> > > #if __has_builtin(__is_pointer)
> > > template 
> > >   inline constexpr bool is_pointer_v = __is_pointer(_Tp);
> > > #else
> > > template 
> > >   inline constexpr bool is_pointer_v = false;
> > > template 
> > >   inline constexpr bool is_pointer_v<_Tp*> = true;
> > > template 
> > >   inline constexpr bool is_pointer_v<_Tp* const> = true;
> > > template 
> > >   inline constexpr bool is_pointer_v<_Tp* volatile> = true;
> > > template 
> > >   inline constexpr bool is_pointer_v<_Tp* const volatile> = true;
> > > #endif
> >
> > Hi François and Jonathan,
> >
> > Thank you for your reviews! I will rename the four underscores to the
> > appropriate name and take a benchmark once I get home.
> >
> > If I apply your change on is_pointer_v, is it better to add the
> > `Co-authored-by:` line in the commit?
>
> Yes, that would be the correct thing to do (although in this case the
> change is small enough that I don't really care about getting credit
> for it :-)
>
Thank you! I will include it in my commit :) I see that you included
the DCO sign-off in the MAINTAINERS file. However, if a reviewer
doesn't, should I include the `Signed-off-by:` line for the reviewer
as well?

Re: [PATCH 0/3] Fix argument evaluation order [PR92178]

[Harald Anlauf via Gcc-patches]

Hi Mikael,

Am 11.07.23 um 12:32 schrieb Mikael Morin via Gcc-patches:

Hello,

this is a followup to Harald's recent work [1] on the evaluation order
of arguments, when one of them is passed to an intent(out) allocatable
dummy and is deallocated before the call.
This extends Harald's fix to support:
  - scalars passed to assumed rank dummies (patch 1),
  - scalars passed to assumed rank dummies with the data reference
  depending on its own content (patch 2),
  - arrays with the data reference depending on its own content
  (patch 3).

There is one (last?) case which is not supported, for which I have opened
a separate PR [2].

Regression tested on x86_64-pc-linux-gnu. OK for master?


this is an impressive improvement for the CLASS case.  Maybe Paul
wants to have another look at it, but it is OK from my side.

Thanks for the patch!

Harald


[1] https://gcc.gnu.org/pipermail/fortran/2023-July/059562.html
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110618

Mikael Morin (3):
   fortran: defer class wrapper initialization after deallocation
 [PR92178]
   fortran: Factor data references for scalar class argument wrapping
 [PR92178]
   fortran: Reorder array argument evaluation parts [PR92178]

  gcc/fortran/trans-array.cc  |   3 +
  gcc/fortran/trans-expr.cc   | 130 +---
  gcc/fortran/trans.cc|  28 +
  gcc/fortran/trans.h |   8 +-
  gcc/testsuite/gfortran.dg/intent_out_19.f90 |  22 
  gcc/testsuite/gfortran.dg/intent_out_20.f90 |  33 +
  gcc/testsuite/gfortran.dg/intent_out_21.f90 |  33 +
  7 files changed, 236 insertions(+), 21 deletions(-)
  create mode 100644 gcc/testsuite/gfortran.dg/intent_out_19.f90
  create mode 100644 gcc/testsuite/gfortran.dg/intent_out_20.f90
  create mode 100644 gcc/testsuite/gfortran.dg/intent_out_21.f90

[Bug middle-end/110659] Error from linker: .eh_frame_hdr refers to overlapping FDEs

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

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

--- Comment #6 from Andrew Pinski  ---
GCC 13 won't build with anything older than GCC 4.8.x as documented at
https://gcc.gnu.org/install/prerequisites.html (which is right now for the
trunk but that requirement has not changed yet).

[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine

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

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #18 from Mikael Morin  ---
Followup patches submitted:
https://gcc.gnu.org/pipermail/fortran/2023-July/059580.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624081.html

[Bug middle-end/110659] Error from linker: .eh_frame_hdr refers to overlapping FDEs

[townsend at astro dot wisc.edu via Gcc-bugs]

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

--- Comment #5 from Rich Townsend  ---
(In reply to Andrew Pinski from comment #2)
> What compiler did you start with?
> That is what is the output of `x86_64-pc-linux-gnu-g++ -v` ?

[user@60947d0cbd04 ~]$ x86_64-pc-linux-gnu-g++ -v
bash: x86_64-pc-linux-gnu-g++: command not found

[user@60947d0cbd04 ~]$ g++ -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --disable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20080704 (Red Hat 4.1.2-55)

[Bug fortran/110618] Dependency between arguments when one is allocatable array whose dummy is intent(out)

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

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

Mikael Morin  changed:

   What|Removed |Added

   Last reconfirmed||2023-07-13
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |mikael at gcc dot 
gnu.org

--- Comment #2 from Mikael Morin  ---
Patches submitted:
https://gcc.gnu.org/pipermail/fortran/2023-July/059596.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624384.html

[Bug middle-end/110659] Error from linker: .eh_frame_hdr refers to overlapping FDEs

[townsend at astro dot wisc.edu via Gcc-bugs]

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

--- Comment #4 from Rich Townsend  ---
Someone else seems to have the same problem:

https://stackoverflow.com/questions/76375244/how-can-i-resolve-a-ld-eh-frame-hdr-refers-to-overlapping-fdes-error-during

...although there is no fix suggested.

[Bug middle-end/110659] Error from linker: .eh_frame_hdr refers to overlapping FDEs

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-07-13
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
To build an GCC 13, you might need to bootstrap GCC 10 (which is just c++98
code rather than C++11) and then bootstrap GCC 13.

[Bug middle-end/110659] Error from linker: .eh_frame_hdr refers to overlapping FDEs

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

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

--- Comment #2 from Andrew Pinski  ---
What compiler did you start with?
That is what is the output of `x86_64-pc-linux-gnu-g++ -v` ?

[Bug middle-end/110659] Error from linker: .eh_frame_hdr refers to overlapping FDEs

[townsend at astro dot wisc.edu via Gcc-bugs]

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

--- Comment #1 from Rich Townsend  ---
I should add that this is on CentOS 5.11, running inside a Docker container.
This ships with a very old binutils, so before trying to compile gcc I
installed binutils 2.40 (built from source with --disable-gprofng).

[Bug fortran/106050] ICE in reject_statement, at fortran/parse.cc:2879 since r8-3056-g5bab4c9631c478b7

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Mikael Morin :

https://gcc.gnu.org/g:616a101848bfd5b61ffdd87ae9b1153139d916ca

commit r14-2507-g616a101848bfd5b61ffdd87ae9b1153139d916ca
Author: Mikael Morin 
Date:   Thu Jul 13 21:23:44 2023 +0200

fortran: Release symbols in reversed order [PR106050]

Release symbols in reversed order wrt the order they were allocated.
This fixes an error recovery ICE in the case of a misplaced
derived type declaration.  Such a declaration creates nested
symbols, one for the derived type and one for each type parameter,
which should be immediately released as the declaration is
rejected.  This breaks if the derived type is released first.
As the type parameter symbols are in the namespace of the derived
type, releasing the derived type releases the type parameters, so
one can't access them after that, even to release them.  Hence,
the type parameters should be released first.

PR fortran/106050

gcc/fortran/ChangeLog:

* symbol.cc (gfc_restore_last_undo_checkpoint): Release symbols
in reverse order.

gcc/testsuite/ChangeLog:

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

[Bug bootstrap/110659] New: Error from linker: .eh_frame_hdr refers to overlapping FDEs

[townsend at astro dot wisc.edu via Gcc-bugs]

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

Bug ID: 110659
   Summary: Error from linker: .eh_frame_hdr refers to overlapping
FDEs
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

I'm running into the following problem during a build of the 13.1.0 release:

x86_64-pc-linux-gnu-g++ -std=c++11   -g -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -Wconditionally-supported
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H  -DGENERATOR_FILE
-static-libstdc++ -static-libgcc  -o build/genenums \
build/genenums.o build/read-md.o build/errors.o
../build-x86_64-pc-linux-gnu/libiberty/libiberty.a
/home/user/sdk2-tmp/mesasdk/bin/ld: .eh_frame_hdr refers to overlapping FDEs
/home/user/sdk2-tmp/mesasdk/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status

This is on Linux with binutils-2.40. Configure as follows:

/home/user/sdk2-tmp/build/gcc/configure CC= CXX= --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--prefix=/home/user/sdk2-tmp/mesasdk --with-gmp=/home/user/sdk2-tmp/mesasdk
--with-mpfr=/home/user/sdk2-tmp/mesasdk --with-mpc=/home/user/sdk2-tmp/mesasdk
--enable-languages=c,c++,fortran --disable-multilib --disable-nls
--disable-libsanitizer --enable-clocale=generic

Wondering whether any of these config flags are what's causing the problem...

[Bug target/110624] Xcode 15 ld warns about -macosx_version_min

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|WAITING |RESOLVED

--- Comment #8 from Iain Sandoe  ---
so fixed by using the platform_version change.  If anyone runs into a problem
because they have makefiles/etc that build stand-alone ld lines, I guess they
will have to fix them anyway (nothing GCC can do about that).

[pushed] Darwin: Use -platform_version when available [PR110624].

[Iain Sandoe via Gcc-patches]

tested on i688, x86_64 Darwin versions with/without support for the
platform_version flag.  Checked by Rainer on macOS14. Pushed to trunk
thanks,
Iain

--- 8< ---

Later versions of the static linker support a more flexible flag to
describe the OS, OS version and SDK used to build the code.  This
replaces the functionality of '-mmacosx_version_min' (which is now
deprecated, leading to the diagnostic described in the PR).

We now use the platform_version flag when available which avoids the
diagnostic.

Signed-off-by: Iain Sandoe 

PR target/110624

gcc/ChangeLog:

* config/darwin.h (DARWIN_PLATFORM_ID): New.
(LINK_COMMAND_A): Use DARWIN_PLATFORM_ID to pass OS, OS version
and SDK data to the static linker.
---
 gcc/config/darwin.h | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/gcc/config/darwin.h b/gcc/config/darwin.h
index 714d3d5cc0d..1b538c73593 100644
--- a/gcc/config/darwin.h
+++ b/gcc/config/darwin.h
@@ -276,6 +276,14 @@ extern GTY(()) int darwin_ms_struct;
 #define DARWIN_RDYNAMIC "%{rdynamic:%nrdynamic is not supported}"
 #endif
 
+#if LD64_HAS_PLATFORM_VERSION
+#define DARWIN_PLATFORM_ID \
+  "%{mmacosx-version-min=*: -platform_version macos %* 0.0} "
+#else
+#define DARWIN_PLATFORM_ID \
+  "%{mmacosx-version-min=*:-macosx_version_min %*} "
+#endif
+
 /* Code built with mdynamic-no-pic does not support PIE/PIC, so  we disallow
these combinations; we also ensure that the no_pie option is passed to
ld64 on system versions that default to PIE when mdynamic-no-pic is given.
@@ -351,7 +359,9 @@ extern GTY(()) int darwin_ms_struct;
 LINK_PLUGIN_SPEC \
 "%{flto*:%

[Bug target/110624] Xcode 15 ld warns about -macosx_version_min

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

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

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

https://gcc.gnu.org/g:032b5da1fc781bd3c23d9caa72fb09439e7f6f3a

commit r14-2506-g032b5da1fc781bd3c23d9caa72fb09439e7f6f3a
Author: Iain Sandoe 
Date:   Thu Jul 13 07:36:51 2023 +0100

Darwin: Use -platform_version when available [PR110624].

Later versions of the static linker support a more flexible flag to
describe the OS, OS version and SDK used to build the code.  This
replaces the functionality of '-mmacosx_version_min' (which is now
deprecated, leading to the diagnostic described in the PR).

We now use the platform_version flag when available which avoids the
diagnostic.

Signed-off-by: Iain Sandoe 

PR target/110624

gcc/ChangeLog:

* config/darwin.h (DARWIN_PLATFORM_ID): New.
(LINK_COMMAND_A): Use DARWIN_PLATFORM_ID to pass OS, OS version
and SDK data to the static linker.

[Bug c++/96533] ICE with three-way comparison when error occurs in templated operator< overload and -Wunused-parameter

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

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

Patrick Palka  changed:

   What|Removed |Added

  Known to work||12.1.0, 13.1.0
  Known to fail||10.5.0, 11.4.0
 CC||ppalka at gcc dot gnu.org

--- Comment #10 from Patrick Palka  ---
This seems fixed for GCC 12+ by r12-6022-gbb2a7f80a98de3.

RE: [PATCH 12/19]middle-end: implement loop peeling and IV updates for early break.

[Tamar Christina via Gcc-patches]

> -Original Message-
> From: Richard Biener 
> Sent: Thursday, July 13, 2023 6:31 PM
> To: Tamar Christina 
> Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> Subject: Re: [PATCH 12/19]middle-end: implement loop peeling and IV
> updates for early break.
> 
> On Wed, 28 Jun 2023, Tamar Christina wrote:
> 
> > Hi All,
> >
> > This patch updates the peeling code to maintain LCSSA during peeling.
> > The rewrite also naturally takes into account multiple exits and so it 
> > didn't
> > make sense to split them off.
> >
> > For the purposes of peeling the only change for multiple exits is that the
> > secondary exits are all wired to the start of the new loop preheader when
> doing
> > epilogue peeling.
> >
> > When doing prologue peeling the CFG is kept in tact.
> >
> > For both epilogue and prologue peeling we wire through between the two
> loops any
> > PHI nodes that escape the first loop into the second loop if flow_loops is
> > specified.  The reason for this conditionality is because
> > slpeel_tree_duplicate_loop_to_edge_cfg is used in the compiler in 3 ways:
> >   - prologue peeling
> >   - epilogue peeling
> >   - loop distribution
> >
> > for the last case the loops should remain independent, and so not be
> connected.
> > Because of this propagation of only used phi nodes get_current_def can be
> used
> > to easily find the previous definitions.  However live statements that are
> > not used inside the loop itself are not propagated (since if unused, the
> moment
> > we add the guard in between the two loops the value across the bypass edge
> can
> > be wrong if the loop has been peeled.)
> >
> > This is dealt with easily enough in find_guard_arg.
> >
> > For multiple exits, while we are in LCSSA form, and have a correct DOM tree,
> the
> > moment we add the guard block we will change the dominators again.  To
> deal with
> > this slpeel_tree_duplicate_loop_to_edge_cfg can optionally return the blocks
> to
> > update without having to recompute the list of blocks to update again.
> >
> > When multiple exits and doing epilogue peeling we will also temporarily have
> an
> > incorrect VUSES chain for the secondary exits as it anticipates the final 
> > result
> > after the VDEFs have been moved.  This will thus be corrected once the code
> > motion is applied.
> >
> > Lastly by doing things this way we can remove the helper functions that
> > previously did lock step iterations to update things as it went along.
> >
> > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> >
> > Ok for master?
> 
> Not sure if I get through all of this in one go - so be prepared that
> the rest of the review follows another day.

No worries, I appreciate the reviews!
Just giving some quick replies for when you continue.

> 
> > Thanks,
> > Tamar
> >
> > gcc/ChangeLog:
> >
> > * tree-loop-distribution.cc (copy_loop_before): Pass flow_loops =
> false.
> > * tree-ssa-loop-niter.cc (loop_only_exit_p):  Fix bug when exit==null.
> > * tree-vect-loop-manip.cc (adjust_phi_and_debug_stmts): Add
> additional
> > assert.
> > (vect_set_loop_condition_normal): Skip modifying loop IV for multiple
> > exits.
> > (slpeel_tree_duplicate_loop_to_edge_cfg): Support multiple exit
> peeling.
> > (slpeel_can_duplicate_loop_p): Likewise.
> > (vect_update_ivs_after_vectorizer): Don't enter this...
> > (vect_update_ivs_after_early_break): ...but instead enter here.
> > (find_guard_arg): Update for new peeling code.
> > (slpeel_update_phi_nodes_for_loops): Remove.
> > (slpeel_update_phi_nodes_for_guard2): Remove hardcoded edge 0
> checks.
> > (slpeel_update_phi_nodes_for_lcssa): Remove.
> > (vect_do_peeling): Fix VF for multiple exits and force epilogue.
> > * tree-vect-loop.cc (_loop_vec_info::_loop_vec_info): Initialize
> > non_break_control_flow and early_breaks.
> > (vect_need_peeling_or_partial_vectors_p): Force partial vector if
> > multiple exits and VLA.
> > (vect_analyze_loop_form): Support inner loop multiple exits.
> > (vect_create_loop_vinfo): Set LOOP_VINFO_EARLY_BREAKS.
> > (vect_create_epilog_for_reduction):  Update live phi nodes.
> > (vectorizable_live_operation): Ignore live operations in vector loop
> > when multiple exits.
> > (vect_transform_loop): Force unrolling for VF loops and multiple exits.
> > * tree-vect-stmts.cc (vect_stmt_relevant_p): Analyze ctrl statements.
> > (vect_mark_stmts_to_be_vectorized): Check for non-exit control flow
> and
> > analyze gcond params.
> > (vect_analyze_stmt): Support gcond.
> > * tree-vectorizer.cc (pass_vectorize::execute): Support multiple exits
> > in RPO pass.
> > * tree-vectorizer.h (enum vect_def_type): Add vect_early_exit_def.
> > (LOOP_VINFO_EARLY_BREAKS, LOOP_VINFO_GENERAL_CTR_FLOW):
> New.
> > (loop_vec_info_for_loop): Change to const and static.
> > (is_loop_header_bb_p): Drop assert.
> > 

[Bug c++/110619] Dangling pointer returned from constexpr function converts in nullptr

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||natattak at gmail dot com,
   ||ppalka at gcc dot gnu.org

--- Comment #5 from Patrick Palka  ---
IIUC Nathaniel's patch at
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623377.html will fix this.

[PATCH v2] c++: wrong error with static constexpr var in tmpl [PR109876]

[Marek Polacek via Gcc-patches]

On Fri, May 26, 2023 at 09:47:10PM -0400, Jason Merrill wrote:
> On 5/26/23 19:18, Marek Polacek wrote:
> > Since r8-509, we'll no longer create a static temporary var for
> > the initializer '{ 1, 2 }' for num in the attached test because
> > the code in finish_compound_literal is now guarded by
> > '&& fcl_context == fcl_c99' but it's fcl_functional here.  This
> > causes us to reject num as non-constant when evaluating it in
> > a template.
> > 
> > Jason's idea was to treat num as value-dependent even though it
> > actually isn't.  This patch implements that suggestion.
> > 
> > The is_really_empty_class check is sort of non-obvious but the
> > comment should explain why I added it.
> > 
> > Co-authored-by: Jason Merrill 
> > 
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > 
> > PR c++/109876
> > 
> > gcc/cp/ChangeLog:
> > 
> > * pt.cc (value_dependent_expression_p) : Treat a
> > constexpr-declared non-constant variable as value-dependent.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > * g++.dg/cpp0x/constexpr-template12.C: New test.
> > * g++.dg/cpp1z/constexpr-template1.C: New test.
> > ---
> >   gcc/cp/pt.cc  | 12 ++
> >   .../g++.dg/cpp0x/constexpr-template12.C   | 38 +++
> >   .../g++.dg/cpp1z/constexpr-template1.C| 25 
> >   3 files changed, 75 insertions(+)
> >   create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-template12.C
> >   create mode 100644 gcc/testsuite/g++.dg/cpp1z/constexpr-template1.C
> > 
> > diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
> > index 7fb3e75bceb..38fd8070705 100644
> > --- a/gcc/cp/pt.cc
> > +++ b/gcc/cp/pt.cc
> > @@ -27969,6 +27969,18 @@ value_dependent_expression_p (tree expression)
> > else if (TYPE_REF_P (TREE_TYPE (expression)))
> > /* FIXME cp_finish_decl doesn't fold reference initializers.  */
> > return true;
> > +  /* We have a constexpr variable and we're processing a template.  
> > When
> > +there's lifetime extension involved (for which finish_compound_literal
> > +used to create a temporary), we'll not be able to evaluate the
> > +variable until instantiating, so pretend it's value-dependent.  */
> > +  else if (DECL_DECLARED_CONSTEXPR_P (expression)
> > +  && !TREE_CONSTANT (expression)
> > +  /* When there's nothing to initialize, we'll never mark the
> > + VAR_DECL TREE_CONSTANT, therefore it would remain
> > + value-dependent and we wouldn't instantiate.  */
 
Sorry it's taken so long to get back to this.

> Interesting.  Can we change that (i.e. mark it TREE_CONSTANT) rather than
> work around it here?

I think we can.  Maybe as in the below:

-- >8 --
Since r8-509, we'll no longer create a static temporary var for
the initializer '{ 1, 2 }' for num in the attached test because
the code in finish_compound_literal is now guarded by
'&& fcl_context == fcl_c99' but it's fcl_functional here.  This
causes us to reject num as non-constant when evaluating it in
a template.

Jason's idea was to treat num as value-dependent even though it
actually isn't.  This patch implements that suggestion.

We weren't marking objects whose type is an empty class type
constant.  This patch changes that so that v_d_e_p doesn't need
to check is_really_empty_class.

Co-authored-by: Jason Merrill 

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

PR c++/109876

gcc/cp/ChangeLog:

* decl.cc (cp_finish_decl): Set TREE_CONSTANT when initializing
an object of empty class type.
* pt.cc (value_dependent_expression_p) : Treat a
constexpr-declared non-constant variable as value-dependent.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-template12.C: New test.
* g++.dg/cpp1z/constexpr-template1.C: New test.
* g++.dg/cpp1z/constexpr-template2.C: New test.
---
 gcc/cp/decl.cc| 13 +--
 gcc/cp/pt.cc  |  7 
 .../g++.dg/cpp0x/constexpr-template12.C   | 38 +++
 .../g++.dg/cpp1z/constexpr-template1.C| 25 
 .../g++.dg/cpp1z/constexpr-template2.C| 25 
 5 files changed, 105 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-template12.C
 create mode 100644 gcc/testsuite/g++.dg/cpp1z/constexpr-template1.C
 create mode 100644 gcc/testsuite/g++.dg/cpp1z/constexpr-template2.C

diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index 60f107d50c4..792ab330dd0 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -8200,7 +8200,6 @@ void
 cp_finish_decl (tree decl, tree init, bool init_const_expr_p,
tree asmspec_tree, int flags)
 {
-  tree type;
   vec *cleanups = NULL;
   const char *asmspec = NULL;
   int was_readonly = 0;
@@ -8220,7 +8219,7 @@ cp_finish_decl (tree decl, tree init, bool 
init_const_expr_p,
   /* Parameters are handled by store_parm_decls, not 

[Bug tree-optimization/110652] [14 Regression] bootstrap failure on tree-vect-stmts.cc with --enable-checking=release: error: 'new_temp' may be used uninitialized

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

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

Sergei Trofimovich  changed:

   What|Removed |Added

 CC||linkw at gcc dot gnu.org

--- Comment #2 from Sergei Trofimovich  ---
If it helps bisect landed on r14-2493-g5f03844b32f452

commit 5f03844b32f45224c33dcea08a20b5a2089082f7
Author: Kewen Lin 
Date:   Wed Jul 12 21:23:22 2023 -0500

vect: Adjust vectorizable_load costing on VMAT_CONTIGUOUS_REVERSE

Re: [PATCH] fix pdp11_expand_epilogue (PR target/107841)

[Jeff Law via Gcc-patches]

On 7/13/23 11:46, Paul Koning via Gcc-patches wrote:




On Jul 13, 2023, at 12:47 PM, Mikael Pettersson  wrote:

If the stack frame only contains an alloca area, then
pdp11_expand_epilogue fails to deallocate it, resulting
in callee-saved registers and the return address being
restored from the wrong stack slots.  Fixed by adding
|| cfun->calls_alloca to the condition for deallocating
the frame.

Tested with a cross to pdp11-unknown-aout.

Ok for master? (Note: I don't have commit rights.)


Yes, thank you!

Question for the experts: how is this handled?  Do I need to apply this change 
to my workspace and commit it, with Mikael as the change author?
That's what I usually do for someone without write access.  commit it 
locally using the --author flag, then push.


jeff

[PATCH] c++: copy elision of object arg in static memfn call [PR110441]

[Patrick Palka via Gcc-patches]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?

-- >8 --

Here the call A().f() is represented as a COMPOUND_EXPR whose first
operand is the otherwise unused object argument A() and second operand
is the call result (both are TARGET_EXPRs).  Within the return statement,
this outermost COMPOUND_EXPR ends up foiling the copy elision check in
build_special_member_call, resulting in us introducing a bogus call to the
deleted move constructor.  (Within the variable initialization, which goes
through ocp_convert instead of convert_for_initialization, we've already
been eliding the copy despite the outermost COMPOUND_EXPR ever since
r10-7410-g72809d6fe8e085 made ocp_convert look through COMPOUND_EXPR).

In contrast, I noticed '(A(), A::f())' (which should be equivalent to
the above call) is represented with the COMPOUND_EXPR inside the RHS's
TARGET_EXPR initializer thanks to a special case in cp_build_compound_expr
thus avoiding the issue.

So this patch fixes this by making keep_unused_object_arg
use cp_build_compound_expr as well.

PR c++/110441

gcc/cp/ChangeLog:

* call.cc (keep_unused_object_arg): Use cp_build_compound_expr
instead of building a COMPOUND_EXPR directly.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/elide8.C: New test.
---
 gcc/cp/call.cc  |  2 +-
 gcc/testsuite/g++.dg/cpp1z/elide8.C | 25 +
 2 files changed, 26 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1z/elide8.C

diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index 119063979fa..b0a69cb46d4 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -5218,7 +5218,7 @@ keep_unused_object_arg (tree result, tree obj, tree fn)
   if (TREE_THIS_VOLATILE (a))
 a = build_this (a);
   if (TREE_SIDE_EFFECTS (a))
-return build2 (COMPOUND_EXPR, TREE_TYPE (result), a, result);
+return cp_build_compound_expr (a, result, tf_warning_or_error);
   return result;
 }
 
diff --git a/gcc/testsuite/g++.dg/cpp1z/elide8.C 
b/gcc/testsuite/g++.dg/cpp1z/elide8.C
new file mode 100644
index 000..7d471be8a2a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/elide8.C
@@ -0,0 +1,25 @@
+// PR c++/110441
+// { dg-do compile { target c++11 } }
+
+struct immovable {
+  immovable(immovable &&) = delete;
+};
+
+struct A {
+  static immovable f();
+};
+
+immovable f() {
+  immovable m = A().f(); // { dg-error "deleted" "" { target c++14_down } }
+  return A().f(); // { dg-error "deleted" "" { target c++14_down } }
+}
+
+struct B {
+  A* operator->();
+};
+
+immovable g() {
+  B b;
+  immovable m = b->f(); // { dg-error "deleted" "" { target c++14_down } }
+  return b->f(); // { dg-error "deleted" "" { target c++14_down } }
+}
-- 
2.41.0.327.gaa9166bcc0

[Bug target/93719] Unable to find a register to spill

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

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

--- Comment #1 from pkoning at gcc dot gnu.org ---
This works with -mlra, so given the deprecation of old reload the right answer
seems to be to close this as fixed.

[Bug tree-optimization/106379] DCE depends on order

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #5)
>   _1 = ~c_5(D);
>   _2 = _1 & s_4(D);
> 
> Mine.
> That is `c < s`.  So the same as PR 106380 .

Or PR 107880 .

[Bug tree-optimization/106570] [12/13/14 Regression] DCE sometimes fails with depending if statements since r12-2305-g398572c1544d8b75

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #7 from Andrew Pinski  ---
I suspect if we optimize:
 _1 = ~c_6(D);
  _2 = _1 & s_7(D);

to:
c < s;

VRP will just work now.

(that would be PR 107880 ).

[Bug tree-optimization/101240] [missed optimization] Transitivity of less-than and less-or-equal

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

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

--- Comment #5 from Andrew Pinski  ---
here is a better testcase:
```
int test_array(unsigned ()[3]) {
  int t = (a[0]+a[1]+a[2]);
  ALWAYS_TRUE(a[0] < a[1] && a[1] < a[2]);
  return (a[0] < a[2])+t;
}
```
(just to make sure VRP is only dealing with SSA names).

We should be able to optimize the above to just
return a[0]+a[1]+a[2]+1;

[Bug fortran/110658] New: MINVAL/MAXVAL and deferred-length character arrays

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

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

Bug ID: 110658
   Summary: MINVAL/MAXVAL and deferred-length character arrays
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anlauf at gcc dot gnu.org
  Target Milestone: ---

Spin-off from pr110288:

program p
  character(len=2), allocatable :: fixed(:)
  character(len=:), allocatable :: array(:)
  fixed = ["bb", "aa"]
  array = ["bb", "aa"]
  print *, minval (fixed) ! OK
  print *, maxval (array) ! runtime error
end

While the MINVAL for the fixed-length character array works fine,
the MAXVAL for the deferred-length character array gives at runtime:

a.out: ../../../gcc-trunk/libgfortran/generated/maxval0_s1.c:68: maxval0_s1:
Assertion `xlen == len' failed.

All versions since gcc-8 (when MINVAL/MAXVAL of character was implemented)
fail.

Re: [x86 PATCH] PR target/110588: Add *bt_setncqi_2 to generate btl

[Uros Bizjak via Gcc-patches]

On Thu, Jul 13, 2023 at 7:10 PM Roger Sayle  wrote:
>
>
> This patch resolves PR target/110588 to catch another case in combine
> where the i386 backend should be generating a btl instruction.  This adds
> another define_insn_and_split to recognize the RTL representation for this
> case.
>
> I also noticed that two related define_insn_and_split weren't using the
> preferred string style for single statement preparation-statements, so
> I've reformatted these to be consistent in style with the new one.
>
> This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
> and make -k check, both with and without --target_board=unix{-m32}
> with no new failures.  Ok for mainline?
>
>
> 2023-07-13  Roger Sayle  
>
> gcc/ChangeLog
> PR target/110588
> * config/i386/i386.md (*bt_setcqi): Prefer string form
> preparation statement over braces for a single statement.
> (*bt_setncqi): Likewise.
> (*bt_setncqi_2): New define_insn_and_split.
>
> gcc/testsuite/ChangeLog
> PR target/110588
> * gcc.target/i386/pr110588.c: New test case.

+;; Help combine recognize bt followed by setnc (PR target/110588)
+(define_insn_and_split "*bt_setncqi_2"
+  [(set (match_operand:QI 0 "register_operand")
+ (eq:QI
+  (zero_extract:SWI48
+(match_operand:SWI48 1 "register_operand")
+(const_int 1)
+(zero_extend:SI (match_operand:QI 2 "register_operand")))
+  (const_int 0)))
+   (clobber (reg:CC FLAGS_REG))]
+  "TARGET_USE_BT && ix86_pre_reload_split ()"
+  "#"
+  "&& 1"
+  [(set (reg:CCC FLAGS_REG)
+(compare:CCC
+ (zero_extract:SWI48 (match_dup 1) (const_int 1) (match_dup 2))
+ (const_int 0)))
+   (set (match_dup 0)
+(ne:QI (reg:CCC FLAGS_REG) (const_int 0)))]
+  "operands[2] = lowpart_subreg (SImode, operands[2], QImode);")

I don't think the above transformation is 100% correct, mainly due to
the use of paradoxical subreg.

The combined instruction is operating with a zero_extended QImode
register, so all bits of the register are well defined. You are
splitting using paradoxical subreg, so you don't know what garbage is
there in the highpart of the count register. However, BTL/BTQ uses
modulo 64 (or 32) of this register, so even with a slightly invalid
RTX, everything checks out.

+  "operands[2] = lowpart_subreg (SImode, operands[2], QImode);")

You probably need mode instead of SImode here.

Otherwise OK.

Thanks,
Uros.

[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs

[dave.anglin at bell dot net via Gcc-bugs]

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

--- Comment #7 from dave.anglin at bell dot net ---
On 2023-07-13 1:57 p.m., dave.anglin at bell dot net wrote:
> ./hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h:4161:36: error:
> 'strtold' is not a member of 'std'; did you mean 'strtoll'?
That's a problem with stdlib.h header.

[Bug c++/108953] inefficient codegen for trivial equality

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||jengelh at inai dot de

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

[Bug c++/103733] Defaulted operator== for arrays of integral types could be done using memcmp instead of loop

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Dup of bug 108953.

Even though PR 108953 is newer, it contains more details on how to fix this and
contains a few different/better testcases and such.

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

[Bug target/59172] pdp11-aout makes a wrong code at the epilogue

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

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

pkoning at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from pkoning at gcc dot gnu.org ---
It works properly in the current release.

Re: [PATCH] m2, build: Use LDLFAGS for mklink

[Gaius Mulley via Gcc-patches]

Rainer Orth  writes:

> When trying to bootstrap current trunk on macOS 14.0 beta 3 with Xcode
> 15 beta 4, the build failed running mklink in stage 2:
>
> unset CC ; m2/boot-bin/mklink -s --langc++ --exit --name m2/mc-boot/main.cc 
> /vol/gcc/src/hg/master/darwin/gcc/m2/init/mcinit
> dyld[55825]: Library not loaded: /vol/gcc/lib/libstdc++.6.dylib
>
> While it's unclear to me why this only happens on macOS 14, the problem
> is clear: unlike other C++ executables, mklink isn't linked with
> -static-libstdc++ which is passed in from toplevel in LDFLAGS.
>
> This patch fixes that and allows the build to continue.
>
> Bootstrapped on x86_64-apple-darwin23.0.0, i386-pc-solaris2.11, and
> sparc-sun-solaris2.11.
>
> Ok for trunk?
>
>   Rainer

sure yes - and thanks for the fix,

regards,
Gaius

[Bug target/59178] Stack corruption on register save/restore when using frame pointer on pdp-11

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

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

pkoning at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from pkoning at gcc dot gnu.org ---
It works properly in the current version -- I see stack push in the prologue
and matching stack pop operations in the epilogue.

[Bug c/102989] Implement C2x's n2763 (_BitInt)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #55530|0   |1
is obsolete||

--- Comment #79 from Jakub Jelinek  ---
Created attachment 55538
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55538=edit
gcc14-bitint-wip.patch

double -> large/huge signed/unsigned _BitInt support.
Works on 8 conversions, will need to add larger testcase coverage and when
happy with double, add it for float, long double and __float128 as well.
And then large/huge signed/unsigned _BitInt support -> floating point.

[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs

[dave.anglin at bell dot net via Gcc-bugs]

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

--- Comment #6 from dave.anglin at bell dot net ---
On 2023-07-13 1:09 p.m., redi at gcc dot gnu.org wrote:
> I'm testing this, which should define std::stof and std::stold for hpux11.11:
>
> --- a/libstdc++-v3/include/bits/basic_string.h
> +++ b/libstdc++-v3/include/bits/basic_string.h
> @@ -4148,12 +4148,14 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
> stod(const string& __str, size_t* __idx = 0)
> { return __gnu_cxx::__stoa(::strtod, "stod", __str.c_str(), __idx); }
>
> -#if _GLIBCXX_USE_C99_STDLIB
> +#if _GLIBCXX_USE_C99_STDLIB || _GLIBCXX_HAVE_STRTOF
> // NB: strtof vs strtod.
> inline float
> stof(const string& __str, size_t* __idx = 0)
> { return __gnu_cxx::__stoa(::strtof, "stof", __str.c_str(), __idx); }
> +#endif
>
> +#if _GLIBCXX_USE_C99_STDLIB || _GLIBCXX_HAVE_STRTOLD
> inline long double
> stold(const string& __str, size_t* __idx = 0)
> { return __gnu_cxx::__stoa(::strtold, "stold", __str.c_str(), __idx); 
> }
> @@ -4161,7 +4163,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
> inline long double
> stold(const string& __str, size_t* __idx = 0)
> { return std::stod(__str, __idx); }
> -#endif // _GLIBCXX_USE_C99_STDLIB
> +#endif
We get this error with the above:

bash-5.1$ gcc/xg++ -Bgcc/ -o xxx xxx.cc
-I./hppa64-hp-hpux11.11/libstdc++-v3/include 
-I./hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++ 
-Lhppa64-hp-hpux11.11/libstdc++-v3/src/.libs -O2
In file included from ./hppa64-hp-hpux11.11/libstdc++-v3/include/string:54,
  from xxx.cc:1:
./hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h: In function
'long double std::__cxx11::stold(const std::string&, std::size_t*)':
./hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h:4161:36: error:
'strtold' is not a member of 'std'; did you mean 'strtoll'?
  4161 |   { return __gnu_cxx::__stoa(::strtold, "stold", __str.c_str(),
__idx); }
   |    ^~~
   |    strtoll

[Bug target/107841] Incorrect generation of the function's epilogue code when there is a _builtin_alloca call.

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

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

pkoning at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2023-07-13
 Status|UNCONFIRMED |ASSIGNED
 CC||pkoning at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug rtl-optimization/110206] [14 Regression] wrong code with -Os -march=cascadelake since r14-1246

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #15 from Uroš Bizjak  ---
Created attachment 55537
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55537=edit
Proposed patch.

v2 patch in testing.

This version prevents emission of invalid REG_EQUAL note in
cprop.cc/try_replace_reg when original, non-simplified RTX contains SUBREG. The
patch is in effect an one-liner:

@@ -795,7 +796,8 @@ try_replace_reg (rtx from, rtx to, rtx_insn *insn)
   /* If we've failed perform the replacement, have a single SET to
 a REG destination and don't yet have a note, add a REG_EQUAL note
 to not lose information.  */
-  if (!success && note == 0 && set != 0 && REG_P (SET_DEST (set)))
+  if (!success && note == 0 && set != 0 && REG_P (SET_DEST (set))
+ && !contains_paradoxical_subreg_p (SET_SRC (set)))
note = set_unique_reg_note (insn, REG_EQUAL, copy_rtx (src));
 }

but we have to move contains_paradoxical_subreg_p to rtlanal.cc.

Re: [PATCH] fix pdp11_expand_epilogue (PR target/107841)

[Paul Koning via Gcc-patches]

> On Jul 13, 2023, at 12:47 PM, Mikael Pettersson  wrote:
> 
> If the stack frame only contains an alloca area, then
> pdp11_expand_epilogue fails to deallocate it, resulting
> in callee-saved registers and the return address being
> restored from the wrong stack slots.  Fixed by adding
> || cfun->calls_alloca to the condition for deallocating
> the frame.
> 
> Tested with a cross to pdp11-unknown-aout.
> 
> Ok for master? (Note: I don't have commit rights.)

Yes, thank you!

Question for the experts: how is this handled?  Do I need to apply this change 
to my workspace and commit it, with Mikael as the change author?

paul

> 
> gcc/
> 
>   PR target/107841
>   * config/pdp11/pdp11.c (pdp11_expand_epilogue): Also
>   deallocate alloca-only frame.
> 
> gcc/testsuite/
> 
>   PR target/107841
>   * gcc.target/pdp11/pr107841.c: New test.
> ---
> gcc/config/pdp11/pdp11.cc |  2 +-
> gcc/testsuite/gcc.target/pdp11/pr107841.c | 12 
> 2 files changed, 13 insertions(+), 1 deletion(-)
> create mode 100644 gcc/testsuite/gcc.target/pdp11/pr107841.c
> 
> diff --git a/gcc/config/pdp11/pdp11.cc b/gcc/config/pdp11/pdp11.cc
> index f6dd841f184..311a1d225e0 100644
> --- a/gcc/config/pdp11/pdp11.cc
> +++ b/gcc/config/pdp11/pdp11.cc
> @@ -393,7 +393,7 @@ pdp11_expand_epilogue (void)
>   rtx x, reg, via_ac = NULL;
> 
>   /* Deallocate the local variables.  */
> -  if (fsize)
> +  if (fsize || cfun->calls_alloca)
> {
>   if (frame_pointer_needed)
>   {
> diff --git a/gcc/testsuite/gcc.target/pdp11/pr107841.c 
> b/gcc/testsuite/gcc.target/pdp11/pr107841.c
> new file mode 100644
> index 000..a363c468b0b
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/pdp11/pr107841.c
> @@ -0,0 +1,12 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2" } */
> +
> +/* Verify that the stack frame is deallocated using the frame pointer.  */
> +
> +void qq (int a)
> +{
> +char *s = __builtin_alloca (128);
> +__builtin_sprintf (s, "qq %d", 3);
> +}
> +
> +/* { dg-final { scan-assembler "mov\tr5,sp" } } */
> -- 
> 2.41.0
> 

[Bug fortran/110288] [11/12/13/14] Regression: segfault in findloc with allocatable array of allocatable characters

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

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
The fix for FINDLOC also fixes the same regression for MINLOC, MAXLOC.

There is another issue for MINVAL and MAXVAL that exists already in
10-branch, thus not a regression.  I get at runtime:


a.out: ../../../gcc-10/libgfortran/generated/maxval0_s1.c:68: maxval0_s1:
Assertion `xlen == len' failed.


Thus should be tracked separately.

Re: [PATCH 12/19]middle-end: implement loop peeling and IV updates for early break.

[Richard Biener via Gcc-patches]

On Wed, 28 Jun 2023, Tamar Christina wrote:

> Hi All,
> 
> This patch updates the peeling code to maintain LCSSA during peeling.
> The rewrite also naturally takes into account multiple exits and so it didn't
> make sense to split them off.
> 
> For the purposes of peeling the only change for multiple exits is that the
> secondary exits are all wired to the start of the new loop preheader when 
> doing
> epilogue peeling.
> 
> When doing prologue peeling the CFG is kept in tact.
> 
> For both epilogue and prologue peeling we wire through between the two loops 
> any
> PHI nodes that escape the first loop into the second loop if flow_loops is
> specified.  The reason for this conditionality is because
> slpeel_tree_duplicate_loop_to_edge_cfg is used in the compiler in 3 ways:
>   - prologue peeling
>   - epilogue peeling
>   - loop distribution
> 
> for the last case the loops should remain independent, and so not be 
> connected.
> Because of this propagation of only used phi nodes get_current_def can be used
> to easily find the previous definitions.  However live statements that are
> not used inside the loop itself are not propagated (since if unused, the 
> moment
> we add the guard in between the two loops the value across the bypass edge can
> be wrong if the loop has been peeled.)
> 
> This is dealt with easily enough in find_guard_arg.
> 
> For multiple exits, while we are in LCSSA form, and have a correct DOM tree, 
> the
> moment we add the guard block we will change the dominators again.  To deal 
> with
> this slpeel_tree_duplicate_loop_to_edge_cfg can optionally return the blocks 
> to
> update without having to recompute the list of blocks to update again.
> 
> When multiple exits and doing epilogue peeling we will also temporarily have 
> an
> incorrect VUSES chain for the secondary exits as it anticipates the final 
> result
> after the VDEFs have been moved.  This will thus be corrected once the code
> motion is applied.
> 
> Lastly by doing things this way we can remove the helper functions that
> previously did lock step iterations to update things as it went along.
> 
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> 
> Ok for master?

Not sure if I get through all of this in one go - so be prepared that
the rest of the review follows another day.

> Thanks,
> Tamar
> 
> gcc/ChangeLog:
> 
>   * tree-loop-distribution.cc (copy_loop_before): Pass flow_loops = false.
>   * tree-ssa-loop-niter.cc (loop_only_exit_p):  Fix bug when exit==null.
>   * tree-vect-loop-manip.cc (adjust_phi_and_debug_stmts): Add additional
>   assert.
>   (vect_set_loop_condition_normal): Skip modifying loop IV for multiple
>   exits.
>   (slpeel_tree_duplicate_loop_to_edge_cfg): Support multiple exit peeling.
>   (slpeel_can_duplicate_loop_p): Likewise.
>   (vect_update_ivs_after_vectorizer): Don't enter this...
>   (vect_update_ivs_after_early_break): ...but instead enter here.
>   (find_guard_arg): Update for new peeling code.
>   (slpeel_update_phi_nodes_for_loops): Remove.
>   (slpeel_update_phi_nodes_for_guard2): Remove hardcoded edge 0 checks.
>   (slpeel_update_phi_nodes_for_lcssa): Remove.
>   (vect_do_peeling): Fix VF for multiple exits and force epilogue.
>   * tree-vect-loop.cc (_loop_vec_info::_loop_vec_info): Initialize
>   non_break_control_flow and early_breaks.
>   (vect_need_peeling_or_partial_vectors_p): Force partial vector if
>   multiple exits and VLA.
>   (vect_analyze_loop_form): Support inner loop multiple exits.
>   (vect_create_loop_vinfo): Set LOOP_VINFO_EARLY_BREAKS.
>   (vect_create_epilog_for_reduction):  Update live phi nodes.
>   (vectorizable_live_operation): Ignore live operations in vector loop
>   when multiple exits.
>   (vect_transform_loop): Force unrolling for VF loops and multiple exits.
>   * tree-vect-stmts.cc (vect_stmt_relevant_p): Analyze ctrl statements.
>   (vect_mark_stmts_to_be_vectorized): Check for non-exit control flow and
>   analyze gcond params.
>   (vect_analyze_stmt): Support gcond.
>   * tree-vectorizer.cc (pass_vectorize::execute): Support multiple exits
>   in RPO pass.
>   * tree-vectorizer.h (enum vect_def_type): Add vect_early_exit_def.
>   (LOOP_VINFO_EARLY_BREAKS, LOOP_VINFO_GENERAL_CTR_FLOW): New.
>   (loop_vec_info_for_loop): Change to const and static.
>   (is_loop_header_bb_p): Drop assert.
>   (slpeel_can_duplicate_loop_p): Update prototype.
>   (class loop): Add early_breaks and non_break_control_flow.
> 
> --- inline copy of patch -- 
> diff --git a/gcc/tree-loop-distribution.cc b/gcc/tree-loop-distribution.cc
> index 
> 97879498db46dd3c34181ae9aa6e5476004dd5b5..d790ce5fffab3aa3dfc40d833a968314a4442b9e
>  100644
> --- a/gcc/tree-loop-distribution.cc
> +++ b/gcc/tree-loop-distribution.cc
> @@ -948,7 +948,7 @@ copy_loop_before (class loop *loop, bool 
> redirect_lc_phi_defs)
>

[x86 PATCH] PR target/110588: Add *bt_setncqi_2 to generate btl

[Roger Sayle]

This patch resolves PR target/110588 to catch another case in combine
where the i386 backend should be generating a btl instruction.  This adds
another define_insn_and_split to recognize the RTL representation for this
case.

I also noticed that two related define_insn_and_split weren't using the
preferred string style for single statement preparation-statements, so
I've reformatted these to be consistent in style with the new one.

This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check, both with and without --target_board=unix{-m32}
with no new failures.  Ok for mainline?


2023-07-13  Roger Sayle  

gcc/ChangeLog
PR target/110588
* config/i386/i386.md (*bt_setcqi): Prefer string form
preparation statement over braces for a single statement.
(*bt_setncqi): Likewise.
(*bt_setncqi_2): New define_insn_and_split.

gcc/testsuite/ChangeLog
PR target/110588
* gcc.target/i386/pr110588.c: New test case.


Thanks again,
Roger
--

diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index e47ced1..04eca049 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -16170,9 +16170,7 @@
  (const_int 0)))
(set (match_dup 0)
 (eq:QI (reg:CCC FLAGS_REG) (const_int 0)))]
-{
-  operands[2] = lowpart_subreg (SImode, operands[2], QImode);
-})
+  "operands[2] = lowpart_subreg (SImode, operands[2], QImode);")
 
 ;; Help combine recognize bt followed by setnc
 (define_insn_and_split "*bt_setncqi"
@@ -16193,9 +16191,7 @@
  (const_int 0)))
(set (match_dup 0)
 (ne:QI (reg:CCC FLAGS_REG) (const_int 0)))]
-{
-  operands[2] = lowpart_subreg (SImode, operands[2], QImode);
-})
+  "operands[2] = lowpart_subreg (SImode, operands[2], QImode);")
 
 (define_insn_and_split "*bt_setnc"
   [(set (match_operand:SWI48 0 "register_operand")
@@ -16219,6 +16215,27 @@
   operands[2] = lowpart_subreg (SImode, operands[2], QImode);
   operands[3] = gen_reg_rtx (QImode);
 })
+
+;; Help combine recognize bt followed by setnc (PR target/110588)
+(define_insn_and_split "*bt_setncqi_2"
+  [(set (match_operand:QI 0 "register_operand")
+   (eq:QI
+ (zero_extract:SWI48
+   (match_operand:SWI48 1 "register_operand")
+   (const_int 1)
+   (zero_extend:SI (match_operand:QI 2 "register_operand")))
+ (const_int 0)))
+   (clobber (reg:CC FLAGS_REG))]
+  "TARGET_USE_BT && ix86_pre_reload_split ()"
+  "#"
+  "&& 1"
+  [(set (reg:CCC FLAGS_REG)
+(compare:CCC
+ (zero_extract:SWI48 (match_dup 1) (const_int 1) (match_dup 2))
+ (const_int 0)))
+   (set (match_dup 0)
+(ne:QI (reg:CCC FLAGS_REG) (const_int 0)))]
+  "operands[2] = lowpart_subreg (SImode, operands[2], QImode);")
 
 ;; Store-flag instructions.
 
diff --git a/gcc/testsuite/gcc.target/i386/pr110588.c 
b/gcc/testsuite/gcc.target/i386/pr110588.c
new file mode 100644
index 000..4505c87
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr110588.c
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mtune=core2" } */
+
+unsigned char foo (unsigned char x, int y)
+{
+  int _1 = (int) x;
+  int _2 = _1 >> y;
+  int _3 = _2 & 1;
+  unsigned char _8 = (unsigned char) _3;
+  unsigned char _6 = _8 ^ 1;
+  return _6;
+}
+
+/* { dg-final { scan-assembler "btl" } } */
+/* { dg-final { scan-assembler "setnc" } } */
+/* { dg-final { scan-assembler-not "sarl" } } */
+/* { dg-final { scan-assembler-not "andl" } } */
+/* { dg-final { scan-assembler-not "xorl" } } */

[Bug libstdc++/78710] suggest better exception text for stoi, stol, ...

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs

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

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to dave.anglin from comment #3)
> On 2023-07-13 9:46 a.m., redi at gcc dot gnu.org wrote:
> > Dave, does this patch work for hppa64-hp-hpux11.11 ?
> Yes.

Great - pushed to trunk.

> On hpux, double and long double have different representations (they are
> same on linux).  hpux11.11 has both
> strtod and strtold.  strtold is checked for:
> 
> /* Define to 1 if you have the `strtof' function. */
> /* #undef HAVE_STRTOF */
> 
> /* Define to 1 if you have the `strtold' function. */
> #define HAVE_STRTOLD 1

Ah yes. That comes from libstdc++-v3/linkage.m4 which I think I've never even
looked at before!

> There doesn't seem to be a configure check for strtod.

That's from C89 and we already assume that's available unconditionally e.g. for
this code in :

  using ::strtod;
  using ::strtol;
  using ::strtoul;


I'm testing this, which should define std::stof and std::stold for hpux11.11:

--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -4148,12 +4148,14 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
   stod(const string& __str, size_t* __idx = 0)
   { return __gnu_cxx::__stoa(::strtod, "stod", __str.c_str(), __idx); }

-#if _GLIBCXX_USE_C99_STDLIB
+#if _GLIBCXX_USE_C99_STDLIB || _GLIBCXX_HAVE_STRTOF
   // NB: strtof vs strtod.
   inline float
   stof(const string& __str, size_t* __idx = 0)
   { return __gnu_cxx::__stoa(::strtof, "stof", __str.c_str(), __idx); }
+#endif

+#if _GLIBCXX_USE_C99_STDLIB || _GLIBCXX_HAVE_STRTOLD
   inline long double
   stold(const string& __str, size_t* __idx = 0)
   { return __gnu_cxx::__stoa(::strtold, "stold", __str.c_str(), __idx); }
@@ -4161,7 +4163,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
   inline long double
   stold(const string& __str, size_t* __idx = 0)
   { return std::stod(__str, __idx); }
-#endif // _GLIBCXX_USE_C99_STDLIB
+#endif

   // DR 1261. Insufficent overloads for to_string / to_wstring

[committed] libstdc++: std::stoi etc. do not need C99 support [PR110653]

[Jonathan Wakely via Gcc-patches]

Tested powerpc64le-linux. Pushed to trunk.

-- >8 --

std::stoi, std::stol, std::stoul, and std::stod only depend on C89
functions, so don't need to be guarded by _GLIBCXX_USE_C99_STDLIB

std::stoll and std::stoull don't need C99 strtoll and strtoull if
sizeof(long) == sizeof(long long).

std::stold doesn't need C99 strtold if DBL_MANT_DIG == LDBL_MANT_DIG.

This only applies to the narrow character overloads, the wchar_t
overloads depend on a separate _GLIBCXX_USE_C99_WCHAR macro and none of
them can be implemented in C89 easily.

libstdc++-v3/ChangeLog:

PR libstdc++/110653
* include/bits/basic_string.h (stoi, stol, stoul, stod): Do not
depend on _GLIBCXX_USE_C99_STDLIB.
[__LONG_WIDTH__ == __LONG_LONG_WIDTH__] (stoll, stoull): Define
in terms of stol and stoul respectively.
[__DBL_MANT_DIG__ == __LDBL_MANT_DIG__] (stold): Define in terms
of stod.
---
 libstdc++-v3/include/bits/basic_string.h | 24 +++-
 1 file changed, 19 insertions(+), 5 deletions(-)

diff --git a/libstdc++-v3/include/bits/basic_string.h 
b/libstdc++-v3/include/bits/basic_string.h
index d15f0f0589f..01e25dad20e 100644
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -4108,7 +4108,6 @@ namespace std _GLIBCXX_VISIBILITY(default)
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
 _GLIBCXX_BEGIN_NAMESPACE_CXX11
 
-#if _GLIBCXX_USE_C99_STDLIB
   // 21.4 Numeric Conversions [string.conversions].
   inline int
   stoi(const string& __str, size_t* __idx = 0, int __base = 10)
@@ -4125,6 +4124,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
   { return __gnu_cxx::__stoa(::strtoul, "stoul", __str.c_str(),
 __idx, __base); }
 
+#if _GLIBCXX_USE_C99_STDLIB
   inline long long
   stoll(const string& __str, size_t* __idx = 0, int __base = 10)
   { return __gnu_cxx::__stoa(::strtoll, "stoll", __str.c_str(),
@@ -4134,19 +4134,33 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
   stoull(const string& __str, size_t* __idx = 0, int __base = 10)
   { return __gnu_cxx::__stoa(::strtoull, "stoull", __str.c_str(),
 __idx, __base); }
+#elif __LONG_WIDTH__ == __LONG_LONG_WIDTH__
+  inline long long
+  stoll(const string& __str, size_t* __idx = 0, int __base = 10)
+  { return std::stol(__str, __idx, __base); }
 
-  // NB: strtof vs strtod.
-  inline float
-  stof(const string& __str, size_t* __idx = 0)
-  { return __gnu_cxx::__stoa(::strtof, "stof", __str.c_str(), __idx); }
+  inline unsigned long long
+  stoull(const string& __str, size_t* __idx = 0, int __base = 10)
+  { return std::stoul(__str, __idx, __base); }
+#endif
 
   inline double
   stod(const string& __str, size_t* __idx = 0)
   { return __gnu_cxx::__stoa(::strtod, "stod", __str.c_str(), __idx); }
 
+#if _GLIBCXX_USE_C99_STDLIB
+  // NB: strtof vs strtod.
+  inline float
+  stof(const string& __str, size_t* __idx = 0)
+  { return __gnu_cxx::__stoa(::strtof, "stof", __str.c_str(), __idx); }
+
   inline long double
   stold(const string& __str, size_t* __idx = 0)
   { return __gnu_cxx::__stoa(::strtold, "stold", __str.c_str(), __idx); }
+#elif __DBL_MANT_DIG__ == __LDBL_MANT_DIG__
+  inline long double
+  stold(const string& __str, size_t* __idx = 0)
+  { return std::stod(__str, __idx); }
 #endif // _GLIBCXX_USE_C99_STDLIB
 
   // DR 1261. Insufficent overloads for to_string / to_wstring
-- 
2.41.0

[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs

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

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

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

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

commit r14-2504-ga1d12752f8d45df5d7962cef6e2a87585002e982
Author: Jonathan Wakely 
Date:   Thu Jul 13 10:44:57 2023 +0100

libstdc++: std::stoi etc. do not need C99  support [PR110653]

std::stoi, std::stol, std::stoul, and std::stod only depend on C89
functions, so don't need to be guarded by _GLIBCXX_USE_C99_STDLIB

std::stoll and std::stoull don't need C99 strtoll and strtoull if
sizeof(long) == sizeof(long long).

std::stold doesn't need C99 strtold if DBL_MANT_DIG == LDBL_MANT_DIG.

This only applies to the narrow character overloads, the wchar_t
overloads depend on a separate _GLIBCXX_USE_C99_WCHAR macro and none of
them can be implemented in C89 easily.

libstdc++-v3/ChangeLog:

PR libstdc++/110653
* include/bits/basic_string.h (stoi, stol, stoul, stod): Do not
depend on _GLIBCXX_USE_C99_STDLIB.
[__LONG_WIDTH__ == __LONG_LONG_WIDTH__] (stoll, stoull): Define
in terms of stol and stoul respectively.
[__DBL_MANT_DIG__ == __LDBL_MANT_DIG__] (stold): Define in terms
of stod.

Re: [PATCH v2] Implement new RTL optimizations pass: fold-mem-offsets.

[Jeff Law via Gcc-patches]

On 7/13/23 08:20, Manolis Tsamis wrote:



I have sent a V3 which contains a number of fixes and improvements:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624439.html
I tested the new version rebased on master and the m68k issue did not reproduce.
I don't know what exactly fixed it; do we need to know why or is it
enough that the issue is gone following some general fixes?
It is highly possible that this also fixes the x264 failure. Please
let me know if the issue persists with v3 once you're able to test.

Sounds good.  I'll test both m68k and x264 on rv64 with the latest patch.

jeff

[PATCH] fix pdp11_expand_epilogue (PR target/107841)

[Mikael Pettersson via Gcc-patches]

If the stack frame only contains an alloca area, then
pdp11_expand_epilogue fails to deallocate it, resulting
in callee-saved registers and the return address being
restored from the wrong stack slots.  Fixed by adding
|| cfun->calls_alloca to the condition for deallocating
the frame.

Tested with a cross to pdp11-unknown-aout.

Ok for master? (Note: I don't have commit rights.)

gcc/

PR target/107841
* config/pdp11/pdp11.c (pdp11_expand_epilogue): Also
deallocate alloca-only frame.

gcc/testsuite/

PR target/107841
* gcc.target/pdp11/pr107841.c: New test.
---
 gcc/config/pdp11/pdp11.cc |  2 +-
 gcc/testsuite/gcc.target/pdp11/pr107841.c | 12 
 2 files changed, 13 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/pdp11/pr107841.c

diff --git a/gcc/config/pdp11/pdp11.cc b/gcc/config/pdp11/pdp11.cc
index f6dd841f184..311a1d225e0 100644
--- a/gcc/config/pdp11/pdp11.cc
+++ b/gcc/config/pdp11/pdp11.cc
@@ -393,7 +393,7 @@ pdp11_expand_epilogue (void)
   rtx x, reg, via_ac = NULL;
 
   /* Deallocate the local variables.  */
-  if (fsize)
+  if (fsize || cfun->calls_alloca)
 {
   if (frame_pointer_needed)
{
diff --git a/gcc/testsuite/gcc.target/pdp11/pr107841.c 
b/gcc/testsuite/gcc.target/pdp11/pr107841.c
new file mode 100644
index 000..a363c468b0b
--- /dev/null
+++ b/gcc/testsuite/gcc.target/pdp11/pr107841.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+/* Verify that the stack frame is deallocated using the frame pointer.  */
+
+void qq (int a)
+{
+char *s = __builtin_alloca (128);
+__builtin_sprintf (s, "qq %d", 3);
+}
+
+/* { dg-final { scan-assembler "mov\tr5,sp" } } */
-- 
2.41.0