[committed] openmp: Fix handling of target constructs in static member functions [PR106829]

[Jakub Jelinek via Gcc-patches]

On Tue, Nov 16, 2021 at 08:43:27PM +0800, Chung-Lin Tang wrote:
> 2021-11-16  Chung-Lin Tang  
> 
>   PR middle-end/92120
> 
> gcc/cp/ChangeLog:
> 
>   * semantics.c (handle_omp_array_sections_1): Add handling to create
...
>   (finish_omp_target_clauses): New function.

Just calling current_nonlambda_class_type in static member functions returns
non-NULL, but something that isn't *this and if unlucky can match part of the
IL and can be added to target clauses.
  if (DECL_NONSTATIC_MEMBER_P (decl)
  && current_class_ptr)
is a guard used elsewhere (in check_accessibility_of_qualified_id).

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk, queued for 12.3 backport.

2022-09-07  Jakub Jelinek  

PR c++/106829
* semantics.cc (finish_omp_target_clauses): If current_function_decl
isn't a nonstatic member function, don't set data.current_object to
non-NULL.

* g++.dg/gomp/pr106829.C: New test.

--- gcc/cp/semantics.cc.jj  2022-09-03 09:41:34.892005463 +0200
+++ gcc/cp/semantics.cc 2022-09-06 15:00:33.253199294 +0200
@@ -9555,16 +9555,15 @@ finish_omp_target_clauses (location_t lo
 {
   omp_target_walk_data data;
   data.this_expr_accessed = false;
+  data.current_object = NULL_TREE;
 
-  tree ct = current_nonlambda_class_type ();
-  if (ct)
-{
-  tree object = maybe_dummy_object (ct, NULL);
-  object = maybe_resolve_dummy (object, true);
-  data.current_object = object;
-}
-  else
-data.current_object = NULL_TREE;
+  if (DECL_NONSTATIC_MEMBER_P (current_function_decl) && current_class_ptr)
+if (tree ct = current_nonlambda_class_type ())
+  {
+   tree object = maybe_dummy_object (ct, NULL);
+   object = maybe_resolve_dummy (object, true);
+   data.current_object = object;
+  }
 
   if (DECL_LAMBDA_FUNCTION_P (current_function_decl))
 {
--- gcc/testsuite/g++.dg/gomp/pr106829.C.jj 2022-09-06 15:03:44.305635408 
+0200
+++ gcc/testsuite/g++.dg/gomp/pr106829.C2022-09-06 15:03:12.987055704 
+0200
@@ -0,0 +1,15 @@
+// PR c++/106829
+
+namespace std
+{
+  template  class complex;
+  template <> struct complex { complex (double); _Complex double d; };
+}
+struct S { void static foo (); };
+
+void
+S::foo ()
+{
+#pragma omp target
+  std::complex c = 0.0;
+}


Jakub

[PATCH V3] rs6000: cannot_force_const_mem for HIGH code rtx[PR106460]

[Jiufu Guo via Gcc-patches]

Hi,

As the issue in PR106460, a rtx 'high:DI (symbol_ref:DI ("var_48")' is tried
to store into constant pool and ICE occur.  But actually, this rtx represents
partial address and can not be put into a .rodata section.

This patch updates rs6000_cannot_force_const_mem to return true for rtx(s) with
HIGH code, because these rtx(s) indicate part of address and are not ok for
constant pool.

Below are some examples:
(high:DI (const:DI (plus:DI (symbol_ref:DI ("xx") (const_int 12 [0xc])
(high:DI (symbol_ref:DI ("var_1")..)))

This patch updated the previous patch, and drafted an test case which ICE
without the patch, and assoicated with one PR.
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/597712.html
This patch also updated the message for previous patch V2.

I would ask help to review this patch one more time.

Bootstrap and regtest pass on ppc64 and ppc64le.
Is this ok for trunk.

BR,
Jeff(Jiufu)

PR target/106460

gcc/ChangeLog:

* config/rs6000/rs6000.cc (rs6000_cannot_force_const_mem): Return true
for HIGH code rtx.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/pr106460.c: New test.
---
 gcc/config/rs6000/rs6000.cc |  7 +--
 gcc/testsuite/gcc.target/powerpc/pr106460.c | 11 +++
 2 files changed, 16 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/pr106460.c

diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index 2f3146e56f8..04e3a393147 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -9643,8 +9643,11 @@ rs6000_init_stack_protect_guard (void)
 static bool
 rs6000_cannot_force_const_mem (machine_mode mode ATTRIBUTE_UNUSED, rtx x)
 {
-  if (GET_CODE (x) == HIGH
-  && GET_CODE (XEXP (x, 0)) == UNSPEC)
+  /* If GET_CODE (x) is HIGH, the 'X' represets the high part of a symbol_ref.
+ It indicates partial address,  which can not be put into a constant pool.
+ e.g.  (high:DI (unspec:DI [(symbol_ref/u:DI ("*.LC0")..)
+ (high:DI (symbol_ref:DI ("var")..)).  */
+  if (GET_CODE (x) == HIGH)
 return true;
 
   /* A TLS symbol in the TOC cannot contain a sum.  */
diff --git a/gcc/testsuite/gcc.target/powerpc/pr106460.c 
b/gcc/testsuite/gcc.target/powerpc/pr106460.c
new file mode 100644
index 000..dfaffcb6e28
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr106460.c
@@ -0,0 +1,11 @@
+/* { dg-options "-O1 -mdejagnu-cpu=power10" } */
+
+/* (high:DI (symbol_ref:DI ("var_48")..))) should not cause ICE. */
+extern short var_48;
+void
+foo (double *r)
+{
+  if (var_48)
+*r = 1234.5678;
+}
+
-- 
2.17.1

[PATCH] LoongArch: Fix pr106828 by define hook TARGET_ASAN_SHADOW_OFFSET in loongarch backend.

[Lulu Cheng]

gcc/ChangeLog:

PR target/106828
* config/loongarch/loongarch.cc (loongarch_asan_shadow_offset): New.
(TARGET_ASAN_SHADOW_OFFSET): New.

gcc/testsuite/ChangeLog:

PR target/106828
* g++.target/loongarch/pr106828.C: New test.
---
 gcc/config/loongarch/loongarch.cc | 14 ++
 gcc/testsuite/g++.target/loongarch/pr106828.C |  4 
 2 files changed, 18 insertions(+)
 create mode 100644 gcc/testsuite/g++.target/loongarch/pr106828.C

diff --git a/gcc/config/loongarch/loongarch.cc 
b/gcc/config/loongarch/loongarch.cc
index 10acf06ef79..58f92e05796 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -6471,6 +6471,17 @@ loongarch_use_anchors_for_symbol_p (const_rtx symbol)
   return default_use_anchors_for_symbol_p (symbol);
 }
 
+/* Implement the TARGET_ASAN_SHADOW_OFFSET hook.  */
+
+static unsigned HOST_WIDE_INT
+loongarch_asan_shadow_offset (void)
+{
+  /* We only have libsanitizer support for LOONGARCH64 at present.
+ This value is obtained from 'LowShadow' in the file
+ libsanitizer/asan/asan_mappint.h for Linux/LoongArch64.  */
+  return TARGET_64BIT ? (HOST_WIDE_INT_1 << 38) : 0;
+}
+
 /* Initialize the GCC target structure.  */
 #undef TARGET_ASM_ALIGNED_HI_OP
 #define TARGET_ASM_ALIGNED_HI_OP "\t.half\t"
@@ -6665,6 +6676,9 @@ loongarch_use_anchors_for_symbol_p (const_rtx symbol)
 #undef  TARGET_USE_ANCHORS_FOR_SYMBOL_P
 #define TARGET_USE_ANCHORS_FOR_SYMBOL_P loongarch_use_anchors_for_symbol_p
 
+#undef TARGET_ASAN_SHADOW_OFFSET
+#define TARGET_ASAN_SHADOW_OFFSET loongarch_asan_shadow_offset
+
 struct gcc_target targetm = TARGET_INITIALIZER;
 
 #include "gt-loongarch.h"
diff --git a/gcc/testsuite/g++.target/loongarch/pr106828.C 
b/gcc/testsuite/g++.target/loongarch/pr106828.C
new file mode 100644
index 000..190c1db715f
--- /dev/null
+++ b/gcc/testsuite/g++.target/loongarch/pr106828.C
@@ -0,0 +1,4 @@
+/* { dg-do-preprocess } */
+/* { dg-options "-mabi=lp64d -fsanitize=address" } */
+
+/* Tests whether the compiler supports compile option '-fsanitize=address'.  */
-- 
2.31.1

PING^2: [PATCH v5] tree-optimization/101186 - extend FRE with "equivalence map" for condition prediction

[Di Zhao OS via Gcc-patches]

Gentle ping again.

Thanks,
Di Zhao

> -Original Message-
> From: Di Zhao OS
> Sent: Tuesday, July 12, 2022 2:08 AM
> To: 'gcc-patches@gcc.gnu.org' 
> Cc: 'Richard Biener' 
> Subject: PING: [PATCH v5] tree-optimization/101186 - extend FRE with
> "equivalence map" for condition prediction
> 
> Updated the patch in the attachment, so it can apply.
> 
> Thanks,
> Di Zhao
> 
> > -Original Message-
> > From: Di Zhao OS
> > Sent: Sunday, May 29, 2022 11:59 PM
> > To: gcc-patches@gcc.gnu.org
> > Cc: Richard Biener 
> > Subject: [PATCH v5] tree-optimization/101186 - extend FRE with "equivalence
> > map" for condition prediction
> >
> > Hi, attached is a new version of the patch. The changes are:
> > - Skip using temporary equivalences for floating-point values, because
> > folding expressions can generate incorrect values. For example,
> > operations on 0.0 and -0.0 may have different results.
> > - Avoid inserting duplicated back-refs from value-number to predicates.
> > - Disable fre in testsuite/g++.dg/pr83541.C .
> >
> > Summary of the previous versions:
> > https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587346.html
> >
> > Is the patch still considered?
> >
> > Thanks,
> > Di Zhao
> >
> > ---
> >
> > Extend FRE with temporary equivalences.
> >
> > 2022-05-29  Di Zhao  
> >
> > gcc/ChangeLog:
> > PR tree-optimization/101186
> > * tree-ssa-sccvn.c (VN_INFO): remove assertions (there could be a
> > predicate already).
> > (dominated_by_p_w_unex): Moved upward.
> > (vn_nary_op_get_predicated_value): Moved upward.
> > (is_vn_valid_at_bb): Check if vn_pval is valid at BB.
> > (lookup_equiv_head): Lookup the "equivalence head" of given node.
> > (lookup_equiv_heads): Lookup the "equivalence head"s of given nodes.
> > (vn_tracking_edge): Extracted utility function.
> > (init_vn_nary_op_from_stmt): Insert and lookup by "equivalence
> head"s.
> > (vn_nary_op_insert_into): Insert new value at the front.
> > (vn_nary_op_insert_pieces_predicated_1): Insert as predicated values
> > from pieces.
> > (fold_const_from_equiv_heads): Fold N-ary expression of equiv-heads.
> > (push_new_nary_ref): Insert a back-reference to vn_nary_op_t.
> > (val_equiv_insert): Record temporary equivalence.
> > (vn_nary_op_insert_pieces_predicated): Record equivalences instead
> of
> > some predicates; insert back-refs.
> > (record_equiv_from_prev_phi_1): Record temporary equivalences
> > generated
> > by PHI nodes.
> > (record_equiv_from_prev_phi): Given an outgoing edge of a
> conditional
> > expression taken, record equivalences generated by PHI nodes.
> > (visit_nary_op): Add lookup previous results of N-ary operations by
> > equivalences.
> > (insert_related_predicates_on_edge): Some predicates can be computed
> > from equivalences, no need to insert them.
> > (process_bb): Add lookup predicated values by equivalences.
> > (struct unwind_state): Unwind state of back-refs to vn_nary_op_t.
> > (do_unwind): Unwind the back-refs to vn_nary_op_t.
> > (do_rpo_vn): Update back-reference unwind state.
> > * tree-ssa-sccvn.h (struct nary_ref): hold a lists of references to
> > the
> > nary map entries.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * g++.dg/pr83541.C: Disable fre.
> > * gcc.dg/tree-ssa/pr68619-2.c: Disable fre.
> > * gcc.dg/tree-ssa/pr71947-1.c: Disable fre.
> > * gcc.dg/tree-ssa/pr71947-2.c: Disable fre.
> > * gcc.dg/tree-ssa/pr71947-3.c: Disable fre.
> > * gcc.dg/tree-ssa/pr71947-5.c: Disable fre.
> > * gcc.dg/tree-ssa/pr71947-7.c: Disable fre.
> > * gcc.dg/tree-ssa/pr71947-8.c: Disable fre.
> > * gcc.dg/tree-ssa/pr71947-9.c: Disable fre.
> > * gcc.dg/tree-ssa/vrp03.c: Disable fre.
> > * gcc.dg/tree-ssa/ssa-fre-100.c: New test.
> > * gcc.dg/tree-ssa/ssa-fre-101.c: New test.
> > * gcc.dg/tree-ssa/ssa-fre-102.c: New test.
> > * gcc.dg/tree-ssa/ssa-pre-34.c: New test.

Re: [PATCH] d: Fix #error You must define PREFERRED_DEBUGGING_TYPE if DWARF is not supported (PR105659)

[Iain Buclaw via Gcc-patches]

Excerpts from Iain Buclaw's message of September 6, 2022 11:41 pm:
> Excerpts from Iain Buclaw's message of September 6, 2022 7:02 pm:
>> Excerpts from Rainer Orth's message of September 6, 2022 4:25 pm:
>>> Hi Iain,
>>> 
> there is indeed ;-)  The previous d21 emits
> 
> binary./266566/gcc/d21
> version   v2.100.1
> 
> predefs GNU D_Version2 LittleEndian GNU_DWARF2_Exceptions
> GNU_StackGrowsDown GNU_InlineAsm assert D_PreConditions D_PostConditions
> D_Invariants D_ModuleInfo D_Exceptions D_TypeInfo all X86 D_HardFloat
> Posix Solaris CppRuntime_Gcc
> 
> while the patched one gives
> 
> core.exception.ArrayIndexError@/var/gcc/reghunt/master/gcc/d/dmd/root/stringtable.d(291):
> index [3530971477] is out of bounds for array of length 0
> gcc.deh(505): uncaught exception
> : internal compiler error: Abort
> 0x96d5b6c crash_signal
>   /var/gcc/reghunt/master/gcc/toplev.cc:314
> 

 Excellent, and the stage1 compiler?
>>> 
>>> binary./prev-gcc/d21
>>> version   v2.100.1
>>> 
>>> predefs   GNU D_Version2 LittleEndian GNU_DWARF2_Exceptions 
>>> GNU_StackGrowsDown GNU_InlineAsm assert D_PreConditions D_PostConditions 
>>> D_Invariants D_ModuleInfo D_Exceptions D_TypeInfo all X86 D_HardFloat Posix 
>>> Solaris CppRuntime_Gcc
>>> 
>>> So identical to the pre-patch one.
>>> 
>>> Just in case, here's the stacktrace of the crashing d21, filtered
>>> through c++filt -s dlang:
>>> 
>>> Thread 2 received signal SIGABRT, Aborted.
>>> [Switching to Thread 1 (LWP 1)]
>>> 0xfe1be2e5 in __lwp_sigqueue () from /lib/libc.so.1
>>> (gdb) bt
>>> #0  0xfe1be2e5 in __lwp_sigqueue () from /lib/libc.so.1
>>> #1  0xfe1b62cf in thr_kill () from /lib/libc.so.1
>>> #2  0xfe0ed662 in raise () from /lib/libc.so.1
>>> #3  0xfe0bae74 in abort () from /lib/libc.so.1
>>> #4  0x0a8e786d in gcc.deh.terminate(immutable(char)[], uint) (msg=..., 
>>> line=) at 
>>> /var/gcc/reghunt/master/libphobos/libdruntime/gcc/deh.d:414
>>> #5  0x0a8e7ab3 in _d_throw (object=) at 
>>> /var/gcc/reghunt/master/libphobos/libdruntime/gcc/deh.d:505
>>> #6  0x0a8edf02 in onArrayIndexError (index=, 
>>> length=, file=..., line=) at 
>>> /var/gcc/reghunt/master/libphobos/libdruntime/core/exception.d:650
>>> #7  0x0a8edf3d in _d_arraybounds_indexp (file=, 
>>> line=, index=, length=) at 
>>> /var/gcc/reghunt/master/libphobos/libdruntime/core/exception.d:848
>>> #8  0x08ffc17a in 
>>> dmd.root.stringtable.StringTable!(dmd.identifier.Identifier).StringTable.findSlot(uint,
>>>  scope const(char)[]) const (this=..., hash=, str=...) at 
>>> /var/gcc/reghunt/master/gcc/d/dmd/root/stringtable.d:291
>> 
>> Yeah, I don't see how that could trigger, as the value of `i` is always
>> adjusted to `i &= (table.length - 1)` (it uses quadratic probing to search
>> the hash table).
>> 
>> The logic of the compiler doesn't appear to have changed, but the data
>> layout may have, so I'm suspecting an issue that was always there has
>> now surfaced to the fore.
>> 
> 
> Yes, this is data related. The DSO registry picks up nothing in the
> miscompiled stage2 compiler, leaving all data uninitialized.  The stage1
> compiler works, and runs all module constructors ahead of compilation.
> 

Ohh, backtrack on that, analysis is correct, but it is a compiler regression.

The TARGET_D_MINFO_SECTION macros are in elfos.h, which of course no
longer get pulled in to sol2-d.cc after I removed the tm.h include.

Re-adding these two ought to fix the bootstrap for you.

#include "tm.h"
#include "memmodel.h"

Iain

Ping [PATCH] rs6000: using li/lis+oris/xoris to build constants

[Jiufu Guo via Gcc-patches]

Jiufu Guo  writes:

Gentle ping:
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600189.html

BR,
Jeff(Jiufu)

> Hi,
>
> PR106708 constaint some constants which can be support by li/lis + oris/xoris.
>
> For constant C:
> if ((c & 0x80008000ULL) == 0x8000ULL) or say:
> 32(0)+1(1)+15(x)+1(0)+15(x), we could use li+oris to build constant 'C'.
>
> if ((c & 0x8000ULL) == 0x8000ULL) or say:
> 32(1)+16(x)+1(1)+15(x), using li+xoris would be ok.
>
> if ((c & 0xULL) == 0x) or say:
> 32(1)+1(0)+15(x)+16(0), using lis+xoris would be ok.
>
> This patch update rs6000_emit_set_long_const to support these forms.
> Bootstrap and regtest pass on ppc64 and ppc64le.
>
> Is this ok for trunk?
>
> BR,
> Jeff(Jiufu)
>
>
>   PR target/106708
>
> gcc/ChangeLog:
>
>   * config/rs6000/rs6000.cc (rs6000_emit_set_long_const): Using li/lis +
>   oris/xoris to build constants.
>
> gcc/testsuite/ChangeLog:
>
>   * gcc.target/powerpc/pr106708.c: New test.
>   * gcc.target/powerpc/pr106708.h: New file.
>   * gcc.target/powerpc/pr106708_1.c: New test.
>
> ---
>  gcc/config/rs6000/rs6000.cc   | 22 +++
>  gcc/testsuite/gcc.target/powerpc/pr106708.c   | 10 +
>  gcc/testsuite/gcc.target/powerpc/pr106708.h   |  9 
>  gcc/testsuite/gcc.target/powerpc/pr106708_1.c | 17 ++
>  4 files changed, 58 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.target/powerpc/pr106708.c
>  create mode 100644 gcc/testsuite/gcc.target/powerpc/pr106708.h
>  create mode 100644 gcc/testsuite/gcc.target/powerpc/pr106708_1.c
>
> diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
> index df491bee2ea..243247fb838 100644
> --- a/gcc/config/rs6000/rs6000.cc
> +++ b/gcc/config/rs6000/rs6000.cc
> @@ -10112,6 +10112,7 @@ rs6000_emit_set_long_const (rtx dest, HOST_WIDE_INT c)
>  {
>rtx temp;
>HOST_WIDE_INT ud1, ud2, ud3, ud4;
> +  HOST_WIDE_INT orig_c = c;
>  
>ud1 = c & 0x;
>c = c >> 16;
> @@ -10137,6 +10138,27 @@ rs6000_emit_set_long_const (rtx dest, HOST_WIDE_INT 
> c)
>   gen_rtx_IOR (DImode, copy_rtx (temp),
>GEN_INT (ud1)));
>  }
> +  else if (ud4 == 0 && ud3 == 0 && (ud2 & 0x8000) && !(ud1 & 0x8000))
> +{
> +  temp = !can_create_pseudo_p () ? dest : gen_reg_rtx (DImode);
> +
> +  /* li+oris */
> +  emit_move_insn (copy_rtx (temp), GEN_INT (ud1));
> +  emit_move_insn (dest, gen_rtx_IOR (DImode, copy_rtx (temp),
> +  GEN_INT (ud2 << 16)));
> +}
> +  else if ((ud4 == 0x && ud3 == 0x)
> +&& ((ud1 & 0x8000) || (ud1 == 0 && !(ud2 & 0x8000
> +{
> +  temp = !can_create_pseudo_p () ? dest : gen_reg_rtx (DImode);
> +
> +  HOST_WIDE_INT imm = (ud1 & 0x8000) ? ((ud1 ^ 0x8000) - 0x8000)
> +  : ((ud2 << 16) - 0x8000);
> +  /* li/lis + xoris */
> +  emit_move_insn (copy_rtx (temp), GEN_INT (imm));
> +  emit_move_insn (dest, gen_rtx_XOR (DImode, copy_rtx (temp),
> +  GEN_INT (orig_c ^ imm)));
> +}
>else if (ud3 == 0 && ud4 == 0)
>  {
>temp = !can_create_pseudo_p () ? dest : gen_reg_rtx (DImode);
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr106708.c 
> b/gcc/testsuite/gcc.target/powerpc/pr106708.c
> new file mode 100644
> index 000..6445fa47747
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr106708.c
> @@ -0,0 +1,10 @@
> +/* PR target/106708 */
> +/* { dg-options "-O2 -mdejagnu-cpu=power8" } */
> +/* { dg-do compile { target has_arch_ppc64 } } */
> +
> +#include "pr106708.h"
> +
> +/* { dg-final { scan-assembler-times {\mli\M} 2 } } */
> +/* { dg-final { scan-assembler-times {\mlis\M} 1 } } */
> +/* { dg-final { scan-assembler-times {\moris\M} 1 } } */
> +/* { dg-final { scan-assembler-times {\mxoris\M} 2 } } */
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr106708.h 
> b/gcc/testsuite/gcc.target/powerpc/pr106708.h
> new file mode 100644
> index 000..ad07eb30547
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr106708.h
> @@ -0,0 +1,9 @@
> +/* li/lis + oris/xoris */
> +void  __attribute__ ((__noinline__, __noclone__)) foo (long long *arg)
> +{
> +  *arg++ = 0x98765432ULL;
> +  *arg++ = 0x7cdeab55ULL;
> +  *arg++ = 0x6543ULL;
> +}
> +
> +
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr106708_1.c 
> b/gcc/testsuite/gcc.target/powerpc/pr106708_1.c
> new file mode 100644
> index 000..df65c321f6b
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr106708_1.c
> @@ -0,0 +1,17 @@
> +/* PR target/106708 */
> +/* { dg-do run } */
> +/* { dg-options "-O2" } */
> +
> +#include "pr106708.h"
> +
> +long long arr[] = {0x98765432ULL, 0x7cdeab55ULL, 
> 0x6543ULL};
> +int
> +main ()
> +{
> +  long long a[3];
> +
> +  foo (a);
> +  if (__builtin_memcmp 

[PATCH v2] LoongArch: Fix pr106828 by define hook TARGET_ASAN_SHADOW_OFFSET in loongarch backend.

[Lulu Cheng]

Sorry, asan shadow offset is wrong in v1.

In the file asan_mapping.h line 207:
#define ASAN_SHADOW_OFFSET_CONST 0x4000

So it's should be 1<<46.


gcc/ChangeLog:

PR target/106828
* config/loongarch/loongarch.cc (loongarch_asan_shadow_offset): New.
(TARGET_ASAN_SHADOW_OFFSET): New.

gcc/testsuite/ChangeLog:

PR target/106828
* g++.target/loongarch/pr106828.C: New test.
---
 gcc/config/loongarch/loongarch.cc | 13 +
 gcc/testsuite/g++.target/loongarch/pr106828.C |  4 
 2 files changed, 17 insertions(+)
 create mode 100644 gcc/testsuite/g++.target/loongarch/pr106828.C

diff --git a/gcc/config/loongarch/loongarch.cc 
b/gcc/config/loongarch/loongarch.cc
index 10acf06ef79..424fa4487f8 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -6471,6 +6471,16 @@ loongarch_use_anchors_for_symbol_p (const_rtx symbol)
   return default_use_anchors_for_symbol_p (symbol);
 }
 
+/* Implement the TARGET_ASAN_SHADOW_OFFSET hook.  */
+
+static unsigned HOST_WIDE_INT
+loongarch_asan_shadow_offset (void)
+{
+  /* We only have libsanitizer support for LOONGARCH64 at present.
+ This value is taken from the file libsanitizer/asan/asan_mappint.h.  */
+  return TARGET_64BIT ? (HOST_WIDE_INT_1 << 46) : 0;
+}
+
 /* Initialize the GCC target structure.  */
 #undef TARGET_ASM_ALIGNED_HI_OP
 #define TARGET_ASM_ALIGNED_HI_OP "\t.half\t"
@@ -6665,6 +6675,9 @@ loongarch_use_anchors_for_symbol_p (const_rtx symbol)
 #undef  TARGET_USE_ANCHORS_FOR_SYMBOL_P
 #define TARGET_USE_ANCHORS_FOR_SYMBOL_P loongarch_use_anchors_for_symbol_p
 
+#undef TARGET_ASAN_SHADOW_OFFSET
+#define TARGET_ASAN_SHADOW_OFFSET loongarch_asan_shadow_offset
+
 struct gcc_target targetm = TARGET_INITIALIZER;
 
 #include "gt-loongarch.h"
diff --git a/gcc/testsuite/g++.target/loongarch/pr106828.C 
b/gcc/testsuite/g++.target/loongarch/pr106828.C
new file mode 100644
index 000..190c1db715f
--- /dev/null
+++ b/gcc/testsuite/g++.target/loongarch/pr106828.C
@@ -0,0 +1,4 @@
+/* { dg-do-preprocess } */
+/* { dg-options "-mabi=lp64d -fsanitize=address" } */
+
+/* Tests whether the compiler supports compile option '-fsanitize=address'.  */
-- 
2.31.1

[PATCH v3, rs6000] Change mode and insn condition for VSX scalar extract/insert instructions

[HAO CHEN GUI via Gcc-patches]

Hi,

  For scalar extract/insert instructions, exponent field can be stored in a
32-bit register. So this patch changes the mode of exponent field from DI to
SI. The instructions using DI registers can be invoked with -mpowerpc64 in a
32-bit environment. The patch changes insn condition from TARGET_64BIT to
TARGET_POWERPC64 for those instructions.

  This patch also changes prototypes of relevant built-ins and effective
target of test cases.

  Bootstrapped and tested on powerpc64-linux BE and LE with no regressions.
Is this okay for trunk? Any recommendations? Thanks a lot.

ChangeLog
2022-09-07  Haochen Gui  

gcc/
* config/rs6000/rs6000-builtins.def
(__builtin_vsx_scalar_extract_exp): Set return type to const unsigned
int.
(__builtin_vsx_scalar_extract_sig): Set return type to const unsigned
long long.
(__builtin_vsx_scalar_insert_exp): Set type of second argument to
unsigned int.
(__builtin_vsx_scalar_insert_exp_dp): Likewise.
* config/rs6000/vsx.md (xsxexpdp): Set mode of first operand to
SImode.  Remove TARGET_64BIT from insn condition.
(xsxsigdp): Change insn condition from TARGET_64BIT to TARGET_POWERPC64.
(xsiexpdp): Change insn condition from TARGET_64BIT to
TARGET_POWERPC64.  Set mode of third operand to SImode.
(xsiexpdpf): Set mode of third operand to SImode.  Remove TARGET_64BIT
from insn condition.

gcc/testsuite/
* gcc.target/powerpc/bfp/scalar-extract-exp-0.c: Change effective
target from lp64 to has_arch_ppc64.
* gcc.target/powerpc/bfp/scalar-extract-exp-6.c: Likewise.
* gcc.target/powerpc/bfp/scalar-extract-sig-0.c: Likewise.
* gcc.target/powerpc/bfp/scalar-extract-sig-6.c: Likewise.
* gcc.target/powerpc/bfp/scalar-insert-exp-0.c: Likewise.
* gcc.target/powerpc/bfp/scalar-insert-exp-12.c: Likewise.
* gcc.target/powerpc/bfp/scalar-insert-exp-13.c: Likewise.
* gcc.target/powerpc/bfp/scalar-insert-exp-3.c: Likewise.

patch.diff
diff --git a/gcc/config/rs6000/rs6000-builtins.def 
b/gcc/config/rs6000/rs6000-builtins.def
index f76f54793d7..ca2a1d7657e 100644
--- a/gcc/config/rs6000/rs6000-builtins.def
+++ b/gcc/config/rs6000/rs6000-builtins.def
@@ -2847,17 +2847,17 @@
   pure vsc __builtin_vsx_lxvl (const void *, signed long);
 LXVL lxvl {}

-  const signed long __builtin_vsx_scalar_extract_exp (double);
+  const unsigned int __builtin_vsx_scalar_extract_exp (double);
 VSEEDP xsxexpdp {}

-  const signed long __builtin_vsx_scalar_extract_sig (double);
+  const unsigned long long __builtin_vsx_scalar_extract_sig (double);
 VSESDP xsxsigdp {}

   const double __builtin_vsx_scalar_insert_exp (unsigned long long, \
-unsigned long long);
+   unsigned int);
 VSIEDP xsiexpdp {}

-  const double __builtin_vsx_scalar_insert_exp_dp (double, unsigned long long);
+  const double __builtin_vsx_scalar_insert_exp_dp (double, unsigned int);
 VSIEDPF xsiexpdpf {}

   pure vsc __builtin_vsx_xl_len_r (void *, signed long);
diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
index e226a93bbe5..9d3a2340a79 100644
--- a/gcc/config/rs6000/vsx.md
+++ b/gcc/config/rs6000/vsx.md
@@ -5095,10 +5095,10 @@ (define_insn "xsxexpqp_"

 ;; VSX Scalar Extract Exponent Double-Precision
 (define_insn "xsxexpdp"
-  [(set (match_operand:DI 0 "register_operand" "=r")
-   (unspec:DI [(match_operand:DF 1 "vsx_register_operand" "wa")]
+  [(set (match_operand:SI 0 "register_operand" "=r")
+   (unspec:SI [(match_operand:DF 1 "vsx_register_operand" "wa")]
 UNSPEC_VSX_SXEXPDP))]
-  "TARGET_P9_VECTOR && TARGET_64BIT"
+  "TARGET_P9_VECTOR"
   "xsxexpdp %0,%x1"
   [(set_attr "type" "integer")])

@@ -5116,7 +5116,7 @@ (define_insn "xsxsigdp"
   [(set (match_operand:DI 0 "register_operand" "=r")
(unspec:DI [(match_operand:DF 1 "vsx_register_operand" "wa")]
 UNSPEC_VSX_SXSIG))]
-  "TARGET_P9_VECTOR && TARGET_64BIT"
+  "TARGET_P9_VECTOR && TARGET_POWERPC64"
   "xsxsigdp %0,%x1"
   [(set_attr "type" "integer")])

@@ -5145,9 +5145,9 @@ (define_insn "xsiexpqp_"
 (define_insn "xsiexpdp"
   [(set (match_operand:DF 0 "vsx_register_operand" "=wa")
(unspec:DF [(match_operand:DI 1 "register_operand" "r")
-   (match_operand:DI 2 "register_operand" "r")]
+   (match_operand:SI 2 "register_operand" "r")]
 UNSPEC_VSX_SIEXPDP))]
-  "TARGET_P9_VECTOR && TARGET_64BIT"
+  "TARGET_P9_VECTOR && TARGET_POWERPC64"
   "xsiexpdp %x0,%1,%2"
   [(set_attr "type" "fpsimple")])

@@ -5155,9 +5155,9 @@ (define_insn "xsiexpdp"
 (define_insn "xsiexpdpf"
   [(set (match_operand:DF 0 "vsx_register_operand" "=wa")
(unspec:DF [(match_operand:DF 1 "register_operand" "r")
-   (match_operand:DI 2 "register_operand" "r")]
+   (match_operand:SI 2 "register_o

Re: [wwdocs PATCH RFA] contribute: link to kernel doc about patch email

[Gerald Pfeifer]

On Tue, 6 Sep 2022, Jason Merrill wrote:
> It occurred to me that it would be useful to link to the kernel's 
> documentation for emailing patches.  OK?

That's a great idea, thank you, Jason!

(Not strictly required by HTML 5, but I'd close the paragraph with 
like we generally do.)

Gerald

Re: [PATCH 2/2] libstdc++: Optimize is_reference

[Jonathan Wakely via Gcc-patches]

On Wed, 7 Sept 2022 at 01:46, Patrick Palka via Libstdc++
 wrote:
>
> Instead of defining is_reference in terms of is_lvalue_reference
> and is_rvalue_reference, just define it directly.
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?

Yes, thanks (I already did this for the std::is_reference_v variable
template, but for some reason left this equivalent change in the local
branch where I was doing the traits refactoring).

> This reduces memory usage of join.cc by 1%.

Now that many of the variable templates have been optimized to avoid
instantiating class templates, I wonder if the  code (and
anything else that's only defined for C++17 or later) would benefit
from using foo_v && bar_v instead of __and_, bar>.
With your improvements to __and_ maybe it doesn't make so much
difference.


>
> libstdc++-v3/ChangeLog:
>
> * include/std/type_traits (is_reference): Make the primary
> template derive from false_type.  Define two partial
> specializations that derive from true_type.
> ---
>  libstdc++-v3/include/std/type_traits | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/libstdc++-v3/include/std/type_traits 
> b/libstdc++-v3/include/std/type_traits
> index b83e7257a9f..94e73eafd2f 100644
> --- a/libstdc++-v3/include/std/type_traits
> +++ b/libstdc++-v3/include/std/type_traits
> @@ -611,8 +611,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>/// is_reference
>template
>  struct is_reference
> -: public __or_,
> -   is_rvalue_reference<_Tp>>::type
> +: public false_type
> +{ };
> +
> +  template
> +struct is_reference<_Tp&>
> +: public true_type
> +{ };
> +
> +  template
> +struct is_reference<_Tp&&>
> +: public true_type
>  { };
>
>/// is_arithmetic
> --
> 2.37.3.518.g79f2338b37
>

Re: [PATCH v2] LoongArch: Fix pr106828 by define hook TARGET_ASAN_SHADOW_OFFSET in loongarch backend.

[Xi Ruoyao via Gcc-patches]

On Wed, 2022-09-07 at 15:39 +0800, Lulu Cheng wrote:
> Sorry, asan shadow offset is wrong in v1.
> 
> In the file asan_mapping.h line 207:
> #    define ASAN_SHADOW_OFFSET_CONST 0x4000
> 
> So it's should be 1<<46.

LGTM.  I forgot to include this change in r13-2296 :(.

> 
> 
> gcc/ChangeLog:
> 
> PR target/106828
> * config/loongarch/loongarch.cc
> (loongarch_asan_shadow_offset): New.
> (TARGET_ASAN_SHADOW_OFFSET): New.
> 
> gcc/testsuite/ChangeLog:
> 
> PR target/106828
> * g++.target/loongarch/pr106828.C: New test.
> ---
>  gcc/config/loongarch/loongarch.cc | 13 +
>  gcc/testsuite/g++.target/loongarch/pr106828.C |  4 
>  2 files changed, 17 insertions(+)
>  create mode 100644 gcc/testsuite/g++.target/loongarch/pr106828.C
> 
> diff --git a/gcc/config/loongarch/loongarch.cc
> b/gcc/config/loongarch/loongarch.cc
> index 10acf06ef79..424fa4487f8 100644
> --- a/gcc/config/loongarch/loongarch.cc
> +++ b/gcc/config/loongarch/loongarch.cc
> @@ -6471,6 +6471,16 @@ loongarch_use_anchors_for_symbol_p (const_rtx
> symbol)
>    return default_use_anchors_for_symbol_p (symbol);
>  }
>  
> +/* Implement the TARGET_ASAN_SHADOW_OFFSET hook.  */
> +
> +static unsigned HOST_WIDE_INT
> +loongarch_asan_shadow_offset (void)
> +{
> +  /* We only have libsanitizer support for LOONGARCH64 at present.
> + This value is taken from the file
> libsanitizer/asan/asan_mappint.h.  */
> +  return TARGET_64BIT ? (HOST_WIDE_INT_1 << 46) : 0;
> +}
> +
>  /* Initialize the GCC target structure.  */
>  #undef TARGET_ASM_ALIGNED_HI_OP
>  #define TARGET_ASM_ALIGNED_HI_OP "\t.half\t"
> @@ -6665,6 +6675,9 @@ loongarch_use_anchors_for_symbol_p (const_rtx
> symbol)
>  #undef  TARGET_USE_ANCHORS_FOR_SYMBOL_P
>  #define TARGET_USE_ANCHORS_FOR_SYMBOL_P
> loongarch_use_anchors_for_symbol_p
>  
> +#undef TARGET_ASAN_SHADOW_OFFSET
> +#define TARGET_ASAN_SHADOW_OFFSET loongarch_asan_shadow_offset
> +
>  struct gcc_target targetm = TARGET_INITIALIZER;
>  
>  #include "gt-loongarch.h"
> diff --git a/gcc/testsuite/g++.target/loongarch/pr106828.C
> b/gcc/testsuite/g++.target/loongarch/pr106828.C
> new file mode 100644
> index 000..190c1db715f
> --- /dev/null
> +++ b/gcc/testsuite/g++.target/loongarch/pr106828.C
> @@ -0,0 +1,4 @@
> +/* { dg-do-preprocess } */
> +/* { dg-options "-mabi=lp64d -fsanitize=address" } */
> +
> +/* Tests whether the compiler supports compile option '-
> fsanitize=address'.  */

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

Re: [PATCH 1/2] libstdc++: Optimize is_void and is_null_pointer

[Jonathan Wakely via Gcc-patches]

On Wed, 7 Sept 2022 at 01:46, Patrick Palka via Libstdc++
 wrote:
>
> Instead of defining these in terms of a helper class template
> and the relatively expensive __remove_cv_t, just declare four
> explicit specializations of the main template, one for each choice
> of cv-quals.
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?

Yes, and we should do the same for is_void_v and  is_null_pointer_v.
Even though the class templates they instantiate will be cheaper now,
they can still avoid any class template instantiation.

> The is_void change alone reduces memory usage for join.cc by
> almost 1%.

Also in my queue of trait refactoring, but I haven't tested if these
are worth doing yet:

template
  struct is_object : is_const::type { };
template<>
  struct is_object : false_type { };
template<>
  struct is_object : false_type { };
// and so on for volatile and const volatile

And we could define is_object_v as simply is_const_v && is_void_v.

Improving is_object should benefit  and also the is_scalar
change proposed at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96710#c2

Re: [PATCH RFA] libstdc++: small dynamic_cast optimization

[Jonathan Wakely via Gcc-patches]

On Wed, 7 Sept 2022 at 02:45, Jason Merrill via Libstdc++
 wrote:
>
> An email discussion of optimizing EH led me to wonder why we weren't doing
> this already.  Not that this change affects EH at all.
>
> Tested x86_64-pc-linux-gnu.  Does this seem worthwhile?

Yes, I think so. If there's a fast path, we should take it.

>
> libstdc++-v3/ChangeLog:
>
> * libsupc++/dyncast.cc (__dynamic_cast): Avoid virtual function
> call in simple success case.
> ---
>  libstdc++-v3/libsupc++/dyncast.cc | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/libstdc++-v3/libsupc++/dyncast.cc 
> b/libstdc++-v3/libsupc++/dyncast.cc
> index 853c911a4cf..616e4c05766 100644
> --- a/libstdc++-v3/libsupc++/dyncast.cc
> +++ b/libstdc++-v3/libsupc++/dyncast.cc
> @@ -71,6 +71,12 @@ __dynamic_cast (const void *src_ptr,// object started 
> from
>if (whole_prefix->whole_type != whole_type)
>  return NULL;
>
> +  // Avoid virtual function call in the simple success case.
> +  if (src2dst >= 0
> +  && src2dst == -prefix->whole_object
> +  && *whole_type == *dst_type)
> +return const_cast  (whole_ptr);
> +
>whole_type->__do_dyncast (src2dst, __class_type_info::__contained_public,
>  dst_type, whole_ptr, src_type, src_ptr, result);
>if (!result.dst_ptr)
>
> base-commit: 0a2fba3697411c07a8330abfe7460ce62bce5e7f
> --
> 2.31.1
>

[PATCH v3 1/2] xtensa: Eliminate unused stack frame allocation/freeing

[Takayuki 'January June' Suwa via Gcc-patches]

Changes from v2:
  (xtensa_expand_prologue): Changed to check conditions for suppressing emit 
insns in advance, instead of tracking emitted and later replacing them with 
NOPs if they are found to be unnecessary.

---

In the example below, 'x' is once placed on the stack frame and then read
into registers as the argument value of bar():

/* example */
struct foo {
  int a, b;
};
extern struct foo bar(struct foo);
struct foo test(void) {
  struct foo x = { 0, 1 };
  return bar(x);
}

Thanks to the dead store elimination, the initialization of 'x' turns into
merely loading the immediates to registers, but corresponding stack frame
growth is not rolled back.  As a result:

;; prereq: the CALL0 ABI
;; before
test:
addisp, sp, -16 // unused stack frame allocation/freeing
movi.n  a2, 0
movi.n  a3, 1
addisp, sp, 16  // because no instructions that refer to
j.l bar, a9 // the stack pointer between the two

This patch eliminates such unused stack frame allocation/freeing:

;; after
test:
movi.n  a2, 0
movi.n  a3, 1
j.l bar, a9

gcc/ChangeLog:

* config/xtensa/xtensa.cc (machine_function): New boolean member as
a flag that controls whether to emit the insns for stack pointer
adjustment inside of the pro/epilogue.
(xtensa_emit_adjust_stack_ptr): New function to share the common
codes and to emit insns if not inhibited.
(xtensa_expand_epilogue): Change to use the function mentioned
above when using the CALL0 ABI.
(xtensa_expand_prologue): Ditto.
And also change to set the inhibit flag used by
xtensa_emit_adjust_stack_ptr() to true if the stack pointer is only
used for its own adjustment.
---
 gcc/config/xtensa/xtensa.cc | 162 +---
 1 file changed, 78 insertions(+), 84 deletions(-)

diff --git a/gcc/config/xtensa/xtensa.cc b/gcc/config/xtensa/xtensa.cc
index 93ac6562b22..86f94152a96 100644
--- a/gcc/config/xtensa/xtensa.cc
+++ b/gcc/config/xtensa/xtensa.cc
@@ -102,6 +102,7 @@ struct GTY(()) machine_function
   int callee_save_size;
   bool frame_laid_out;
   bool epilogue_done;
+  bool inhibit_logues_a1_adjusts;
 };
 
 /* Vector, indexed by hard register number, which contains 1 for a
@@ -3048,7 +3049,7 @@ xtensa_output_literal (FILE *file, rtx x, machine_mode 
mode, int labelno)
 }
 
 static bool
-xtensa_call_save_reg(int regno)
+xtensa_call_save_reg (int regno)
 {
   if (TARGET_WINDOWED_ABI)
 return false;
@@ -3084,7 +3085,7 @@ compute_frame_size (poly_int64 size)
   cfun->machine->callee_save_size = 0;
   for (regno = 0; regno < FIRST_PSEUDO_REGISTER; ++regno)
 {
-  if (xtensa_call_save_reg(regno))
+  if (xtensa_call_save_reg (regno))
cfun->machine->callee_save_size += UNITS_PER_WORD;
 }
 
@@ -3139,6 +3140,49 @@ xtensa_initial_elimination_offset (int from, int to 
ATTRIBUTE_UNUSED)
   return offset;
 }
 
+#define ADJUST_SP_NONE  0x0
+#define ADJUST_SP_NEED_NOTE 0x1
+#define ADJUST_SP_FRAME_PTR 0x2
+static void
+xtensa_emit_adjust_stack_ptr (HOST_WIDE_INT offset, int flags)
+{
+  rtx_insn *insn;
+  rtx ptr = (flags & ADJUST_SP_FRAME_PTR) ? hard_frame_pointer_rtx
+ : stack_pointer_rtx;
+
+  if (cfun->machine->inhibit_logues_a1_adjusts)
+return;
+
+  if (xtensa_simm8 (offset)
+  || xtensa_simm8x256 (offset))
+insn = emit_insn (gen_addsi3 (stack_pointer_rtx, ptr, GEN_INT (offset)));
+  else
+{
+  rtx tmp_reg = gen_rtx_REG (Pmode, A9_REG);
+
+  if (offset < 0)
+   {
+ emit_move_insn (tmp_reg, GEN_INT (-offset));
+ insn = emit_insn (gen_subsi3 (stack_pointer_rtx, ptr, tmp_reg));
+   }
+  else
+   {
+ emit_move_insn (tmp_reg, GEN_INT (offset));
+ insn = emit_insn (gen_addsi3 (stack_pointer_rtx, ptr, tmp_reg));
+   }
+}
+
+  if (flags & ADJUST_SP_NEED_NOTE)
+{
+  rtx note_rtx = gen_rtx_SET (stack_pointer_rtx,
+ plus_constant (Pmode, stack_pointer_rtx,
+offset));
+
+  RTX_FRAME_RELATED_P (insn) = 1;
+  add_reg_note (insn, REG_FRAME_RELATED_EXPR, note_rtx);
+}
+}
+
 /* minimum frame = reg save area (4 words) plus static chain (1 word)
and the total number of words must be a multiple of 128 bits.  */
 #define MIN_FRAME_SIZE (8 * UNITS_PER_WORD)
@@ -3174,17 +3218,28 @@ xtensa_expand_prologue (void)
   int regno;
   HOST_WIDE_INT offset = 0;
   int callee_save_size = cfun->machine->callee_save_size;
+  df_ref ref;
+  bool stack_pointer_really_used = false;
+
+  /* Check if the function body really needs the stack pointer.  */
+  for (ref = DF_REG_USE_CHAIN (A1_REG);
+  ref; ref = DF_REF_NEXT_REG (ref))
+   if (DF_REF_CLASS (ref) == DF_REF_REGULAR)
+ stack_pointe

Re: [commited PATCH v2] LoongArch: Fix pr106828 by define hook TARGET_ASAN_SHADOW_OFFSET in loongarch backend.

[Lulu Cheng]

在 2022/9/7 下午4:02, Xi Ruoyao 写道:

On Wed, 2022-09-07 at 15:39 +0800, Lulu Cheng wrote:

Sorry, asan shadow offset is wrong in v1.

In the file asan_mapping.h line 207:
 #    define ASAN_SHADOW_OFFSET_CONST 0x4000

So it's should be 1<<46.

LGTM.  I forgot to include this change in r13-2296 :(.

pushed to r13-2510.:-)




gcc/ChangeLog:

 PR target/106828
 * config/loongarch/loongarch.cc
(loongarch_asan_shadow_offset): New.
 (TARGET_ASAN_SHADOW_OFFSET): New.

gcc/testsuite/ChangeLog:

 PR target/106828
 * g++.target/loongarch/pr106828.C: New test.
---
  gcc/config/loongarch/loongarch.cc | 13 +
  gcc/testsuite/g++.target/loongarch/pr106828.C |  4 
  2 files changed, 17 insertions(+)
  create mode 100644 gcc/testsuite/g++.target/loongarch/pr106828.C

diff --git a/gcc/config/loongarch/loongarch.cc
b/gcc/config/loongarch/loongarch.cc
index 10acf06ef79..424fa4487f8 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -6471,6 +6471,16 @@ loongarch_use_anchors_for_symbol_p (const_rtx
symbol)
    return default_use_anchors_for_symbol_p (symbol);
  }
  
+/* Implement the TARGET_ASAN_SHADOW_OFFSET hook.  */

+
+static unsigned HOST_WIDE_INT
+loongarch_asan_shadow_offset (void)
+{
+  /* We only have libsanitizer support for LOONGARCH64 at present.
+ This value is taken from the file
libsanitizer/asan/asan_mappint.h.  */
+  return TARGET_64BIT ? (HOST_WIDE_INT_1 << 46) : 0;
+}
+
  /* Initialize the GCC target structure.  */
  #undef TARGET_ASM_ALIGNED_HI_OP
  #define TARGET_ASM_ALIGNED_HI_OP "\t.half\t"
@@ -6665,6 +6675,9 @@ loongarch_use_anchors_for_symbol_p (const_rtx
symbol)
  #undef  TARGET_USE_ANCHORS_FOR_SYMBOL_P
  #define TARGET_USE_ANCHORS_FOR_SYMBOL_P
loongarch_use_anchors_for_symbol_p
  
+#undef TARGET_ASAN_SHADOW_OFFSET

+#define TARGET_ASAN_SHADOW_OFFSET loongarch_asan_shadow_offset
+
  struct gcc_target targetm = TARGET_INITIALIZER;
  
  #include "gt-loongarch.h"

diff --git a/gcc/testsuite/g++.target/loongarch/pr106828.C
b/gcc/testsuite/g++.target/loongarch/pr106828.C
new file mode 100644
index 000..190c1db715f
--- /dev/null
+++ b/gcc/testsuite/g++.target/loongarch/pr106828.C
@@ -0,0 +1,4 @@
+/* { dg-do-preprocess } */
+/* { dg-options "-mabi=lp64d -fsanitize=address" } */
+
+/* Tests whether the compiler supports compile option '-
fsanitize=address'.  */

[pushed] aarch64: Prevent FPR register asms for +nofp

[Richard Sandiford via Gcc-patches]

+nofp disabled the automatic allocation of FPRs, but it didn't stop
users from explicitly putting register variables in FPRs.  We'd then
either report an ICE or generate unsupported instructions.

It's still possible (and deliberately redundant) to specify FPRs in
clobber lists.

Tested on aarch64-linux-gnu & pushed.

Richard


gcc/
* config/aarch64/aarch64.cc (aarch64_conditional_register_usage):
Disallow use of FPRs in register asms for !TARGET_FLOAT.

gcc/testsuite/
* gcc.target/aarch64/nofp_2.c: New test.
---
 gcc/config/aarch64/aarch64.cc |  1 +
 gcc/testsuite/gcc.target/aarch64/nofp_2.c | 19 +++
 2 files changed, 20 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/nofp_2.c

diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index 566763ce50c..786ede76131 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -19847,6 +19847,7 @@ aarch64_conditional_register_usage (void)
{
  fixed_regs[i] = 1;
  call_used_regs[i] = 1;
+ CLEAR_HARD_REG_BIT (operand_reg_set, i);
}
 }
   if (!TARGET_SVE)
diff --git a/gcc/testsuite/gcc.target/aarch64/nofp_2.c 
b/gcc/testsuite/gcc.target/aarch64/nofp_2.c
new file mode 100644
index 000..8a262cc76fa
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/nofp_2.c
@@ -0,0 +1,19 @@
+/* { dg-options "" } */
+
+#pragma GCC target "+nothing+nofp"
+
+void
+test (void)
+{
+  register int q0 asm ("q0"); // { dg-error "not general enough" }
+  register int q1 asm ("q1"); // { dg-error "not general enough" }
+  asm volatile ("" : "=w" (q0));
+  q1 = q0;
+  asm volatile ("" :: "w" (q1));
+}
+
+void
+ok (void)
+{
+  asm volatile ("" ::: "q0");
+}
-- 
2.25.1

[pushed] aarch64: Fix +nosimd handling of FPR moves

[Richard Sandiford via Gcc-patches]

8-bit and 16-bit FPR moves would ICE for +nosimd+fp, and some other
moves would handle FPR<-zero inefficiently.  This is very much a
niche case at the moment, but something like it becomes more
important with SME streaming mode.

The si, di and vector tests already passed, they're just included for
completeness.

We're a bit inconsistent about whether alternatives involving FPRs
are marked with arch==fp or arch=* (i.e. default).  E.g. FPR loads
and stores are sometimes * and sometimes fp.

IMO * makes more sense.  FPRs should not be used at all without
TARGET_FLOAT, so TARGET_FLOAT represents the base architecture
when FPRs are enabled.  I think it's more useful if non-default
arches represent a genuine restriction.

Tested on aarch64-linux-gnu & pushed.

Richard


gcc/
* config/aarch64/aarch64.md (*mov_aarch64): Extend
w<-w, r<-w and w<-r alternatives to !simd, using 32-bit moves
in that case.  Extend w<-r to w<-Z.
(*mov_aarch64): Likewise, but with Y instead of Z.
(*movti_aarch64): Use an FMOV from XZR for w<-Z if MOVI is not
available.
(define_split): Do not apply the floating-point immediate-to-register
split to zeros, even if MOVI is not available.

gcc/testsuite/
* gcc.target/aarch64/movqi_1.c: New test.
* gcc.target/aarch64/movhi_1.c: Likewise.
* gcc.target/aarch64/movsi_1.c: Likewise.
* gcc.target/aarch64/movdi_2.c: Likewise.
* gcc.target/aarch64/movti_2.c: Likewise.
* gcc.target/aarch64/movhf_1.c: Likewise.
* gcc.target/aarch64/movsf_1.c: Likewise.
* gcc.target/aarch64/movdf_1.c: Likewise.
* gcc.target/aarch64/movtf_2.c: Likewise.
* gcc.target/aarch64/movv8qi_1.c: Likewise.
* gcc.target/aarch64/movv16qi_1.c: Likewise.
---
 gcc/config/aarch64/aarch64.md | 38 
 gcc/testsuite/gcc.target/aarch64/movdf_1.c| 53 
 gcc/testsuite/gcc.target/aarch64/movdi_2.c| 61 +
 gcc/testsuite/gcc.target/aarch64/movhf_1.c| 53 
 gcc/testsuite/gcc.target/aarch64/movhi_1.c| 61 +
 gcc/testsuite/gcc.target/aarch64/movqi_1.c| 61 +
 gcc/testsuite/gcc.target/aarch64/movsf_1.c| 53 
 gcc/testsuite/gcc.target/aarch64/movsi_1.c| 61 +
 gcc/testsuite/gcc.target/aarch64/movtf_2.c| 81 +
 gcc/testsuite/gcc.target/aarch64/movti_2.c| 86 +++
 gcc/testsuite/gcc.target/aarch64/movv16qi_1.c | 82 ++
 gcc/testsuite/gcc.target/aarch64/movv8qi_1.c  | 55 
 12 files changed, 729 insertions(+), 16 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/movdf_1.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/movdi_2.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/movhf_1.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/movhi_1.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/movqi_1.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/movsf_1.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/movsi_1.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/movtf_2.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/movti_2.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/movv16qi_1.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/movv8qi_1.c

diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 3ea16dbc255..efcbecbf67a 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -1195,7 +1195,7 @@ (define_expand "mov"
 
 (define_insn "*mov_aarch64"
   [(set (match_operand:SHORT 0 "nonimmediate_operand" "=r,r,w,r  ,r,w, 
m,m,r,w,w")
-   (match_operand:SHORT 1 "aarch64_mov_operand"  " 
r,M,D,Usv,m,m,rZ,w,w,r,w"))]
+   (match_operand:SHORT 1 "aarch64_mov_operand"  " 
r,M,D,Usv,m,m,rZ,w,w,rZ,w"))]
   "(register_operand (operands[0], mode)
 || aarch64_reg_or_zero (operands[1], mode))"
 {
@@ -1219,11 +1219,11 @@ (define_insn "*mov_aarch64"
  case 7:
return "str\t%1, %0";
  case 8:
-   return "umov\t%w0, %1.[0]";
+   return TARGET_SIMD ? "umov\t%w0, %1.[0]" : "fmov\t%w0, %s1";
  case 9:
-   return "dup\t%0., %w1";
+   return TARGET_SIMD ? "dup\t%0., %w1" : "fmov\t%s0, %w1";
  case 10:
-   return "dup\t%0, %1.[0]";
+   return TARGET_SIMD ? "dup\t%0, %1.[0]" : "fmov\t%s0, %s1";
  default:
gcc_unreachable ();
  }
@@ -1231,7 +1231,7 @@ (define_insn "*mov_aarch64"
   ;; The "mov_imm" type for CNT is just a placeholder.
   [(set_attr "type" "mov_reg,mov_imm,neon_move,mov_imm,load_4,load_4,store_4,
 store_4,neon_to_gp,neon_from_gp,neon_dup")
-   (set_attr "arch" "*,*,simd,sve,*,*,*,*,simd,simd,simd")]
+   (set_attr "arch" "*,*,simd,sve,*,*,*,*,*,*,*")]
 )
 
 (define_expand "mov"
@@ -1393,14 +1393,15 @@ (define_expand "movti"
 
 (define_insn "*movti_aarch64"
   [(set (match_operand:TI 0
-"nonimmediate_operand

Re: [PATCH v2] LoongArch: Fix pr106828 by define hook TARGET_ASAN_SHADOW_OFFSET in loongarch backend.

[Martin Liška]

On 9/7/22 09:39, Lulu Cheng wrote:
> |+ This value is taken from the file libsanitizer/asan/asan_mappint.h. */|

s/asan_mappint.h/asan_mapping.h

Cheers,
Martin

Re: [PATCH v2] LoongArch: Fix pr106828 by define hook TARGET_ASAN_SHADOW_OFFSET in loongarch backend.

[Lulu Cheng]

Sorry, I will correct this typo.

Thanks!

在 2022/9/7 下午5:58, Martin Liška 写道:

On 9/7/22 09:39, Lulu Cheng wrote:

|+ This value is taken from the file libsanitizer/asan/asan_mappint.h. */|

s/asan_mappint.h/asan_mapping.h

Cheers,
Martin

[PATCH] mark region also for USE predicate discovery

[Richard Biener via Gcc-patches]

The following makes sure to mark the dominating region also for
USE predicate discovery, avoiding compute_control_dep_chain to
walk to unrelated areas, eating up walking budget.

Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.

* gimple-predicate-analysis.cc (dfs_mark_dominating_region):
Adjust to take the region exit source as argument.
(uninit_analysis::init_from_phi_def): Adjust.
(uninit_analysis::init_use_preds): Mark the dominating region
before computing control dependences.
---
 gcc/gimple-predicate-analysis.cc | 27 +++
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/gcc/gimple-predicate-analysis.cc b/gcc/gimple-predicate-analysis.cc
index 5dade458947..f81af2589cd 100644
--- a/gcc/gimple-predicate-analysis.cc
+++ b/gcc/gimple-predicate-analysis.cc
@@ -934,23 +934,23 @@ simple_control_dep_chain (vec& chain, basic_block 
from, basic_block to)
 }
 
 /* Perform a DFS walk on predecessor edges to mark the region denoted
-   by the EXIT edge and DOM which dominates EXIT->src, including DOM.
+   by the EXIT_SRC block and DOM which dominates EXIT_SRC, including DOM.
Blocks in the region are marked with FLAG and added to BBS.  BBS is
filled up to its capacity only after which the walk is terminated
and false is returned.  If the whole region was marked, true is returned.  
*/
 
 static bool
-dfs_mark_dominating_region (edge exit, basic_block dom, int flag,
+dfs_mark_dominating_region (basic_block exit_src, basic_block dom, int flag,
vec &bbs)
 {
-  if (exit->src == dom || exit->src->flags & flag)
+  if (exit_src == dom || exit_src->flags & flag)
 return true;
   if (!bbs.space (1))
 return false;
-  bbs.quick_push (exit->src);
-  exit->src->flags |= flag;
+  bbs.quick_push (exit_src);
+  exit_src->flags |= flag;
   auto_vec stack (bbs.allocated () - bbs.length () + 1);
-  stack.quick_push (ei_start (exit->src->preds));
+  stack.quick_push (ei_start (exit_src->preds));
   while (!stack.is_empty ())
 {
   /* Look at the edge on the top of the stack.  */
@@ -1960,6 +1960,10 @@ uninit_analysis::init_use_preds (predicate &use_preds, 
basic_block def_bb,
 }
   while (1);
 
+  auto_bb_flag in_region (cfun);
+  auto_vec region (MIN (n_basic_blocks_for_fn (cfun),
+param_uninit_control_dep_attempts));
+
   /* Set DEP_CHAINS to the set of edges between CD_ROOT and USE_BB.
  Each DEP_CHAINS element is a series of edges whose conditions
  are logical conjunctions.  Together, the DEP_CHAINS vector is
@@ -1967,7 +1971,9 @@ uninit_analysis::init_use_preds (predicate &use_preds, 
basic_block def_bb,
   unsigned num_chains = 0;
   auto_vec dep_chains[MAX_NUM_CHAINS];
 
-  if (!compute_control_dep_chain (cd_root, use_bb, dep_chains, &num_chains))
+  if (!dfs_mark_dominating_region (use_bb, cd_root, in_region, region)
+  || !compute_control_dep_chain (cd_root, use_bb, dep_chains, &num_chains,
+in_region))
 {
   /* If the info in dep_chains is not complete we need to use a
 conservative approximation for the use predicate.  */
@@ -1979,6 +1985,10 @@ uninit_analysis::init_use_preds (predicate &use_preds, 
basic_block def_bb,
   simple_control_dep_chain (dep_chains[0], cd_root, use_bb);
 }
 
+  /* Unmark the region.  */
+  for (auto bb : region)
+bb->flags &= ~in_region;
+
   /* From the set of edges computed above initialize *THIS as the OR
  condition under which the definition in DEF_BB is used in USE_BB.
  Each OR subexpression is represented by one element of DEP_CHAINS,
@@ -2061,7 +2071,8 @@ uninit_analysis::init_from_phi_def (gphi *phi)
}
 }
   for (unsigned i = 0; i < nedges; i++)
-if (!dfs_mark_dominating_region (def_edges[i], cd_root, in_region, region))
+if (!dfs_mark_dominating_region (def_edges[i]->src, cd_root,
+in_region, region))
   break;
 
   unsigned num_chains = 0;
-- 
2.37.3

[PATCH] tree-optimization/106860 - fix profile scaling in split_loop

[Richard Biener via Gcc-patches]

The following fixes a mistake in loop splitting which assumes loop
latches have a single predecessor and that edge is from the exit
test.  Instead work from the single exit edge we have to find the
edge towards the latch.

Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.

PR tree-optimization/106860
* tree-ssa-loop-split.cc (split_loop): Find the exit to
latch edge from the loop exit edge instead of from the
latch.  Verify we're going to find it.

* g++.dg/opt/pr106860.C: New testcase.
---
 gcc/testsuite/g++.dg/opt/pr106860.C | 23 +++
 gcc/tree-ssa-loop-split.cc  | 16 ++--
 2 files changed, 33 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/opt/pr106860.C

diff --git a/gcc/testsuite/g++.dg/opt/pr106860.C 
b/gcc/testsuite/g++.dg/opt/pr106860.C
new file mode 100644
index 000..a0209dcf9da
--- /dev/null
+++ b/gcc/testsuite/g++.dg/opt/pr106860.C
@@ -0,0 +1,23 @@
+// { dg-do compile }
+// { dg-options "-Ofast -ftrapv -fnon-call-exceptions -fno-tree-fre" }
+
+static const int N = 12;
+int nSlip;
+
+int main ()
+{
+  int i, j, k, fdot = 0;
+  int a[N][N];
+
+  for ( i = 1; i < nSlip; i++)
+{
+  for ( j = i+1; j < nSlip; j++)
+{
+  for ( k = 0; k < i; k++)
+fdot += a[i][k] * a[k][j];
+  a[i][j] = a[i][j] - fdot;
+}
+   }
+
+  return 0;
+}
diff --git a/gcc/tree-ssa-loop-split.cc b/gcc/tree-ssa-loop-split.cc
index bccf621493b..fad4e8361b0 100644
--- a/gcc/tree-ssa-loop-split.cc
+++ b/gcc/tree-ssa-loop-split.cc
@@ -531,16 +531,17 @@ split_loop (class loop *loop1)
   tree guard_iv;
   tree border = NULL_TREE;
   affine_iv iv;
+  edge exit1;
 
-  if (!single_exit (loop1)
+  if (!(exit1 = single_exit (loop1))
+  || EDGE_COUNT (exit1->src->succs) != 2
   /* ??? We could handle non-empty latches when we split the latch edge
 (not the exit edge), and put the new exit condition in the new block.
 OTOH this executes some code unconditionally that might have been
 skipped by the original exit before.  */
   || !empty_block_p (loop1->latch)
   || !easy_exit_values (loop1)
-  || !number_of_iterations_exit (loop1, single_exit (loop1), &niter,
-false, true)
+  || !number_of_iterations_exit (loop1, exit1, &niter, false, true)
   || niter.cmp == ERROR_MARK
   /* We can't yet handle loops controlled by a != predicate.  */
   || niter.cmp == NE_EXPR)
@@ -644,10 +645,13 @@ split_loop (class loop *loop1)
fix_loop_bb_probability (loop1, loop2, true_edge, false_edge);
 
/* Fix first loop's exit probability after scaling.  */
-   edge exit_to_latch1 = single_pred_edge (loop1->latch);
+   edge exit_to_latch1;
+   if (EDGE_SUCC (exit1->src, 0) == exit1)
+ exit_to_latch1 = EDGE_SUCC (exit1->src, 1);
+   else
+ exit_to_latch1 = EDGE_SUCC (exit1->src, 0);
exit_to_latch1->probability *= true_edge->probability;
-   single_exit (loop1)->probability
- = exit_to_latch1->probability.invert ();
+   exit1->probability = exit_to_latch1->probability.invert ();
 
/* Finally patch out the two copies of the condition to be always
   true/false (or opposite).  */
-- 
2.37.3

Re: [PATCH] Always default to DWARF2_DEBUG if not specified, warn about deprecated STABS

[Jan-Benedict Glaw]

Hi!

On Mon, 2022-08-29 22:11:35 +0200, Jan-Benedict Glaw  wrote:
> On Sun, 2022-08-28 15:32:53 -0600, Jeff Law via Gcc-patches 
>  wrote:
> > On 8/28/2022 1:50 AM, Jan-Benedict Glaw wrote:
> > > On Tue, 2021-09-21 16:25:19 +0200, Richard Biener via Gcc-patches 
> > >  wrote:
> > > > This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE
> > > > is not specified by the target and errors out if DWARF DWARF is not 
> > > > supported.
> > > While I think the pdp11 bits arreved, the rest did not (yet). Just
> > > checked my auto-builder logs. When building current HEAD as
> > > 
> > >   ../gcc/configure --prefix=... --enable-werror-always \
> > >   --enable-languages=all --disable-gcov \
> > >   --disable-shared --disable-threads --without-headers \
> > >   --target=...
> > >   make V=1 all-gcc
> > > 
> > > ALL of these targets won't build right now:
> [...]
> > Umm, most of those -elf targets do build.  See:
> > 
> > http://law-sandy.freeddns.org:8080
> 
> Another builder. :)  Randomly picking xtensa-elf, you're configuring
> as
> 
> + ../../gcc/configure --disable-analyzer --with-system-libunwind
> --with-newlib --without-headers --disable-threads --disable-shared
> --enable-languages=c,c++
> --prefix=/home/jlaw/jenkins/workspace/xtensa-elf/xtensa-elf-obj/gcc/../../xtensa-elf-installed
> --target=xtensa-elf
> 
> I guess the main difference that lets my builds fail might be
> --enable-languages=all (vs. c,c++ in your case.)
> 
> Maybe you'd give that a try? (...and I'll trigger a build with just
> c,c++ on my builder.)

So ... just building for --enable-languages=c,c++ usually works for
the *-elf targets, but I'm interested in building as much code as
possible. Is it expected that with --enable-languages=all, all those
targets will break? Can we have a sane default here, or need the
maintainers decide for any given debug format?

Thanks,
  Jan-Benedict

-- 


signature.asc
Description: PGP signature

Re: [PATCH v3] Simplify memchr with small constant strings

[Jan-Benedict Glaw]

Hi!

On Wed, 2022-07-13 09:50:14 -0700, H.J. Lu via Gcc-patches 
 wrote:
> When memchr is applied on a constant string of no more than the bytes of
> a word, simplify memchr by checking each byte in the constant string.
> 
> int f (int a)
> {
>return  __builtin_memchr ("AE", a, 2) != 0;
> }
> 
> is simplified to
> 
> int f (int a)
> {
>   return ((char) a == 'A' || (char) a == 'E') != 0;
> }

Seems this caused a regression for --target=avr-elf, pru-elf and
rl78-elf:

.../gcc/configure --prefix=... --enable-werror-always --enable-languages=all 
--disable-gcov --disable-shared --disable-threads --target=pru-elf 
--without-headers
[...]
make V=1 all-gcc
[...]
/usr/lib/gcc-snapshot/bin/g++  -fno-PIE -c   -g -O2   -DIN_GCC  
-DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 
 -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. 
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include 
-I../../gcc/gcc/../libcody  -I../../gcc/gcc/../libdecnumber 
-I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
-I../../gcc/gcc/../libbacktrace   -o tree-ssa-forwprop.o -MT 
tree-ssa-forwprop.o -MMD -MP -MF ./.deps/tree-ssa-forwprop.TPo 
../../gcc/gcc/tree-ssa-forwprop.cc
../../gcc/gcc/tree-ssa-forwprop.cc: In function 'bool 
simplify_builtin_call(gimple_stmt_iterator*, tree)':
../../gcc/gcc/tree-ssa-forwprop.cc:1258:42: error: array subscript 1 is outside 
array bounds of 'tree_node* [1]' [-Werror=array-bounds]
 1258 | op[i - 1] = fold_convert_loc (loc, boolean_type_node,
  | ~^~~~
 1259 |   fold_build2_loc (loc,
  |   ~
 1260 |BIT_IOR_EXPR,
  |~
 1261 |
boolean_type_node,
  |
~~
 1262 |op[i - 1],
  |~~
 1263 |op[i]));
  |~~~
In file included from ../../gcc/gcc/system.h:707,
 from ../../gcc/gcc/tree-ssa-forwprop.cc:21:
../../gcc/gcc/../include/libiberty.h:733:36: note: at offset 8 into object of 
size [0, 8] allocated by '__builtin_alloca'
  733 | # define alloca(x) __builtin_alloca(x)
  |^~~
../../gcc/gcc/../include/libiberty.h:365:40: note: in expansion of macro 
'alloca'
  365 | #define XALLOCAVEC(T, N)((T *) alloca (sizeof (T) * (N)))
  |^~
../../gcc/gcc/tree-ssa-forwprop.cc:1250:22: note: in expansion of macro 
'XALLOCAVEC'
 1250 |   tree *op = XALLOCAVEC (tree, isize);
  |  ^~
cc1plus: all warnings being treated as errors
make[1]: *** [Makefile:1146: tree-ssa-forwprop.o] Error 1
make[1]: Leaving directory 
'/var/lib/laminar/run/gcc-pru-elf/1/toolchain-build/gcc'
make: *** [Makefile:4583: all-gcc] Error 2

Thanks,
  Jan-Benedict

-- 


signature.asc
Description: PGP signature

[COMMITTED] [PR106867] Add test for PR.

[Aldy Hernandez via Gcc-patches]

PR tree-optimization/106867

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/pr106867.c: New test.
---
 gcc/testsuite/gcc.dg/tree-ssa/pr106867.c | 16 
 1 file changed, 16 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr106867.c

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr106867.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr106867.c
new file mode 100644
index 000..68773d9ae74
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr106867.c
@@ -0,0 +1,16 @@
+// { dg-do compile }
+// { dg-options "-O2 -fno-tree-fre" }
+
+double m;
+int n;
+
+void
+foo (void)
+{
+  static double a[] = { 0.0 / 0.0, 0.0 };
+  int i;
+
+  for (i = 0; i < n; ++i)
+if (m >= a[i])
+  __builtin_abort ();
+}
-- 
2.37.1

Re: [PING^2][PATCH][gdb/build] Fix build breaker with --enabled-shared

[Richard Sandiford via Gcc-patches]

Tom de Vries via Gcc-patches  writes:
> On 7/12/22 15:42, Tom de Vries wrote:
>> [ dropped gdb-patches, since already applied there. ]
>> 
>> On 6/27/22 15:38, Tom de Vries wrote:
>>> On 6/27/22 15:03, Tom de Vries wrote:
 Hi,

 When building gdb with --enabled-shared, I run into:
 ...
 ld: build/zlib/libz.a(libz_a-inffast.o): relocation R_X86_64_32S 
 against \
    `.rodata' can not be used when making a shared object; recompile 
 with -fPIC
 ld: build/zlib/libz.a(libz_a-inflate.o): warning: relocation against \
    `inflateResetKeep' in read-only section `.text'
 collect2: error: ld returned 1 exit status
 make[3]: *** [libbfd.la] Error 1
 ...

 This is a regression since commit a08bdb159bb ("[gdb/build] Fix 
 gdbserver
 build with -fsanitize=thread").

 The problem is that a single case statement in configure is shared to 
 handle
 special requirements for both the host libiberty and host zlib, which 
 has the
 effect that only one is handled.

 Fix this by handling libiberty and zlib each in its own case statement.

 Build on x86_64-linux, with and without --enable-shared.

 OK for gcc trunk?

>> 
>
> Ping^2.

OK, thanks.

(Not really my area, but since noone else has commented...)

Richard

> Thanks,
> - Tom
>
>>> To fix the buildbot breakage, I already pushed to the gdb repo.
>>>
>>> Thanks,
>>> - Tom
>>>

 [gdb/build] Fix build breaker with --enabled-shared

 ChangeLog:

 2022-06-27  Tom de Vries  

 * configure.ac: Set extra_host_libiberty_configure_flags and
 extra_host_zlib_configure_flags in separate case statements.
 * configure: Regenerate.

 ---
   configure    | 8 ++--
   configure.ac | 8 ++--
   2 files changed, 12 insertions(+), 4 deletions(-)

 diff --git a/configure b/configure
 index aac80b88d70..be433ef6d5d 100755
 --- a/configure
 +++ b/configure
 @@ -6962,13 +6962,18 @@ fi
   # Sometimes we have special requirements for the host libiberty.
   extra_host_libiberty_configure_flags=
 -extra_host_zlib_configure_flags=
   case " $configdirs " in
     *" lto-plugin "* | *" libcc1 "* | *" gdbserver "*)
   # When these are to be built as shared libraries, the same 
 applies to
   # libiberty.
   extra_host_libiberty_configure_flags=--enable-shared
   ;;
 +esac
 +
 +
 +# Sometimes we have special requirements for the host zlib.
 +extra_host_zlib_configure_flags=
 +case " $configdirs " in
     *" bfd "*)
   # When bfd is to be built as a shared library, the same applies to
   # zlib.
 @@ -6979,7 +6984,6 @@ case " $configdirs " in
   esac
 -
   # Produce a warning message for the subdirs we can't configure.
   # This isn't especially interesting in the Cygnus tree, but in the 
 individual
   # FSF releases, it's important to let people know when their 
 machine isn't
 diff --git a/configure.ac b/configure.ac
 index 29f74d10b5a..1651cbf3b02 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -2342,13 +2342,18 @@ fi
   # Sometimes we have special requirements for the host libiberty.
   extra_host_libiberty_configure_flags=
 -extra_host_zlib_configure_flags=
   case " $configdirs " in
     *" lto-plugin "* | *" libcc1 "* | *" gdbserver "*)
   # When these are to be built as shared libraries, the same 
 applies to
   # libiberty.
   extra_host_libiberty_configure_flags=--enable-shared
   ;;
 +esac
 +AC_SUBST(extra_host_libiberty_configure_flags)
 +
 +# Sometimes we have special requirements for the host zlib.
 +extra_host_zlib_configure_flags=
 +case " $configdirs " in
     *" bfd "*)
   # When bfd is to be built as a shared library, the same applies to
   # zlib.
 @@ -2357,7 +2362,6 @@ case " $configdirs " in
   fi
   ;;
   esac
 -AC_SUBST(extra_host_libiberty_configure_flags)
   AC_SUBST(extra_host_zlib_configure_flags)
   # Produce a warning message for the subdirs we can't configure.

[COMMITTED] C-SKY: Fix expanding of float LE comparing with zero for fpuv3.

[Xianmiao Qu via Gcc-patches]

The original code will cause the warning:
/usr/lib/gcc-snapshot/bin/g++  -fno-PIE -c   -g -O2   -DIN_GCC  
-DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 
 -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. 
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include 
-I../../gcc/gcc/../libcody  -I../../gcc/gcc/../libdecnumber 
-I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
-I../../gcc/gcc/../libbacktrace   -o csky.o -MT csky.o -MMD -MP -MF 
./.deps/csky.TPo ../../gcc/gcc/config/csky/csky.cc
In file included from ../../gcc/gcc/config/csky/csky.h:183,
from ./tm.h:20,
from ../../gcc/gcc/backend.h:28,
from ../../gcc/gcc/config/csky/csky.cc:27:
../../gcc/gcc/config/csky/csky.cc: In function 'bool 
csky_emit_compare_float(rtx_code, rtx, rtx)':
../../gcc/gcc/config/csky/csky_isa.h:29:37: error: enum constant in boolean 
context [-Werror=int-in-bool-context]
  29 | #define CSKY_ISA_FEATURE_DEFINE(x)  isa_bit_ ## x
  | ^~~~
../../gcc/gcc/config/csky/csky_isa.h:30:37: note: in expansion of macro 
'CSKY_ISA_FEATURE_DEFINE'
  30 | #define CSKY_ISA_FEATURE_GET(x) CSKY_ISA_FEATURE_DEFINE (x)
  | ^~~
../../gcc/gcc/config/csky/csky.cc:6346:43: note: in expansion of macro 
'CSKY_ISA_FEATURE_GET'
6346 ||| CSKY_ISA_FEATURE_GET(fpv2_df)
  |   ^~~~
../../gcc/gcc/config/csky/csky_isa.h:29:37: error: enum constant in boolean 
context [-Werror=int-in-bool-context]
  29 | #define CSKY_ISA_FEATURE_DEFINE(x)  isa_bit_ ## x
  | ^~~~
../../gcc/gcc/config/csky/csky_isa.h:30:37: note: in expansion of macro 
'CSKY_ISA_FEATURE_DEFINE'
  30 | #define CSKY_ISA_FEATURE_GET(x) CSKY_ISA_FEATURE_DEFINE (x)
  | ^~~
../../gcc/gcc/config/csky/csky.cc:6346:43: note: in expansion of macro 
'CSKY_ISA_FEATURE_GET'
6346 ||| CSKY_ISA_FEATURE_GET(fpv2_df)
  |   ^~~~
../../gcc/gcc/config/csky/csky_isa.h:29:37: error: enum constant in boolean 
context [-Werror=int-in-bool-context]
  29 | #define CSKY_ISA_FEATURE_DEFINE(x)  isa_bit_ ## x
  | ^~~~
../../gcc/gcc/config/csky/csky_isa.h:30:37: note: in expansion of macro 
'CSKY_ISA_FEATURE_DEFINE'
  30 | #define CSKY_ISA_FEATURE_GET(x) CSKY_ISA_FEATURE_DEFINE (x)
  | ^~~
../../gcc/gcc/config/csky/csky.cc:6347:43: note: in expansion of macro 
'CSKY_ISA_FEATURE_GET'
6347 ||| 
CSKY_ISA_FEATURE_GET(fpv2_divd)))
  |   ^~~~

The 'CSKY_ISA_FEATURE_DEFINE (x)' is an enum contant, it will cause the 
condition always being true.
In addition to warning, it will let FPUV3 to generate a move instruction, which 
is unnecessary.
In a simple test case, the move instruction can be combined, so it was not 
found in the testsuite.
But in some complex scenarios, this may generate some redundant instructions.
The correct way is to use 'CSKY_ISA_FEATURE' instead of 
'CSKY_ISA_FEATURE_DEFINE'.

gcc/
* config/csky/csky.cc (csky_emit_compare_float): Fix the expanding of
float LE comparing with zero for fpuv3.
* config/csky/csky.h (TARGET_SUPPORT_FPV2): New, true if any fpuv2
features are enabled.
---
 gcc/config/csky/csky.cc | 4 +---
 gcc/config/csky/csky.h  | 4 
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/gcc/config/csky/csky.cc b/gcc/config/csky/csky.cc
index a7dc6cefead..4dc74d8924f 100644
--- a/gcc/config/csky/csky.cc
+++ b/gcc/config/csky/csky.cc
@@ -6342,9 +6342,7 @@ csky_emit_compare_float (enum rtx_code code, rtx op0, rtx 
op1)
 case GT:
 case LT:
 case LE:
-  if (op1 == CONST0_RTX (mode) && (CSKY_ISA_FEATURE_GET(fpv2_sf)
-  || CSKY_ISA_FEATURE_GET(fpv2_df)
-  || CSKY_ISA_FEATURE_GET(fpv2_divd)))
+  if (op1 == CONST0_RTX (mode) && TARGET_SUPPORT_FPV2)
op1 = force_reg (mode, op1);
   break;
 case ORDERED:
diff --git a/gcc/config/csky/csky.h b/gcc/config/csky/csky.h
index 37410f0cda4..f786ad55d43 100644
--- a/gcc/config/csky/csky.h
+++ b/gcc/config/csky/csky.h
@@ -165,6 +165,10 @@
 || CSKY_ISA_FEATURE (fpv3_sf) \
 || CSKY_ISA_FEATURE (fpv3_df))
 
+#define TARGET_SUPPORT_FPV2 (CSKY_ISA_FEATURE(fpv2_sf)\
+

[PATCH] tree-optimization/106866 - avoid dead abnormal edges from DCE

[Richard Biener via Gcc-patches]

When DCE clears cfun->calls_setjmp then suddenly we don't need
any abnormal call edges anymore.  The following makes sure to
prune them which otherwise can confuse other passes.

Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.

PR tree-optimization/106866
* tree-ssa-dce.cc (eliminate_unnecessary_stmts): When
we changed cfun->calls_setjmp make sure to purge all
abnormal call edges.

* gcc.dg/uninit-pr106866.c: New testcase.
---
 gcc/testsuite/gcc.dg/uninit-pr106866.c | 38 
 gcc/tree-ssa-dce.cc| 48 ++
 2 files changed, 79 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/uninit-pr106866.c

diff --git a/gcc/testsuite/gcc.dg/uninit-pr106866.c 
b/gcc/testsuite/gcc.dg/uninit-pr106866.c
new file mode 100644
index 000..530e274118c
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/uninit-pr106866.c
@@ -0,0 +1,38 @@
+/* { dg-do compile } */
+/* { dg-options "-O1 -fno-ipa-pure-const -Wuninitialized" } */
+
+int n;
+
+void
+empty (int)
+{
+}
+
+int
+bar (int x)
+{
+  return n + x + 1;
+}
+
+__attribute__ ((pure, returns_twice)) int
+foo (void)
+{
+  int uninitialized;
+
+  if (n)
+{
+  if (bar (0))
+return 0;
+
+  __builtin_unreachable ();
+}
+
+  while (uninitialized < 1) /* { dg-warning "uninitialized" } */
+{
+  foo ();
+  empty (bar (0) == foo ());
+  ++uninitialized;
+}
+
+  return 0;
+}
diff --git a/gcc/tree-ssa-dce.cc b/gcc/tree-ssa-dce.cc
index daf0782b0e1..54e5d8c2923 100644
--- a/gcc/tree-ssa-dce.cc
+++ b/gcc/tree-ssa-dce.cc
@@ -1313,6 +1313,7 @@ eliminate_unnecessary_stmts (bool aggressive)
   if (dump_file && (dump_flags & TDF_DETAILS))
 fprintf (dump_file, "\nEliminating unnecessary statements:\n");
 
+  bool had_setjmp = cfun->calls_setjmp;
   clear_special_calls ();
 
   /* Walking basic blocks and statements in reverse order avoids
@@ -1496,19 +1497,48 @@ eliminate_unnecessary_stmts (bool aggressive)
   something_changed |= remove_dead_phis (bb);
 }
 
-
-  /* Since we don't track liveness of virtual PHI nodes, it is possible that we
- rendered some PHI nodes unreachable while they are still in use.
- Mark them for renaming.  */
+  /* First remove queued edges.  */
   if (!to_remove_edges.is_empty ())
 {
-  basic_block prev_bb;
-
   /* Remove edges.  We've delayed this to not get bogus debug stmts
  during PHI node removal.  */
   for (unsigned i = 0; i < to_remove_edges.length (); ++i)
remove_edge (to_remove_edges[i]);
   cfg_altered = true;
+}
+  /* When we cleared calls_setjmp we can purge all abnormal edges.  Do so.  */
+  if (cfun->calls_setjmp != had_setjmp)
+{
+  gcc_assert (!cfun->calls_setjmp);
+  /* Make sure we only remove the edges, not dominated blocks.  Using
+gimple_purge_dead_abnormal_call_edges would do that and we
+cannot free dominators yet.  */
+  FOR_EACH_BB_FN (bb, cfun)
+   if (gcall *stmt = safe_dyn_cast  (last_stmt (bb)))
+ if (!stmt_can_make_abnormal_goto (stmt))
+   {
+ edge_iterator ei;
+ edge e;
+ for (ei = ei_start (bb->succs); (e = ei_safe_edge (ei)); )
+   {
+ if (e->flags & EDGE_ABNORMAL)
+   {
+ if (e->flags & EDGE_FALLTHRU)
+   e->flags &= ~EDGE_ABNORMAL;
+ else
+   remove_edge (e);
+ cfg_altered = true;
+   }
+ else
+   ei_next (&ei);
+   }
+   }
+}
+
+  /* Now remove the unreachable blocks.  */
+  if (cfg_altered)
+{
+  basic_block prev_bb;
 
   find_unreachable_blocks ();
 
@@ -1518,9 +1548,13 @@ eliminate_unnecessary_stmts (bool aggressive)
{
  prev_bb = bb->prev_bb;
 
- if (!bitmap_bit_p (bb_contains_live_stmts, bb->index)
+ if ((bb_contains_live_stmts
+  && !bitmap_bit_p (bb_contains_live_stmts, bb->index))
  || !(bb->flags & BB_REACHABLE))
{
+ /* Since we don't track liveness of virtual PHI nodes, it is
+possible that we rendered some PHI nodes unreachable while
+they are still in use.  Mark them for renaming.  */
  for (gphi_iterator gsi = gsi_start_phis (bb); !gsi_end_p (gsi);
   gsi_next (&gsi))
if (virtual_operand_p (gimple_phi_result (gsi.phi (
-- 
2.35.3

[PATCH] Restore XCOFF for DWARF on AIX.

[Martin Liška]

Hi.

The patch restores DWARF support for AIX target where XCOFF file container is 
used.
Verified before and after the patch, gcc119 machine (AIX) could not build any 
run-time library,
now it can.

Ready to be installed?
Thanks,
Martin

PR bootstrap/106855

gcc/ChangeLog:

* collect2.cc (scan_prog_file): Restore if XCOFF_DEBUGGING_INFO.
* config/rs6000/rs6000.cc (rs6000_option_override_internal):
  Restore usage of XCOFF_DEBUGGING_INFO.
* config/rs6000/xcoff.h (XCOFF_DEBUGGING_INFO): Restore.
* dwarf2asm.cc (XCOFF_DEBUGGING_INFO): Restore support for
  XCOFF_DEBUGGING_INFO.
(dw2_asm_output_nstring): Likewise.
(USE_LINKONCE_INDIRECT): Likewise.
* dwarf2out.cc (XCOFF_DEBUGGING_INFO): Likewise.
(HAVE_XCOFF_DWARF_EXTRAS): Likewise.
(output_fde): Likewise.
(output_call_frame_info): Likewise.
(have_macinfo): Likewise.
(add_AT_loc_list): Likewise.
(add_AT_view_list): Likewise.
(output_compilation_unit_header): Likewise.
(output_pubnames): Likewise.
(output_aranges): Likewise.
(output_line_info): Likewise.
(output_macinfo): Likewise.
(dwarf2out_finish): Likewise.
(dwarf2out_early_finish): Likewise.
---
 gcc/collect2.cc |   7 +++
 gcc/config/rs6000/rs6000.cc |   6 +++
 gcc/config/rs6000/xcoff.h   |   3 ++
 gcc/dwarf2asm.cc|  13 +++--
 gcc/dwarf2out.cc| 103 +---
 5 files changed, 97 insertions(+), 35 deletions(-)

diff --git a/gcc/collect2.cc b/gcc/collect2.cc
index 9715e8eee30..d81c7f28f16 100644
--- a/gcc/collect2.cc
+++ b/gcc/collect2.cc
@@ -2784,6 +2784,13 @@ scan_prog_file (const char *prog_name, scanpass 
which_pass,
  if ((name = ldgetname (ldptr, &symbol)) == NULL)
continue;   /* Should never happen.  */
 
+#ifdef XCOFF_DEBUGGING_INFO
+ /* All AIX function names have a duplicate entry
+beginning with a dot.  */
+ if (*name == '.')
+   ++name;
+#endif
+
  switch (is_ctor_dtor (name))
{
 #if TARGET_AIX_VERSION
diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index 8b4edd281ca..7623d69a8c0 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -3821,6 +3821,12 @@ rs6000_option_override_internal (bool global_init_p)
   if (TARGET_DEBUG_REG || TARGET_DEBUG_TARGET)
 rs6000_print_isa_options (stderr, 0, "before defaults", rs6000_isa_flags);
 
+#ifdef XCOFF_DEBUGGING_INFO
+  /* For AIX default to 64-bit DWARF.  */
+  if (!OPTION_SET_P (dwarf_offset_size))
+dwarf_offset_size = POINTER_SIZE_UNITS;
+#endif
+
   /* Handle explicit -mno-{altivec,vsx,power8-vector,power9-vector} and turn
  off all of the options that depend on those flags.  */
   ignore_masks = rs6000_disable_incompatible_switches ();
diff --git a/gcc/config/rs6000/xcoff.h b/gcc/config/rs6000/xcoff.h
index bafc57df59a..cd0f99cb9c6 100644
--- a/gcc/config/rs6000/xcoff.h
+++ b/gcc/config/rs6000/xcoff.h
@@ -21,6 +21,9 @@
 
 #define TARGET_OBJECT_FORMAT OBJECT_XCOFF
 
+/* The RS/6000 uses the XCOFF format.  */
+#define XCOFF_DEBUGGING_INFO 1
+
 /* Define if the object format being used is COFF or a superset.  */
 #define OBJECT_FORMAT_COFF
 
diff --git a/gcc/dwarf2asm.cc b/gcc/dwarf2asm.cc
index 7eac83f7b0f..274f574f25e 100644
--- a/gcc/dwarf2asm.cc
+++ b/gcc/dwarf2asm.cc
@@ -35,6 +35,10 @@ along with GCC; see the file COPYING3.  If not see
 #include "emit-rtl.h"
 #include "fold-const.h"
 
+#ifndef XCOFF_DEBUGGING_INFO
+#define XCOFF_DEBUGGING_INFO 0
+#endif
+
 
 /* Output an unaligned integer with the given value and size.  Prefer not
to print a newline, since the caller may want to add a comment.  */
@@ -380,13 +384,16 @@ dw2_asm_output_nstring (const char *str, size_t orig_len,
 
   if (flag_debug_asm && comment)
 {
-  fputs ("\t.ascii \"", asm_out_file);
+  if (XCOFF_DEBUGGING_INFO)
+   fputs ("\t.byte \"", asm_out_file);
+  else
+   fputs ("\t.ascii \"", asm_out_file);
 
   for (i = 0; i < len; i++)
{
  int c = str[i];
  if (c == '\"')
-   fputc ('\\', asm_out_file);
+   fputc (XCOFF_DEBUGGING_INFO ? '\"' : '\\', asm_out_file);
  else if (c == '\\')
fputc ('\\', asm_out_file);
  if (ISPRINT (c))
@@ -906,7 +913,7 @@ static GTY(()) hash_map *indirect_pool;
 static GTY(()) int dw2_const_labelno;
 
 #if defined(HAVE_GAS_HIDDEN)
-# define USE_LINKONCE_INDIRECT (SUPPORTS_ONE_ONLY)
+# define USE_LINKONCE_INDIRECT (SUPPORTS_ONE_ONLY && !XCOFF_DEBUGGING_INFO)
 #else
 # define USE_LINKONCE_INDIRECT 0
 #endif
diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
index e4183607ff8..2df75904022 100644
--- a/gcc/dwarf2out.cc
+++ b/gcc/dwarf2out.cc
@@ -105,6 +105,14 @@ static rtx_insn *cac

Re: [PATCH 1/3] STABS: remove -gstabs and -gxcoff functionality

[Martin Liška]

On 9/6/22 19:00, David Edelsohn wrote:
>   * dwarf2out.cc (XCOFF_DEBUGGING_INFO): Likewise.
>   (HAVE_XCOFF_DWARF_EXTRAS): Likewise.
>   (output_fde): Likewise.
>   (output_call_frame_info): Likewise.
>   (have_macinfo): Likewise.
>   (add_AT_loc_list): Likewise.
>   (add_AT_view_list): Likewise.
>   (output_compilation_unit_header): Likewise.
>   (output_pubnames): Likewise.
>   (output_aranges): Likewise.
>   (output_line_info): Likewise.
>   (output_macinfo): Likewise.
>   (dwarf2out_finish): Likewise.
>   (dwarf2out_early_finish): Likewise.
> 
> These changes are not correct and break AIX bootstrap.
> 
> Those changes are not related to stabs support. We agreed to remove stabs and
> 
> XCOFF stabs support, not GCC DWARF debugging support for AIX.

Sorry for the breakage, I've just sent a patch that restores that.

Cheers,
Martin

> 
> Also
> 
>   * configure: Regenerate. Likewise.
>   * configure.ac : Likewise.
> 
> does not list that tests for HAVE_XCOFF_DWARF_EXTRAS was removed, so the 
> ChangeLog was not accurate.
> 
> Again, that test is required for AIX is not part of stabs support.
> 
> 
> Please revert this change so that AIX can continue to be bootstrapped and 
> tested, and we can work together to test a corrected patch.
> 
> Thanks, David
> 
> 
> On Tue, Sep 6, 2022 at 12:31 PM David Edelsohn  > wrote:
> 
> I fully support the plan to remove stabs support, but this patch broke 
> bootstrap on AIX.  It seems rather bad policy to remove support for a feature 
> without ensuring that the removal does not negatively impact the targets 
> touched by the patch.  I should have been explicitly copied on these patches 
> and I should have been asked to test the patches before they were installed, 
> if for no other reason than politeness and consideration.
> 
> Thanks, David
> 
> 

Re: Patch ping (was Re: [PATCH] libstdc++: Clear padding bits in atomic compare_exchange)

[Jonathan Wakely via Gcc-patches]

Here's a complete patch that combines the various incremental patches
that have been going around. I'm testing this now.

Please take a look.
commit 4a0a8ec5bc2a890a1568f99eace666e9f72d
Author: Thomas Rodgers 
Date:   Thu Aug 25 11:11:40 2022

libstdc++: Clear padding bits in atomic compare_exchange

This change implements P0528 which requires that padding bits not
participate in atomic compare exchange operations. All arguments to the
generic template are 'sanitized' by the __builtin_clear_padding intrinsic
before they are used in comparisons. This requires that any stores
also sanitize the incoming value.

Co-authored-by: Jakub Jelinek 
Co-authored-by: Jonathan Wakely 

Signed-off-by: Thomas Rodgers 

libstdc++-v3/ChangeLog:

* include/bits/atomic_base.h (__atomic_impl::__maybe_has_padding):
New function.
(__atomic_impl::clear_padding): Likewise.
(__atomic_impl::__compare_exchange): Likewise.
(__atomic_impl::compare_exchange_weak): Delegate to
__compare_exchange.
(__atomic_impl::compare_exchange_strong): Likewise.
* include/std/atomic (atomic::atomic(T)): Clear padding when
possible in a constexpr function.
(atomic::store): Clear padding.
(atomic::exchange): Likewise.
(atomic::compare_exchange_weak): Use __compare_exchange.
(atomic::compare_exchange_strong): Likewise.
* testsuite/29_atomics/atomic/compare_exchange_padding.cc: New
test.
* testsuite/29_atomics/atomic_ref/compare_exchange_padding.cc:
New test.

diff --git a/libstdc++-v3/include/bits/atomic_base.h 
b/libstdc++-v3/include/bits/atomic_base.h
index d29e4434177..29315547aab 100644
--- a/libstdc++-v3/include/bits/atomic_base.h
+++ b/libstdc++-v3/include/bits/atomic_base.h
@@ -33,6 +33,7 @@
 #pragma GCC system_header
 
 #include 
+#include  // For placement new
 #include 
 #include 
 #include 
@@ -952,19 +953,76 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   { return __atomic_fetch_sub(&_M_p, _M_type_size(__d), int(__m)); }
 };
 
-  /// @endcond
+  namespace __atomic_impl
+  {
+// Implementation details of atomic padding handling
+
+template
+  constexpr bool
+  __maybe_has_padding()
+  {
+#if ! __has_builtin(__builtin_clear_padding)
+   return false;
+#elif __has_builtin(__has_unique_object_representations)
+   return !__has_unique_object_representations(_Tp)
+ && !is_same<_Tp, float>::value && !is_same<_Tp, double>::value;
+#else
+   return true;
+#endif
+  }
+
+template
+  _GLIBCXX_ALWAYS_INLINE _Tp*
+  __clear_padding(_Tp& __val) noexcept
+  {
+   auto* __ptr = std::__addressof(__val);
+#if __has_builtin(__builtin_clear_padding)
+   if _GLIBCXX17_CONSTEXPR (__atomic_impl::__maybe_has_padding<_Tp>())
+ __builtin_clear_padding(__ptr);
+#endif
+   return __ptr;
+  }
+
+// Remove volatile and create a non-deduced context for value arguments.
+template
+  using _Val = typename remove_volatile<_Tp>::type;
+
+template
+  _GLIBCXX_ALWAYS_INLINE bool
+  __compare_exchange(_Tp& __val, _Val<_Tp>& __e, _Val<_Tp>& __i,
+bool __weak, memory_order __s, memory_order __f) 
noexcept
+  {
+   __glibcxx_assert(__is_valid_cmpexch_failure_order(__f));
+
+   using _Vp = _Val<_Tp>;
+
+   if _GLIBCXX17_CONSTEXPR (__atomic_impl::__maybe_has_padding<_Vp>())
+ {
+   // We must not modify __e on success, so cannot clear its padding.
+   // Copy into a buffer and clear that, then copy back on failure.
+   alignas(_Vp) unsigned char __buf[sizeof(_Vp)];
+   _Vp* __exp = ::new((void*)__buf) _Vp(__e);
+   __atomic_impl::__clear_padding(*__exp);
+   if (__atomic_compare_exchange(std::__addressof(__val), __exp,
+ __atomic_impl::__clear_padding(__i),
+ __weak, int(__s), int(__f)))
+ return true;
+   __builtin_memcpy(std::__addressof(__e), __exp, sizeof(_Vp));
+   return false;
+ }
+   else
+ return __atomic_compare_exchange(std::__addressof(__val),
+  std::__addressof(__e),
+  std::__addressof(__i),
+  __weak, int(__s), int(__f));
+  }
+  } // namespace __atomic_impl
 
 #if __cplusplus > 201703L
-  /// @cond undocumented
-
   // Implementation details of atomic_ref and atomic.
   namespace __atomic_impl
   {
-// Remove volatile and create a non-deduced context for value arguments.
-template
-  using _Val = remove_volatile_t<_Tp>;
-
-// As above, but for difference_type arguments.
+// Like _Val above, but for difference_type arguments.
 template
 

Re: [PATCH][DOCS] Mention removed ports in GCC 13.

[Martin Liška]

On 9/5/22 14:31, Gerald Pfeifer wrote:
> On Fri, 26 Aug 2022, Richard Biener via Gcc-patches wrote:
>>> Ready for master?
>> OK
> 
> Actually both Richi and me missed a little detail:
> 
>>> -  ...
>>> +The support for the cr16-elf, 
>>> tilegx*-linux and tilepro*-linux
>>> +  configurations has been removed.
>>> + ^
> ^

Thanks for the fix. Btw. have you removed the w3c validation script?

Martin

> 
> The patch added one  plus two s - fixed thusly.
> 
> Gerald
> 
> 
> commit 0d66c0f73e9c54536070346bd4d52f61132ba012
> Author: Gerald Pfeifer 
> Date:   Mon Sep 5 20:28:57 2022 +0800
> 
> gcc-13: Remove extraneous  under Caveats
> 
> This snuck in via 79ecba7b which added two s instead of one.
> 
> diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
> index 3d3d012c..5b336e04 100644
> --- a/htdocs/gcc-13/changes.html
> +++ b/htdocs/gcc-13/changes.html
> @@ -35,7 +35,6 @@ a work-in-progress.
>-gstabs and -gxcoff options) has been 
> removed.
>(This means the dbx debugger is no longer
>supported, either.)
> -
>  
>  
>  

Re: [PATCH] Always default to DWARF2_DEBUG if not specified, warn about deprecated STABS

[Richard Biener via Gcc-patches]

On Wed, Sep 7, 2022 at 12:51 PM Jan-Benedict Glaw  wrote:
>
> Hi!
>
> On Mon, 2022-08-29 22:11:35 +0200, Jan-Benedict Glaw  
> wrote:
> > On Sun, 2022-08-28 15:32:53 -0600, Jeff Law via Gcc-patches 
> >  wrote:
> > > On 8/28/2022 1:50 AM, Jan-Benedict Glaw wrote:
> > > > On Tue, 2021-09-21 16:25:19 +0200, Richard Biener via Gcc-patches 
> > > >  wrote:
> > > > > This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE
> > > > > is not specified by the target and errors out if DWARF DWARF is not 
> > > > > supported.
> > > > While I think the pdp11 bits arreved, the rest did not (yet). Just
> > > > checked my auto-builder logs. When building current HEAD as
> > > >
> > > >   ../gcc/configure --prefix=... --enable-werror-always \
> > > >   --enable-languages=all --disable-gcov \
> > > >   --disable-shared --disable-threads --without-headers \
> > > >   --target=...
> > > >   make V=1 all-gcc
> > > >
> > > > ALL of these targets won't build right now:
> > [...]
> > > Umm, most of those -elf targets do build.  See:
> > >
> > > http://law-sandy.freeddns.org:8080
> >
> > Another builder. :)  Randomly picking xtensa-elf, you're configuring
> > as
> >
> > + ../../gcc/configure --disable-analyzer --with-system-libunwind
> > --with-newlib --without-headers --disable-threads --disable-shared
> > --enable-languages=c,c++
> > --prefix=/home/jlaw/jenkins/workspace/xtensa-elf/xtensa-elf-obj/gcc/../../xtensa-elf-installed
> > --target=xtensa-elf
> >
> > I guess the main difference that lets my builds fail might be
> > --enable-languages=all (vs. c,c++ in your case.)
> >
> > Maybe you'd give that a try? (...and I'll trigger a build with just
> > c,c++ on my builder.)
>
> So ... just building for --enable-languages=c,c++ usually works for
> the *-elf targets, but I'm interested in building as much code as
> possible. Is it expected that with --enable-languages=all, all those
> targets will break? Can we have a sane default here, or need the
> maintainers decide for any given debug format?

It's not expected that they break - when targets do not decide on a default
format and they can handle DWARF that is automatically selected.  And
that shouldn't change whether you enable some language or not.

Richard.

>
> Thanks,
>   Jan-Benedict
>
> --

Re: [PATCH v3] Simplify memchr with small constant strings

[Richard Biener via Gcc-patches]

On Wed, Sep 7, 2022 at 12:58 PM Jan-Benedict Glaw  wrote:
>
> Hi!
>
> On Wed, 2022-07-13 09:50:14 -0700, H.J. Lu via Gcc-patches 
>  wrote:
> > When memchr is applied on a constant string of no more than the bytes of
> > a word, simplify memchr by checking each byte in the constant string.
> >
> > int f (int a)
> > {
> >return  __builtin_memchr ("AE", a, 2) != 0;
> > }
> >
> > is simplified to
> >
> > int f (int a)
> > {
> >   return ((char) a == 'A' || (char) a == 'E') != 0;
> > }
>
> Seems this caused a regression for --target=avr-elf, pru-elf and
> rl78-elf:
>
> .../gcc/configure --prefix=... --enable-werror-always --enable-languages=all 
> --disable-gcov --disable-shared --disable-threads --target=pru-elf 
> --without-headers
> [...]
> make V=1 all-gcc
> [...]
> /usr/lib/gcc-snapshot/bin/g++  -fno-PIE -c   -g -O2   -DIN_GCC  
> -DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions -fno-rtti 
> -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
> -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic 
> -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror 
> -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. 
> -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include 
> -I../../gcc/gcc/../libcody  -I../../gcc/gcc/../libdecnumber 
> -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
> -I../../gcc/gcc/../libbacktrace   -o tree-ssa-forwprop.o -MT 
> tree-ssa-forwprop.o -MMD -MP -MF ./.deps/tree-ssa-forwprop.TPo 
> ../../gcc/gcc/tree-ssa-forwprop.cc
> ../../gcc/gcc/tree-ssa-forwprop.cc: In function 'bool 
> simplify_builtin_call(gimple_stmt_iterator*, tree)':
> ../../gcc/gcc/tree-ssa-forwprop.cc:1258:42: error: array subscript 1 is 
> outside array bounds of 'tree_node* [1]' [-Werror=array-bounds]
>  1258 | op[i - 1] = fold_convert_loc (loc, boolean_type_node,
>   | ~^~~~
>  1259 |   fold_build2_loc (loc,
>   |   ~
>  1260 |
> BIT_IOR_EXPR,
>   |
> ~
>  1261 |
> boolean_type_node,
>   |
> ~~
>  1262 |op[i - 1],
>   |~~
>  1263 |op[i]));
>   |~~~
> In file included from ../../gcc/gcc/system.h:707,
>  from ../../gcc/gcc/tree-ssa-forwprop.cc:21:
> ../../gcc/gcc/../include/libiberty.h:733:36: note: at offset 8 into object of 
> size [0, 8] allocated by '__builtin_alloca'
>   733 | # define alloca(x) __builtin_alloca(x)
>   |^~~
> ../../gcc/gcc/../include/libiberty.h:365:40: note: in expansion of macro 
> 'alloca'
>   365 | #define XALLOCAVEC(T, N)((T *) alloca (sizeof (T) * (N)))
>   |^~
> ../../gcc/gcc/tree-ssa-forwprop.cc:1250:22: note: in expansion of macro 
> 'XALLOCAVEC'
>  1250 |   tree *op = XALLOCAVEC (tree, isize);
>   |  ^~
> cc1plus: all warnings being treated as errors
> make[1]: *** [Makefile:1146: tree-ssa-forwprop.o] Error 1
> make[1]: Leaving directory 
> '/var/lib/laminar/run/gcc-pru-elf/1/toolchain-build/gcc'
> make: *** [Makefile:4583: all-gcc] Error 2

can you open a bugreport please?

> Thanks,
>   Jan-Benedict
>
> --

Re: [PATCH] Restore XCOFF for DWARF on AIX.

[Richard Biener via Gcc-patches]

On Wed, Sep 7, 2022 at 1:45 PM Martin Liška  wrote:
>
> Hi.
>
> The patch restores DWARF support for AIX target where XCOFF file container is 
> used.
> Verified before and after the patch, gcc119 machine (AIX) could not build any 
> run-time library,
> now it can.
>
> Ready to be installed?

OK.

Thanks,
Richard.

> Thanks,
> Martin
>
> PR bootstrap/106855
>
> gcc/ChangeLog:
>
> * collect2.cc (scan_prog_file): Restore if XCOFF_DEBUGGING_INFO.
> * config/rs6000/rs6000.cc (rs6000_option_override_internal):
>   Restore usage of XCOFF_DEBUGGING_INFO.
> * config/rs6000/xcoff.h (XCOFF_DEBUGGING_INFO): Restore.
> * dwarf2asm.cc (XCOFF_DEBUGGING_INFO): Restore support for
>   XCOFF_DEBUGGING_INFO.
> (dw2_asm_output_nstring): Likewise.
> (USE_LINKONCE_INDIRECT): Likewise.
> * dwarf2out.cc (XCOFF_DEBUGGING_INFO): Likewise.
> (HAVE_XCOFF_DWARF_EXTRAS): Likewise.
> (output_fde): Likewise.
> (output_call_frame_info): Likewise.
> (have_macinfo): Likewise.
> (add_AT_loc_list): Likewise.
> (add_AT_view_list): Likewise.
> (output_compilation_unit_header): Likewise.
> (output_pubnames): Likewise.
> (output_aranges): Likewise.
> (output_line_info): Likewise.
> (output_macinfo): Likewise.
> (dwarf2out_finish): Likewise.
> (dwarf2out_early_finish): Likewise.
> ---
>  gcc/collect2.cc |   7 +++
>  gcc/config/rs6000/rs6000.cc |   6 +++
>  gcc/config/rs6000/xcoff.h   |   3 ++
>  gcc/dwarf2asm.cc|  13 +++--
>  gcc/dwarf2out.cc| 103 +---
>  5 files changed, 97 insertions(+), 35 deletions(-)
>
> diff --git a/gcc/collect2.cc b/gcc/collect2.cc
> index 9715e8eee30..d81c7f28f16 100644
> --- a/gcc/collect2.cc
> +++ b/gcc/collect2.cc
> @@ -2784,6 +2784,13 @@ scan_prog_file (const char *prog_name, scanpass 
> which_pass,
>   if ((name = ldgetname (ldptr, &symbol)) == NULL)
> continue;   /* Should never happen.  */
>
> +#ifdef XCOFF_DEBUGGING_INFO
> + /* All AIX function names have a duplicate entry
> +beginning with a dot.  */
> + if (*name == '.')
> +   ++name;
> +#endif
> +
>   switch (is_ctor_dtor (name))
> {
>  #if TARGET_AIX_VERSION
> diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
> index 8b4edd281ca..7623d69a8c0 100644
> --- a/gcc/config/rs6000/rs6000.cc
> +++ b/gcc/config/rs6000/rs6000.cc
> @@ -3821,6 +3821,12 @@ rs6000_option_override_internal (bool global_init_p)
>if (TARGET_DEBUG_REG || TARGET_DEBUG_TARGET)
>  rs6000_print_isa_options (stderr, 0, "before defaults", 
> rs6000_isa_flags);
>
> +#ifdef XCOFF_DEBUGGING_INFO
> +  /* For AIX default to 64-bit DWARF.  */
> +  if (!OPTION_SET_P (dwarf_offset_size))
> +dwarf_offset_size = POINTER_SIZE_UNITS;
> +#endif
> +
>/* Handle explicit -mno-{altivec,vsx,power8-vector,power9-vector} and turn
>   off all of the options that depend on those flags.  */
>ignore_masks = rs6000_disable_incompatible_switches ();
> diff --git a/gcc/config/rs6000/xcoff.h b/gcc/config/rs6000/xcoff.h
> index bafc57df59a..cd0f99cb9c6 100644
> --- a/gcc/config/rs6000/xcoff.h
> +++ b/gcc/config/rs6000/xcoff.h
> @@ -21,6 +21,9 @@
>
>  #define TARGET_OBJECT_FORMAT OBJECT_XCOFF
>
> +/* The RS/6000 uses the XCOFF format.  */
> +#define XCOFF_DEBUGGING_INFO 1
> +
>  /* Define if the object format being used is COFF or a superset.  */
>  #define OBJECT_FORMAT_COFF
>
> diff --git a/gcc/dwarf2asm.cc b/gcc/dwarf2asm.cc
> index 7eac83f7b0f..274f574f25e 100644
> --- a/gcc/dwarf2asm.cc
> +++ b/gcc/dwarf2asm.cc
> @@ -35,6 +35,10 @@ along with GCC; see the file COPYING3.  If not see
>  #include "emit-rtl.h"
>  #include "fold-const.h"
>
> +#ifndef XCOFF_DEBUGGING_INFO
> +#define XCOFF_DEBUGGING_INFO 0
> +#endif
> +
>
>  /* Output an unaligned integer with the given value and size.  Prefer not
> to print a newline, since the caller may want to add a comment.  */
> @@ -380,13 +384,16 @@ dw2_asm_output_nstring (const char *str, size_t 
> orig_len,
>
>if (flag_debug_asm && comment)
>  {
> -  fputs ("\t.ascii \"", asm_out_file);
> +  if (XCOFF_DEBUGGING_INFO)
> +   fputs ("\t.byte \"", asm_out_file);
> +  else
> +   fputs ("\t.ascii \"", asm_out_file);
>
>for (i = 0; i < len; i++)
> {
>   int c = str[i];
>   if (c == '\"')
> -   fputc ('\\', asm_out_file);
> +   fputc (XCOFF_DEBUGGING_INFO ? '\"' : '\\', asm_out_file);
>   else if (c == '\\')
> fputc ('\\', asm_out_file);
>   if (ISPRINT (c))
> @@ -906,7 +913,7 @@ static GTY(()) hash_map 
> *indirect_pool;
>  static GTY(()) int dw2_const_labelno;
>
>  #if defined(HAVE_GAS_HIDDEN)
> -# define USE_LINKONCE

Re: [PATCH] expand: Convert cst - x into cst xor x.

[Richard Biener via Gcc-patches]

On Tue, Sep 6, 2022 at 4:01 PM Robin Dapp  wrote:
>
> > cost might also depend on the context in case flag setting
> > behavior differs for xor vs sub (on x86 sub looks strictly more
> > powerful here).  The same is probably true when looking for
> > a combination with another bitwise operation.
> >
> > Btw, why not perform the optimization in expand_binop?  That
> > for example already does
> >
> >   if (binoptab == sub_optab && CONST_INT_P (op1))
> > {
> >   op1 = negate_rtx (mode, op1);
> >   binoptab = add_optab;
> > }
> >
> > alternatively a targets expander can do the selection as well.
>
> I was under the impression optabs/expand_binops is only supposed to
> "optimize" when it's clear that it is an optimization/canonicalization.
> I didn't see other functions there trying two alternatives and also none
> seems to use range information already.
>
> Regarding the proper costing (including the surroundings): is it even
> possible to encompass everything in such a localized decision? A
> target's expander decision would also not take this into account when
> deciding? If so, should we not perform this conversion generally and not
> only target specifc?

The question is really whether xor or sub is "better" statically.  I can't
think of any reasons.  On s390, why does xor end up "better"?

Richard.

>
> Regards
>  Robin

[PATCH] c++: Fix type completeness checks for type traits [PR106838]

[Jonathan Wakely via Gcc-patches]

Tested powerpc64le-linux. OK for trunk?

-- >8 --

The check_trait_type function is used for a number of different type
traits that have different requirements on their arguments. For example,
__is_constructible allows arrays of unknown bound even if the array
element is an incomplete type, but __is_aggregate does not, it always
requires the array element type to be complete. Other traits have
different requirements again, e.g. __is_empty allows incomplete unions,
and arrays (of known or unknown bound) of incomplete types.

This alters the check_trait_type function to take an additional KIND
parameter which indicates which set of type trait requirements to check.

The type_has_virtual_destructor change is needed to avoid an ICE.
Previously it could never be called for incomplete union types as they
were (incorrectly) rejected by check_trait_type.

This change causes some additional diagnostics in some libstdc++ tests,
where the front end was not previously complaining about invalid types
that the library assertions diagnosed. We should consider removing the
library assertions from traits where the front end implements the
correct checks now.

PR c++/106838

gcc/cp/ChangeLog:

* class.cc (type_has_virtual_destructor): Return false for
union types.
* semantics.cc (check_trait_type): Add KIND parameter to support
different sets of requirements.
(finish_trait_expr): Pass KIND argument for relevant traits.

gcc/ChangeLog:

* doc/extend.texi (Type Traits): Fix requirements. Document
__is_aggregate and __is_final.

gcc/testsuite/ChangeLog:

* g++.dg/ext/array4.C: Fix invalid use of __is_constructible.
* g++.dg/ext/unary_trait_incomplete.C: Fix tests for traits with
different requirements.

libstdc++-v3/ChangeLog:

* testsuite/20_util/is_complete_or_unbounded/memoization_neg.cc:
Prune additional errors from front-end.
* testsuite/20_util/is_move_constructible/incomplete_neg.cc:
Likewise.
* testsuite/20_util/is_nothrow_swappable/incomplete_neg.cc:
Likewise.
* testsuite/20_util/is_nothrow_swappable_with/incomplete_neg.cc:
Likewise.
* testsuite/20_util/is_swappable_with/incomplete_neg.cc:
Likewise.
---
 gcc/cp/class.cc   |   2 +-
 gcc/cp/semantics.cc   |  54 +++--
 gcc/doc/extend.texi   |  31 --
 gcc/testsuite/g++.dg/ext/array4.C |   3 +-
 .../g++.dg/ext/unary_trait_incomplete.C   | 105 ++
 .../memoization_neg.cc|   2 +
 .../is_move_constructible/incomplete_neg.cc   |   1 +
 .../is_nothrow_swappable/incomplete_neg.cc|   1 +
 .../incomplete_neg.cc |   1 +
 .../is_swappable_with/incomplete_neg.cc   |   1 +
 10 files changed, 151 insertions(+), 50 deletions(-)

diff --git a/gcc/cp/class.cc b/gcc/cp/class.cc
index a12d3673b96..b84f4227e7e 100644
--- a/gcc/cp/class.cc
+++ b/gcc/cp/class.cc
@@ -5620,7 +5620,7 @@ type_has_virtual_destructor (tree type)
 {
   tree dtor;
 
-  if (!CLASS_TYPE_P (type))
+  if (!NON_UNION_CLASS_TYPE_P (type))
 return false;
 
   gcc_assert (COMPLETE_TYPE_P (type));
diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 3d58d67ec11..ee361ae22cb 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -12028,11 +12028,23 @@ trait_expr_value (cp_trait_kind kind, tree type1, 
tree type2)
 }
 }
 
-/* If TYPE is an array of unknown bound, or (possibly cv-qualified)
-   void, or a complete type, returns true, otherwise false.  */
+/* Returns true if TYPE meets the requirements for the specified KIND,
+   false otherwise.
+
+   When KIND == 1, TYPE must be an array of unknown bound,
+   or (possibly cv-qualified) void, or a complete type.
+
+   When KIND == 2, TYPE must be a complete type, or array of complete type,
+   or (possibly cv-qualified) void.
+
+   When KIND == 3:
+   If TYPE is a non-union class type, it must be complete.
+
+   When KIND == 4:
+   If TYPE is a class type, it must be complete.  */
 
 static bool
-check_trait_type (tree type)
+check_trait_type (tree type, int kind = 1)
 {
   if (type == NULL_TREE)
 return true;
@@ -12041,8 +12053,14 @@ check_trait_type (tree type)
 return (check_trait_type (TREE_VALUE (type))
&& check_trait_type (TREE_CHAIN (type)));
 
-  if (TREE_CODE (type) == ARRAY_TYPE && !TYPE_DOMAIN (type))
-return true;
+  if (kind == 1 && TREE_CODE (type) == ARRAY_TYPE && !TYPE_DOMAIN (type))
+return true; // Array of unknown bound. Don't care about completeness.
+
+  if (kind == 3 && !NON_UNION_CLASS_TYPE_P (type))
+return true; // Not a non-union class type. Don't care about completeness.
+
+  if (kind == 4 && TREE_CODE (type) == ARRAY_TYPE)
+return true; // Not a class type. Don't care about completeness.
 
   if (VOID_TYPE_P (type))
 return true;
@@ -12080,23 +12098,37 @@ fi

Re: [PATCH] expand: Convert cst - x into cst xor x.

[Robin Dapp via Gcc-patches]

> The question is really whether xor or sub is "better" statically.  I can't
> think of any reasons.  On s390, why does xor end up "better"?

There is an xor with immediate (as opposed to no "subtract from
immediate") which saves an instruction, usually.  On x86, I think the
usual argument for xor is that it's shorter (if flags etc. are not needed).

It's not that I don't want to implement it in the backend, just that I
understood the original PR in a way that it would make sense to have
this conversion available for more targets.  If there are too many
confounding factors that prevent this situation from being statically
costed properly, then sure, not much use in implementing it generally.

Regards
 Robin

Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

[Martin Liška]

On 8/31/22 15:25, Martin Liška wrote:
> On 8/31/22 15:19, Gaius Mulley wrote:
>> Martin Liška  writes:
>>
>>> How do you mean that? You should ideally generate .rst (Sphinx markup)
>>> instead of the *.texi files. These will be then included in the converted
>>> Sphinx manual similarly to how you include it now to the Texinfo manual.
>>>
>>> Does it make sense?
>>>
>>> Cheers,
>>> Martin
>>
>> ah right - yes this makes sense.
> 
> Goo!
> 
>> I mistakenly thought the .rst files
>> could be automatically generated from texinfo sources.  In any case
>> generating .rst directly will likely contain advantages,
> 
> Yes, that's what I'm doing for the existing documentation, but the conversion
> is not perfect and I had to make some manual changes to the emitted .rst 
> content.
> 
> So please fix the crash I reported and I can convert GM2 texi manual.

Note I've just converted the current Modula-2 manual to RST (Sphinx):
https://splichal.eu/scripts/sphinx/

It contains some minor issues, but in general it should be pretty fine. Note 
pygments
contains a corresponding lexer:
https://pygments.org/docs/lexers/#multi-dialect-lexer-for-modula-2

Martin

> 
> Cheers,
> Martin
> 
>>
>> regards,
>> Gaius
> 

Re: [PATCH] d: Fix #error You must define PREFERRED_DEBUGGING_TYPE if DWARF is not supported (PR105659)

[Rainer Orth]

Hi Iain,

>> Yes, this is data related. The DSO registry picks up nothing in the
>> miscompiled stage2 compiler, leaving all data uninitialized.  The stage1
>> compiler works, and runs all module constructors ahead of compilation.
>> 
>
> Ohh, backtrack on that, analysis is correct, but it is a compiler regression.
>
> The TARGET_D_MINFO_SECTION macros are in elfos.h, which of course no
> longer get pulled in to sol2-d.cc after I removed the tm.h include.
>
> Re-adding these two ought to fix the bootstrap for you.
>
> #include "tm.h"
> #include "memmodel.h"

it does indeed: with that patch, i386-pc-solaris2.11 and
sparc-sun-solaris2.11 bootstraps completed successfully and test results
are back to normal.

Thanks a lot.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] expand: Convert cst - x into cst xor x.

[Richard Biener via Gcc-patches]

On Wed, Sep 7, 2022 at 2:20 PM Robin Dapp  wrote:
>
> > The question is really whether xor or sub is "better" statically.  I can't
> > think of any reasons.  On s390, why does xor end up "better"?
>
> There is an xor with immediate (as opposed to no "subtract from
> immediate") which saves an instruction, usually.  On x86, I think the
> usual argument for xor is that it's shorter (if flags etc. are not needed).
>
> It's not that I don't want to implement it in the backend, just that I
> understood the original PR in a way that it would make sense to have
> this conversion available for more targets.  If there are too many
> confounding factors that prevent this situation from being statically
> costed properly, then sure, not much use in implementing it generally.

Do we have evidence that targets properly cost XOR vs SUB RTXen?

It might actually be a reload optimization - when the constant is
available in a register use 'sub', when it needs to be reloaded
use 'xor'?

That said, I wonder if the fallout of changing some SUB to XOR
is bigger than the benefit when we do it early (missed combines, etc.)?

> Regards
>  Robin

[PATCH] arm: Fix constant immediates predicates and constraints for some MVE builtins

[Christophe Lyon via Gcc-patches]

Several MVE builtins incorrectly use the same predicate/constraint
pair for several modes, which does not match the specification.
This patch uses the appropriate iterator instead.

2022-09-06  Christophe Lyon  

gcc/
* config/arm/mve.md (mve_vqshluq_n_s): Use
MVE_pred/MVE_constraint instead of mve_imm_7/Ra.
(mve_vqshluq_m_n_s): Likewise.
(mve_vqrshrnbq_n_): Use MVE_pred3/MVE_constraint3
instead of mve_imm_8/Rb.
(mve_vqrshrunbq_n_s): Likewise.
(mve_vqrshrntq_n_): Likewise.
(mve_vqrshruntq_n_s): Likewise.
(mve_vrshrnbq_n_): Likewise.
(mve_vrshrntq_n_): Likewise.
(mve_vqrshrnbq_m_n_): Likewise.
(mve_vqrshrntq_m_n_): Likewise.
(mve_vrshrnbq_m_n_): Likewise.
(mve_vrshrntq_m_n_): Likewise.
(mve_vqrshrunbq_m_n_s): Likewise.
(mve_vsriq_n_): Likewise.
---
 gcc/config/arm/mve.md | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md
index c4dec01baac..714178609f7 100644
--- a/gcc/config/arm/mve.md
+++ b/gcc/config/arm/mve.md
@@ -1624,7 +1624,7 @@ (define_insn "mve_vqshluq_n_s"
   [
(set (match_operand:MVE_2 0 "s_register_operand" "=w")
(unspec:MVE_2 [(match_operand:MVE_2 1 "s_register_operand" "w")
-  (match_operand:SI 2 "mve_imm_7" "Ra")]
+  (match_operand:SI 2 "" "")]
 VQSHLUQ_N_S))
   ]
   "TARGET_HAVE_MVE"
@@ -2615,7 +2615,7 @@ (define_insn "mve_vqrshrnbq_n_"
(set (match_operand: 0 "s_register_operand" "=w")
(unspec: [(match_operand: 1 
"s_register_operand" "0")
 (match_operand:MVE_5 2 "s_register_operand" 
"w")
-(match_operand:SI 3 "mve_imm_8" "Rb")]
+(match_operand:SI 3 "" 
"")]
 VQRSHRNBQ_N))
   ]
   "TARGET_HAVE_MVE"
@@ -2630,7 +2630,7 @@ (define_insn "mve_vqrshrunbq_n_s"
(set (match_operand: 0 "s_register_operand" "=w")
(unspec: [(match_operand: 1 
"s_register_operand" "0")
 (match_operand:MVE_5 2 "s_register_operand" 
"w")
-(match_operand:SI 3 "mve_imm_8" "Rb")]
+(match_operand:SI 3 "" 
"")]
 VQRSHRUNBQ_N_S))
   ]
   "TARGET_HAVE_MVE"
@@ -3570,7 +3570,7 @@ (define_insn "mve_vsriq_n_"
(set (match_operand:MVE_2 0 "s_register_operand" "=w")
(unspec:MVE_2 [(match_operand:MVE_2 1 "s_register_operand" "0")
   (match_operand:MVE_2 2 "s_register_operand" "w")
-  (match_operand:SI 3 "mve_imm_selective_upto_8" "Rg")]
+  (match_operand:SI 3 "" "")]
 VSRIQ_N))
   ]
   "TARGET_HAVE_MVE"
@@ -4473,7 +4473,7 @@ (define_insn "mve_vqrshrntq_n_"
(set (match_operand: 0 "s_register_operand" "=w")
(unspec: [(match_operand: 1 
"s_register_operand" "0")
   (match_operand:MVE_5 2 "s_register_operand" "w")
-  (match_operand:SI 3 "mve_imm_8" "Rb")]
+  (match_operand:SI 3 "" "")]
 VQRSHRNTQ_N))
   ]
   "TARGET_HAVE_MVE"
@@ -4489,7 +4489,7 @@ (define_insn "mve_vqrshruntq_n_s"
(set (match_operand: 0 "s_register_operand" "=w")
(unspec: [(match_operand: 1 
"s_register_operand" "0")
   (match_operand:MVE_5 2 "s_register_operand" "w")
-  (match_operand:SI 3 "mve_imm_8" "Rb")]
+  (match_operand:SI 3 "" "")]
 VQRSHRUNTQ_N_S))
   ]
   "TARGET_HAVE_MVE"
@@ -4777,7 +4777,7 @@ (define_insn "mve_vrshrnbq_n_"
(set (match_operand: 0 "s_register_operand" "=w")
(unspec: [(match_operand: 1 
"s_register_operand" "0")
   (match_operand:MVE_5 2 "s_register_operand" "w")
-  (match_operand:SI 3 "mve_imm_8" "Rb")]
+  (match_operand:SI 3 "" "")]
 VRSHRNBQ_N))
   ]
   "TARGET_HAVE_MVE"
@@ -4793,7 +4793,7 @@ (define_insn "mve_vrshrntq_n_"
(set (match_operand: 0 "s_register_operand" "=w")
(unspec: [(match_operand: 1 
"s_register_operand" "0")
   (match_operand:MVE_5 2 "s_register_operand" "w")
-  (match_operand:SI 3 "mve_imm_8" "Rb")]
+  (match_operand:SI 3 "" "")]
 VRSHRNTQ_N))
   ]
   "TARGET_HAVE_MVE"
@@ -4987,7 +4987,7 @@ (define_insn "mve_vqshluq_m_n_s"
(set (match_operand:MVE_2 0 "s_register_operand" "=w")
(unspec:MVE_2 [(match_operand:MVE_2 1 "s_register_operand" "0")
   (match_operand:MVE_2 2 "s_register_operand" "w")
-  (match_operand:SI 3 "mve_imm_7" "Ra")
+  (match_operand:SI 3 "" "")
   (match_operand: 4 "vpr_register_operand" 
"Up")]
 VQSHLUQ_M_N_S))
   ]
@@ -5019,7 +5019,7 @@ (define_insn "mve_vsriq_m_n_"
(set (match_operand:MVE_2 0 "s_regist

Re: [PATCH] d: Fix #error You must define PREFERRED_DEBUGGING_TYPE if DWARF is not supported (PR105659)

[Iain Buclaw via Gcc-patches]

Excerpts from Rainer Orth's message of September 7, 2022 2:40 pm:
> Hi Iain,
> 
>>> Yes, this is data related. The DSO registry picks up nothing in the
>>> miscompiled stage2 compiler, leaving all data uninitialized.  The stage1
>>> compiler works, and runs all module constructors ahead of compilation.
>>> 
>>
>> Ohh, backtrack on that, analysis is correct, but it is a compiler regression.
>>
>> The TARGET_D_MINFO_SECTION macros are in elfos.h, which of course no
>> longer get pulled in to sol2-d.cc after I removed the tm.h include.
>>
>> Re-adding these two ought to fix the bootstrap for you.
>>
>> #include "tm.h"
>> #include "memmodel.h"
> 
> it does indeed: with that patch, i386-pc-solaris2.11 and
> sparc-sun-solaris2.11 bootstraps completed successfully and test results
> are back to normal.
> 
> Thanks a lot.
> 

I'm just running through various target configurations with memmodel.h
removed, I know it was used to be required for one of the targets
(probably SPARC), though that may have been because of the previously
included tm_p.h header.

Will have a think about a likely follow-up though.

Firstly fixing the outstanding issues with
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598078.html

Secondly possibly using a different method to coax out the object format
to the D target hooks, or front-end.

Iain.

Re: [PATCH] d: Fix #error You must define PREFERRED_DEBUGGING_TYPE if DWARF is not supported (PR105659)

[Rainer Orth]

Hi Iain,

> Excerpts from Rainer Orth's message of September 7, 2022 2:40 pm:
>> Hi Iain,
>> 
 Yes, this is data related. The DSO registry picks up nothing in the
 miscompiled stage2 compiler, leaving all data uninitialized.  The stage1
 compiler works, and runs all module constructors ahead of compilation.
 
>>>
>>> Ohh, backtrack on that, analysis is correct, but it is a compiler 
>>> regression.
>>>
>>> The TARGET_D_MINFO_SECTION macros are in elfos.h, which of course no
>>> longer get pulled in to sol2-d.cc after I removed the tm.h include.
>>>
>>> Re-adding these two ought to fix the bootstrap for you.
>>>
>>> #include "tm.h"
>>> #include "memmodel.h"
>> 
>> it does indeed: with that patch, i386-pc-solaris2.11 and
>> sparc-sun-solaris2.11 bootstraps completed successfully and test results
>> are back to normal.
>> 
>> Thanks a lot.
>> 
>
> I'm just running through various target configurations with memmodel.h
> removed, I know it was used to be required for one of the targets
> (probably SPARC), though that may have been because of the previously

almost certainly.  It's in my initial patch to fix D compilation on
Solaris:

https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01890.html

> included tm_p.h header.
>
> Will have a think about a likely follow-up though.
>
> Firstly fixing the outstanding issues with
> https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598078.html

I belive I had it working on Solaris, at least...

> Secondly possibly using a different method to coax out the object format
> to the D target hooks, or front-end.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

RE: [PATCH] arm: Fix constant immediates predicates and constraints for some MVE builtins

[Kyrylo Tkachov via Gcc-patches]

Hi Christophe,

> -Original Message-
> From: Gcc-patches  bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Christophe
> Lyon via Gcc-patches
> Sent: Wednesday, September 7, 2022 2:03 PM
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH] arm: Fix constant immediates predicates and constraints for
> some MVE builtins
> 
> Several MVE builtins incorrectly use the same predicate/constraint
> pair for several modes, which does not match the specification.
> This patch uses the appropriate iterator instead.
> 

This looks ok to me.
I presume you've tested this appropriately?
If so, ok for trunk.
Thanks,
Kyrill

> 2022-09-06  Christophe Lyon  
> 
>   gcc/
>   * config/arm/mve.md (mve_vqshluq_n_s): Use
>   MVE_pred/MVE_constraint instead of mve_imm_7/Ra.
>   (mve_vqshluq_m_n_s): Likewise.
>   (mve_vqrshrnbq_n_): Use
> MVE_pred3/MVE_constraint3
>   instead of mve_imm_8/Rb.
>   (mve_vqrshrunbq_n_s): Likewise.
>   (mve_vqrshrntq_n_): Likewise.
>   (mve_vqrshruntq_n_s): Likewise.
>   (mve_vrshrnbq_n_): Likewise.
>   (mve_vrshrntq_n_): Likewise.
>   (mve_vqrshrnbq_m_n_): Likewise.
>   (mve_vqrshrntq_m_n_): Likewise.
>   (mve_vrshrnbq_m_n_): Likewise.
>   (mve_vrshrntq_m_n_): Likewise.
>   (mve_vqrshrunbq_m_n_s): Likewise.
>   (mve_vsriq_n_ instead
>   of mve_imm_selective_upto_8/Rg.
>   (mve_vsriq_m_n_): Likewise.
> ---
>  gcc/config/arm/mve.md | 30 +++---
>  1 file changed, 15 insertions(+), 15 deletions(-)
> 
> diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md
> index c4dec01baac..714178609f7 100644
> --- a/gcc/config/arm/mve.md
> +++ b/gcc/config/arm/mve.md
> @@ -1624,7 +1624,7 @@ (define_insn "mve_vqshluq_n_s"
>[
> (set (match_operand:MVE_2 0 "s_register_operand" "=w")
>   (unspec:MVE_2 [(match_operand:MVE_2 1 "s_register_operand"
> "w")
> -(match_operand:SI 2 "mve_imm_7" "Ra")]
> +(match_operand:SI 2 ""
> "")]
>VQSHLUQ_N_S))
>]
>"TARGET_HAVE_MVE"
> @@ -2615,7 +2615,7 @@ (define_insn "mve_vqrshrnbq_n_"
> (set (match_operand: 0 "s_register_operand" "=w")
>   (unspec: [(match_operand: 1
> "s_register_operand" "0")
>(match_operand:MVE_5 2
> "s_register_operand" "w")
> -  (match_operand:SI 3 "mve_imm_8" "Rb")]
> +  (match_operand:SI 3 ""
> "")]
>VQRSHRNBQ_N))
>]
>"TARGET_HAVE_MVE"
> @@ -2630,7 +2630,7 @@ (define_insn "mve_vqrshrunbq_n_s"
> (set (match_operand: 0 "s_register_operand" "=w")
>   (unspec: [(match_operand: 1
> "s_register_operand" "0")
>(match_operand:MVE_5 2
> "s_register_operand" "w")
> -  (match_operand:SI 3 "mve_imm_8" "Rb")]
> +  (match_operand:SI 3 ""
> "")]
>VQRSHRUNBQ_N_S))
>]
>"TARGET_HAVE_MVE"
> @@ -3570,7 +3570,7 @@ (define_insn "mve_vsriq_n_"
> (set (match_operand:MVE_2 0 "s_register_operand" "=w")
>   (unspec:MVE_2 [(match_operand:MVE_2 1 "s_register_operand"
> "0")
>  (match_operand:MVE_2 2 "s_register_operand" "w")
> -(match_operand:SI 3 "mve_imm_selective_upto_8"
> "Rg")]
> +(match_operand:SI 3 ""
> "")]
>VSRIQ_N))
>]
>"TARGET_HAVE_MVE"
> @@ -4473,7 +4473,7 @@ (define_insn "mve_vqrshrntq_n_"
> (set (match_operand: 0 "s_register_operand" "=w")
>   (unspec: [(match_operand: 1
> "s_register_operand" "0")
>  (match_operand:MVE_5 2 "s_register_operand" "w")
> -(match_operand:SI 3 "mve_imm_8" "Rb")]
> +(match_operand:SI 3 ""
> "")]
>VQRSHRNTQ_N))
>]
>"TARGET_HAVE_MVE"
> @@ -4489,7 +4489,7 @@ (define_insn "mve_vqrshruntq_n_s"
> (set (match_operand: 0 "s_register_operand" "=w")
>   (unspec: [(match_operand: 1
> "s_register_operand" "0")
>  (match_operand:MVE_5 2 "s_register_operand" "w")
> -(match_operand:SI 3 "mve_imm_8" "Rb")]
> +(match_operand:SI 3 ""
> "")]
>VQRSHRUNTQ_N_S))
>]
>"TARGET_HAVE_MVE"
> @@ -4777,7 +4777,7 @@ (define_insn "mve_vrshrnbq_n_"
> (set (match_operand: 0 "s_register_operand" "=w")
>   (unspec: [(match_operand: 1
> "s_register_operand" "0")
>  (match_operand:MVE_5 2 "s_register_operand" "w")
> -(match_operand:SI 3 "mve_imm_8" "Rb")]
> +(match_operand:SI 3 ""
> "")]
>VRSHRNBQ_N))
>]
>"TARGET_HAVE_MVE"
> @@ -4793,7 +4793,7 @@ (define_insn "mve_vrshrntq_n_"
> (set (match_operand: 0 "s_register_operand" "=w")
>   (unspec: [(match_operand: 1
> "s_register_operand" "0")
>  (match_operand:MVE_5 2 "s_register_operand" "w")
> -(match_operand:SI 3 "mve_imm_8" "Rb")]
> +(match_operan

Re: [PATCH] arm: Fix constant immediates predicates and constraints for some MVE builtins

[Christophe Lyon via Gcc-patches]

On 9/7/22 15:34, Kyrylo Tkachov wrote:

Hi Christophe,


-Original Message-
From: Gcc-patches  On Behalf Of Christophe
Lyon via Gcc-patches
Sent: Wednesday, September 7, 2022 2:03 PM
To: gcc-patches@gcc.gnu.org
Subject: [PATCH] arm: Fix constant immediates predicates and constraints for
some MVE builtins

Several MVE builtins incorrectly use the same predicate/constraint
pair for several modes, which does not match the specification.
This patch uses the appropriate iterator instead.



This looks ok to me.
I presume you've tested this appropriately?


I tested it manually with an offending testcase.

Unfortunately, the existing testcases all use '1' as immediate, so this 
does not really check the boundaries. We do plan to improve the existing 
tests in a later patch that will more generally improve the MVE tests.


Christophe


If so, ok for trunk.
Thanks,
Kyrill


2022-09-06  Christophe Lyon  

gcc/
* config/arm/mve.md (mve_vqshluq_n_s): Use
MVE_pred/MVE_constraint instead of mve_imm_7/Ra.
(mve_vqshluq_m_n_s): Likewise.
(mve_vqrshrnbq_n_): Use
MVE_pred3/MVE_constraint3
instead of mve_imm_8/Rb.
(mve_vqrshrunbq_n_s): Likewise.
(mve_vqrshrntq_n_): Likewise.
(mve_vqrshruntq_n_s): Likewise.
(mve_vrshrnbq_n_): Likewise.
(mve_vrshrntq_n_): Likewise.
(mve_vqrshrnbq_m_n_): Likewise.
(mve_vqrshrntq_m_n_): Likewise.
(mve_vrshrnbq_m_n_): Likewise.
(mve_vrshrntq_m_n_): Likewise.
(mve_vqrshrunbq_m_n_s): Likewise.
(mve_vsriq_n_): Likewise.
---
  gcc/config/arm/mve.md | 30 +++---
  1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md
index c4dec01baac..714178609f7 100644
--- a/gcc/config/arm/mve.md
+++ b/gcc/config/arm/mve.md
@@ -1624,7 +1624,7 @@ (define_insn "mve_vqshluq_n_s"
[
 (set (match_operand:MVE_2 0 "s_register_operand" "=w")
(unspec:MVE_2 [(match_operand:MVE_2 1 "s_register_operand"
"w")
-  (match_operand:SI 2 "mve_imm_7" "Ra")]
+  (match_operand:SI 2 ""
"")]
 VQSHLUQ_N_S))
]
"TARGET_HAVE_MVE"
@@ -2615,7 +2615,7 @@ (define_insn "mve_vqrshrnbq_n_"
 (set (match_operand: 0 "s_register_operand" "=w")
(unspec: [(match_operand: 1
"s_register_operand" "0")
 (match_operand:MVE_5 2
"s_register_operand" "w")
-(match_operand:SI 3 "mve_imm_8" "Rb")]
+(match_operand:SI 3 ""
"")]
 VQRSHRNBQ_N))
]
"TARGET_HAVE_MVE"
@@ -2630,7 +2630,7 @@ (define_insn "mve_vqrshrunbq_n_s"
 (set (match_operand: 0 "s_register_operand" "=w")
(unspec: [(match_operand: 1
"s_register_operand" "0")
 (match_operand:MVE_5 2
"s_register_operand" "w")
-(match_operand:SI 3 "mve_imm_8" "Rb")]
+(match_operand:SI 3 ""
"")]
 VQRSHRUNBQ_N_S))
]
"TARGET_HAVE_MVE"
@@ -3570,7 +3570,7 @@ (define_insn "mve_vsriq_n_"
 (set (match_operand:MVE_2 0 "s_register_operand" "=w")
(unspec:MVE_2 [(match_operand:MVE_2 1 "s_register_operand"
"0")
   (match_operand:MVE_2 2 "s_register_operand" "w")
-  (match_operand:SI 3 "mve_imm_selective_upto_8"
"Rg")]
+  (match_operand:SI 3 ""
"")]
 VSRIQ_N))
]
"TARGET_HAVE_MVE"
@@ -4473,7 +4473,7 @@ (define_insn "mve_vqrshrntq_n_"
 (set (match_operand: 0 "s_register_operand" "=w")
(unspec: [(match_operand: 1
"s_register_operand" "0")
   (match_operand:MVE_5 2 "s_register_operand" "w")
-  (match_operand:SI 3 "mve_imm_8" "Rb")]
+  (match_operand:SI 3 ""
"")]
 VQRSHRNTQ_N))
]
"TARGET_HAVE_MVE"
@@ -4489,7 +4489,7 @@ (define_insn "mve_vqrshruntq_n_s"
 (set (match_operand: 0 "s_register_operand" "=w")
(unspec: [(match_operand: 1
"s_register_operand" "0")
   (match_operand:MVE_5 2 "s_register_operand" "w")
-  (match_operand:SI 3 "mve_imm_8" "Rb")]
+  (match_operand:SI 3 ""
"")]
 VQRSHRUNTQ_N_S))
]
"TARGET_HAVE_MVE"
@@ -4777,7 +4777,7 @@ (define_insn "mve_vrshrnbq_n_"
 (set (match_operand: 0 "s_register_operand" "=w")
(unspec: [(match_operand: 1
"s_register_operand" "0")
   (match_operand:MVE_5 2 "s_register_operand" "w")
-  (match_operand:SI 3 "mve_imm_8" "Rb")]
+  (match_operand:SI 3 ""
"")]
 VRSHRNBQ_N))
]
"TARGET_HAVE_MVE"
@@ -4793,7 +4793,7 @@ (define_insn "mve_vrshrntq_n_"
 (set (match_operand: 0 "s_register_operand" "=w")
(unspec: [(match_operand: 1
"s_register_operand" "0")
   (match_operand:MVE_5 2 "s_register_operand" "w")
-

RE: [PATCH] arm: Fix constant immediates predicates and constraints for some MVE builtins

[Kyrylo Tkachov via Gcc-patches]

> -Original Message-
> From: Christophe Lyon 
> Sent: Wednesday, September 7, 2022 2:41 PM
> To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] arm: Fix constant immediates predicates and
> constraints for some MVE builtins
> 
> 
> 
> On 9/7/22 15:34, Kyrylo Tkachov wrote:
> > Hi Christophe,
> >
> >> -Original Message-
> >> From: Gcc-patches  >> bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Christophe
> >> Lyon via Gcc-patches
> >> Sent: Wednesday, September 7, 2022 2:03 PM
> >> To: gcc-patches@gcc.gnu.org
> >> Subject: [PATCH] arm: Fix constant immediates predicates and constraints
> for
> >> some MVE builtins
> >>
> >> Several MVE builtins incorrectly use the same predicate/constraint
> >> pair for several modes, which does not match the specification.
> >> This patch uses the appropriate iterator instead.
> >>
> >
> > This looks ok to me.
> > I presume you've tested this appropriately?
> 
> I tested it manually with an offending testcase.
> 
> Unfortunately, the existing testcases all use '1' as immediate, so this
> does not really check the boundaries. We do plan to improve the existing
> tests in a later patch that will more generally improve the MVE tests.

Sure, improving the tests is definitely worth it here.
I meant more in the context of a standard bootstrap and testsuite run.
Thanks,
Kyrill

> 
> Christophe
> 
> > If so, ok for trunk.
> > Thanks,
> > Kyrill
> >
> >> 2022-09-06  Christophe Lyon  
> >>
> >>gcc/
> >>* config/arm/mve.md (mve_vqshluq_n_s): Use
> >>MVE_pred/MVE_constraint instead of mve_imm_7/Ra.
> >>(mve_vqshluq_m_n_s): Likewise.
> >>(mve_vqrshrnbq_n_): Use
> >> MVE_pred3/MVE_constraint3
> >>instead of mve_imm_8/Rb.
> >>(mve_vqrshrunbq_n_s): Likewise.
> >>(mve_vqrshrntq_n_): Likewise.
> >>(mve_vqrshruntq_n_s): Likewise.
> >>(mve_vrshrnbq_n_): Likewise.
> >>(mve_vrshrntq_n_): Likewise.
> >>(mve_vqrshrnbq_m_n_): Likewise.
> >>(mve_vqrshrntq_m_n_): Likewise.
> >>(mve_vrshrnbq_m_n_): Likewise.
> >>(mve_vrshrntq_m_n_): Likewise.
> >>(mve_vqrshrunbq_m_n_s): Likewise.
> >>(mve_vsriq_n_ >> instead
> >>of mve_imm_selective_upto_8/Rg.
> >>(mve_vsriq_m_n_): Likewise.
> >> ---
> >>   gcc/config/arm/mve.md | 30 +++---
> >>   1 file changed, 15 insertions(+), 15 deletions(-)
> >>
> >> diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md
> >> index c4dec01baac..714178609f7 100644
> >> --- a/gcc/config/arm/mve.md
> >> +++ b/gcc/config/arm/mve.md
> >> @@ -1624,7 +1624,7 @@ (define_insn "mve_vqshluq_n_s"
> >> [
> >>  (set (match_operand:MVE_2 0 "s_register_operand" "=w")
> >>(unspec:MVE_2 [(match_operand:MVE_2 1 "s_register_operand"
> >> "w")
> >> - (match_operand:SI 2 "mve_imm_7" "Ra")]
> >> + (match_operand:SI 2 ""
> >> "")]
> >> VQSHLUQ_N_S))
> >> ]
> >> "TARGET_HAVE_MVE"
> >> @@ -2615,7 +2615,7 @@ (define_insn
> "mve_vqrshrnbq_n_"
> >>  (set (match_operand: 0 "s_register_operand" "=w")
> >>(unspec: [(match_operand: 1
> >> "s_register_operand" "0")
> >> (match_operand:MVE_5 2
> >> "s_register_operand" "w")
> >> -   (match_operand:SI 3 "mve_imm_8" "Rb")]
> >> +   (match_operand:SI 3 ""
> >> "")]
> >> VQRSHRNBQ_N))
> >> ]
> >> "TARGET_HAVE_MVE"
> >> @@ -2630,7 +2630,7 @@ (define_insn "mve_vqrshrunbq_n_s"
> >>  (set (match_operand: 0 "s_register_operand" "=w")
> >>(unspec: [(match_operand: 1
> >> "s_register_operand" "0")
> >> (match_operand:MVE_5 2
> >> "s_register_operand" "w")
> >> -   (match_operand:SI 3 "mve_imm_8" "Rb")]
> >> +   (match_operand:SI 3 ""
> >> "")]
> >> VQRSHRUNBQ_N_S))
> >> ]
> >> "TARGET_HAVE_MVE"
> >> @@ -3570,7 +3570,7 @@ (define_insn "mve_vsriq_n_"
> >>  (set (match_operand:MVE_2 0 "s_register_operand" "=w")
> >>(unspec:MVE_2 [(match_operand:MVE_2 1 "s_register_operand"
> >> "0")
> >>   (match_operand:MVE_2 2 "s_register_operand" "w")
> >> - (match_operand:SI 3 "mve_imm_selective_upto_8"
> >> "Rg")]
> >> + (match_operand:SI 3 ""
> >> "")]
> >> VSRIQ_N))
> >> ]
> >> "TARGET_HAVE_MVE"
> >> @@ -4473,7 +4473,7 @@ (define_insn
> "mve_vqrshrntq_n_"
> >>  (set (match_operand: 0 "s_register_operand" "=w")
> >>(unspec: [(match_operand: 1
> >> "s_register_operand" "0")
> >>   (match_operand:MVE_5 2 "s_register_operand" "w")
> >> - (match_operand:SI 3 "mve_imm_8" "Rb")]
> >> + (match_operand:SI 3 ""
> >> "")]
> >> VQRSHRNTQ_N))
> >> ]
> >> "TARGET_HAVE_MVE"
> >> @@ -4489,7 +4489,7 @@ (define_insn "mve_vqrshruntq_n_s"
> >>  (set (match_operand: 0 "s_register_operand" "=w")
> >>(unspec: [(match_operand: 1
> >> "s_register_operand" "0")
> >>

Re: [PATCH] Restore XCOFF for DWARF on AIX.

[David Edelsohn via Gcc-patches]

On Wed, Sep 7, 2022 at 7:45 AM Martin Liška  wrote:

> Hi.
>
> The patch restores DWARF support for AIX target where XCOFF file container
> is used.
> Verified before and after the patch, gcc119 machine (AIX) could not build
> any run-time library,
> now it can.
>
> Ready to be installed?
> Thanks,
> Martin
>
> PR bootstrap/106855
>
> gcc/ChangeLog:
>
> * collect2.cc (scan_prog_file): Restore if XCOFF_DEBUGGING_INFO.
> * config/rs6000/rs6000.cc (rs6000_option_override_internal):
>   Restore usage of XCOFF_DEBUGGING_INFO.
> * config/rs6000/xcoff.h (XCOFF_DEBUGGING_INFO): Restore.
> * dwarf2asm.cc (XCOFF_DEBUGGING_INFO): Restore support for
>   XCOFF_DEBUGGING_INFO.
> (dw2_asm_output_nstring): Likewise.
> (USE_LINKONCE_INDIRECT): Likewise.
> * dwarf2out.cc (XCOFF_DEBUGGING_INFO): Likewise.
> (HAVE_XCOFF_DWARF_EXTRAS): Likewise.
> (output_fde): Likewise.
> (output_call_frame_info): Likewise.
> (have_macinfo): Likewise.
> (add_AT_loc_list): Likewise.
> (add_AT_view_list): Likewise.
> (output_compilation_unit_header): Likewise.
> (output_pubnames): Likewise.
> (output_aranges): Likewise.
> (output_line_info): Likewise.
> (output_macinfo): Likewise.
> (dwarf2out_finish): Likewise.
> (dwarf2out_early_finish): Likewise.
>

Hi, Martin

Thanks for the quick patch to fix this.  This restores bootstrap, but does
not completely restore functionality.  This patch did not restore the
gcc/configure test for AIX assembler XCOFF feature support that defines
HAVE_XCOFF_DWARF_EXTRAS.  That part of the removal patch also needs to be
reverted.

Thanks, David

Re: [PATCH v2, rs6000] Change insn condition from TARGET_64BIT to TARGET_POWERPC64 for VSX scalar extract/insert instructions

[Paul A. Clarke via Gcc-patches]

On Tue, Sep 06, 2022 at 12:19:06PM -0500, Segher Boessenkool wrote:
> On Mon, Sep 05, 2022 at 02:36:30PM +0800, HAO CHEN GUI wrote:
> > On 2/9/2022 下午 11:56, Segher Boessenkool wrote:
> > >> -  const signed long __builtin_vsx_scalar_extract_exp (double);
> > >> +  const unsigned long long __builtin_vsx_scalar_extract_exp (double);
> > >>  VSEEDP xsxexpdp {}
> > >>
> > >> -  const signed long __builtin_vsx_scalar_extract_sig (double);
> > >> +  const unsigned long long __builtin_vsx_scalar_extract_sig (double);
> > >>  VSESDP xsxsigdp {}
> > > This also brings these legacy builtins in line with the vec_ versions,
> > > which are the preferred builtins (they are defined in the PVIPR).
> > 
> > The return type of vec_ version built-ins are different than their 
> > definition
> > in PVIPR. In PVIPR, they're vector unsigned int or vector unsigned long 
> > long.
> > Shall we correct them?
> > 
> >   const vd __builtin_vsx_extract_exp_dp (vd);
> > VEEDP xvxexpdp {}
> > 
> >   const vf __builtin_vsx_extract_exp_sp (vf);
> > VEESP xvxexpsp {}
> > 
> >   const vd __builtin_vsx_extract_sig_dp (vd);
> > VESDP xvxsigdp {}
> > 
> >   const vf __builtin_vsx_extract_sig_sp (vf);
> > VESSP xvxsigsp {}
> 
> Those are the vsx_ versions.  I'm not sure what you're asking.
> 
> It won't be easy at all to change types from vector integer to vector
> float, it will break all over.  A compatibility nightmare.  It is better
> if you can show the current stuff cannot ever work, it's not a problem
> to replace it in that case.

I think Hao Chen is concerned about the return types:

> >   const vd __builtin_vsx_extract_exp_dp (vd);
> > VEEDP xvxexpdp {}

Per PVIPR, this should return vector unsigned long long ("vull" not "vd").

> >   const vf __builtin_vsx_extract_exp_sp (vf);
> > VEESP xvxexpsp {}

This should return vector unsigned int ("vui" not "vf").

> >   const vd __builtin_vsx_extract_sig_dp (vd);
> > VESDP xvxsigdp {}

This should return vector unsigned long long ("vull" not "vd").

> >   const vf __builtin_vsx_extract_sig_sp (vf);
> > VESSP xvxsigsp {}

This should return vector unsigned int ("vui" not "vf").

PC

[PATCH 0/2] Variable tracking and subvalues

[Stefan Schulze Frielinghaus via Gcc-patches]

For variable tracking there exists cases where a value is moved in a
wider mode than its native mode.  For example:

int
foo (int x)
{
  bar (x);
  return x;
}

compiles on IBM zSystems into

0x010012b0 <+0>: stmg%r12,%r15,96(%r15)
0x010012b6 <+6>: lgr %r12,%r2
0x010012ba <+10>:lay %r15,-160(%r15)
0x010012c0 <+16>:brasl   %r14,0x10012a0 
0x010012c6 <+22>:lgr %r2,%r12
0x010012ca <+26>:lmg %r12,%r15,256(%r15)
0x010012d0 <+32>:br  %r14

Initially variable x with SImode is held in register r2 which is moved
to call-saved register r12 with DImode from where it is also restored.
The cselib patch records that the initial value held in r2 is a subvalue
of r12 which enables var-tracking to emit a register location entry:

(gdb) info address x
Symbol "x" is multi-location:
  Base address 0x10012b0  Range 0x10012b0-0x10012c5: a variable in $r2
  Range 0x10012c5-0x10012d0: a variable in $r12
  Range 0x10012d0-0x10012d2: a variable in $r2

However, this only works for straight-line programs and fails e.g. for

__attribute__((noinline, noclone)) void
fn1 (int x)
{
  __asm volatile ("" : "+r" (x) : : "memory");
}

__attribute__((noinline, noclone)) int
fn2 (int x, int y)
{
  if (x)
{
  fn1 (x);  // (*)
  fn1 (x);
}
  return y;
}

__attribute__((noinline, noclone)) int
fn3 (int x, int y)
{
  return fn2 (x, y);
}

int
main ()
{
  fn3 (36, 25);
  return 0;
}

At (*) variable x is moved into a call-saved register.  However, the
former cselib patch does not cover this since cselib flushes its tables
across jumps.  In order to not give up entirely by the second patch an
entry value is referred.

In summary this fixes the following guality tests for IBM zSystems:

Fixed by cselib patch:
FAIL: gcc.dg/guality/pr43051-1.c   -O1  -DPREVENT_OPTIMIZATION  line 35 v == 1
FAIL: gcc.dg/guality/pr43051-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 35 v == 1
FAIL: gcc.dg/guality/pr43051-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 40 v == 1
FAIL: gcc.dg/guality/pr43051-1.c   -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  -DPREVENT_OPTIMIZATION  line 35 v == 1
FAIL: gcc.dg/guality/pr43051-1.c   -O2  -DPREVENT_OPTIMIZATION  line 40 v == 1
FAIL: gcc.dg/guality/pr43051-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  -DPREVENT_OPTIMIZATION line 40 v == 1
FAIL: gcc.dg/guality/pr43051-1.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 35 v == 
1
FAIL: gcc.dg/guality/pr43051-1.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 40 v == 
1
FAIL: gcc.dg/guality/pr43051-1.c   -O2  -DPREVENT_OPTIMIZATION  line 35 v == 1
FAIL: gcc.dg/guality/pr43051-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  -DPREVENT_OPTIMIZATION line 35 v == 1
FAIL: gcc.dg/guality/pr43051-1.c   -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  -DPREVENT_OPTIMIZATION  line 40 v == 1
FAIL: gcc.dg/guality/pr43051-1.c  -Og -DPREVENT_OPTIMIZATION  line 35 v == 1
FAIL: gcc.dg/guality/pr43051-1.c  -Og -DPREVENT_OPTIMIZATION  line 40 v == 1
FAIL: gcc.dg/guality/pr43051-1.c   -O1  -DPREVENT_OPTIMIZATION  line 40 v == 1

Fixed by var-tracking patch:
FAIL: gcc.dg/guality/pr54519-1.c   -O2  -DPREVENT_OPTIMIZATION  line 23 x == 98
FAIL: gcc.dg/guality/pr54519-5.c  -Og -DPREVENT_OPTIMIZATION  line 17 y == 25
FAIL: gcc.dg/guality/pr54519-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  -DPREVENT_OPTIMIZATION line 20 x == 36
FAIL: gcc.dg/guality/pr54519-1.c  -Og -DPREVENT_OPTIMIZATION  line 20 x == 36
FAIL: gcc.dg/guality/pr54519-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  -DPREVENT_OPTIMIZATION line 23 x == 98
FAIL: gcc.dg/guality/pr54551.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  -DPREVENT_OPTIMIZATION line 18 a == 4
FAIL: gcc.dg/guality/pr54551.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 18 a == 4
FAIL: gcc.dg/guality/pr54519-1.c   -O1  -DPREVENT_OPTIMIZATION  line 23 x == 98
FAIL: gcc.dg/guality/pr54551.c   -Os  -DPREVENT_OPTIMIZATION  line 18 a == 4
FAIL: gcc.dg/guality/pr54519-5.c   -O1  -DPREVENT_OPTIMIZATION  line 17 y == 25
FAIL: gcc.dg/guality/pr54519-1.c   -O1  -DPREVENT_OPTIMIZATION  line 20 x == 36
FAIL: gcc.dg/guality/pr54519-4.c   -Os  -DPREVENT_OPTIMIZATION  line 17 y == 25
FAIL: gcc.dg/guality/pr54519-3.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 23 z == 
8
FAIL: gcc.dg/guality/pr54551.c   -O2  -DPREVENT_OPTIMIZATION  line 18 a == 4
FAIL: gcc.dg/guality/pr54551.c   -O1  -DPREVENT_OPTIMIZATION  line 18 a == 4
FAIL: gcc.dg/guality/pr54519-1.c   -O2  -DPREVENT_OPTIMIZATION  line 20 x == 36
FAIL: gcc.dg/guality/pr54693-2.c   -Os  -DPREVENT_OPTIMIZATION  line 21 x == 10 
- i
FAIL: gcc.dg/guality/pr54519-5.c   -O2  -DPREVENT_OPTIMIZATION  line 17 y == 25
FAIL: gcc.dg/guality/pr54519-3.c   -Os  -DPREVENT_OPTIMIZATION  line 20 z == 6
FAIL: gcc.dg/guality/pr54519-1

[PATCH 1/2] cselib: Keep track of further subvalue relations

[Stefan Schulze Frielinghaus via Gcc-patches]

Whenever a new cselib value is created check whether a smaller value
exists which is contained in the bigger one.  If so add a subreg
relation to locs of the smaller one.

gcc/ChangeLog:

* cselib.cc (new_cselib_val): Keep track of further subvalue
relations.
---
 gcc/cselib.cc | 20 
 1 file changed, 20 insertions(+)

diff --git a/gcc/cselib.cc b/gcc/cselib.cc
index 6a5609786fa..9b582e5d3d6 100644
--- a/gcc/cselib.cc
+++ b/gcc/cselib.cc
@@ -1569,6 +1569,26 @@ new_cselib_val (unsigned int hash, machine_mode mode, 
rtx x)
   e->locs = 0;
   e->next_containing_mem = 0;
 
+  scalar_int_mode int_mode;
+  if (REG_P (x) && is_int_mode (mode, &int_mode)
+  && REG_VALUES (REGNO (x)) != NULL
+  && (!cselib_current_insn || !DEBUG_INSN_P (cselib_current_insn)))
+{
+  rtx copy = shallow_copy_rtx (x);
+  scalar_int_mode narrow_mode_iter;
+  FOR_EACH_MODE_UNTIL (narrow_mode_iter, int_mode)
+   {
+ PUT_MODE_RAW (copy, narrow_mode_iter);
+ cselib_val *v = cselib_lookup (copy, narrow_mode_iter, 0, VOIDmode);
+ if (v)
+   {
+ rtx sub = lowpart_subreg (narrow_mode_iter, e->val_rtx, int_mode);
+ if (sub)
+   new_elt_loc_list (v, sub);
+   }
+   }
+}
+
   if (dump_file && (dump_flags & TDF_CSELIB))
 {
   fprintf (dump_file, "cselib value %u:%u ", e->uid, hash);
-- 
2.37.2

[PATCH 2/2] var-tracking: Add entry values up to max register mode

[Stefan Schulze Frielinghaus via Gcc-patches]

For parameter of type integer which do not consume a whole register
(modulo sign/zero extension) this patch adds entry values up to maximal
register mode.

gcc/ChangeLog:

* var-tracking.cc (vt_add_function_parameter): Add entry values
up to maximal register mode.
---
 gcc/var-tracking.cc | 17 +
 1 file changed, 17 insertions(+)

diff --git a/gcc/var-tracking.cc b/gcc/var-tracking.cc
index 235981d100f..9c40ec4fb8b 100644
--- a/gcc/var-tracking.cc
+++ b/gcc/var-tracking.cc
@@ -9906,6 +9906,23 @@ vt_add_function_parameter (tree parm)
 VAR_INIT_STATUS_INITIALIZED, NULL, INSERT);
}
}
+
+ if (GET_MODE_CLASS (mode) == MODE_INT)
+   {
+ machine_mode wider_mode_iter;
+ FOR_EACH_WIDER_MODE (wider_mode_iter, mode)
+   {
+ if (!HWI_COMPUTABLE_MODE_P (wider_mode_iter))
+   break;
+ rtx wider_reg
+   = gen_rtx_REG (wider_mode_iter, REGNO (incoming));
+ cselib_val *wider_val
+   = cselib_lookup_from_insn (wider_reg, wider_mode_iter, 1,
+  VOIDmode, get_insns ());
+ preserve_value (wider_val);
+ record_entry_value (wider_val, wider_reg);
+   }
+   }
}
 }
   else if (GET_CODE (incoming) == PARALLEL && !dv_onepart_p (dv))
-- 
2.37.2

Re: [PATCH v2, rs6000] Change insn condition from TARGET_64BIT to TARGET_POWERPC64 for VSX scalar extract/insert instructions

[Segher Boessenkool]

Hi!

On Wed, Sep 07, 2022 at 08:51:17AM -0500, Paul A. Clarke wrote:
> On Tue, Sep 06, 2022 at 12:19:06PM -0500, Segher Boessenkool wrote:
> > On Mon, Sep 05, 2022 at 02:36:30PM +0800, HAO CHEN GUI wrote:
> > > The return type of vec_ version built-ins are different than their 
> > > definition
> > > in PVIPR. In PVIPR, they're vector unsigned int or vector unsigned long 
> > > long.
> > > Shall we correct them?
> > > 
> > >   const vd __builtin_vsx_extract_exp_dp (vd);
> > > VEEDP xvxexpdp {}
> > > 
> > >   const vf __builtin_vsx_extract_exp_sp (vf);
> > > VEESP xvxexpsp {}
> > > 
> > >   const vd __builtin_vsx_extract_sig_dp (vd);
> > > VESDP xvxsigdp {}
> > > 
> > >   const vf __builtin_vsx_extract_sig_sp (vf);
> > > VESSP xvxsigsp {}
> > 
> > Those are the vsx_ versions.  I'm not sure what you're asking.
> > 
> > It won't be easy at all to change types from vector integer to vector
> > float, it will break all over.  A compatibility nightmare.  It is better
> > if you can show the current stuff cannot ever work, it's not a problem
> > to replace it in that case.
> 
> I think Hao Chen is concerned about the return types:

Yes, and so am I.

> > >   const vd __builtin_vsx_extract_exp_dp (vd);
> > > VEEDP xvxexpdp {}
> 
> Per PVIPR, this should return vector unsigned long long ("vull" not "vd").

But changing that will make any existing code that now works, fail
horribly.  Of course it is possible no such code exists :-)

What did this do before the builtin rewrite?


 ~ - ~ - ~


It looks like it did the right thing before, but that is just based on
reading the code, I haven't actually tried it :-)

So, changing the vsx_ code here should be okay, because obviously no one
is using it.  OTOH, why do we have those separately at all, why do they
not just redirect to the canonical vec_ versions?  Or, can we just get
rid of the vsx_ version completely?


Segher

Re: [PATCH][DOCS] Mention removed ports in GCC 13.

[Gerald Pfeifer]

On Wed, 7 Sep 2022, Martin Liška wrote:
> Thanks for the fix. Btw. have you removed the w3c validation script?

I didn't remove it, but had to deactive automated notifications since the 
w3.org service started to employ some "are you a secure machine?" checks 
that appear to use Javascript or the like, breaking any automated use of 
that service. :-(

So I literally have to click through notification e-mails and manually 
check the result in the browser; hence the delay.

Gerald

Re: [PATCH] Restore XCOFF for DWARF on AIX.

[Martin Liška]

On 9/7/22 15:43, David Edelsohn wrote:
> On Wed, Sep 7, 2022 at 7:45 AM Martin Liška  > wrote:
> 
> Hi.
> 
> The patch restores DWARF support for AIX target where XCOFF file 
> container is used.
> Verified before and after the patch, gcc119 machine (AIX) could not build 
> any run-time library,
> now it can.
> 
> Ready to be installed?
> Thanks,
> Martin
> 
>         PR bootstrap/106855
> 
> gcc/ChangeLog:
> 
>         * collect2.cc (scan_prog_file): Restore if XCOFF_DEBUGGING_INFO.
>         * config/rs6000/rs6000.cc (rs6000_option_override_internal):
>           Restore usage of XCOFF_DEBUGGING_INFO.
>         * config/rs6000/xcoff.h (XCOFF_DEBUGGING_INFO): Restore.
>         * dwarf2asm.cc (XCOFF_DEBUGGING_INFO): Restore support for
>           XCOFF_DEBUGGING_INFO.
>         (dw2_asm_output_nstring): Likewise.
>         (USE_LINKONCE_INDIRECT): Likewise.
>         * dwarf2out.cc (XCOFF_DEBUGGING_INFO): Likewise.
>         (HAVE_XCOFF_DWARF_EXTRAS): Likewise.
>         (output_fde): Likewise.
>         (output_call_frame_info): Likewise.
>         (have_macinfo): Likewise.
>         (add_AT_loc_list): Likewise.
>         (add_AT_view_list): Likewise.
>         (output_compilation_unit_header): Likewise.
>         (output_pubnames): Likewise.
>         (output_aranges): Likewise.
>         (output_line_info): Likewise.
>         (output_macinfo): Likewise.
>         (dwarf2out_finish): Likewise.
>         (dwarf2out_early_finish): Likewise.
> 
> 
> Hi, Martin
> 
> Thanks for the quick patch to fix this.  This restores bootstrap, but does 
> not completely restore functionality.  This patch did not restore the 
> gcc/configure test for AIX assembler XCOFF feature support that defines 
> HAVE_XCOFF_DWARF_EXTRAS.  That part of the removal patch also needs to be 
> reverted.

Ohh! Sorry about that, should be restored by the following patch.

Ready for master?
Thanks,
Martin

> 
> Thanks, David
>  
From d5f346c60157c4d2461ad9a77a47c9c5feebfaf2 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Wed, 7 Sep 2022 16:33:59 +0200
Subject: [PATCH] Restore detection of HAVE_XCOFF_DWARF_EXTRAS

gcc/ChangeLog:

	* configure.ac: Restore detection of  HAVE_XCOFF_DWARF_EXTRAS.
	* config/rs6000/rs6000.cc (HAVE_XCOFF_DWARF_EXTRAS): Reset it.
	* configure: Regenerate.
	* config.in: Regenerate.
---
 gcc/config.in   |  7 +++
 gcc/config/rs6000/rs6000.cc |  5 +
 gcc/configure   | 35 +++
 gcc/configure.ac|  9 +
 4 files changed, 56 insertions(+)

diff --git a/gcc/config.in b/gcc/config.in
index 9c53319b544..6ac17be189e 100644
--- a/gcc/config.in
+++ b/gcc/config.in
@@ -2099,6 +2099,13 @@
 #endif
 
 
+/* Define if your assembler supports AIX debug frame section label reference.
+   */
+#ifndef USED_FOR_TARGET
+#undef HAVE_XCOFF_DWARF_EXTRAS
+#endif
+
+
 /* Define if you have a working  header file. */
 #ifndef USED_FOR_TARGET
 #undef HAVE_ZSTD_H
diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index 7623d69a8c0..a656cb32a47 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -20946,6 +20946,11 @@ rs6000_elf_file_end (void)
 
 #if TARGET_XCOFF
 
+#ifndef HAVE_XCOFF_DWARF_EXTRAS
+#define HAVE_XCOFF_DWARF_EXTRAS 0
+#endif
+
+
 /* Names of bss and data sections.  These should be unique names for each
compilation unit.  */
 
diff --git a/gcc/configure b/gcc/configure
index 39f7ed129a4..817d765568e 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -28142,6 +28142,41 @@ if test $gcc_cv_as_aix_ref = yes; then
 
 $as_echo "#define HAVE_AS_REF 1" >>confdefs.h
 
+fi
+
+
+	{ $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for AIX DWARF location lists section support" >&5
+$as_echo_n "checking assembler for AIX DWARF location lists section support... " >&6; }
+if ${gcc_cv_as_aix_dwloc+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  gcc_cv_as_aix_dwloc=no
+  if test x$gcc_cv_as != x; then
+$as_echo '	.dwsect 0xA
+	Lframe..0:
+		.vbyte 4,Lframe..0
+	  ' > conftest.s
+if { ac_try='$gcc_cv_as $gcc_cv_as_flags  -o conftest.o conftest.s >&5'
+  { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+  test $ac_status = 0; }; }
+then
+	gcc_cv_as_aix_dwloc=yes
+else
+  echo "configure: failed program was" >&5
+  cat conftest.s >&5
+fi
+rm -f conftest.o conftest.s
+  fi
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $gcc_cv_as_aix_dwloc" >&5
+$as_echo "$gcc_cv_as_aix_dwloc" >&6; }
+if test $gcc_cv_as_aix_dwloc = yes; then
+
+$as_echo "#define HAVE_XCOFF_DWARF_EXTRAS 1" >>confdefs.h
+
 fi
 
 	;;
diff --git a/gcc/configure.ac b/gcc/configure.ac
index 50bb61c1b61..59f205a1781 100644
--- a/gcc/configur

[RFC] postreload cse'ing vector constants

[Robin Dapp via Gcc-patches]

Hi,

I recently looked into a sequence like

 vzero %v0
 vlr   %v2, %v0
 vlr   %v3, %v0.

Ideally we would like to use vzero for all of these sets in order to not
create dependencies.

For some instances of this problem I found the offending snippet to be
the postreload cse pass. If there is a non hard reg whose value is
equivalent to an existing hard reg, it will replace the non hard reg.
The costs are only compared if the respective operand is a CONST_INT_P,
otherwise we always replace.

The comment before says:
   /* See if REGNO fits this alternative, and set it up as the


  replacement register if we don't have one for this


  alternative yet and the operand being replaced is not


  a cheap CONST_INT.  */

Now, in my case we have a CONST_VECTOR consisting of CONST_INTS (zeros).
 This is obviously no CONST_INT therefore the substitution takes place
resulting in a "vlr" instead of a "vzero".
Would it not make sense to always compare costs here? Some backends have
instructions for loading vector constants and there could also be
backends able to load floating point constants directly.

For my snippet getting rid of the CONST_INT check suffices because the
costs are similar and no replacement happens.  Was this originally a
shortcut for performance reasons?  I thought we were not checking that
many alternatives and only locally at this point anymore.

Any comments or ideas?

Regards
 Robin

--

diff --git a/gcc/postreload.cc b/gcc/postreload.cc
index 41f61d326482..934439733d52 100644
--- a/gcc/postreload.cc
+++ b/gcc/postreload.cc
@@ -558,13 +558,12 @@ reload_cse_simplify_operands (rtx_insn *insn, rtx
testreg)
  if (op_alt_regno[i][j] == -1
  && TEST_BIT (preferred, j)
  && reg_fits_class_p (testreg, rclass, 0, mode)
- && (!CONST_INT_P (recog_data.operand[i])
- || (set_src_cost (recog_data.operand[i], mode,
-   optimize_bb_for_speed_p
-(BLOCK_FOR_INSN (insn)))
- > set_src_cost (testreg, mode,
- optimize_bb_for_speed_p
-  (BLOCK_FOR_INSN (insn))
+ && (set_src_cost (recog_data.operand[i], mode,
+   optimize_bb_for_speed_p
+(BLOCK_FOR_INSN (insn)))
+ > set_src_cost (testreg, mode,
+ optimize_bb_for_speed_p
+  (BLOCK_FOR_INSN (insn)
{
  alternative_nregs[j]++;
  op_alt_regno[i][j] = regno;

Re: [PATCH v3 1/2] xtensa: Eliminate unused stack frame allocation/freeing

[Max Filippov via Gcc-patches]

Hi Suwa-san,

On Wed, Sep 7, 2022 at 2:08 AM Takayuki 'January June' Suwa
 wrote:
>
> Changes from v2:
>   (xtensa_expand_prologue): Changed to check conditions for suppressing emit 
> insns in advance, instead of tracking emitted and later replacing them with 
> NOPs if they are found to be unnecessary.
>
> ---
>
> In the example below, 'x' is once placed on the stack frame and then read
> into registers as the argument value of bar():
>
> /* example */
> struct foo {
>   int a, b;
> };
> extern struct foo bar(struct foo);
> struct foo test(void) {
>   struct foo x = { 0, 1 };
>   return bar(x);
> }
>
> Thanks to the dead store elimination, the initialization of 'x' turns into
> merely loading the immediates to registers, but corresponding stack frame
> growth is not rolled back.  As a result:
>
> ;; prereq: the CALL0 ABI
> ;; before
> test:
> addisp, sp, -16 // unused stack frame allocation/freeing
> movi.n  a2, 0
> movi.n  a3, 1
> addisp, sp, 16  // because no instructions that refer to
> j.l bar, a9 // the stack pointer between the two
>
> This patch eliminates such unused stack frame allocation/freeing:
>
> ;; after
> test:
> movi.n  a2, 0
> movi.n  a3, 1
> j.l bar, a9
>
> gcc/ChangeLog:
>
> * config/xtensa/xtensa.cc (machine_function): New boolean member as
> a flag that controls whether to emit the insns for stack pointer
> adjustment inside of the pro/epilogue.
> (xtensa_emit_adjust_stack_ptr): New function to share the common
> codes and to emit insns if not inhibited.
> (xtensa_expand_epilogue): Change to use the function mentioned
> above when using the CALL0 ABI.
> (xtensa_expand_prologue): Ditto.
> And also change to set the inhibit flag used by
> xtensa_emit_adjust_stack_ptr() to true if the stack pointer is only
> used for its own adjustment.
> ---
>  gcc/config/xtensa/xtensa.cc | 162 +---
>  1 file changed, 78 insertions(+), 84 deletions(-)

There's still a minor issue here: this change introduces a new regression
in the following test:
g++.dg/opt/pr100469.C

AFAICS it generates different code with and without the '-g' option: no
stack modification without -g, but adjustment in prologue and epilogue
with -g.

-- 
Thanks.
-- Max

Re: [RFC] postreload cse'ing vector constants

[Jeff Law via Gcc-patches]

On 9/7/2022 8:40 AM, Robin Dapp via Gcc-patches wrote:

Hi,

I recently looked into a sequence like

  vzero %v0
  vlr   %v2, %v0
  vlr   %v3, %v0.

Ideally we would like to use vzero for all of these sets in order to not
create dependencies.

For some instances of this problem I found the offending snippet to be
the postreload cse pass. If there is a non hard reg whose value is
equivalent to an existing hard reg, it will replace the non hard reg.
The costs are only compared if the respective operand is a CONST_INT_P,
otherwise we always replace.

The comment before says:
/* See if REGNO fits this alternative, and set it up as the


   replacement register if we don't have one for this


   alternative yet and the operand being replaced is not


   a cheap CONST_INT.  */

Now, in my case we have a CONST_VECTOR consisting of CONST_INTS (zeros).
  This is obviously no CONST_INT therefore the substitution takes place
resulting in a "vlr" instead of a "vzero".
Would it not make sense to always compare costs here? Some backends have
instructions for loading vector constants and there could also be
backends able to load floating point constants directly.

For my snippet getting rid of the CONST_INT check suffices because the
costs are similar and no replacement happens.  Was this originally a
shortcut for performance reasons?  I thought we were not checking that
many alternatives and only locally at this point anymore.

Any comments or ideas?
It looks sensible to me.  ISTM this should be driven by costs, not by 
any particular rtx codes.  Your patch takes things in the right direction.


Did you did any archeology into this code to see if there was any 
history that might shed light on why it doesn't just using the costing 
models?


jeff

Re: [PATCH] c++: Fix type completeness checks for type traits [PR106838]

[Jason Merrill via Gcc-patches]

On 9/7/22 08:18, Jonathan Wakely wrote:

Tested powerpc64le-linux. OK for trunk?

-- >8 --

The check_trait_type function is used for a number of different type
traits that have different requirements on their arguments. For example,
__is_constructible allows arrays of unknown bound even if the array
element is an incomplete type, but __is_aggregate does not, it always
requires the array element type to be complete. Other traits have
different requirements again, e.g. __is_empty allows incomplete unions,
and arrays (of known or unknown bound) of incomplete types.

This alters the check_trait_type function to take an additional KIND
parameter which indicates which set of type trait requirements to check.

The type_has_virtual_destructor change is needed to avoid an ICE.
Previously it could never be called for incomplete union types as they
were (incorrectly) rejected by check_trait_type.

This change causes some additional diagnostics in some libstdc++ tests,
where the front end was not previously complaining about invalid types
that the library assertions diagnosed. We should consider removing the
library assertions from traits where the front end implements the
correct checks now.

PR c++/106838

gcc/cp/ChangeLog:

* class.cc (type_has_virtual_destructor): Return false for
union types.
* semantics.cc (check_trait_type): Add KIND parameter to support
different sets of requirements.
(finish_trait_expr): Pass KIND argument for relevant traits.

gcc/ChangeLog:

* doc/extend.texi (Type Traits): Fix requirements. Document
__is_aggregate and __is_final.

gcc/testsuite/ChangeLog:

* g++.dg/ext/array4.C: Fix invalid use of __is_constructible.
* g++.dg/ext/unary_trait_incomplete.C: Fix tests for traits with
different requirements.

libstdc++-v3/ChangeLog:

* testsuite/20_util/is_complete_or_unbounded/memoization_neg.cc:
Prune additional errors from front-end.
* testsuite/20_util/is_move_constructible/incomplete_neg.cc:
Likewise.
* testsuite/20_util/is_nothrow_swappable/incomplete_neg.cc:
Likewise.
* testsuite/20_util/is_nothrow_swappable_with/incomplete_neg.cc:
Likewise.
* testsuite/20_util/is_swappable_with/incomplete_neg.cc:
Likewise.
---
  gcc/cp/class.cc   |   2 +-
  gcc/cp/semantics.cc   |  54 +++--
  gcc/doc/extend.texi   |  31 --
  gcc/testsuite/g++.dg/ext/array4.C |   3 +-
  .../g++.dg/ext/unary_trait_incomplete.C   | 105 ++
  .../memoization_neg.cc|   2 +
  .../is_move_constructible/incomplete_neg.cc   |   1 +
  .../is_nothrow_swappable/incomplete_neg.cc|   1 +
  .../incomplete_neg.cc |   1 +
  .../is_swappable_with/incomplete_neg.cc   |   1 +
  10 files changed, 151 insertions(+), 50 deletions(-)

diff --git a/gcc/cp/class.cc b/gcc/cp/class.cc
index a12d3673b96..b84f4227e7e 100644
--- a/gcc/cp/class.cc
+++ b/gcc/cp/class.cc
@@ -5620,7 +5620,7 @@ type_has_virtual_destructor (tree type)
  {
tree dtor;
  
-  if (!CLASS_TYPE_P (type))

+  if (!NON_UNION_CLASS_TYPE_P (type))
  return false;
  
gcc_assert (COMPLETE_TYPE_P (type));

diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 3d58d67ec11..ee361ae22cb 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -12028,11 +12028,23 @@ trait_expr_value (cp_trait_kind kind, tree type1, 
tree type2)
  }
  }
  
-/* If TYPE is an array of unknown bound, or (possibly cv-qualified)

-   void, or a complete type, returns true, otherwise false.  */
+/* Returns true if TYPE meets the requirements for the specified KIND,
+   false otherwise.
+
+   When KIND == 1, TYPE must be an array of unknown bound,
+   or (possibly cv-qualified) void, or a complete type.
+
+   When KIND == 2, TYPE must be a complete type, or array of complete type,
+   or (possibly cv-qualified) void.
+
+   When KIND == 3:
+   If TYPE is a non-union class type, it must be complete.
+
+   When KIND == 4:
+   If TYPE is a class type, it must be complete.  */
  
  static bool

-check_trait_type (tree type)
+check_trait_type (tree type, int kind = 1)
  {
if (type == NULL_TREE)
  return true;
@@ -12041,8 +12053,14 @@ check_trait_type (tree type)
  return (check_trait_type (TREE_VALUE (type))
&& check_trait_type (TREE_CHAIN (type)));
  
-  if (TREE_CODE (type) == ARRAY_TYPE && !TYPE_DOMAIN (type))

-return true;
+  if (kind == 1 && TREE_CODE (type) == ARRAY_TYPE && !TYPE_DOMAIN (type))
+return true; // Array of unknown bound. Don't care about completeness.
+
+  if (kind == 3 && !NON_UNION_CLASS_TYPE_P (type))
+return true; // Not a non-union class type. Don't care about completeness.
+
+  if (kind == 4 && TREE_CODE (type) == ARRAY_TYPE)
+return true; // Not a class type. Don't care about completeness.
 

Re: [PATCH v2] coroutines: Ensure there's a top level bind when rewriting [PR106188]

[Jason Merrill via Gcc-patches]

On 9/4/22 15:04, Arsen Arsenović wrote:

In the edge case of a coroutine not containing any locals, the ifcd/swch
temporaries would get added to the coroutine frame, corrupting its
layout. To prevent this, we can make sure there is always a BIND_EXPR at
the top of the function body, and thus, always a place for our new
temporaries to go without interfering with the coroutine frame.

PR c++/106188 - [coroutines] Incorrect frame layout after transforming 
conditional statement without top-level bind expression

PR c++/106713 - [11/12/13 Regression] Coroutine regression in GCC 11.3.0: if 
(co_await ...) crashes with a jump to ud2 since r12-3529-g70ee703c479081ac

gcc/cp/ChangeLog:
PR c++/106188
PR c++/106713
* coroutines.cc (coro_rewrite_function_body): Ensure we have a
  BIND_EXPR wrapping the function body.

gcc/testsuite/ChangeLog:

* g++.dg/coroutines/pr106188.C: New test.

Signed-off-by: Arsen Arsenović 


Applied with some minor tweaks, described below.

Thanks!

Jason


---
  gcc/cp/coroutines.cc   | 10 +++
  gcc/testsuite/g++.dg/coroutines/pr106188.C | 35 ++
  2 files changed, 45 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/coroutines/pr106188.C

Hi Iain,


I can see that adding the bind expression in this way seems to avoid
adding one unnecessarily***, however it makes a complex part of the
code even more complex (and conflates two jobs).

It seems to me that it would be better to add the bind expression
consistently and to do it in the part of the code that deals with
outlining the original functiion - so …

… in coro_rewrite_function_body() we check to see if the outlined
body has a bind expression and connect up the BLOCKs if so (otherwise
debug will not work).

How about adding the bind expression consistently by appending an else
clause to that check (coroutines.cc:4079..40097) ?

Since the function has no local variables, there is no BLOCK tree at
this point (so there is no work to do in connecting them up).

I’d much prefer to keep the work of restructuring the function
separate from the work of analysing the await expressions (if
possible).

WDYT?  Iain


I actually quite like the idea, it's a lot more elegant! I'm not quite
confident enough to tell whether this will have any adverse effects (as
I am a quite fresh contributor to GCC), but I implemented it anyway, ran
the tests, and they come up green in comparison to the tree I based this
patch on.

The reason I implemented maybe_add_bind initially is to make a minimally
intrusive change, but I'm not sure that's worth it with the extra
potential for confusion (and for error, as this is something that'd have
to be handled by every caller to add_var_to_bind).

Thank you for the swift response!
- Arsen

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index edb3b706ddc..4e7f1c4a08c 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -4095,6 +4095,16 @@ coro_rewrite_function_body (location_t fn_start, tree 
fnbody, tree orig,
BLOCK_SUPERCONTEXT (replace_blk) = top_block;
BLOCK_SUBBLOCKS (top_block) = replace_blk;
  }
+  else
+{
+  /* We are missing a top level BIND_EXPR. We need one to ensure that we
+   * don't shuffle around the coroutine frame and corrupt it.
+   */


We put */ at the end of the last line, and don't add more * to line 
beginnings.



+  tree bind_wrap = build3_loc (fn_start, BIND_EXPR, void_type_node,
+  NULL, NULL, NULL);
+  BIND_EXPR_BODY (bind_wrap) = fnbody;
+  fnbody = bind_wrap;
+}
  
/* Wrap the function body in a try {} catch (...) {} block, if exceptions

   are enabled.  */
diff --git a/gcc/testsuite/g++.dg/coroutines/pr106188.C 
b/gcc/testsuite/g++.dg/coroutines/pr106188.C
new file mode 100644
index 000..1de3d4cceca
--- /dev/null
+++ b/gcc/testsuite/g++.dg/coroutines/pr106188.C
@@ -0,0 +1,35 @@
+//  { dg-additional-options "-std=c++20 -w" }
+//  { dg-do run }


I changed this to { target c++20 } so the test is also run in C++23 
mode, and dropped the first line.



+// test case from pr106188, w/o workaround
+#include 
+
+struct task {
+  struct promise_type {
+task get_return_object() { return task{}; }
+void return_void() {}
+void unhandled_exception() {}
+auto initial_suspend() noexcept { return std::suspend_never{}; }
+auto final_suspend() noexcept { return std::suspend_never{}; }
+  };
+};
+
+struct suspend_and_resume {
+  bool await_ready() const { return false; }
+  void await_suspend(std::coroutine_handle<> h) { h.resume(); }
+  void await_resume() {}
+};
+
+task f() {
+  if (co_await suspend_and_resume{}, false) {}
+}
+
+task g() {
+  switch (co_await suspend_and_resume{}, 0) {
+default: break;
+  }
+}
+
+int main() {
+  f();
+  g();
+}

Re: [PATCH v2] coroutines: Ensure there's a top level bind when rewriting [PR106188]

[Arsen Arsenović via Gcc-patches]

Hi,

On Wednesday, 7 September 2022 17:13:03 CEST Jason Merrill wrote:
> Applied with some minor tweaks, described below.
> 
> Thanks!
Got it, and noted the changes and rationale you provided

Thank you!
-- 
Arsen Arsenović


signature.asc
Description: This is a digitally signed message part.

Re: [RFC] postreload cse'ing vector constants

[Robin Dapp via Gcc-patches]

> Did you did any archeology into this code to see if there was any 
> history that might shed light on why it doesn't just using the costing 
> models?
This one was buried under some dust :)

commit 0254c56158b0533600ba9036258c11d377d46adf
Author: John Carr 
Date:   Wed Jun 10 06:00:50 1998 +

reload1.c (reload_cse_simplify_operands): Do not call gen_rtx_REG
for each alternative.

Wed Jun 10 08:56:27 1998  John Carr  
* reload1.c (reload_cse_simplify_operands): Do not call
gen_rtx_REG
for each alternative.  Do not replace a CONST_INT with a REG
unless
the reg is cheaper.

From-SVN: r20402

Back then we didn't have vectors I suppose but apart from that I don't
see a compelling reason not to unconditionally check costs from this.
It seems like we did even more unconditional replacing before it,
including CONST_INTs.

Regards
 Robin

Re: [RFC] postreload cse'ing vector constants

[Jeff Law via Gcc-patches]

On 9/7/2022 9:33 AM, Robin Dapp wrote:

Did you did any archeology into this code to see if there was any
history that might shed light on why it doesn't just using the costing
models?

This one was buried under some dust :)

commit 0254c56158b0533600ba9036258c11d377d46adf
Author: John Carr 
Date:   Wed Jun 10 06:00:50 1998 +

 reload1.c (reload_cse_simplify_operands): Do not call gen_rtx_REG
for each alternative.

 Wed Jun 10 08:56:27 1998  John Carr  
 * reload1.c (reload_cse_simplify_operands): Do not call
gen_rtx_REG
 for each alternative.  Do not replace a CONST_INT with a REG
unless
 the reg is cheaper.

 From-SVN: r20402

Back then we didn't have vectors I suppose but apart from that I don't
see a compelling reason not to unconditionally check costs from this.
It seems like we did even more unconditional replacing before it,
including CONST_INTs.

Which is this from the mail archives:

https://gcc.gnu.org/pipermail/gcc-patches/1998-June/000308.html

I would tend to agree that for equal cost that the constant would be 
preferred since that should be better from a scheduling/dependency 
standpoint.   So it seems to me we can drive this purely from a costing 
standpoint.


jef

Re: [PATCH] Restore XCOFF for DWARF on AIX.

[Richard Biener via Gcc-patches]

> Am 07.09.2022 um 16:37 schrieb Martin Liška :
> 
> On 9/7/22 15:43, David Edelsohn wrote:
>> On Wed, Sep 7, 2022 at 7:45 AM Martin Liška > > wrote:
>> 
>>Hi.
>> 
>>The patch restores DWARF support for AIX target where XCOFF file 
>> container is used.
>>Verified before and after the patch, gcc119 machine (AIX) could not build 
>> any run-time library,
>>now it can.
>> 
>>Ready to be installed?
>>Thanks,
>>Martin
>> 
>>PR bootstrap/106855
>> 
>>gcc/ChangeLog:
>> 
>>* collect2.cc (scan_prog_file): Restore if XCOFF_DEBUGGING_INFO.
>>* config/rs6000/rs6000.cc (rs6000_option_override_internal):
>>  Restore usage of XCOFF_DEBUGGING_INFO.
>>* config/rs6000/xcoff.h (XCOFF_DEBUGGING_INFO): Restore.
>>* dwarf2asm.cc (XCOFF_DEBUGGING_INFO): Restore support for
>>  XCOFF_DEBUGGING_INFO.
>>(dw2_asm_output_nstring): Likewise.
>>(USE_LINKONCE_INDIRECT): Likewise.
>>* dwarf2out.cc (XCOFF_DEBUGGING_INFO): Likewise.
>>(HAVE_XCOFF_DWARF_EXTRAS): Likewise.
>>(output_fde): Likewise.
>>(output_call_frame_info): Likewise.
>>(have_macinfo): Likewise.
>>(add_AT_loc_list): Likewise.
>>(add_AT_view_list): Likewise.
>>(output_compilation_unit_header): Likewise.
>>(output_pubnames): Likewise.
>>(output_aranges): Likewise.
>>(output_line_info): Likewise.
>>(output_macinfo): Likewise.
>>(dwarf2out_finish): Likewise.
>>(dwarf2out_early_finish): Likewise.
>> 
>> 
>> Hi, Martin
>> 
>> Thanks for the quick patch to fix this.  This restores bootstrap, but does 
>> not completely restore functionality.  This patch did not restore the 
>> gcc/configure test for AIX assembler XCOFF feature support that defines 
>> HAVE_XCOFF_DWARF_EXTRAS.  That part of the removal patch also needs to be 
>> reverted.
> 
> Ohh! Sorry about that, should be restored by the following patch.
> 
> Ready for master?

Ok.

Richard 


> Thanks,
> Martin
> 
>> 
>> Thanks, David
>>  
> <0001-Restore-detection-of-HAVE_XCOFF_DWARF_EXTRAS.patch>

[PATCH v2] analyzer: support for symbolic values in the out-of-bounds checker [PR106625]

[Tim Lange]

Hi Dave,

while re-reading that patch, I noticed a small mistake. I accidently did
not move the op == PLUS_EXPR or MULT_EXPR guard in symbolic_greater_than
when implementing the "eliminate operands on both sides" feature, which
lead to the old patch also eliminating operands on both sides if the
operator decreases the value, which is obviously wrong.

I moved the guard outside and added test coverage for this in
symbolic-gt-1.c. The patch passed the regrtests with the fix included.

I assume it is still okay for trunk?

- Tim

This patch adds support for reasoning about the inequality of two symbolic
values in the special case specifically suited for reasoning about
out-of-bounds past the end of the buffer. With this patch, the analyzer
catches off-by-one errors and more even when the offset and capacity is
symbolic.

Regrtested on Linux x86_64 and tested on coreutils, curl, httpd and
openssh as usual.

2022-09-07  Tim Lange  

gcc/analyzer/ChangeLog:

PR analyzer/106625
* analyzer.h (region_offset): Eliminate m_is_symbolic member.
* region-model-impl-calls.cc (region_model::impl_call_realloc):
Refine implementation to be more precise.
* region-model.cc (class symbolic_past_the_end):
Abstract diagnostic class to complain about accesses past the end
with symbolic values.
(class symbolic_buffer_overflow):
Concrete diagnostic class to complain about buffer overflows with
symbolic values.
(class symbolic_buffer_overread):
Concrete diagnostic class to complain about buffer overreads with
symbolic values.
(region_model::check_symbolic_bounds): New function.
(maybe_get_integer_cst_tree): New helper function.
(region_model::check_region_bounds):
Add call to check_symbolic_bounds if offset is not concrete.
(region_model::eval_condition_without_cm):
Add support for EQ_EXPR and GT_EXPR with binaryop_svalues. 
(is_positive_svalue): New hleper function.
(region_model::symbolic_greater_than): 
(region_model::structural_equality): New function to compare
whether two svalues are structured the same, i.e. evaluate to
the same value.
(test_struct): Reflect changes to region::calc_offset.
(test_var): Likewise.
(test_array_2): Likewise and add selftest with symbolic i.
* region-model.h (class region_model): Add check_symbolic_bounds,
symbolic_greater_than and structural_equality.
* region.cc (region::get_offset):
Reflect changes to region::calc_offset.
(region::calc_offset):
Compute the symbolic offset if the offset is not concrete.
(region::get_relative_symbolic_offset): New function to return the
symbolic offset in bytes relative to its parent.
(field_region::get_relative_symbolic_offset): Likewise.
(element_region::get_relative_symbolic_offset): Likewise.
(offset_region::get_relative_symbolic_offset): Likewise.
(bit_range_region::get_relative_symbolic_offset): Likewise.
* region.h: Add get_relative_symbolic_offset.
* store.cc (binding_key::make):
Reflect changes to region::calc_offset.
(binding_map::apply_ctor_val_to_range): Likewise.
(binding_map::apply_ctor_pair_to_child_region): Likewise.
(binding_cluster::bind_compound_sval): Likewise.
(binding_cluster::get_any_binding): Likewise.
(binding_cluster::maybe_get_compound_binding): Likewise.

gcc/ChangeLog:

PR analyzer/106625
* doc/invoke.texi:
State that the checker also reasons about symbolic values.

gcc/testsuite/ChangeLog:

PR analyzer/106625
* gcc.dg/analyzer/data-model-1.c: Change expected result.
* gcc.dg/analyzer/out-of-bounds-5.c: New test.
* gcc.dg/analyzer/out-of-bounds-realloc-grow.c: New test.
* gcc.dg/analyzer/symbolic-gt-1.c: New test.

---
 gcc/analyzer/analyzer.h   |  23 +-
 gcc/analyzer/region-model-impl-calls.cc   |  39 +-
 gcc/analyzer/region-model.cc  | 469 --
 gcc/analyzer/region-model.h   |   9 +
 gcc/analyzer/region.cc| 131 -
 gcc/analyzer/region.h |  17 +-
 gcc/analyzer/store.cc |  18 +-
 gcc/doc/invoke.texi   |   8 +-
 gcc/testsuite/gcc.dg/analyzer/data-model-1.c  |   3 +-
 .../gcc.dg/analyzer/out-of-bounds-5.c | 156 ++
 .../analyzer/out-of-bounds-realloc-grow.c |  87 
 gcc/testsuite/gcc.dg/analyzer/symbolic-gt-1.c |  76 +++
 12 files changed, 941 insertions(+), 95 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/out-of-bounds-5.c
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/out-of-bounds-realloc-grow.c
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/symbolic-gt-1.c

diff --git a/gcc/analyzer/analyzer.h b/

Re: [PATCH] expand: Convert cst - x into cst xor x.

[Jeff Law via Gcc-patches]

On 9/7/2022 6:45 AM, Richard Biener via Gcc-patches wrote:

On Wed, Sep 7, 2022 at 2:20 PM Robin Dapp  wrote:

The question is really whether xor or sub is "better" statically.  I can't
think of any reasons.  On s390, why does xor end up "better"?

There is an xor with immediate (as opposed to no "subtract from
immediate") which saves an instruction, usually.  On x86, I think the
usual argument for xor is that it's shorter (if flags etc. are not needed).

It's not that I don't want to implement it in the backend, just that I
understood the original PR in a way that it would make sense to have
this conversion available for more targets.  If there are too many
confounding factors that prevent this situation from being statically
costed properly, then sure, not much use in implementing it generally.

Do we have evidence that targets properly cost XOR vs SUB RTXen?
Probably not.  And I have vague memories of some targets not having xor 
with immediate, but which did have more expressive sub instructions (so 
the opposite of the situation on s390).


Checking costs seems like a very sensible thing to do though and if 
targets need adjustment, then we can cope.





It might actually be a reload optimization - when the constant is
available in a register use 'sub', when it needs to be reloaded
use 'xor'?
Perhaps.  The question is finding out of the constant is actually 
available in a register.  We don't do a particularly good job at that.





That said, I wonder if the fallout of changing some SUB to XOR
is bigger than the benefit when we do it early (missed combines, etc.)?

Quite possibly -- though I doubt it matters in practice.

jeff

[committed] Update my entry in MAINTAINERS

[Jeff Law via Gcc-patches]

I'm leaving Tachyum this Friday.  Adjust my maintainers address, but not 
the DCO entry in the MAINTAINERS file.


commit 756ccf97cf976011b3800a055bfb9fc3a2c943c6 (HEAD -> master, 
origin/master, origin/HEAD)

Author: Jeff Law 
Date:   Wed Sep 7 12:32:31 2022 -0400

    Update my email address

    /
    * MAINTAINERS: Update my email address.

diff --git a/MAINTAINERS b/MAINTAINERS
index 5e483e3cbe1..e89eb343528 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -30,7 +30,7 @@ Richard Biener 
 Richard Earnshaw 
 Jakub Jelinek 
 Richard Kenner 
-Jeff Law 
+Jeff Law 
 Michael Meissner 
 Jason Merrill 
 David S. Miller 

Pushed to the trunk,
Jeff

Re: [PATCH] A == 0 ? A : -A same as -A (when A is 0.0)

[Jeff Law via Gcc-patches]

On 8/29/2022 2:44 PM, Aldy Hernandez via Gcc-patches wrote:

The upcoming work for frange triggers a regression in
gcc.dg/tree-ssa/phi-opt-24.c.

For -O2 -fno-signed-zeros, we fail to transform the following into -A:

float f0(float A)
{
   // A == 0? A : -Asame as -A
   if (A == 0)  return A;
   return -A;
}

This is because the abs/negative match.pd pattern here:

/* abs/negative simplifications moved from fold_cond_expr_with_comparison,
Need to handle (A - B) case as fold_cond_expr_with_comparison does.
Need to handle UN* comparisons.
...
...

Sees IL that has the 0.0 propagated.

Instead of:

[local count: 1073741824]:
   if (A_2(D) == 0.0)
 goto ; [34.00%]
   else
 goto ; [66.00%]

[local count: 708669601]:
   _3 = -A_2(D);

[local count: 1073741824]:
   # _1 = PHI 

It now sees:

[local count: 1073741824]:
   # _1 = PHI <0.0(2), _3(3)>

which it leaves untouched, causing the if conditional to survive.

Adding a variant to the pattern that for real_zerop fixes the problem.

I am a match.pd weenie, and am avoiding touching more patterns that
may also benefit from handling real constants.  So please use simple
words if what I'm doing isn't correct ;-).

I did not include a testcase, as it's just phi-opt-24.c which will get
triggered when I commit the frange with endpoints work.

Tested on x86-64 & ppc64le Linux.

OK?

gcc/ChangeLog:

* match.pd ((cmp @0 zerop) real_zerop (negate@1 @0)): Add variant
for real zero.

OK
jeff

Re: [PATCH] arm: Fix constant immediates predicates and constraints for some MVE builtins

[Christophe Lyon via Gcc-patches]

On 9/7/22 15:42, Kyrylo Tkachov wrote:




-Original Message-
From: Christophe Lyon 
Sent: Wednesday, September 7, 2022 2:41 PM
To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] arm: Fix constant immediates predicates and
constraints for some MVE builtins



On 9/7/22 15:34, Kyrylo Tkachov wrote:

Hi Christophe,


-Original Message-
From: Gcc-patches  On Behalf Of Christophe
Lyon via Gcc-patches
Sent: Wednesday, September 7, 2022 2:03 PM
To: gcc-patches@gcc.gnu.org
Subject: [PATCH] arm: Fix constant immediates predicates and constraints

for

some MVE builtins

Several MVE builtins incorrectly use the same predicate/constraint
pair for several modes, which does not match the specification.
This patch uses the appropriate iterator instead.



This looks ok to me.
I presume you've tested this appropriately?


I tested it manually with an offending testcase.

Unfortunately, the existing testcases all use '1' as immediate, so this
does not really check the boundaries. We do plan to improve the existing
tests in a later patch that will more generally improve the MVE tests.


Sure, improving the tests is definitely worth it here.
I meant more in the context of a standard bootstrap and testsuite run.


OK, just ran a bootstrap on arm-linux-gnueabihf, no issue, and 
regression tested on a cross arm-eabi with the default 
RUNTESTFLAGS/target-board, no issue either.


Thanks,

Christophe


Thanks,
Kyrill



Christophe


If so, ok for trunk.
Thanks,
Kyrill


2022-09-06  Christophe Lyon  

gcc/
* config/arm/mve.md (mve_vqshluq_n_s): Use
MVE_pred/MVE_constraint instead of mve_imm_7/Ra.
(mve_vqshluq_m_n_s): Likewise.
(mve_vqrshrnbq_n_): Use
MVE_pred3/MVE_constraint3
instead of mve_imm_8/Rb.
(mve_vqrshrunbq_n_s): Likewise.
(mve_vqrshrntq_n_): Likewise.
(mve_vqrshruntq_n_s): Likewise.
(mve_vrshrnbq_n_): Likewise.
(mve_vrshrntq_n_): Likewise.
(mve_vqrshrnbq_m_n_): Likewise.
(mve_vqrshrntq_m_n_): Likewise.
(mve_vrshrnbq_m_n_): Likewise.
(mve_vrshrntq_m_n_): Likewise.
(mve_vqrshrunbq_m_n_s): Likewise.
(mve_vsriq_n_): Likewise.
---
   gcc/config/arm/mve.md | 30 +++---
   1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md
index c4dec01baac..714178609f7 100644
--- a/gcc/config/arm/mve.md
+++ b/gcc/config/arm/mve.md
@@ -1624,7 +1624,7 @@ (define_insn "mve_vqshluq_n_s"
 [
  (set (match_operand:MVE_2 0 "s_register_operand" "=w")
(unspec:MVE_2 [(match_operand:MVE_2 1 "s_register_operand"
"w")
-  (match_operand:SI 2 "mve_imm_7" "Ra")]
+  (match_operand:SI 2 ""
"")]
 VQSHLUQ_N_S))
 ]
 "TARGET_HAVE_MVE"
@@ -2615,7 +2615,7 @@ (define_insn

"mve_vqrshrnbq_n_"

  (set (match_operand: 0 "s_register_operand" "=w")
(unspec: [(match_operand: 1
"s_register_operand" "0")
 (match_operand:MVE_5 2
"s_register_operand" "w")
-(match_operand:SI 3 "mve_imm_8" "Rb")]
+(match_operand:SI 3 ""
"")]
 VQRSHRNBQ_N))
 ]
 "TARGET_HAVE_MVE"
@@ -2630,7 +2630,7 @@ (define_insn "mve_vqrshrunbq_n_s"
  (set (match_operand: 0 "s_register_operand" "=w")
(unspec: [(match_operand: 1
"s_register_operand" "0")
 (match_operand:MVE_5 2
"s_register_operand" "w")
-(match_operand:SI 3 "mve_imm_8" "Rb")]
+(match_operand:SI 3 ""
"")]
 VQRSHRUNBQ_N_S))
 ]
 "TARGET_HAVE_MVE"
@@ -3570,7 +3570,7 @@ (define_insn "mve_vsriq_n_"
  (set (match_operand:MVE_2 0 "s_register_operand" "=w")
(unspec:MVE_2 [(match_operand:MVE_2 1 "s_register_operand"
"0")
   (match_operand:MVE_2 2 "s_register_operand" "w")
-  (match_operand:SI 3 "mve_imm_selective_upto_8"
"Rg")]
+  (match_operand:SI 3 ""
"")]
 VSRIQ_N))
 ]
 "TARGET_HAVE_MVE"
@@ -4473,7 +4473,7 @@ (define_insn

"mve_vqrshrntq_n_"

  (set (match_operand: 0 "s_register_operand" "=w")
(unspec: [(match_operand: 1
"s_register_operand" "0")
   (match_operand:MVE_5 2 "s_register_operand" "w")
-  (match_operand:SI 3 "mve_imm_8" "Rb")]
+  (match_operand:SI 3 ""
"")]
 VQRSHRNTQ_N))
 ]
 "TARGET_HAVE_MVE"
@@ -4489,7 +4489,7 @@ (define_insn "mve_vqrshruntq_n_s"
  (set (match_operand: 0 "s_register_operand" "=w")
(unspec: [(match_operand: 1
"s_register_operand" "0")
   (match_operand:MVE_5 2 "s_register_operand" "w")
-  (match_operand:SI 3 "mve_imm_8" "Rb")]
+  (match_operand:SI 3 ""
"")]
 VQRSHRUNTQ_N_S))
 ]
 "TARGET_HAVE_MVE"
@@ -47

Re: [PATCH] Ignore debug insns with CONCAT and CONCATN for insn scheduling

[Jeff Law via Gcc-patches]

On 9/2/2022 8:36 AM, H.J. Lu via Gcc-patches wrote:

CONCAT and CONCATN never appear in the insn chain.  They are only used
in debug insn.  Ignore debug insns with CONCAT and CONCATN for insn
scheduling to avoid different insn orders with and without debug insn.

gcc/

PR rtl-optimization/106746
* sched-deps.cc (sched_analyze_2): Ignore debug insns with CONCAT
and CONCATN.
Shouldn't we be ignoring everything in a debug insn?   I don't see why 
CONCAT/CONCATN are special here.


jeff

[PATCH] Use mallinfo2 with glibc >= 2.33

[François Dumont via Gcc-patches]

libstdc++: Use glibc >= 2.33 mallinfo2 function

mallinfo started to be deprecated which makes performance tests failed 
to build, just

adopt mallinfo2.

libstdcxx-v3/ChangeLog:

    * testsuite/util/testsuite_performance.h (__mallinfo): New, our 
own mallinfo
    struct with just what we need. When using glibc >= 2.33 use 
mallinfo2 to

    populate it.

Tested under Linux x86_64,

Ok to commit ?

François
diff --git a/libstdc++-v3/testsuite/util/testsuite_performance.h b/libstdc++-v3/testsuite/util/testsuite_performance.h
index 2e05bef8460..dc002b8c390 100644
--- a/libstdc++-v3/testsuite/util/testsuite_performance.h
+++ b/libstdc++-v3/testsuite/util/testsuite_performance.h
@@ -35,37 +35,49 @@
 #include 
 #include 
 
-#if defined (__linux__) || defined (__GLIBC__)
-#include 
-#elif defined (__FreeBSD__)
 extern "C"
 {
-  struct mallinfo
+  struct __mallinfo
   {
-int uordblks;
-int hblkhd;
+size_t uordblks;
+size_t hblkhd;
   };
+}
 
-  struct mallinfo
-  mallinfo(void)
+#if defined (__linux__) || defined (__GLIBC__)
+#include 
+extern "C"
+{
+  struct __mallinfo
+  __mallinfo(void)
+  {
+#if __GLIBC__ >= 2 && __GLIBC_MINOR__ >= 33
+struct mallinfo2 mi = mallinfo2();
+struct __mallinfo m = { mi.uordblks, mi.hblkhd };
+#else
+struct mallinfo mi = mallinfo();
+struct __mallinfo m = { mi.uordblks, mi.hblkhd };
+#endif
+return m;
+  }
+}
+#elif defined (__FreeBSD__)
+extern "C"
+{
+  struct __mallinfo
+  __mallinfo(void)
   {
-struct mallinfo m = { (((std::size_t) sbrk (0) + 1023) / 1024), 0 };
+struct __mallinfo m = { (((std::size_t) sbrk (0) + 1023) / 1024), 0 };
 return m;
   }
 }
 #elif !defined (__hpux__)
 extern "C"
 {
-  struct mallinfo
-  {
-int uordblks;
-int hblkhd;
-  };
-
-  struct mallinfo empty = { 0, 0 };
+  struct __mallinfo empty = { 0, 0 };
 
-  struct mallinfo
-  mallinfo(void)
+  struct __mallinfo
+  __mallinfo(void)
   { return empty; }
 }
 #endif
@@ -146,8 +158,8 @@ namespace __gnu_test
 int who;
 rusage	rusage_begin;
 rusage	rusage_end;
-struct mallinfo  	allocation_begin;
-struct mallinfo  	allocation_end;
+struct __mallinfo  	allocation_begin;
+struct __mallinfo  	allocation_end;
 
   public:
 resource_counter(int i = RUSAGE_SELF) : who(i)
@@ -168,7 +180,7 @@ namespace __gnu_test
   if (getrusage(who, &rusage_begin) != 0 )
 	memset(&rusage_begin, 0, sizeof(rusage_begin));
   void* p __attribute__((unused)) = malloc(0); // Needed for some implementations.
-  allocation_begin = mallinfo();
+  allocation_begin = __mallinfo();
 }
 
 void
@@ -176,7 +188,7 @@ namespace __gnu_test
 {
   if (getrusage(who, &rusage_end) != 0 )
 	memset(&rusage_end, 0, sizeof(rusage_end));
-  allocation_end = mallinfo();
+  allocation_end = __mallinfo();
 }
 
 int

Re: [PATCH] Use mallinfo2 with glibc >= 2.33

[Jonathan Wakely via Gcc-patches]

On Wed, 7 Sept 2022 at 18:03, François Dumont via Libstdc++
 wrote:
>
> libstdc++: Use glibc >= 2.33 mallinfo2 function
>
> mallinfo started to be deprecated which makes performance tests failed
> to build, just
> adopt mallinfo2.
>
> libstdcxx-v3/ChangeLog:
>
>  * testsuite/util/testsuite_performance.h (__mallinfo): New, our
> own mallinfo

There's no reason to use a reserved name here, this isn't a header
that users include.

I would call the struct MallocInfo and the function malloc_info().
Even better, put them both in namespace __gnu_test, as
__gnu_test::MallocInfo and __gnu_test::malloc_info (without the extern
"C" language linkage). If we're not calling the glibc function
directly, but via our own wrapper, then there's no reason it has to
use the name "mallinfo", no reason it has to be in the global
namespace, and no reason it has to be extern "C" (in fact, I don't
think there was ever a reason for it to be extern "C").



>  struct with just what we need. When using glibc >= 2.33 use
> mallinfo2 to
>  populate it.
>
> Tested under Linux x86_64,
>
> Ok to commit ?
>
> François

[pushed] c++: diagnostic for template placeholder in parm [PR106793]

[Jason Merrill via Gcc-patches]

Talking about the declarator form doesn't help when fixing that would get
you a different error about placeholders not being valid in a parameter.

This also adds a <> fixit, which isn't enough for most templates, but is a
start.

Tested x86_64-pc-linux-gnu, applying to trunk.

PR c++/106793

gcc/cp/ChangeLog:

* decl.cc (grokdeclarator): Improve placeholder diagnostics.
* parser.cc (cp_parser_type_id_1): Add fixit.

gcc/testsuite/ChangeLog:

* g++.dg/cpp23/auto-array2.C: Adjust.
* g++.dg/cpp1z/class-deduction113.C: New test.
---
 gcc/cp/decl.cc| 30 ---
 gcc/cp/parser.cc  |  7 +++--
 .../g++.dg/cpp1z/class-deduction113.C |  5 
 gcc/testsuite/g++.dg/cpp23/auto-array2.C  |  4 +--
 4 files changed, 32 insertions(+), 14 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1z/class-deduction113.C

diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index 6d20765f40c..4665a29a24d 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -12407,14 +12407,20 @@ grokdeclarator (const cp_declarator *declarator,
 
   if (cxx_dialect >= cxx17 && type && is_auto (type)
   && innermost_code != cdk_function
+  /* Placeholder in parm gets a better error below.  */
+  && !(decl_context == PARM || decl_context == CATCHPARM)
   && id_declarator && declarator != id_declarator)
 if (tree tmpl = CLASS_PLACEHOLDER_TEMPLATE (type))
-{
-  error_at (typespec_loc, "template placeholder type %qT must be followed "
-   "by a simple declarator-id", type);
-  inform (DECL_SOURCE_LOCATION (tmpl), "%qD declared here", tmpl);
-  type = error_mark_node;
-}
+  {
+   auto_diagnostic_group g;
+   gcc_rich_location richloc (typespec_loc);
+   richloc.add_fixit_insert_after ("<>");
+   error_at (&richloc, "missing template argument list after %qE; "
+ "for deduction, template placeholder must be followed "
+ "by a simple declarator-id", tmpl);
+   inform (DECL_SOURCE_LOCATION (tmpl), "%qD declared here", tmpl);
+   type = error_mark_node;
+  }
 
   staticp = 0;
   inlinep = decl_spec_seq_has_spec_p (declspecs, ds_inline);
@@ -12892,6 +12898,7 @@ grokdeclarator (const cp_declarator *declarator,
  {
if (!funcdecl_p || !dguide_name_p (unqualified_id))
  {
+   auto_diagnostic_group g;
error_at (typespec_loc, "deduced class "
  "type %qD in function return type",
  DECL_NAME (tmpl));
@@ -13837,12 +13844,15 @@ grokdeclarator (const cp_declarator *declarator,
  else if (tree c = CLASS_PLACEHOLDER_TEMPLATE (auto_node))
{
  auto_diagnostic_group g;
- error_at (typespec_loc,
-   "class template placeholder %qE not permitted "
-   "in this context", c);
+ gcc_rich_location richloc (typespec_loc);
+ richloc.add_fixit_insert_after ("<>");
+ error_at (&richloc,
+   "missing template argument list after %qE; template 
"
+   "placeholder not permitted in parameter", c);
  if (decl_context == PARM && cxx_dialect >= cxx20)
-   inform (typespec_loc, "use % for an "
+   inform (typespec_loc, "or use % for an "
"abbreviated function template");
+ inform (DECL_SOURCE_LOCATION (c), "%qD declared here", c);
}
  else
error_at (typespec_loc,
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 289c2142e45..841ba6ed997 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -24397,8 +24397,11 @@ cp_parser_type_id_1 (cp_parser *parser, 
cp_parser_flags flags,
location_t loc = type_specifier_seq.locations[ds_type_spec];
if (tree tmpl = CLASS_PLACEHOLDER_TEMPLATE (auto_node))
  {
-   error_at (loc, "missing template arguments after %qT",
- auto_node);
+   auto_diagnostic_group g;
+   gcc_rich_location richloc (loc);
+   richloc.add_fixit_insert_after ("<>");
+   error_at (&richloc, "missing template arguments after %qE",
+ tmpl);
inform (DECL_SOURCE_LOCATION (tmpl), "%qD declared here",
tmpl);
  }
diff --git a/gcc/testsuite/g++.dg/cpp1z/class-deduction113.C 
b/gcc/testsuite/g++.dg/cpp1z/class-deduction113.C
new file mode 100644
index 000..8f6908e2746
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/class-deduction113.C
@@ -0,0 +1,5 @@
+// PR c++/106793
+
+template  struct A { A(T); };
+template 

Re: [PATCH] Fortran: Add IEEE_SIGNBIT and IEEE_FMA functions

[FX via Gcc-patches]

Hi,

> Both of these functions are new with Fortran 2018, could you add
> a standards version check?

Thanks Thomas, I will do that and post here the commit diff. The check will not 
be perfect, though, because the warning/error cannot be emitted when loading 
the module (because it’s in an external file), but will have to be when the 
call is actually emitted. This means that loading a symbol and not using it 
will not trigger the error it should, but we cannot do better in the current 
scheme.

IEEE modules will need to be fully moved to the front-end at some point, 
bécause F2018 added two procedures that cannot be described in a Fortran module 
(functions whose return kind is described by an optional KIND argument).

 - IEEE_INT (A, ROUND [, KIND])
 - IEEE_REAL (A [, KIND])

But emitting all the symbols in the front-end is a huge work, and there are 
some cases I do not know how to handle.

FX

Re: [PATCH] tree-object-size: Support strndup and strdup

[Siddhesh Poyarekar]

Ping!

On 2022-08-29 10:16, Siddhesh Poyarekar wrote:

Ping!

On 2022-08-15 15:23, Siddhesh Poyarekar wrote:

Use string length of input to strdup to determine the usable size of the
resulting object.  Avoid doing the same for strndup since there's a
chance that the input may be too large, resulting in an unnecessary
overhead or worse, the input may not be NULL terminated, resulting in a
crash where there would otherwise have been none.

gcc/ChangeLog:

* tree-object-size.cc (get_whole_object): New function.
(addr_object_size): Use it.
(strdup_object_size): New function.
(call_object_size): Use it.
(pass_data_object_sizes, pass_data_early_object_sizes): Set
todo_flags_finish to TODO_update_ssa_no_phi.

gcc/testsuite/ChangeLog:

* gcc.dg/builtin-dynamic-object-size-0.c (test_strdup,
test_strndup, test_strdup_min, test_strndup_min): New tests.
(main): Call them.
* gcc.dg/builtin-dynamic-object-size-1.c: Silence overread
warnings.
* gcc.dg/builtin-dynamic-object-size-2.c: Likewise.
* gcc.dg/builtin-dynamic-object-size-3.c: Likewise.
* gcc.dg/builtin-dynamic-object-size-4.c: Likewise.
* gcc.dg/builtin-object-size-1.c: Silence overread warnings.
Declare free, strdup and strndup.
(test11): New test.
(main): Call it.
* gcc.dg/builtin-object-size-2.c: Silence overread warnings.
Declare free, strdup and strndup.
(test9): New test.
(main): Call it.
* gcc.dg/builtin-object-size-3.c: Silence overread warnings.
Declare free, strdup and strndup.
(test11): New test.
(main): Call it.
* gcc.dg/builtin-object-size-4.c: Silence overread warnings.
Declare free, strdup and strndup.
(test9): New test.
(main): Call it.
---
  .../gcc.dg/builtin-dynamic-object-size-0.c    | 43 +++
  .../gcc.dg/builtin-dynamic-object-size-1.c    |  2 +-
  .../gcc.dg/builtin-dynamic-object-size-2.c    |  2 +-
  .../gcc.dg/builtin-dynamic-object-size-3.c    |  2 +-
  .../gcc.dg/builtin-dynamic-object-size-4.c    |  2 +-
  gcc/testsuite/gcc.dg/builtin-object-size-1.c  | 64 +++-
  gcc/testsuite/gcc.dg/builtin-object-size-2.c  | 63 ++-
  gcc/testsuite/gcc.dg/builtin-object-size-3.c  | 63 ++-
  gcc/testsuite/gcc.dg/builtin-object-size-4.c  | 63 ++-
  gcc/tree-object-size.cc   | 76 +--
  10 files changed, 366 insertions(+), 14 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-0.c 
b/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-0.c

index 01a280b2d7b..7f023708b15 100644
--- a/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-0.c
+++ b/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-0.c
@@ -479,6 +479,40 @@ test_loop (int *obj, size_t sz, size_t start, 
size_t end, int incr)

    return __builtin_dynamic_object_size (ptr, 0);
  }
+/* strdup/strndup.  */
+
+size_t
+__attribute__ ((noinline))
+test_strdup (const char *in)
+{
+  char *res = __builtin_strdup (in);
+  return __builtin_dynamic_object_size (res, 0);
+}
+
+size_t
+__attribute__ ((noinline))
+test_strndup (const char *in, size_t bound)
+{
+  char *res = __builtin_strndup (in, bound);
+  return __builtin_dynamic_object_size (res, 0);
+}
+
+size_t
+__attribute__ ((noinline))
+test_strdup_min (const char *in)
+{
+  char *res = __builtin_strdup (in);
+  return __builtin_dynamic_object_size (res, 2);
+}
+
+size_t
+__attribute__ ((noinline))
+test_strndup_min (const char *in, size_t bound)
+{
+  char *res = __builtin_strndup (in, bound);
+  return __builtin_dynamic_object_size (res, 2);
+}
+
  /* Other tests.  */
  struct TV4
@@ -651,6 +685,15 @@ main (int argc, char **argv)
    int *t = test_pr105736 (&val3);
    if (__builtin_dynamic_object_size (t, 0) != -1)
  FAIL ();
+  const char *str = "hello world";
+  if (test_strdup (str) != __builtin_strlen (str) + 1)
+    FAIL ();
+  if (test_strndup (str, 4) != 5)
+    FAIL ();
+  if (test_strdup_min (str) != __builtin_strlen (str) + 1)
+    FAIL ();
+  if (test_strndup_min (str, 4) != 0)
+    FAIL ();
    if (nfails > 0)
  __builtin_abort ();
diff --git a/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-1.c 
b/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-1.c

index 7cc8b1c9488..8f17c8edcaf 100644
--- a/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-1.c
+++ b/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-1.c
@@ -1,5 +1,5 @@
  /* { dg-do run } */
-/* { dg-options "-O2" } */
+/* { dg-options "-O2 -Wno-stringop-overread" } */
  /* { dg-require-effective-target alloca } */
  #define __builtin_object_size __builtin_dynamic_object_size
diff --git a/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-2.c 
b/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-2.c

index 267dbf48ca7..3677782ff1c 100644
--- a/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-2.c
+++ b/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-2.c
@@ -1,5 +1,5 @@
  /* { dg-do run } */
-/* { dg-options "-O2" } */
+/* { dg-options "-O2 -Wno-stringop-

[committed] libstdc++: Add missing runtime exception to licence notice

[Jonathan Wakely via Gcc-patches]

Tested powerpc64le-linux, pushed to trunk.

Backports to gcc-11 and gcc-12 needed too.

-- >8 --

This file is missing the GCC Runtime Library Exception text in the
licence header. That is unintentional, and it should have been present.

libstdc++-v3/ChangeLog:

* include/std/barrier: Add missing runtime exception.
---
 libstdc++-v3/include/std/barrier | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/include/std/barrier b/libstdc++-v3/include/std/barrier
index 2a2650546ad..997e0a8f7ab 100644
--- a/libstdc++-v3/include/std/barrier
+++ b/libstdc++-v3/include/std/barrier
@@ -13,8 +13,13 @@
 // 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 this library; see the file COPYING3.  If not see
+// Under Section 7 of GPL version 3, you are granted additional
+// permissions described in the GCC Runtime Library Exception, version
+// 3.1, as published by the Free Software Foundation.
+
+// You should have received a copy of the GNU General Public License and
+// a copy of the GCC Runtime Library Exception along with this program;
+// see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 // .
 
 // This implementation is based on libcxx/include/barrier
-- 
2.37.3

[PATCH] c++: unnecessary instantiation of constexpr var [PR99130]

[Patrick Palka via Gcc-patches]

Here the use of the constexpr member/variable specialization 'value'
from within an unevaluated context causes us to overeagerly instantiate
it, via maybe_instantiate_decl called from mark_used, despite only its
declaration not its definition being needed.

We used to have the same issue for constexpr function specializations
until r6-1309-g81371eff9bc7ef made us delay their instantiation until
necessary during constexpr evaluation.

So this patch makes us avoid unnecessarily instantiating constexpr
variable template specializations from mark_used as well.  To that end
this patch pulls out the test in maybe_instantiate_decl

  (decl_maybe_constant_var_p (decl)
   || (TREE_CODE (decl) == FUNCTION_DECL
   && DECL_OMP_DECLARE_REDUCTION_P (decl))
   || undeduced_auto_decl (decl))

into each of its three callers (including mark_used) and refines the
test appropriately.  The net result is that only mark_used is changed,
because the other two callers, resolve_address_of_overloaded_function
and decl_constant_var_p, already guard the call appropriately.  And
presumably decl_constant_var_p will take care of instantiation when
needed for e.g. constexpr evaluation.

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

PR c++/99130

gcc/cp/ChangeLog:

* decl2.cc (maybe_instantiate_decl): Adjust function comment.
Check VAR_OR_FUNCTION_DECL_P. Pull out the disjunction into ...
(mark_used): ... here, removing the decl_maybe_constant_var_p
part of it.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/var-templ70.C: New test.
---
 gcc/cp/decl2.cc  | 33 
 gcc/testsuite/g++.dg/cpp1y/var-templ70.C | 19 ++
 2 files changed, 30 insertions(+), 22 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/var-templ70.C

diff --git a/gcc/cp/decl2.cc b/gcc/cp/decl2.cc
index 89ab2545d64..cd188813bee 100644
--- a/gcc/cp/decl2.cc
+++ b/gcc/cp/decl2.cc
@@ -5381,24 +5381,15 @@ possibly_inlined_p (tree decl)
   return true;
 }
 
-/* Normally, we can wait until instantiation-time to synthesize DECL.
-   However, if DECL is a static data member initialized with a constant
-   or a constexpr function, we need it right now because a reference to
-   such a data member or a call to such function is not value-dependent.
-   For a function that uses auto in the return type, we need to instantiate
-   it to find out its type.  For OpenMP user defined reductions, we need
-   them instantiated for reduction clauses which inline them by hand
-   directly.  */
+/* If DECL is a function or variable template specialization, instantiate
+   its definition now.  */
 
 void
 maybe_instantiate_decl (tree decl)
 {
-  if (DECL_LANG_SPECIFIC (decl)
+  if (VAR_OR_FUNCTION_DECL_P (decl)
+  && DECL_LANG_SPECIFIC (decl)
   && DECL_TEMPLATE_INFO (decl)
-  && (decl_maybe_constant_var_p (decl)
- || (TREE_CODE (decl) == FUNCTION_DECL
- && DECL_OMP_DECLARE_REDUCTION_P (decl))
- || undeduced_auto_decl (decl))
   && !DECL_DECLARED_CONCEPT_P (decl)
   && !uses_template_parms (DECL_TI_ARGS (decl)))
 {
@@ -5700,15 +5691,13 @@ mark_used (tree decl, tsubst_flags_t complain)
   return false;
 }
 
-  /* Normally, we can wait until instantiation-time to synthesize DECL.
- However, if DECL is a static data member initialized with a constant
- or a constexpr function, we need it right now because a reference to
- such a data member or a call to such function is not value-dependent.
- For a function that uses auto in the return type, we need to instantiate
- it to find out its type.  For OpenMP user defined reductions, we need
- them instantiated for reduction clauses which inline them by hand
- directly.  */
-  maybe_instantiate_decl (decl);
+  /* If DECL has a deduced return type, we need to instantiate it now to
+ find out its type.  For OpenMP user defined reductions, we need them
+ instantiated for reduction clauses which inline them by hand directly.  */
+  if (undeduced_auto_decl (decl)
+  || (TREE_CODE (decl) == FUNCTION_DECL
+ && DECL_OMP_DECLARE_REDUCTION_P (decl)))
+maybe_instantiate_decl (decl);
 
   if (processing_template_decl || in_template_function ())
 return true;
diff --git a/gcc/testsuite/g++.dg/cpp1y/var-templ70.C 
b/gcc/testsuite/g++.dg/cpp1y/var-templ70.C
new file mode 100644
index 000..80965657c32
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/var-templ70.C
@@ -0,0 +1,19 @@
+// PR c++/99130
+// { dg-do compile { target c++14 } }
+
+template
+struct A {
+  static constexpr int value = T::value;
+};
+
+struct B {
+  template
+  static constexpr int value = T::value;
+};
+
+template
+constexpr int value = T::value;
+
+using ty1 = decltype(A::value);
+using ty2 = decltype(B::value);
+using ty3 = decltype(value);
-- 
2.37.3.518.g79f2338b37

Re: [PATCH] c++: unnecessary instantiation of constexpr var [PR99130]

[Jason Merrill via Gcc-patches]

On 9/7/22 15:41, Patrick Palka wrote:

Here the use of the constexpr member/variable specialization 'value'
from within an unevaluated context causes us to overeagerly instantiate
it, via maybe_instantiate_decl called from mark_used, despite only its
declaration not its definition being needed.


If the issue is with unevaluated context, maybe maybe_instantiate_decl 
should guard the call to decl_maybe_constant_var_p with 
!cp_unevaluated_operand?



We used to have the same issue for constexpr function specializations
until r6-1309-g81371eff9bc7ef made us delay their instantiation until
necessary during constexpr evaluation.

So this patch makes us avoid unnecessarily instantiating constexpr
variable template specializations from mark_used as well.  To that end
this patch pulls out the test in maybe_instantiate_decl

   (decl_maybe_constant_var_p (decl)
|| (TREE_CODE (decl) == FUNCTION_DECL
&& DECL_OMP_DECLARE_REDUCTION_P (decl))
|| undeduced_auto_decl (decl))

into each of its three callers (including mark_used) and refines the
test appropriately.  The net result is that only mark_used is changed,
because the other two callers, resolve_address_of_overloaded_function
and decl_constant_var_p, already guard the call appropriately.  And
presumably decl_constant_var_p will take care of instantiation when
needed for e.g. constexpr evaluation.

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

PR c++/99130

gcc/cp/ChangeLog:

* decl2.cc (maybe_instantiate_decl): Adjust function comment.
Check VAR_OR_FUNCTION_DECL_P. Pull out the disjunction into ...
(mark_used): ... here, removing the decl_maybe_constant_var_p
part of it.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/var-templ70.C: New test.
---
  gcc/cp/decl2.cc  | 33 
  gcc/testsuite/g++.dg/cpp1y/var-templ70.C | 19 ++
  2 files changed, 30 insertions(+), 22 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp1y/var-templ70.C

diff --git a/gcc/cp/decl2.cc b/gcc/cp/decl2.cc
index 89ab2545d64..cd188813bee 100644
--- a/gcc/cp/decl2.cc
+++ b/gcc/cp/decl2.cc
@@ -5381,24 +5381,15 @@ possibly_inlined_p (tree decl)
return true;
  }
  
-/* Normally, we can wait until instantiation-time to synthesize DECL.

-   However, if DECL is a static data member initialized with a constant
-   or a constexpr function, we need it right now because a reference to
-   such a data member or a call to such function is not value-dependent.
-   For a function that uses auto in the return type, we need to instantiate
-   it to find out its type.  For OpenMP user defined reductions, we need
-   them instantiated for reduction clauses which inline them by hand
-   directly.  */
+/* If DECL is a function or variable template specialization, instantiate
+   its definition now.  */
  
  void

  maybe_instantiate_decl (tree decl)
  {
-  if (DECL_LANG_SPECIFIC (decl)
+  if (VAR_OR_FUNCTION_DECL_P (decl)
+  && DECL_LANG_SPECIFIC (decl)
&& DECL_TEMPLATE_INFO (decl)
-  && (decl_maybe_constant_var_p (decl)
- || (TREE_CODE (decl) == FUNCTION_DECL
- && DECL_OMP_DECLARE_REDUCTION_P (decl))
- || undeduced_auto_decl (decl))
&& !DECL_DECLARED_CONCEPT_P (decl)
&& !uses_template_parms (DECL_TI_ARGS (decl)))
  {
@@ -5700,15 +5691,13 @@ mark_used (tree decl, tsubst_flags_t complain)
return false;
  }
  
-  /* Normally, we can wait until instantiation-time to synthesize DECL.

- However, if DECL is a static data member initialized with a constant
- or a constexpr function, we need it right now because a reference to
- such a data member or a call to such function is not value-dependent.
- For a function that uses auto in the return type, we need to instantiate
- it to find out its type.  For OpenMP user defined reductions, we need
- them instantiated for reduction clauses which inline them by hand
- directly.  */
-  maybe_instantiate_decl (decl);
+  /* If DECL has a deduced return type, we need to instantiate it now to
+ find out its type.  For OpenMP user defined reductions, we need them
+ instantiated for reduction clauses which inline them by hand directly.  */
+  if (undeduced_auto_decl (decl)
+  || (TREE_CODE (decl) == FUNCTION_DECL
+ && DECL_OMP_DECLARE_REDUCTION_P (decl)))
+maybe_instantiate_decl (decl);
  
if (processing_template_decl || in_template_function ())

  return true;
diff --git a/gcc/testsuite/g++.dg/cpp1y/var-templ70.C 
b/gcc/testsuite/g++.dg/cpp1y/var-templ70.C
new file mode 100644
index 000..80965657c32
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/var-templ70.C
@@ -0,0 +1,19 @@
+// PR c++/99130
+// { dg-do compile { target c++14 } }
+
+template
+struct A {
+  static constexpr int value = T::value;
+};
+
+struct B {
+  template
+  static constexpr int value = T::value;
+};
+
+template
+co

Re: [PATCH][DOCS] Mention removed ports in GCC 13.

[Martin Liška]

On 9/7/22 16:28, Gerald Pfeifer wrote:
> On Wed, 7 Sep 2022, Martin Liška wrote:
>> Thanks for the fix. Btw. have you removed the w3c validation script?
> 
> I didn't remove it, but had to deactive automated notifications since the 
> w3.org service started to employ some "are you a secure machine?" checks 
> that appear to use Javascript or the like, breaking any automated use of 
> that service. :-(

What a pity.

Martin

> 
> So I literally have to click through notification e-mails and manually 
> check the result in the browser; hence the delay.
> 
> Gerald

Re: [PATCH] Improve converting between 128-bit modes that use the same format

[Michael Meissner via Gcc-patches]

On Tue, Sep 06, 2022 at 05:22:11PM -0500, Segher Boessenkool wrote:
> Please do this.  It is the biggest problem I have with most of your
> patches: you seem to save up development of a week, and then send it out
> as big omnibus patch an hour or two before my weekend.  This is not
> ideal.

This is always going to be the case.  As I'm developing the larger patches,
there are usually at least 3 smaller problems wanting to get out.  I don't know
what these things are until I run into them.

With the long patch review cycle, I have to be working n patches ahead of what
is submitted just to keep busy.

I try my best to segreate the patches into smaller chunks, but at the end of
the day there are going to various changes to get to the larger goal.  I really
don't see any way around that.

Things don't always come in 3 line changes.  A lot of times I make the 3 line
change, and then I have to make several other changes to compensate for it
elsewhere.  If I submit smaller patches, things will break unless all of the
patches in the chain are committed.  And invariably you will then ask why this
particular change is needed, when it is needed by the next patch or the patch
after that.

> > > > +(define_expand "extendkfif2"
> > > > +  [(set (match_operand:IF 0 "gpc_reg_operand")
> > > > +   (float_extend:IF (match_operand:KF 1 "gpc_reg_operand")))]
> > > > +  "TARGET_FLOAT128_TYPE"
> > > > +{
> > > > +  rs6000_expand_float128_convert (operands[0], operands[1], false);
> > > > +  DONE;
> > > > +})
> > > 
> > > This does not belong here.
> > > 
> > > It really shouldn't *exist* at all: this is *not* a float_extend!  It is
> > > not converting to a wider mode (as required!), but not even to a mode of
> > > higher precision: both IFmode and KFmode can represent (finite, normal)
> > > numbers the other can not.
> > 
> > We know that TFmode (if -mabi=ieeelongdouble) and KFmode are the same, just
> > like TFmode (if -mabi=ibmlongdouble) and IFmode are the same.  But RTL does 
> > not
> > know that these modes use the same representation.  So to convert between 
> > them,
> > it needs to use either FLOAT_EXTEND or FLOAT_TRUNCATE, depending on which
> > precision each of the three modes have (i.e. rs6000-modes.h).  So you need
> > these conversions in RTL.
> 
> You have "extends" also when it is to a lower precision!
>
> Also, let me say this again: this needs to be solved.  We cannot make
> real progress as long as we keep pretending every pait of floating point
> modes can be ordered.

I have no plans to solve this.  I view it as an unsolvable problem that will
invariably lead to lots and lots of changes that will need buy in from the
other GCC developers.  If you can make the changes, fine.  But I view it as
work with what you have rather than trying to change the whole floating point
infrastructure within GCC.

> > Unfortunately, you can't just use SUBREG before register allocation is done.
> 
> Why not?  It isn't valid (in all cases) *after* RA, but before is fine.

I haven't tracked it down.  But I tend to think it is a whack-a-mole problem
where there will be 50+ small changes that are needed to get this to work.  And
then we get back to the issue that you need all of these changes.

> But you do not want a subreg, you need a conversion.
> 
> > > But it certainly does not belong here in the middle of no-op moves.
> 
> This is still very true.
> 
> > So for example, for IBM floating point my current patches are:
> 
> > But for the IEEE side, combining the two insns won't work, since going from
> > TFmode to KFmode will generate a FLOAT_TRUNCATE instead of a FLOAT_EXTEND.
> 
> Yes.  Please just fix the code depending on fundamentally wrong and
> unworkable assumptions, instead of adding perpetually worse workarounds
> that make things more rickety all the time.
> 
> When you added this IF/KF/TF ordering stuff first, I was amazed that it
> worked as well as it did.  And this was perhaps the best we could do for
> GCC 10, sure.  But the problem should have been fixed since, there is no
> sane way forward without doing that.

When I first looked at it, the number of hidden assumptions that I discovered
just in the changes I made was high.  I believe fundamentally that there will
be a lot more changes to do what you want.  And as I said, this will need a lot
of buy-in from other developers.

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com

Re: [PATCH] c++: unnecessary instantiation of constexpr var [PR99130]

[Patrick Palka via Gcc-patches]

On Wed, 7 Sep 2022, Jason Merrill wrote:

> On 9/7/22 15:41, Patrick Palka wrote:
> > Here the use of the constexpr member/variable specialization 'value'
> > from within an unevaluated context causes us to overeagerly instantiate
> > it, via maybe_instantiate_decl called from mark_used, despite only its
> > declaration not its definition being needed.
> 
> If the issue is with unevaluated context, maybe maybe_instantiate_decl should
> guard the call to decl_maybe_constant_var_p with !cp_unevaluated_operand?

Hmm, that seems to work too.  But IIUC this would mean in an evaluated
(but non-constexpr) context we'd continue to instantiate constexpr
variables _immediately_ rather than ideally allowing mark_used to
postpone their instantiation until the end of TU processing (which is
what happens with the below approach).

Another benefit of the below approach is that from within a template
definition we we now avoid instantiation altogether e.g. for

  template constexpr int value = /* blah */;

  template
  int f() { return value; }

we no longer instantiate value which IIUC is consistent with how we
handle other kinds of specializations used within a template definition.
So making mark_used no longer instantiate constexpr variables immediately
(in both evaluated and unevaluated contexts) seems to yield the most
benefits.

> 
> > We used to have the same issue for constexpr function specializations
> > until r6-1309-g81371eff9bc7ef made us delay their instantiation until
> > necessary during constexpr evaluation.
> > 
> > So this patch makes us avoid unnecessarily instantiating constexpr
> > variable template specializations from mark_used as well.  To that end
> > this patch pulls out the test in maybe_instantiate_decl
> > 
> >(decl_maybe_constant_var_p (decl)
> > || (TREE_CODE (decl) == FUNCTION_DECL
> > && DECL_OMP_DECLARE_REDUCTION_P (decl))
> > || undeduced_auto_decl (decl))
> > 
> > into each of its three callers (including mark_used) and refines the
> > test appropriately.  The net result is that only mark_used is changed,
> > because the other two callers, resolve_address_of_overloaded_function
> > and decl_constant_var_p, already guard the call appropriately.  And
> > presumably decl_constant_var_p will take care of instantiation when
> > needed for e.g. constexpr evaluation.
> > 
> > Bootstrapped and regteste on x86_64-pc-linux-gnu, does this look OK for
> > trunk?
> > 
> > PR c++/99130
> > 
> > gcc/cp/ChangeLog:
> > 
> > * decl2.cc (maybe_instantiate_decl): Adjust function comment.
> > Check VAR_OR_FUNCTION_DECL_P. Pull out the disjunction into ...
> > (mark_used): ... here, removing the decl_maybe_constant_var_p
> > part of it.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > * g++.dg/cpp1y/var-templ70.C: New test.
> > ---
> >   gcc/cp/decl2.cc  | 33 
> >   gcc/testsuite/g++.dg/cpp1y/var-templ70.C | 19 ++
> >   2 files changed, 30 insertions(+), 22 deletions(-)
> >   create mode 100644 gcc/testsuite/g++.dg/cpp1y/var-templ70.C
> > 
> > diff --git a/gcc/cp/decl2.cc b/gcc/cp/decl2.cc
> > index 89ab2545d64..cd188813bee 100644
> > --- a/gcc/cp/decl2.cc
> > +++ b/gcc/cp/decl2.cc
> > @@ -5381,24 +5381,15 @@ possibly_inlined_p (tree decl)
> > return true;
> >   }
> >   -/* Normally, we can wait until instantiation-time to synthesize DECL.
> > -   However, if DECL is a static data member initialized with a constant
> > -   or a constexpr function, we need it right now because a reference to
> > -   such a data member or a call to such function is not value-dependent.
> > -   For a function that uses auto in the return type, we need to instantiate
> > -   it to find out its type.  For OpenMP user defined reductions, we need
> > -   them instantiated for reduction clauses which inline them by hand
> > -   directly.  */
> > +/* If DECL is a function or variable template specialization, instantiate
> > +   its definition now.  */
> > void
> >   maybe_instantiate_decl (tree decl)
> >   {
> > -  if (DECL_LANG_SPECIFIC (decl)
> > +  if (VAR_OR_FUNCTION_DECL_P (decl)
> > +  && DECL_LANG_SPECIFIC (decl)
> > && DECL_TEMPLATE_INFO (decl)
> > -  && (decl_maybe_constant_var_p (decl)
> > - || (TREE_CODE (decl) == FUNCTION_DECL
> > - && DECL_OMP_DECLARE_REDUCTION_P (decl))
> > - || undeduced_auto_decl (decl))
> > && !DECL_DECLARED_CONCEPT_P (decl)
> > && !uses_template_parms (DECL_TI_ARGS (decl)))
> >   {
> > @@ -5700,15 +5691,13 @@ mark_used (tree decl, tsubst_flags_t complain)
> > return false;
> >   }
> >   -  /* Normally, we can wait until instantiation-time to synthesize DECL.
> > - However, if DECL is a static data member initialized with a constant
> > - or a constexpr function, we need it right now because a reference to
> > - such a data member or a call to such function is not value-dependent.
> > - For a function that uses auto 

Re: [PATCH] Improve converting between 128-bit modes that use the same format

[Segher Boessenkool]

On Wed, Sep 07, 2022 at 04:25:49PM -0400, Michael Meissner wrote:
> On Tue, Sep 06, 2022 at 05:22:11PM -0500, Segher Boessenkool wrote:
> > Please do this.  It is the biggest problem I have with most of your
> > patches: you seem to save up development of a week, and then send it out
> > as big omnibus patch an hour or two before my weekend.  This is not
> > ideal.
> 
> This is always going to be the case.  As I'm developing the larger patches,
> there are usually at least 3 smaller problems wanting to get out.  I don't 
> know
> what these things are until I run into them.

This is the only large problem.  Humongous, if you want.  It has been
_the_ problem since the beginning of the IEEE QP work.  None of this is
news to anyone.

It makes all other problems tens of times as hard to solve.

The other thing that would have made development way way way less work
in total, and much simpler, is supporting this on more systems.
Everything with VMX for example (with the exact same ABI as we have
now!), or just a la "nof" ("-msoft-float"), which is easy to so as well.
You end up testing more cases, "having" to test more cases, *but* there
are way fewer exceptions.  Anything downstream from us (essentially
everything, we are the C and C++ compilers after all) has to do a lot
of unnecessary work as well, because of this.

But the fundamental problem that IEEE QP and double-double can not be
ordered causes so many problems it is just not funny.  The *workarounds*
for it each cause a cascade of *other problems*, and there is no end in
sight.


Segher

Re: [PATCH v2] analyzer: support for symbolic values in the out-of-bounds checker [PR106625]

[David Malcolm via Gcc-patches]

On Wed, 2022-09-07 at 17:51 +0200, Tim Lange wrote:
> Hi Dave,
> 
> while re-reading that patch, I noticed a small mistake. I accidently
> did
> not move the op == PLUS_EXPR or MULT_EXPR guard in
> symbolic_greater_than
> when implementing the "eliminate operands on both sides" feature,
> which
> lead to the old patch also eliminating operands on both sides if the
> operator decreases the value, which is obviously wrong.
> 
> I moved the guard outside and added test coverage for this in
> symbolic-gt-1.c. The patch passed the regrtests with the fix
> included.
> 
> I assume it is still okay for trunk?

Yes it is - thanks for the updated patch.

Dave

Re: [committed] libstdc++: Add missing runtime exception to licence notice

[Thomas Rodgers via Gcc-patches]

Looks good to me.

Tom.

On Wed, Sep 7, 2022 at 12:27 PM Jonathan Wakely via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:

> Tested powerpc64le-linux, pushed to trunk.
>
> Backports to gcc-11 and gcc-12 needed too.
>
> -- >8 --
>
> This file is missing the GCC Runtime Library Exception text in the
> licence header. That is unintentional, and it should have been present.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/barrier: Add missing runtime exception.
> ---
>  libstdc++-v3/include/std/barrier | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/libstdc++-v3/include/std/barrier
> b/libstdc++-v3/include/std/barrier
> index 2a2650546ad..997e0a8f7ab 100644
> --- a/libstdc++-v3/include/std/barrier
> +++ b/libstdc++-v3/include/std/barrier
> @@ -13,8 +13,13 @@
>  // 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 this library; see the file COPYING3.  If not see
> +// Under Section 7 of GPL version 3, you are granted additional
> +// permissions described in the GCC Runtime Library Exception, version
> +// 3.1, as published by the Free Software Foundation.
> +
> +// You should have received a copy of the GNU General Public License and
> +// a copy of the GCC Runtime Library Exception along with this program;
> +// see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
>  // .
>
>  // This implementation is based on libcxx/include/barrier
> --
> 2.37.3
>
>

[PATCH] pch: Fix the reconstruction of adhoc data hash table

[Lewis Hyatt via Gcc-patches]

The function rebuild_location_adhoc_htab() was meant to reconstruct the
adhoc location hash map after restoring a line_maps instance from a
PCH. However, the function has never performed as intended because it
missed the last step of adding the data into the newly reconstructed hash
map. This patch fixes that.

It does not seem possible to construct a test case such that the current
incorrect behavior is observable as a compiler issue. It would be
observable, if it were possible for a precompiled header to contain an
adhoc location with a non-zero custom data pointer. But currently, such
data pointers are used only by the middle end to track inlining
information, and this happens later, too late to show up in a PCH.

I also noted that location_adhoc_data_update, which updates the hash map
pointers in a different scenario, was relying on undefined pointer
arithmetic behavior. I'm not aware of this having caused any issue in
practice, but in this patch I have also changed it to use defined pointer
operations instead.

libcpp/ChangeLog:

* line-map.cc (location_adhoc_data_update): Remove reliance on
undefined behavior.
(get_combined_adhoc_loc): Likewise.
(rebuild_location_adhoc_htab): Fix issue where the htab was not
properly updated.
---

Notes:
Hello-

While working on something unrelated in line-map.cc, I noticed that the
function rebuild_location_adhoc_htab(), whose job is to reconstruct the
adhoc data hash table after a line_maps instance is reconstructed from PCH,
doesn't actually rebuild the hash table at all:

void
rebuild_location_adhoc_htab (line_maps *set)
{
  unsigned i;
  set->location_adhoc_data_map.htab =
  htab_create (100, location_adhoc_data_hash, location_adhoc_data_eq, 
NULL);
  for (i = 0; i < set->location_adhoc_data_map.curr_loc; i++)
htab_find_slot (set->location_adhoc_data_map.htab,
set->location_adhoc_data_map.data + i, INSERT);
 ^^
}

In order to have the intended effect, it needs to set the return value of
htab_find_slot to be set->location_adhoc_data_map.data + i, otherwise it
doesn't effectively do anything except make the hash table think it has
curr_loc elements set, when in fact it has 0. Subsequent calls to
htab_traverse, for instance, will do nothing, and any lookups will also 
fail.

I tried for some time to construct a test case that would demonstrate an
observable consequence of this issue, but I don't think it's possible... The
nontrivial uses of this hash map are in the middle end (e.g. to produce the
trace of where a given expression was inlined from), and all this happens
after PCH was read in, and doesn't require any state to be read from the
PCH. It would become apparent in the future, however, if the ability to
attach arbitrary data to an adhoc location were used in other ways, perhaps
somewhere in libcpp; in that hypothetical case, the data would be lost when
reading back in the PCH.

There is another kinda related function, location_adhoc_data_update, which
updates all the pointers in the hash map whenever they are invalidated. It
seems to me, that this function invokes undefined behavior, since it adds an
arbitrary offset to the pointers, which do not necessarily point into the
same array after they were realloced. I don't think it's led to any problems
in practice but in this patch I also changed that to use well-defined
operations. Note sure how people may feel about that, since it does require
on the surface 2x as many operations with this change, but I can't see how
the current approach is guaranteed to be valid on all architectures?

Bootstrap + regtest looks good on x86-64 Linux. Thanks a lot to whoever may
have time to take a look at it.

-Lewis

 libcpp/line-map.cc | 41 +++--
 1 file changed, 27 insertions(+), 14 deletions(-)

diff --git a/libcpp/line-map.cc b/libcpp/line-map.cc
index 62077c3857c..391f1d4bbc1 100644
--- a/libcpp/line-map.cc
+++ b/libcpp/line-map.cc
@@ -85,27 +85,38 @@ location_adhoc_data_eq (const void *l1, const void *l2)
  && lb1->data == lb2->data);
 }
 
-/* Update the hashtable when location_adhoc_data is reallocated.  */
+/* Update the hashtable when location_adhoc_data_map::data is reallocated.
+   The param is an array of two pointers, the previous value of the data
+   pointer, and then the new value.  The pointers stored in the hash map
+   are then rebased to be relative to the new data pointer instead of the
+   old one.  */
 
 static int
-location_adhoc_data_update (void **slot, void *data)
+location_adhoc_data_update (void **slot_v, void *param_v)
 {
-  *((char **) slot)
-= (char *) ((uintptr_t) *((char **) slot) + *((ptrdiff_t *) data));
+  const auto slot = reinterpret_cast (slot_v);
+  const auto param =

Re: Patch ping (was Re: [PATCH] libstdc++: Clear padding bits in atomic compare_exchange)

[Thomas Rodgers via Gcc-patches]

Looks good to me.

Tom.

On Wed, Sep 7, 2022 at 4:56 AM Jonathan Wakely  wrote:

> Here's a complete patch that combines the various incremental patches
> that have been going around. I'm testing this now.
>
> Please take a look.
>

[PATCH] : [gcc/config/rs600/rs6000.cc][Fix typo] Add parentheses for if statement

[Akari Takahashi via Gcc-patches]

Hello:
I am very interested in GCC and have joined the FSF membership.
I found a small bug in the latest source code, so I report it.

Patch:
[Fix typo]Add parentheses for if statement in line 18117.
gcc/config/rs600/rs6000.cc

Diff:
--
diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index bcf634a146d..a656cb32a47 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -18114,7 +18114,7 @@ get_memref_parts (rtx mem, rtx *base,
HOST_WIDE_INT *offset,
  HOST_WIDE_INT *size)
 {
   rtx addr_rtx;
-  if (MEM_SIZE_KNOWN_P (mem))
+  if MEM_SIZE_KNOWN_P (mem)
 *size = MEM_SIZE (mem);
   else
 return false;
--

Takahashi Akari

[PATCH] RISC-V:Add '-m[no]-csr-check' option in gcc.

[jiawei]

From: Jiawei 

Add -m[no]-csr-check option in gcc part, when enable -mcsr-check option,
it will add csr-check in .option section and pass this to assembler.

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_file_start): New .option.
* config/riscv/riscv.opt: New options.
* doc/invoke.texi: New definations.

---
 gcc/config/riscv/riscv.cc  | 5 +
 gcc/config/riscv/riscv.opt | 6 ++
 gcc/doc/invoke.texi| 6 ++
 3 files changed, 17 insertions(+)

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 675d92c0961..e98e6b1f561 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -5135,6 +5135,11 @@ riscv_file_start (void)
   if (! riscv_mrelax)
 fprintf (asm_out_file, "\t.option norelax\n");
 
+  /* If the user specifies "-mcsr-check" on the command line then enable csr
+ check in the assembler.  */
+  if (riscv_mcsr_check)
+fprintf (asm_out_file, "\t.option csr-check\n");
+
   if (riscv_emit_attribute_p)
 riscv_emit_attribute ();
 }
diff --git a/gcc/config/riscv/riscv.opt b/gcc/config/riscv/riscv.opt
index fbca91b956c..3a12dd47310 100644
--- a/gcc/config/riscv/riscv.opt
+++ b/gcc/config/riscv/riscv.opt
@@ -132,6 +132,12 @@ Target Bool Var(riscv_mrelax) Init(1)
 Take advantage of linker relaxations to reduce the number of instructions
 required to materialize symbol addresses.
 
+mcsr-check
+Target Bool Var(riscv_mcsr_check) Init(1)
+Enable the CSR checking for the ISA-dependent CRS and the read-only CSR.
+The ISA-dependent CSR are only valid when the specific ISA is set.  The
+read-only CSR can not be written by the CSR instructions.
+
 Mask(64BIT)
 
 Mask(MUL)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index dd3302fcd15..7caade26b94 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -1224,6 +1224,7 @@ See RS/6000 and PowerPC Options.
 -mbig-endian  -mlittle-endian @gol
 -mstack-protector-guard=@var{guard}  -mstack-protector-guard-reg=@var{reg} @gol
 -mstack-protector-guard-offset=@var{offset}}
+-mcsr-check -mno-csr-check @gol
 
 @emph{RL78 Options}
 @gccoptlist{-msim  -mmul=none  -mmul=g13  -mmul=g14  -mallregs @gol
@@ -28551,6 +28552,11 @@ linker relaxations.
 Emit (do not emit) RISC-V attribute to record extra information into ELF
 objects.  This feature requires at least binutils 2.32.
 
+@item -mcsr-check
+@itemx -mno-csr-check
+@opindex mcsr-check
+Enables or disables the CSR checking.
+
 @item -malign-data=@var{type}
 @opindex malign-data
 Control how GCC aligns variables and constants of array, structure, or union
-- 
2.34.1

[PATCH 2/2] rs6000: building const with lis/li/pli+rlwinm

[Jiufu Guo via Gcc-patches]

Hi,

We may use two instructions (rlwinm with mask + li/lis) to build 64bit constant.
For example: 'li 9,16383 + rlwinm 9,9,0,29,25' builds 0x3fff3fc7LL.

This updates rs6000_emit_set_long_const to building constants through rlwinm.

Bootstrap & regtest pass on ppc64 and ppc64le.
Is this ok for trunk?

BR,
Jeff(Jiufu)


PR target/94395

gcc/ChangeLog:

* config/rs6000/rs6000.cc (from_rotate32): New function to check a 32
bit value is rotate32 from li/lis.
(check_rotate32_mask): New function to check sh/mb/me for rlwinm.
(rs6000_emit_set_long_const): Use rlwinm to build constant.
* config/rs6000/rs6000.md (rlwinm3): New define_insn.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/pr93012.c: Update insn count.
* gcc.target/powerpc/pr94395_rlwinm.c: New test.
* gcc.target/powerpc/pr94395_rlwinm.h: New file.
* gcc.target/powerpc/pr94395_rlwinm_1.c: New test.

---
 gcc/config/rs6000/rs6000.cc   | 83 ++-
 gcc/config/rs6000/rs6000.md   | 11 +++
 gcc/testsuite/gcc.target/powerpc/pr93012.c|  3 +-
 .../gcc.target/powerpc/pr94395_rlwinm.c   |  6 ++
 .../gcc.target/powerpc/pr94395_rlwinm.h   |  8 ++
 .../gcc.target/powerpc/pr94395_rlwinm_1.c | 16 
 6 files changed, 123 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/pr94395_rlwinm.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/pr94395_rlwinm.h
 create mode 100644 gcc/testsuite/gcc.target/powerpc/pr94395_rlwinm_1.c

diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index 93438b4da07..3b5a2f5a16e 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -10110,7 +10110,8 @@ rs6000_emit_set_const (rtx dest, rtx source)
Return -1 if C can not be rotated as from.  */
 
 static int
-rotate_from_leading_zeros_const (unsigned HOST_WIDE_INT c, int clz)
+rotate_from_leading_zeros_const (unsigned HOST_WIDE_INT c, int clz,
+bool rotl32 = false)
 {
   /* case a. 0..0xxx: already at least clz zeros.  */
   int lz = clz_hwi (c);
@@ -10126,7 +10127,9 @@ rotate_from_leading_zeros_const (unsigned HOST_WIDE_INT 
c, int clz)
   ^bit -> Vbit, then zeros are at head or tail.
 00...00xxx100, 'clz + 1' >= 'bits of '.  */
   const int rot_bits = HOST_BITS_PER_WIDE_INT - clz + 1;
-  unsigned HOST_WIDE_INT rc = (c >> rot_bits) | (c << (clz - 1));
+  unsigned HOST_WIDE_INT rc;
+  rc = rotl32 ? (((c >> rot_bits) | (c << (32 - rot_bits))) & 0xULL)
+ : (c >> rot_bits) | (c << (clz - 1));
   lz = clz_hwi (rc);
   tz = ctz_hwi (rc);
   if (lz + tz >= clz)
@@ -10319,6 +10322,71 @@ check_rotate_mask (unsigned HOST_WIDE_INT c, 
HOST_WIDE_INT *val, int *shift,
   return true;
 }
 
+/* For low 32bits of C, check if it can be rotated from an constant value
+   which contains count of leading zeros at least CLZ.  */
+
+static int
+from_rotate32 (unsigned HOST_WIDE_INT c)
+{
+  /* rotate32 from li possitive 17bits zeros (17 + 32 = 49).  */
+  int n = rotate_from_leading_zeros_const (c & 0xULL, 49, true);
+
+  /* rotate32 from li negative.  */
+  if (n < 0)
+n = rotate_from_leading_zeros_const ((~c) & 0xULL, 49, true);
+
+  /* rotate32 from lis negative.  */
+  if (n < 0)
+{
+  n = rotate_from_leading_zeros_const (c & 0xULL, 48, true);
+  if (n >= 0)
+   n += 16;
+}
+
+  return n < 0 ? -1 : (n % 32);
+}
+
+/* Check if value C can be generated by 2 instructions, one instruction
+   is li/lis or pli, another instruction is rlwinm.  */
+
+static bool
+check_rotate32_mask (unsigned HOST_WIDE_INT c, HOST_WIDE_INT *val, int *shift,
+int *mb, int *me, bool for_pli)
+{
+  unsigned HOST_WIDE_INT low = c & 0xULL;
+  unsigned HOST_WIDE_INT high = (c >> 32) & 0xULL;
+  unsigned HOST_WIDE_INT v;
+  int b, e;
+
+  /* diff of high and low (high ^ low) should be the mask position.  */
+  unsigned HOST_WIDE_INT m = low ^ high;
+  int tz = ctz_hwi (m);
+  int lz = clz_hwi (m);
+  b = m == 0 ? 1 : (high != 0 ? 32 - tz : lz - 32);
+  e = m == 0 ? 0 : (high != 0 ? lz - 33 : 31 - tz);
+  if (m != 0)
+m = ((HOST_WIDE_INT_M1U >> (lz + tz)) << tz);
+  if (high != 0)
+m = ~m;
+  v = high != 0 ? high : ((low | ~m) & 0x);
+
+  if ((high != 0) && ((v & m) != low || e < 0 || b > 31))
+return false;
+
+  int n = for_pli ? 0 : from_rotate32 (v);
+  if (n < 0)
+return false;
+
+  v = ((v >> n) | (v << (32 - n))) & 0x;
+  if (v & 0x8000ULL)
+v |= HOST_WIDE_INT_M1U << 32;
+  *me = e;
+  *mb = b;
+  *val = v;
+  *shift = n;
+  return true;
+}
+
 /* Subroutine of rs6000_emit_set_const, handling PowerPC64 DImode.
Output insns to set DEST equal to the constant C as a series of
lis, ori and shl instructions.  */
@@ -10330,7 +10398,7 @@ rs6000_emit_set_long_const (rtx dest, HOST_WIDE_INT c)
   HOST_WID

Re: [PATCH] RISC-V:Add '-m[no]-csr-check' option in gcc.

[Kito Cheng via Gcc-patches]

Hi Jiawei:

Could you add check in config/configure.ac and gcc/config.in to make
sure the binutils has support for that or not?

You can reference the commit for -misa-spec to see how it work and how it add:
https://github.com/gcc-mirror/gcc/commit/4b81528241ca682025d92558ff6aeec91dafdca8

Thanks :)

On Thu, Sep 8, 2022 at 9:51 AM jiawei  wrote:
>
> From: Jiawei 
>
> Add -m[no]-csr-check option in gcc part, when enable -mcsr-check option,
> it will add csr-check in .option section and pass this to assembler.
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.cc (riscv_file_start): New .option.
> * config/riscv/riscv.opt: New options.
> * doc/invoke.texi: New definations.
>
> ---
>  gcc/config/riscv/riscv.cc  | 5 +
>  gcc/config/riscv/riscv.opt | 6 ++
>  gcc/doc/invoke.texi| 6 ++
>  3 files changed, 17 insertions(+)
>
> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> index 675d92c0961..e98e6b1f561 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -5135,6 +5135,11 @@ riscv_file_start (void)
>if (! riscv_mrelax)
>  fprintf (asm_out_file, "\t.option norelax\n");
>
> +  /* If the user specifies "-mcsr-check" on the command line then enable csr
> + check in the assembler.  */
> +  if (riscv_mcsr_check)
> +fprintf (asm_out_file, "\t.option csr-check\n");
> +
>if (riscv_emit_attribute_p)
>  riscv_emit_attribute ();
>  }
> diff --git a/gcc/config/riscv/riscv.opt b/gcc/config/riscv/riscv.opt
> index fbca91b956c..3a12dd47310 100644
> --- a/gcc/config/riscv/riscv.opt
> +++ b/gcc/config/riscv/riscv.opt
> @@ -132,6 +132,12 @@ Target Bool Var(riscv_mrelax) Init(1)
>  Take advantage of linker relaxations to reduce the number of instructions
>  required to materialize symbol addresses.
>
> +mcsr-check
> +Target Bool Var(riscv_mcsr_check) Init(1)
> +Enable the CSR checking for the ISA-dependent CRS and the read-only CSR.
> +The ISA-dependent CSR are only valid when the specific ISA is set.  The
> +read-only CSR can not be written by the CSR instructions.
> +
>  Mask(64BIT)
>
>  Mask(MUL)
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index dd3302fcd15..7caade26b94 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -1224,6 +1224,7 @@ See RS/6000 and PowerPC Options.
>  -mbig-endian  -mlittle-endian @gol
>  -mstack-protector-guard=@var{guard}  -mstack-protector-guard-reg=@var{reg} 
> @gol
>  -mstack-protector-guard-offset=@var{offset}}
> +-mcsr-check -mno-csr-check @gol
>
>  @emph{RL78 Options}
>  @gccoptlist{-msim  -mmul=none  -mmul=g13  -mmul=g14  -mallregs @gol
> @@ -28551,6 +28552,11 @@ linker relaxations.
>  Emit (do not emit) RISC-V attribute to record extra information into ELF
>  objects.  This feature requires at least binutils 2.32.
>
> +@item -mcsr-check
> +@itemx -mno-csr-check
> +@opindex mcsr-check
> +Enables or disables the CSR checking.
> +
>  @item -malign-data=@var{type}
>  @opindex malign-data
>  Control how GCC aligns variables and constants of array, structure, or union
> --
> 2.34.1
>

Re: [PATCH] Use mallinfo2 with glibc >= 2.33

[François Dumont via Gcc-patches]

    libstdc++: glibc mallinfo deprecated, use mallinfo2 when version => 
2.33


    glibc mallinfo is now deprecated resulting in make check-performance
    failure. When glibc => 2.33 prefer mallinfo2.

    libstdcxx-v3/ChangeLog:

    * testsuite/util/testsuite_performance.h 
(__gnu_test::MallocInfo): New.
    (__gnu_test::malloc_info): New, replace mallinfo on current 
platform

    supporting it and use mallinfo2 when glibc >= 2.33.

Tested under Linux x86_64.

Ok to commit ?

François

On 07/09/22 19:10, Jonathan Wakely wrote:

On Wed, 7 Sept 2022 at 18:03, François Dumont via Libstdc++
 wrote:

libstdc++: Use glibc >= 2.33 mallinfo2 function

mallinfo started to be deprecated which makes performance tests failed
to build, just
adopt mallinfo2.

libstdcxx-v3/ChangeLog:

  * testsuite/util/testsuite_performance.h (__mallinfo): New, our
own mallinfo

There's no reason to use a reserved name here, this isn't a header
that users include.

I would call the struct MallocInfo and the function malloc_info().
Even better, put them both in namespace __gnu_test, as
__gnu_test::MallocInfo and __gnu_test::malloc_info (without the extern
"C" language linkage). If we're not calling the glibc function
directly, but via our own wrapper, then there's no reason it has to
use the name "mallinfo", no reason it has to be in the global
namespace, and no reason it has to be extern "C" (in fact, I don't
think there was ever a reason for it to be extern "C").




  struct with just what we need. When using glibc >= 2.33 use
mallinfo2 to
  populate it.

Tested under Linux x86_64,

Ok to commit ?

François


diff --git a/libstdc++-v3/testsuite/util/testsuite_performance.h b/libstdc++-v3/testsuite/util/testsuite_performance.h
index 2e05bef8460..4f8b1eab8b9 100644
--- a/libstdc++-v3/testsuite/util/testsuite_performance.h
+++ b/libstdc++-v3/testsuite/util/testsuite_performance.h
@@ -36,42 +36,39 @@
 #include 
 
 #if defined (__linux__) || defined (__GLIBC__)
-#include 
-#elif defined (__FreeBSD__)
-extern "C"
-{
-  struct mallinfo
-  {
-int uordblks;
-int hblkhd;
-  };
+#include  // For mallinfo.
+#endif
 
-  struct mallinfo
-  mallinfo(void)
-  {
-struct mallinfo m = { (((std::size_t) sbrk (0) + 1023) / 1024), 0 };
-return m;
-  }
-}
-#elif !defined (__hpux__)
-extern "C"
+namespace __gnu_test
 {
-  struct mallinfo
+  struct MallocInfo
   {
-int uordblks;
-int hblkhd;
-  };
+MallocInfo() : uordblks(0), hblkhd(0) { }
+MallocInfo(std::size_t uordblocks, std::size_t hblockhd)
+  : uordblks(uordblocks), hblkhd(hblockhd)
+{ }
 
-  struct mallinfo empty = { 0, 0 };
+std::size_t uordblks;
+std::size_t hblkhd;
+  };
 
-  struct mallinfo
-  mallinfo(void)
-  { return empty; }
-}
+  MallocInfo
+  malloc_info()
+  {
+#if defined (__linux__) || defined (__hpux__) || defined (__GLIBC__)
+#if __GLIBC__ > 2 || __GLIBC__ == 2 && __GLIBC_MINOR__ >= 33
+struct mallinfo2 mi = mallinfo2();
+#else
+struct mallinfo mi = mallinfo();
+#endif
+return MallocInfo(mi.uordblks, mi.hblkhd);
+#elif defined (__FreeBSD__)
+return MallocInfostd::size_t) sbrk (0) + 1023) / 1024), 0);
+#else
+return MallocInfo();
 #endif
+  }
 
-namespace __gnu_test
-{
   class time_counter
   {
   private:
@@ -146,8 +143,8 @@ namespace __gnu_test
 int who;
 rusage	rusage_begin;
 rusage	rusage_end;
-struct mallinfo  	allocation_begin;
-struct mallinfo  	allocation_end;
+MallocInfo  	allocation_begin;
+MallocInfo  	allocation_end;
 
   public:
 resource_counter(int i = RUSAGE_SELF) : who(i)
@@ -168,7 +165,7 @@ namespace __gnu_test
   if (getrusage(who, &rusage_begin) != 0 )
 	memset(&rusage_begin, 0, sizeof(rusage_begin));
   void* p __attribute__((unused)) = malloc(0); // Needed for some implementations.
-  allocation_begin = mallinfo();
+  allocation_begin = malloc_info();
 }
 
 void
@@ -176,7 +173,7 @@ namespace __gnu_test
 {
   if (getrusage(who, &rusage_end) != 0 )
 	memset(&rusage_end, 0, sizeof(rusage_end));
-  allocation_end = mallinfo();
+  allocation_end = malloc_info();
 }
 
 int

Re: [PATCH 1/2] Allow subtarget customization of CC1_SPEC

[Sebastian Huber]

On 04/08/2022 15:02, Sebastian Huber wrote:

On 22/07/2022 15:02, Sebastian Huber wrote:

gcc/ChangeLog:

* gcc.cc (SUBTARGET_CC1_SPEC): Define if not defined.
(CC1_SPEC): Define to SUBTARGET_CC1_SPEC.
* config/arm/arm.h (CC1_SPEC): Remove.
* config/arc/arc.h (CC1_SPEC): Append SUBTARGET_CC1_SPEC.
* config/cris/cris.h (CC1_SPEC): Likewise.
* config/frv/frv.h (CC1_SPEC): Likewise.
* config/i386/i386.h (CC1_SPEC): Likewise.
* config/ia64/ia64.h (CC1_SPEC): Likewise.
* config/lm32/lm32.h (CC1_SPEC): Likewise.
* config/m32r/m32r.h (CC1_SPEC): Likewise.
* config/mcore/mcore.h (CC1_SPEC): Likewise.
* config/microblaze/microblaze.h: Likewise.
* config/nds32/nds32.h (CC1_SPEC): Likewise.
* config/nios2/nios2.h (CC1_SPEC): Likewise.
* config/pa/pa.h (CC1_SPEC): Likewise.
* config/rs6000/sysv4.h (CC1_SPEC): Likewise.
* config/rx/rx.h (CC1_SPEC): Likewise.
* config/sparc/sparc.h (CC1_SPEC): Likewise.


Could someone please have a look at this patch set?


Ping.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

[PATCH] Handle OPAQUE_TYPE specially in verify_type [PR106833]

[Kewen.Lin via Gcc-patches]

Hi,

As PR106833 shows, cv-qualified opaque type can cause ICE
during LTO.  It exposes that we missd to handle OPAQUE_TYPE
well in type verification.  As Richi pointed out, also
assuming that target will always define TYPE_MAIN_VARIANT
and TYPE_CANONICAL for opaque type, this patch is to check
both are OPAQUE_TYPE_P.  Besides, it also checks the only
available size and alignment information as well as type
mode for TYPE_MAIN_VARIANT.

Bootstrapped and regtested on powerpc64-linux-gnu P7 and
powerpc64le-linux-gnu P9 and P10.

Is it ok for trunk?

BR,
Kewen
-
PR middle-end/106833

gcc/ChangeLog:

* tree.cc (verify_opaque_type): New function.
(verify_match): New macro.
(verify_type): Call verify_opaque_type for OPAQUE_TYPE.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/pr106833.c: New test.
---
 gcc/testsuite/gcc.target/powerpc/pr106833.c | 14 +++
 gcc/tree.cc | 45 -
 2 files changed, 58 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/pr106833.c

diff --git a/gcc/testsuite/gcc.target/powerpc/pr106833.c 
b/gcc/testsuite/gcc.target/powerpc/pr106833.c
new file mode 100644
index 000..968d75184ff
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr106833.c
@@ -0,0 +1,14 @@
+/* { dg-do link } */
+/* { dg-require-effective-target power10_ok } */
+/* { dg-require-effective-target lto } */
+/* { dg-options "-flto -mdejagnu-cpu=power10" } */
+
+/* Verify there is no ICE in LTO mode.  */
+
+int main ()
+{
+  float *b;
+  const __vector_quad c;
+  __builtin_mma_disassemble_acc (b, &c);
+  return 0;
+}
diff --git a/gcc/tree.cc b/gcc/tree.cc
index fed1434d141..e67caa8f85d 100644
--- a/gcc/tree.cc
+++ b/gcc/tree.cc
@@ -13670,6 +13670,42 @@ gimple_canonical_types_compatible_p (const_tree t1, 
const_tree t2,
 }
 }

+/* For OPAQUE_TYPE T, it has only size and alignment information, so verify
+   these properties of T match TV which is the main variant of T.  Also
+   verify the type of TC, which is the canonical of T, is OPAQUE_TYPE.  */
+
+static void
+verify_opaque_type (const_tree t, tree tv, tree tc)
+{
+  gcc_assert (OPAQUE_TYPE_P (t));
+  gcc_assert (tv && tv == TYPE_MAIN_VARIANT (tv));
+  gcc_assert (tc && tc == TYPE_CANONICAL (tc));
+
+#define verify_match(flag, t, tv)  
\
+  do   
\
+{  
\
+  if (flag (t) != flag (tv))   
\
+   {  \
+ error ("opaque type differs by %s", #flag);  \
+ debug_tree (tv); \
+   }  \
+}  
\
+  while (false)
+
+  if (t != tv)
+{
+  verify_match (TREE_CODE, t, tv);
+  verify_match (TYPE_MODE, t, tv);
+  verify_match (TYPE_SIZE, t, tv);
+  verify_match (TYPE_ALIGN, t, tv);
+  verify_match (TYPE_USER_ALIGN, t, tv);
+}
+
+  if (t != tc)
+verify_match (TREE_CODE, t, tc);
+#undef verify_match
+}
+
 /* Verify type T.  */

 void
@@ -13677,6 +13713,14 @@ verify_type (const_tree t)
 {
   bool error_found = false;
   tree mv = TYPE_MAIN_VARIANT (t);
+  tree ct = TYPE_CANONICAL (t);
+
+  if (OPAQUE_TYPE_P (t))
+{
+  verify_opaque_type (t, mv, ct);
+  return;
+}
+
   if (!mv)
 {
   error ("main variant is not defined");
@@ -13691,7 +13735,6 @@ verify_type (const_tree t)
   else if (t != mv && !verify_type_variant (t, mv))
 error_found = true;

-  tree ct = TYPE_CANONICAL (t);
   if (!ct)
 ;
   else if (TYPE_CANONICAL (ct) != ct)
--
2.27.0

RE: [PATCH v2, rs6000] Change insn condition from TARGET_64BIT to TARGET_POWERPC64 for VSX scalar extract/insert instructions

[HAO CHEN GUI via Gcc-patches]

On 7/9/2022 下午 10:25, Segher Boessenkool wrote:
> Hi!
> 
> On Wed, Sep 07, 2022 at 08:51:17AM -0500, Paul A. Clarke wrote:
>> On Tue, Sep 06, 2022 at 12:19:06PM -0500, Segher Boessenkool wrote:
>>> On Mon, Sep 05, 2022 at 02:36:30PM +0800, HAO CHEN GUI wrote:
 The return type of vec_ version built-ins are different than their 
 definition
 in PVIPR. In PVIPR, they're vector unsigned int or vector unsigned long 
 long.
 Shall we correct them?

   const vd __builtin_vsx_extract_exp_dp (vd);
 VEEDP xvxexpdp {}

   const vf __builtin_vsx_extract_exp_sp (vf);
 VEESP xvxexpsp {}

   const vd __builtin_vsx_extract_sig_dp (vd);
 VESDP xvxsigdp {}

   const vf __builtin_vsx_extract_sig_sp (vf);
 VESSP xvxsigsp {}
>>>
>>> Those are the vsx_ versions.  I'm not sure what you're asking.
>>>
>>> It won't be easy at all to change types from vector integer to vector
>>> float, it will break all over.  A compatibility nightmare.  It is better
>>> if you can show the current stuff cannot ever work, it's not a problem
>>> to replace it in that case.
>>
>> I think Hao Chen is concerned about the return types:
> 
> Yes, and so am I.
> 
   const vd __builtin_vsx_extract_exp_dp (vd);
 VEEDP xvxexpdp {}
>>
>> Per PVIPR, this should return vector unsigned long long ("vull" not "vd").
> 
> But changing that will make any existing code that now works, fail
> horribly.  Of course it is possible no such code exists :-)
> 
> What did this do before the builtin rewrite?
> 
> 
>  ~ - ~ - ~
> 
> 
> It looks like it did the right thing before, but that is just based on
> reading the code, I haven't actually tried it :-)
> 
> So, changing the vsx_ code here should be okay, because obviously no one
> is using it.  OTOH, why do we have those separately at all, why do they
> not just redirect to the canonical vec_ versions?  Or, can we just get
> rid of the vsx_ version completely?

In rs6000-overload.def, the vsx_ version built-ins are overridden to vec_
version. And the return types of vec_ version is inline with those defined
in PVIPR. So there should be no problem. Sorry for that.

[VEC_VEEDP, vec_extract_exp_dp, __builtin_vec_extract_exp_dp]
  vull __builtin_vec_extract_exp_dp (vd);
VEEDP  VEEDP_DEPR1

[VEC_VEESP, vec_extract_exp_sp, __builtin_vec_extract_exp_sp]
  vui __builtin_vec_extract_exp_sp (vf);
VEESP  VEESP_DEPR1

[VEC_VEE, vec_extract_exp, __builtin_vec_extract_exp]
  vui __builtin_vec_extract_exp (vf);
VEESP
  vull __builtin_vec_extract_exp (vd);
VEEDP

Thanks
Gui Haochen

[PATCH] Implement known/maybe fpclassify like API for frange.

[Aldy Hernandez via Gcc-patches]

This is what I have in mind for the fpclassify-like methods on the
current implementation.  I'll get to the removal of the tristates after
Cauldron.

As you mentioned, isnormal is kinda tricky, and likely to be confusing
for the user.  We can revisit it if it's important.

?? I assume maybe_inf() does not return true for NAN ??

Also, what are your thoughts on signbit?  Perhaps a method returning
true if we're sure, and the actual signbit result as a reference?

bool known_signbit (const frange &r, int &signbit);

How does this look?  I must say, the uses look much cleaner.
Aldy

gcc/ChangeLog:

* gimple-range-fold.cc
(fold_using_range::range_of_builtin_int_call): Use fpclassify like API.
* range-op-float.cc (finite_operand_p): Same.
(finite_operands_p): Same.
(foperator_lt::fold_range): Same.
(foperator_le::fold_range): Same.
(foperator_gt::fold_range): Same.
(foperator_ge::fold_range): Same.
(foperator_unordered::fold_range): Same.
(foperator_unordered::op1_range): Same.
(foperator_ordered::fold_range): Same.
* value-range.cc (frange::set_nan): Same.
(frange::set_signbit): Same.
(frange::union_): Same.
(frange::intersect): Same.
(frange::operator==): Same.
(frange::singleton_p): Same.
(frange::verify_range): Same.
(range_tests_nan): Same.
(range_tests_floats): Same.
* value-range.h(frange::known_finite): New.
(frange::maybe_inf): New.
(frange::known_inf): New.
(frange::maybe_nan): New.
(frange::known_nan): New.
---
 gcc/gimple-range-fold.cc |  2 +-
 gcc/range-op-float.cc| 26 ---
 gcc/value-range.cc   | 37 ++-
 gcc/value-range.h| 54 +++-
 4 files changed, 83 insertions(+), 36 deletions(-)

diff --git a/gcc/gimple-range-fold.cc b/gcc/gimple-range-fold.cc
index c9c7a2ccc70..47a1f49eb36 100644
--- a/gcc/gimple-range-fold.cc
+++ b/gcc/gimple-range-fold.cc
@@ -1031,7 +1031,7 @@ fold_using_range::range_of_builtin_int_call (irange &r, 
gcall *call,
  {
if (tmp.get_signbit ().varying_p ()
// FIXME: We don't support signed NANs yet.
-   || !tmp.get_nan ().no_p ())
+   || tmp.maybe_nan ())
  return false;
if (tmp.get_signbit ().yes_p ())
  r.set_nonzero (type);
diff --git a/gcc/range-op-float.cc b/gcc/range-op-float.cc
index 5fbbaa1fb36..0f928b6c098 100644
--- a/gcc/range-op-float.cc
+++ b/gcc/range-op-float.cc
@@ -167,7 +167,7 @@ frange_set_nan (frange &r, tree type)
 static inline bool
 finite_operand_p (const frange &op1)
 {
-  return flag_finite_math_only || op1.get_nan ().no_p ();
+  return flag_finite_math_only || !op1.maybe_nan ();
 }
 
 // Return TRUE if OP1 and OP2 are known to be free of NANs.
@@ -175,9 +175,7 @@ finite_operand_p (const frange &op1)
 static inline bool
 finite_operands_p (const frange &op1, const frange &op2)
 {
-  return (flag_finite_math_only
- || (op1.get_nan ().no_p ()
- && op2.get_nan ().no_p ()));
+  return flag_finite_math_only || (!op1.maybe_nan () && !op2.maybe_nan ());
 }
 
 // Floating version of relop_early_resolve that takes into account NAN
@@ -546,7 +544,7 @@ foperator_lt::fold_range (irange &r, tree type,
   else
r = range_true_and_false (type);
 }
-  else if (op1.get_nan ().yes_p () || op2.get_nan ().yes_p ())
+  else if (op1.known_nan () || op2.known_nan ())
 r = range_false (type);
   else
 r = range_true_and_false (type);
@@ -648,7 +646,7 @@ foperator_le::fold_range (irange &r, tree type,
   else
r = range_true_and_false (type);
 }
-  else if (op1.get_nan ().yes_p () || op2.get_nan ().yes_p ())
+  else if (op1.known_nan () || op2.known_nan ())
 r = range_false (type);
   else
 r = range_true_and_false (type);
@@ -742,7 +740,7 @@ foperator_gt::fold_range (irange &r, tree type,
   else
r = range_true_and_false (type);
 }
-  else if (op1.get_nan ().yes_p () || op2.get_nan ().yes_p ())
+  else if (op1.known_nan () || op2.known_nan ())
 r = range_false (type);
   else
 r = range_true_and_false (type);
@@ -844,7 +842,7 @@ foperator_ge::fold_range (irange &r, tree type,
   else
r = range_true_and_false (type);
 }
-  else if (op1.get_nan ().yes_p () || op2.get_nan ().yes_p ())
+  else if (op1.known_nan () || op2.known_nan ())
 r = range_false (type);
   else
 r = range_true_and_false (type);
@@ -927,10 +925,10 @@ foperator_unordered::fold_range (irange &r, tree type,
 relation_kind) const
 {
   // UNORDERED is TRUE if either operand is a NAN.
-  if (op1.get_nan ().yes_p () || op2.get_nan ().yes_p ())
+  if (op1.known_nan () || op2.known_nan ())
 r = range_true (type);
   // UNORDERED is FALSE if neither operand is a NAN.
-  else if (op1.ge