Re: [PATCH] testsuite: Fix mistransformed gcov

[Torbjorn SVENSSON via Gcc-patches]

Hi,

On 2022-11-16 03:11, Hans-Peter Nilsson wrote:

How was r13-2619-g34b9a03353d3fd "gcov: Respect triplet when looking
for gcov" tested?  I'm having a hard time believing it was tested with
a *cross-compiler* *in-build-tree*.  I think it was only tested for
the special-case of an installed cross-compiler; not even with a
native build exercising the false branch (see patch), considering that
a breaking typo ("}" vs "]") snuck by in the first revision, before
commit.


I was testing this in out-of-tree test with a cross-compiler (built for 
arm-none-eabi) running on Windows and Linux and just noticed the failure 
and (wrongly) assumed that all of the cases needed the transformation 
call as that's how other tools were handled.
The test systems used is are hosts that does not have any internet 
connection, so that's why I got a typo in the first patch when moving 
the fix to a system that did have an internet connection.

Sorry for the mess I caused!

Regarding the patch you propose; it looks good to me, but I'm not able 
to approve it.


Kind regards,
Torbjörn


I guess reviewers forgot to ask that, but it's really on the
submitter; it's a general requirement for patches to say how it was
tested.  Usually no more is needed than "tested with a cross-compiler
for ..., no regressions" (implying running twice and comparing results
before and after the patch).

In this case, when adjusting test-framework bits, a little more care
and mentioned details about how it was tested, would have been in
order.  It's likely it'd have shown that an uninstalled in-tree cross
(an IMHO more expected case) wasn't tested, which that patch broke for
the one gcov invocation that the testsuite does for cross-builds
(IIUC).

It can be said like this: I tested *this* patch as follows (all
directory names below manually redacted), showing no regressions and
fixing the regression for the in-tree cross build;

For a native build (x86_64, Debian 11):
- In the gcc build directory:
  make check RUNTESTFLAGS=gcov.exp

- In an empty new directory after native installation in /pre.
/gccsrc/top/contrib/test_installed --prefix=/pre gcov.exp

- Also, for good measure (mentioned somewhere in the installation
documentation) native:
for tool in gcc g++ ; do env PATH=/pre/bin:$PATH runtest \
  --tool $tool --srcdir=/gccsrc/top/gcc/testsuite gcov.exp; done

For a cris-elf cross:
- In the gcc build directory:
make check 'RUNTESTFLAGS=--target_board=cris-sim gcov.exp'

- In an empty new directory after installation in /pre.
/gccsrc/top/contrib/test_installed --with-gcc=/pre/bin/cris-elf-gcc \
  --with-g++=/pre/bin/cris-elf-g++ --with-gfortran=/pre/bin/cris-elf-gfortran \
  --target=cris-elf --target_board=cris-sim gcov.exp

Ok to commit?

brgds, H-P
PS. Beware that the proc name may be up for bikeshedding.

 8<  8<  8<  8< 

In commit r13-2619-g34b9a03353d3fd, [transform] was applied to all
invocations of gcov, for both out-of-tree and in-tree testing.
For in-tree cross builds, this means gcov was called as
"/path/to/gccobj/gcc/target-tuple-gcov" gcov-pr94029.c which is
incorrect, as it's there "/path/to/gccobj/gcc/gcov" until it's
installed.  This caused a testsuite failure, like:

Running /x/gcc/gcc/testsuite/gcc.misc-tests/gcov.exp ...
FAIL: gcc.misc-tests/gcov-pr94029.c gcov failed: spawn failed

To avoid cumbersome conditionals, use a dedicated new helper function.

gcc/testsuite:
* lib/gcc-dg.exp (gcc-transform-out-of-tree): New proc.
* g++.dg/gcov/gcov.exp, gcc.misc-tests/gcov.exp: Call
gcc-transform-out-of-tree instead of transform.
---
  gcc/testsuite/g++.dg/gcov/gcov.exp|  4 ++--
  gcc/testsuite/gcc.misc-tests/gcov.exp |  4 ++--
  gcc/testsuite/lib/gcc-dg.exp  | 13 +
  3 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/gcc/testsuite/g++.dg/gcov/gcov.exp 
b/gcc/testsuite/g++.dg/gcov/gcov.exp
index 04e7a0164865..c9f20958836b 100644
--- a/gcc/testsuite/g++.dg/gcov/gcov.exp
+++ b/gcc/testsuite/g++.dg/gcov/gcov.exp
@@ -24,9 +24,9 @@ global GXX_UNDER_TEST
  
  # Find gcov in the same directory as $GXX_UNDER_TEST.

  if { ![is_remote host] && [string match "*/*" [lindex $GXX_UNDER_TEST 0]] } {
-set GCOV [file dirname [lindex $GXX_UNDER_TEST 0]]/[transform gcov]
+set GCOV [file dirname [lindex $GXX_UNDER_TEST 
0]]/[gcc-transform-out-of-tree gcov]
  } else {
-set GCOV [transform gcov]
+set GCOV [gcc-transform-out-of-tree gcov]
  }
  
  # Initialize harness.

diff --git a/gcc/testsuite/gcc.misc-tests/gcov.exp 
b/gcc/testsuite/gcc.misc-tests/gcov.exp
index b8e9661aa537..90ceec46e0f0 100644
--- a/gcc/testsuite/gcc.misc-tests/gcov.exp
+++ b/gcc/testsuite/gcc.misc-tests/gcov.exp
@@ -24,9 +24,9 @@ global GCC_UNDER_TEST
  
  # For now find gcov in the same directory as $GCC_UNDER_TEST.

  if { ![is_remote host] && [string match "*/*" [lindex $GCC_UNDER_TEST 0]] } {
-set GCOV [file dirname [lindex $GCC_UNDER_TEST 0]]/[transform gcov]
+set 

Re: [PATCH] doc: Reword the description of -mrelax-cmpxchg-loop [PR 107676]

[Alexander Monakov via Gcc-patches]

On Wed, 16 Nov 2022, Hongyu Wang wrote:

> > When emitting a compare-and-swap loop for @ref{__sync Builtins}
> > and @ref{__atomic Builtins} lacking a native instruction, optimize
> > for the highly contended case by issuing an atomic load before the
> > @code{CMPXCHG} instruction, and using the @code{PAUSE} instruction
> > to save CPU power when restarting the loop.
> 
> Thanks for the correction, it looks quite clear now! Here is the
> updated patch, ok for trunk?

Please use 'git commit --author' to indicate authorship of the patch
(or simply let me push it once approved).

Jonathan, please let us know if the above wording looks fine to you?
Mainly I'm asking if '... and using' or '... and use' is easier to read.

Alexander

[PATCH] Fix typo in gimple_fold_partial_load_store_mem_ref

[Kewen.Lin via Gcc-patches]

Hi,

As Robin spotted, my recent commit r13-3716 caused an ICE
on s390 if vector access with length is enabled there (his
patch for the enablement hasn't been committed yet).  The
failure is caused by one stupid typo, the bias on s390 is
-1, so the assertion should use tree_fits_shwi_p rather
than tree_fits_uhwi_p.  Thanks for Robin's catching.

I just reproduced the ICE and verified the fix worked fine
with a cross build, the optimized dump against the test case
gcc.target/powerpc/pr107412.c looked expected.

Is it ok for trunk?

BR,
Kewen
-
gcc/ChangeLog:

* gimple-fold.cc (gimple_fold_partial_load_store_mem_ref): Use
tree_fits_shwi_p rather than tree_fits_uhwi_p as bias is signed.
---
 gcc/gimple-fold.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/gimple-fold.cc b/gcc/gimple-fold.cc
index 0a212e6d0d4..f8a1875ea3e 100644
--- a/gcc/gimple-fold.cc
+++ b/gcc/gimple-fold.cc
@@ -5392,7 +5392,7 @@ gimple_fold_partial_load_store_mem_ref (gcall *call, tree 
vectype, bool mask_p)
return NULL_TREE;
   unsigned int nargs = gimple_call_num_args (call);
   tree bias = gimple_call_arg (call, nargs - 1);
-  gcc_assert (tree_fits_uhwi_p (bias));
+  gcc_assert (tree_fits_shwi_p (bias));
   tree biased_len = int_const_binop (MINUS_EXPR, basic_len, bias);
   unsigned int len = tree_to_uhwi (biased_len);
   unsigned int vect_len
--
2.25.1

[PATCH 2/2] rs6000: Refine integer comparison handlings in rs6000_emit_vector_compare

[Kewen.Lin via Gcc-patches]

Hi,

The current handlings in rs6000_emit_vector_compare is a bit
complicated to me, especially after we emit vector float
comparison insn with the given code directly.  This patch is
to refine the handlings for vector integer comparison operators,
it becomes not recursive, and we don't need the helper function
rs6000_emit_vector_compare_inner any more.

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

I'm going to push this later this week if no objections.

BR,
Kewen
-
gcc/ChangeLog:

* config/rs6000/rs6000.cc (rs6000_emit_vector_compare_inner): Remove.
(rs6000_emit_vector_compare): Refine it by directly using the reversed
or swapped code, to avoid the recursion.
---
 gcc/config/rs6000/rs6000.cc | 159 
 1 file changed, 34 insertions(+), 125 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index 56db12f08a0..21f4cda7b80 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -15639,169 +15639,78 @@ output_cbranch (rtx op, const char *label, int 
reversed, rtx_insn *insn)
   return string;
 }

-/* Return insn for VSX or Altivec comparisons.  */
-
-static rtx
-rs6000_emit_vector_compare_inner (enum rtx_code code, rtx op0, rtx op1)
-{
-  rtx mask;
-  machine_mode mode = GET_MODE (op0);
-
-  switch (code)
-{
-default:
-  break;
-
-case GE:
-  if (GET_MODE_CLASS (mode) == MODE_VECTOR_INT)
-   return NULL_RTX;
-  /* FALLTHRU */
-
-case EQ:
-case GT:
-case GTU:
-  mask = gen_reg_rtx (mode);
-  emit_insn (gen_rtx_SET (mask, gen_rtx_fmt_ee (code, mode, op0, op1)));
-  return mask;
-}
-
-  return NULL_RTX;
-}
-
 /* Emit vector compare for operands OP0 and OP1 using code RCODE.
-   DMODE is expected destination mode. This is a recursive function.  */
+   DMODE is expected destination mode.  */

 static rtx
 rs6000_emit_vector_compare (enum rtx_code rcode,
rtx op0, rtx op1,
machine_mode dmode)
 {
-  rtx mask;
   gcc_assert (VECTOR_UNIT_ALTIVEC_OR_VSX_P (dmode));
   gcc_assert (GET_MODE (op0) == GET_MODE (op1));
+  rtx mask = gen_reg_rtx (dmode);

   /* In vector.md, we support all kinds of vector float point
  comparison operators in a comparison rtl pattern, we can
  just emit the comparison rtx insn directly here.  Besides,
  we should have a centralized place to handle the possibility
- of raising invalid exception.  */
-  if (GET_MODE_CLASS (dmode) == MODE_VECTOR_FLOAT)
+ of raising invalid exception.  Also emit directly for vector
+ integer comparison operators EQ/GT/GTU.  */
+  if (GET_MODE_CLASS (dmode) == MODE_VECTOR_FLOAT
+  || rcode == EQ
+  || rcode == GT
+  || rcode == GTU)
 {
-  mask = gen_reg_rtx (dmode);
   emit_insn (gen_rtx_SET (mask, gen_rtx_fmt_ee (rcode, dmode, op0, op1)));
   return mask;
 }

   bool swap_operands = false;
-  bool try_again = false;
-
-  /* See if the comparison works as is.  */
-  mask = rs6000_emit_vector_compare_inner (rcode, op0, op1);
-  if (mask)
-return mask;
+  bool need_invert = false;
+  enum rtx_code code = UNKNOWN;

   switch (rcode)
 {
 case LT:
-  rcode = GT;
-  swap_operands = true;
-  try_again = true;
-  break;
 case LTU:
-  rcode = GTU;
+  code = swap_condition (rcode);
   swap_operands = true;
-  try_again = true;
   break;
 case NE:
-  /* Invert condition and try again.
-e.g., A != B becomes ~(A==B).  */
-  {
-   enum rtx_code rev_code;
-   enum insn_code nor_code;
-   rtx mask2;
-
-   rev_code = reverse_condition_maybe_unordered (rcode);
-   if (rev_code == UNKNOWN)
- return NULL_RTX;
-
-   nor_code = optab_handler (one_cmpl_optab, dmode);
-   if (nor_code == CODE_FOR_nothing)
- return NULL_RTX;
-
-   mask2 = rs6000_emit_vector_compare (rev_code, op0, op1, dmode);
-   if (!mask2)
- return NULL_RTX;
-
-   mask = gen_reg_rtx (dmode);
-   emit_insn (GEN_FCN (nor_code) (mask, mask2));
-   return mask;
-  }
+case LE:
+case LEU:
+  code = reverse_condition (rcode);
+  need_invert = true;
   break;
 case GE:
+  code = GT;
+  swap_operands = true;
+  need_invert = true;
+  break;
 case GEU:
-case LE:
-case LEU:
-  /* Try GT/GTU/LT/LTU OR EQ */
-  {
-   rtx c_rtx, eq_rtx;
-   enum insn_code ior_code;
-   enum rtx_code new_code;
-
-   switch (rcode)
- {
- case  GE:
-   new_code = GT;
-   break;
-
- case GEU:
-   new_code = GTU;
-   break;
-
- case LE:
-   new_code = LT;
-   break;
-
- case LEU:
-   new_code = LTU;
-   break;
-
- default:
-   gcc_unreachable ();
- }
-
-   ior_code = 

[PATCH 1/2] rs6000: Emit vector fp comparison directly in rs6000_emit_vector_compare

[Kewen.Lin via Gcc-patches]

Hi,

All kinds of vector float comparison operators have been
supported in one rtl comparison pattern as vector.md, we can
just emit an rtx comparison insn with the given comparison
operator in function rs6000_emit_vector_compare instead of
checking and handling the reverse condition cases.

This is also for a subsequent patch to deal with some
comparison operators under trapping math enabled or disabled,
so it's important to have one centralized place for vector
float comparison handlings for better maintenance.

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

I'm going to push this later this week if no objections.

BR,
Kewen
-

gcc/ChangeLog:

* config/rs6000/rs6000.cc (rs6000_emit_vector_compare_inner): Remove
float only comparison operators.
(rs6000_emit_vector_compare): Emit vector comparison insn directly for
float modes.
---
 gcc/config/rs6000/rs6000.cc | 26 +++---
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index 635aced6105..56db12f08a0 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -15660,10 +15660,6 @@ rs6000_emit_vector_compare_inner (enum rtx_code code, 
rtx op0, rtx op1)
 case EQ:
 case GT:
 case GTU:
-case ORDERED:
-case UNORDERED:
-case UNEQ:
-case LTGT:
   mask = gen_reg_rtx (mode);
   emit_insn (gen_rtx_SET (mask, gen_rtx_fmt_ee (code, mode, op0, op1)));
   return mask;
@@ -15681,12 +15677,24 @@ rs6000_emit_vector_compare (enum rtx_code rcode,
machine_mode dmode)
 {
   rtx mask;
-  bool swap_operands = false;
-  bool try_again = false;
-
   gcc_assert (VECTOR_UNIT_ALTIVEC_OR_VSX_P (dmode));
   gcc_assert (GET_MODE (op0) == GET_MODE (op1));

+  /* In vector.md, we support all kinds of vector float point
+ comparison operators in a comparison rtl pattern, we can
+ just emit the comparison rtx insn directly here.  Besides,
+ we should have a centralized place to handle the possibility
+ of raising invalid exception.  */
+  if (GET_MODE_CLASS (dmode) == MODE_VECTOR_FLOAT)
+{
+  mask = gen_reg_rtx (dmode);
+  emit_insn (gen_rtx_SET (mask, gen_rtx_fmt_ee (rcode, dmode, op0, op1)));
+  return mask;
+}
+
+  bool swap_operands = false;
+  bool try_again = false;
+
   /* See if the comparison works as is.  */
   mask = rs6000_emit_vector_compare_inner (rcode, op0, op1);
   if (mask)
@@ -15705,10 +15713,6 @@ rs6000_emit_vector_compare (enum rtx_code rcode,
   try_again = true;
   break;
 case NE:
-case UNLE:
-case UNLT:
-case UNGE:
-case UNGT:
   /* Invert condition and try again.
 e.g., A != B becomes ~(A==B).  */
   {
--
2.27.0

[committed] range-op-float: Fix up float_binary_op_range_finish [PR107668]

[Jakub Jelinek via Gcc-patches]

Hi!

The following testcase ICEs, because when !HONOR_NANS but
HONOR_SIGNED_ZEROS, if we see
lhs = op1 * op2;
and know that lhs is [-0.0, 0.0] and op2 is [0.0, 0.0], the
division of these two yields UNDEFINED and clear_nan () on it
fails an assert.  With HONOR_NANS it would actually result in
a known NAN, but when NANs aren't honored, we clear the NAN bits.
Now, for the above case we actually don't know anything about
the op1 range (except that it isn't a NAN/INF because of
!HONOR_NANS !HONOR_INFINITIES), so I think the best is just
to return VARYING for the case we get UNDEFINED as well.

If we want, the op[12]_range methods perhaps can handle the
corner cases earlier separately, say for
lhs [0.0, 0.0] and op2 [0.0, 0.0] when HONOR_SIGNED_ZEROS this
would be just [0.0, MAX].

Bootstrapped/regtested on x86_64-linux and i686-linux, preapproved by
Aldy in the PR, committed to trunk.

2022-11-16  Jakub Jelinek  

PR tree-optimization/107668
* range-op-float.cc (float_binary_op_range_finish): Set VARYING
also when r is UNDEFINED.

* gcc.dg/ubsan/pr107668.c: New test.

--- gcc/range-op-float.cc.jj2022-11-14 19:33:32.514881313 +0100
+++ gcc/range-op-float.cc   2022-11-15 09:25:57.956137343 +0100
@@ -1891,8 +1891,9 @@ float_binary_op_range_finish (bool ret,
   // or the reverse operation introduced a known NAN.
   // Say for lhs = op1 * op2 if lhs is [-0, +0] and op2 is too,
   // 0 / 0 is known NAN.  Just punt in that case.
+  // If NANs aren't honored, we get for 0 / 0 UNDEFINED, so punt as well.
   // Or if lhs is a known NAN, we also don't know anything.
-  if (r.known_isnan () || lhs.known_isnan ())
+  if (r.known_isnan () || lhs.known_isnan () || r.undefined_p ())
 {
   r.set_varying (type);
   return true;
--- gcc/testsuite/gcc.dg/ubsan/pr107668.c.jj2022-11-15 09:24:40.281189629 
+0100
+++ gcc/testsuite/gcc.dg/ubsan/pr107668.c   2022-11-15 09:24:40.281189629 
+0100
@@ -0,0 +1,12 @@
+/* PR tree-optimization/107668 */
+/* { dg-do compile } */
+/* { dg-options "-ffast-math -fno-associative-math 
-fsanitize=float-cast-overflow -fno-guess-branch-probability -fsigned-zeros" } 
*/
+
+_Complex int c;
+int i;
+
+void
+foo (void)
+{
+  c /= (_Complex) i;
+}

Jakub

Re: [PATCH][i386]: Update ix86_can_change_mode_class target hook to accept QImode conversions

[Hongtao Liu via Gcc-patches]

On Mon, Nov 14, 2022 at 10:14 AM Hongtao Liu  wrote:
>
> On Fri, Nov 11, 2022 at 10:47 PM Tamar Christina via Gcc-patches
>  wrote:
> >
> > Hi All,
> >
> > The current i386 implementation of the TARGET_CAN_CHANGE_MODE_CLASS is 
> > currently
> > not useful before re-alloc.
> >
> > In particular before regalloc optimization passes query the hook using 
> > ALL_REGS,
> > but because of the
> >
> >   if (MAYBE_FLOAT_CLASS_P (regclass))
> >   return false;
> >
> > The hook returns false for all modes, even integer ones because ALL_REGS
> > overlaps with floating point regs.
> >
> > The vector permute fallback cases used to unconditionally convert vector 
> > integer
> > permutes to vector QImode ones as a fallback plan.  This is incorrect and 
> > can
> > result in incorrect code if the target doesn't support this conversion.
> >
> > To fix this some more checks were added, however that ended up introducing 
> > ICEs
> > in the i386 backend because e.g. the hook would reject conversions between 
> > modes
> > like V2TImode and V32QImode.
> >
> > My understanding is that for x87 we don't want to allow floating point
> > conversions, but integers are fine.  So I have modified the check such that 
> > it
> > also checks the modes, not just the register class groups.
> >
> > The second part of the code is needed because now that integer modes aren't
> > uniformly rejected the i386 backend trigger further optimizations.  However 
> > the
> > backend lacks instructions to deal with canonical RTL representations of
> > certain instructions.  for instance the back-end seems to prefer vec_select > > 0
> > instead of subregs.
> >
> > So to prevent the canonicalization I reject integer modes when the sizes of 
> > to
This should not be right, we still want something like (subreg:SI (reg:V4SI))
> > and from don't match and when we would have exited with false previously.
> >
> > This fixes all the ICEs and codegen regressions, but perhaps an x86 
> > maintainer
> > should take a deeper look at this hook implementation.
> >
> > Bootstrapped Regtested on x86_64-pc-linux-gnu and no issues.
> >
> > Ok for master?
> >
> > Thanks,
> > Tamar
> >
> > gcc/ChangeLog:
> >
> > * config/i386/i386.cc (ix86_can_change_mode_class): Update the 
> > target
> > hook.
> >
> > --- inline copy of patch --
> > diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> > index 
> > c4d0e36e9c0a2256f5dde1f4dc021c0328aa0cba..477dd007ea80272680751b61e35cc3eec79b66c3
> >  100644
> > --- a/gcc/config/i386/i386.cc
> > +++ b/gcc/config/i386/i386.cc
> > @@ -19682,7 +19682,15 @@ ix86_can_change_mode_class (machine_mode from, 
> > machine_mode to,
> >
> >/* x87 registers can't do subreg at all, as all values are reformatted
> >   to extended precision.  */
> > -  if (MAYBE_FLOAT_CLASS_P (regclass))
> > +  if (MAYBE_FLOAT_CLASS_P (regclass)
> > +  && VALID_FP_MODE_P (from)
> > +  && VALID_FP_MODE_P (to))
> > +return false;
> This change looks reasonable since only VALID_FP_MODE_P will be
> allocated to FLOAT_CLASS.
> > +
> > +  /* Reject integer modes if the sizes aren't the same.  It would have
> > + normally exited above.  */
> > +  if (MAYBE_FLOAT_CLASS_P (regclass)
> > +  && GET_MODE_SIZE (from) != GET_MODE_SIZE (to))
> >  return false;
> Do you have a case(or a patch so I can reproduce the regression
> myself) to indicate the regression, so I can have a deep look.
This is not right, we still want something like (subreg:SI
(reg:V4SI)). I'm trying to adjust all those vec_select to subregs, and
it may take some time. We also need to adjust modes_tieable_p to
prevent high rtx_cost for subreg which will prevent insns being
combined. x86 is conservative on both can_change_mode_class and
modes_tieable_p.
I'm a bit worried that these changes are a bit big for stage3, let me
try it first.
> >
> >if (MAYBE_SSE_CLASS_P (regclass) || MAYBE_MMX_CLASS_P (regclass))
> >
> >
> >
> >
> > --
>
>
>
> --
> BR,
> Hongtao



-- 
BR,
Hongtao

Re: [PATCH] c++, v2: Implement C++23 P2647R1 - Permitting static constexpr variables in constexpr functions

[Jakub Jelinek via Gcc-patches]

On Wed, Nov 16, 2022 at 12:27:02AM +, Jonathan Wakely wrote:
> On Tue, 15 Nov 2022 at 23:50, Jakub Jelinek  wrote:
> >
> > On Tue, Nov 15, 2022 at 06:36:38PM -0500, Jason Merrill wrote:
> > > > Here is an updated patch that passed bootstrap/regtest, the only
> > > > change is another testcase tweak.
> > > >
> > > > 2022-11-13  Jakub Jelinek  
> > > >
> > > > gcc/c-family/
> > > > * c-cppbuiltin.cc (c_cpp_builtins): Bump __cpp_constexpr
> > > > value from 202207L to 202211L.
> > > > gcc/cp/
> > > > * constexpr.cc (cxx_eval_constant_expression): Implement C++23
> > > > P2647R1 - Permitting static constexpr variables in constexpr 
> > > > functions.
> > > > Allow decl_maybe_constant_var_p static or thread_local vars for
> > > > C++23.
> > >
> > > This was accepted as a DR, so it shouldn't be limited to C++23 mode.
> > > Certainly it should be allowed in C++20 mode; I don't have a strong 
> > > opinion
> > > about C++14/17.  Jonathan, do you?
> >
> > How will a feature with feature test macro with multiple values work as DR?
> > Or will everything but the macro be treated as a DR (so __cpp_constexpr >=
> > 202211L only for C++23)?
> 
> Yes, I think so. We just won't be able to advertise this feature as
> supported in C++20.

Ok.  But there is another issue, the
https://eel.is/c++draft/expr.const#5.2
spot that P2647R1 is changing didn't exist in C++20, it was only added with
P2242R3.  So, if one would treat P2647R1 as a DR for C++20, one has to come up 
with
a different standard modification.
Probably change the last bullet of:
[dcl.constexpr]/3
its function-body shall not enclose

a goto statement,
an identifier label,
a definition of a variable of non-literal type or of static or thread 
storage duration.
to
a definition of a variable of non-literal type or of a non-constexpr
  variable of static or thread storage duration.
or so.

Jakub

Re: [PATCH] Fix gdb FilteringTypePrinter (again)

[François Dumont via Gcc-patches]

On 15/11/22 17:17, Jonathan Wakely wrote:

On 06/10/22 19:38 +0200, François Dumont wrote:

Hi

Looks like the previous patch was not enough. When using it in the
context of a build without dual abi and versioned namespace I started
having failures again. I guess I hadn't rebuild everything properly.

This time I think the problem was in those lines:

    if self.type_obj == type_obj:
    return strip_inline_namespaces(self.name)

I've added a call to gdb.types.get_basic_type so that we do not compare
a type with its typedef.

Thanks for the pointer to the doc !

Doing so I eventually use your code Jonathan to make FilteringTypeFilter
more specific to a given instantiation.

    libstdc++: Fix gdb FilteringTypePrinter

    Once we found a matching FilteringTypePrinter instance we look for
the associated
    typedef and check that the returned Python Type is equal to the
Type to recognize.
    But gdb Python Type includes properties to distinguish a typedef
from the actual
    type. So use gdb.types.get_basic_type to check if we are indeed on
the same type.

    Additionnaly enhance FilteringTypePrinter matching mecanism by
introducing targ1 that,
    if not None, will be used as the 1st template parameter.

    libstdc++-v3/ChangeLog:

    * python/libstdcxx/v6/printers.py (FilteringTypePrinter):
Rename 'match' field
    'template'. Add self.targ1 to specify the first template
parameter of the instantiation
    to match.
    (add_one_type_printer): Add targ1 optional parameter,
default to None.
    Use gdb.types.get_basic_type to compare the type to
recognize and the type
    returned from the typedef lookup.
    (register_type_printers): Adapt calls to 
add_one_type_printers.


Tested under Linux x86_64 normal, version namespace with or without dual
abi.

François

diff --git a/libstdc++-v3/python/libstdcxx/v6/printers.py 
b/libstdc++-v3/python/libstdcxx/v6/printers.py

index 0fa7805183e..52339b247d8 100644
--- a/libstdc++-v3/python/libstdcxx/v6/printers.py
+++ b/libstdc++-v3/python/libstdcxx/v6/printers.py
@@ -2040,62 +2040,72 @@ def add_one_template_type_printer(obj, name, 
defargs):


class FilteringTypePrinter(object):
    r"""
-    A type printer that uses typedef names for common template 
specializations.
+    A type printer that uses typedef names for common template 
instantiations.


    Args:
-    match (str): The class template to recognize.
+    template (str): The class template to recognize.
    name (str): The typedef-name that will be used instead.
+    targ1 (str): The first template argument.
+    If arg1 is provided (not None), only template 
instantiations with this type
+    as the first template argument, e.g. if 
template='basic_string

-    Checks if a specialization of the class template 'match' is the 
same type
+    Checks if an instantiation of the class template 'template' is 
the same type

    as the typedef 'name', and prints it as 'name' instead.

-    e.g. if an instantiation of std::basic_istream is the same 
type as
+    e.g. for template='basic_istream', name='istream', if any 
instantiation of
+    std::basic_istream is the same type as std::istream then 
print it as

+    std::istream.
+
+    e.g. for template='basic_istream', name='istream', targ1='char', 
if any

+    instantiation of std::basic_istream is the same type as
    std::istream then print it as std::istream.
    """


These are template specializations, not instantiations. Please undo
the changes to the comments, because the comments are 100% correct
now, and would become wrong with this patch.

template struct foo { };
using F = foo; // #1
template struct foo { }; // #2
template<> struct foo { }; // #3

#1 is a *specialization* of the class template foo. It is
*instantiated* when you construct one or depend on its size, or its
members.
#2 is a *partial specialization* and #3 is an explicit specialization.
But #1 is a speclialization, not an instantiation.

Instantiation is a process that happens during compilation. A
specialization is a type (or function, or variable) generated from a
template by substituting arguments for the template parameters. The
python type printer matches specializations.


Lesson learned, thanks.

Maybe comment on line 169 is wrong then. I think there is a clue in the 
function name 'is_specialization_of' :-)






-    def __init__(self, match, name):
-    self.match = match
+    def __init__(self, template, name, targ1):


Is there a reason to require targ1 here, instead of making it
optional, by using =None as the default?


In your original, and I know untested, proposal it was not working.

The function add_one_type_printer was missing to pass its targ1 
parameter to the FilteringTypePrinter ctor but thanks to the default 
value it was un-noticed by the interpreter. So I removed it as useless 
and redundant with this function default value.







+    

Re: [rs6000, patch] Enable have_cbranchcc4 on rs6000

[HAO CHEN GUI via Gcc-patches]

Hi David,
  I found definition of the operands in 'cbranch'. The argumnets matters.
I will create a new expand pattern for cbranchcc4. Thanks a lot for your
comments.

'cbranchmode4’
Conditional branch instruction combined with a compare instruction.
Operand 0 is a comparison operator. Operand 1 and operand 2 are the
first and second operands of the comparison, respectively. Operand 3
is the code_label to jump to.

Gui Haochen
Thanks

在 2022/11/16 11:04, David Edelsohn 写道:
> It's great to add cbranchcc4 to the Power port where it definitely was an 
> omission, but adapting *cbranch for that purpose is the wrong approach.  The 
> changes to the pattern are incorrect because they are covering up a 
> difference in ordering of the operands.  One can argue that the named pattern 
> only enables the functionality in ifcvt and the pattern otherwise is used in 
> its previous role.  But this is a Frankenstein monster approach.  You're 
> trying to twist the existing pattern so that it triggers as cbranchcc4, but 
> creating a pattern that messes up its arguments and only works because the 
> new, named pattern never is called.  This is too ugly.  Please fix.

Re: [PATCH] doc: Reword the description of -mrelax-cmpxchg-loop [PR 107676]

[Hongyu Wang via Gcc-patches]

> When emitting a compare-and-swap loop for @ref{__sync Builtins}
> and @ref{__atomic Builtins} lacking a native instruction, optimize
> for the highly contended case by issuing an atomic load before the
> @code{CMPXCHG} instruction, and using the @code{PAUSE} instruction
> to save CPU power when restarting the loop.

Thanks for the correction, it looks quite clear now! Here is the
updated patch, ok for trunk?

Alexander Monakov via Gcc-patches 
于2022年11月15日周二 21:59写道：
>
>
> On Tue, 15 Nov 2022, Jonathan Wakely wrote:
>
> > > How about the following:
> > >
> > > When emitting a compare-and-swap loop for @ref{__sync Builtins}
> > > and @ref{__atomic Builtins} lacking a native instruction, optimize
> > > for the highly contended case by issuing an atomic load before the
> > > @code{CMPXCHG} instruction, and invoke the @code{PAUSE} instruction
> > > when restarting the loop.
> >
> > That's much better, thanks. My only remaining quibble would be that
> > "invoking" an instruction seems only marginally better than running
> > one. Emitting? Issuing? Using? Adding?
>
> Right, it should be 'using'; let me also add 'to save CPU power':
>
> When emitting a compare-and-swap loop for @ref{__sync Builtins}
> and @ref{__atomic Builtins} lacking a native instruction, optimize
> for the highly contended case by issuing an atomic load before the
> @code{CMPXCHG} instruction, and using the @code{PAUSE} instruction
> to save CPU power when restarting the loop.
>
> Alexander
From e82f3e03115480ac3d055819658a107249932c65 Mon Sep 17 00:00:00 2001
From: Hongyu Wang 
Date: Tue, 15 Nov 2022 11:16:17 +0800
Subject: [PATCH] doc: Reword the description of -mrelax-cmpxchg-loop [PR
 107676]

gcc/ChangeLog:

	PR target/107676
	* doc/invoke.texi: Reword the description of
	-mrelax-cmpxchg-loop.
---
 gcc/doc/invoke.texi | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 40f667a630a..bcbe3a7e420 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -33805,10 +33805,11 @@ registers.
 
 @item -mrelax-cmpxchg-loop
 @opindex mrelax-cmpxchg-loop
-Relax cmpxchg loop by emitting an early load and compare before cmpxchg,
-execute pause if load value is not expected. This reduces excessive
-cachline bouncing when and works for all atomic logic fetch builtins
-that generates compare and swap loop.
+When emitting a compare-and-swap loop for @ref{__sync Builtins}
+and @ref{__atomic Builtins} lacking a native instruction, optimize
+for the highly contended case by issuing an atomic load before the
+@code{CMPXCHG} instruction, and using the @code{PAUSE} instruction
+to save CPU power when restarting the loop.
 
 @item -mindirect-branch=@var{choice}
 @opindex mindirect-branch
-- 
2.18.1

Re: [PATCH] libstdc++: Fix stream initialization with static library [PR107701]

[Patrick Palka via Gcc-patches]

On Tue, 15 Nov 2022, Patrick Palka wrote:

> When linking with a static library, the linker seems to exclude a
> constituent .o object (including its global initializers) if nothing
> from it is referenced by the program (unless e.g. --whole-archive is
> used).  This behavior breaks iostream when linking with static libstdc++.a
> (on systems that support init priorities) because we're defining the
> global initializer for the standard stream objects in a separate TU
> (ios_init.cc) from the stream objects definitions (globals_io.cc).
> 
> Thus in order to ensure that the global initializer for the standard
> stream objects doesn't get wrongly dropped when statically linking,
> we need to perform the initialization from the same TU that actually
> defines the stream objects.
> 
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?

v2 with more comment fixes/additions:

-- >8 --

Subject: [PATCH] libstdc++: Fix stream initialization with static library
 [PR107701]

When linking with a static library, the linker seems to discard a
constituent .o object (including its global initializers) if nothing
from it is referenced by the program (unless e.g. --whole-archive is
used).  This behavior breaks iostream when linking with static libstdc++.a
(on systems that support init priorities) because we define the global
initializer for the standard stream objects in a separate TU (ios_init.cc)
from the stream objects definitions (globals_io.cc).

Thus in order to ensure that the global initializer for the standard
stream objects doesn't get wrongly dropped when statically linking,
we need to perform the initialization from the same TU that actually
defines the stream objects.

Tested on x86_64-pc-linux-gnu, does this look OK for trunk?

PR libstdc++/107701

libstdc++-v3/ChangeLog:

* include/std/iostream (__ioinit): Adjust comment.
* src/c++98/globals_io.cc: Include "io_base_init.h" here
instead of ...
* src/c++98/ios_init.cc: ... here.
* src/c++98/ios_base_init.h (__ioinit): Extend comment.
* testsuite/17_intro/static.cc: Run the test as well.
---
 libstdc++-v3/include/std/iostream | 2 +-
 libstdc++-v3/src/c++98/globals_io.cc  | 2 ++
 libstdc++-v3/src/c++98/ios_base_init.h| 1 +
 libstdc++-v3/src/c++98/ios_init.cc| 2 --
 libstdc++-v3/testsuite/17_intro/static.cc | 2 +-
 5 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/libstdc++-v3/include/std/iostream 
b/libstdc++-v3/include/std/iostream
index ff78e1cfb87..0c62e9aeb7f 100644
--- a/libstdc++-v3/include/std/iostream
+++ b/libstdc++-v3/include/std/iostream
@@ -74,7 +74,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   // For construction of filebuffers for cout, cin, cerr, clog et. al.
   // When the init_priority attribute is usable, we do this initialization
-  // in the compiled library instead (src/c++98/ios_init.cc).
+  // in the compiled library instead (src/c++98/globals_io.cc).
 #if !__has_attribute(__init_priority__)
   static ios_base::Init __ioinit;
 #endif
diff --git a/libstdc++-v3/src/c++98/globals_io.cc 
b/libstdc++-v3/src/c++98/globals_io.cc
index 04fecb22aeb..bfd808b5bbd 100644
--- a/libstdc++-v3/src/c++98/globals_io.cc
+++ b/libstdc++-v3/src/c++98/globals_io.cc
@@ -69,6 +69,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   fake_wostream wclog;
 #endif
 
+#include "ios_base_init.h"
+
 _GLIBCXX_END_NAMESPACE_VERSION
 } // namespace
 
diff --git a/libstdc++-v3/src/c++98/ios_base_init.h 
b/libstdc++-v3/src/c++98/ios_base_init.h
index 1c71038f4a1..b600ec3298e 100644
--- a/libstdc++-v3/src/c++98/ios_base_init.h
+++ b/libstdc++-v3/src/c++98/ios_base_init.h
@@ -7,6 +7,7 @@
 // sufficiently early (so that it happens before any other global
 // constructor when statically linking with libstdc++.a), instead of
 // doing so in (each TU that includes) .
+// This needs to be done in the same TU that defines the stream objects.
 #if __has_attribute(init_priority)
 static ios_base::Init __ioinit __attribute__((init_priority(90)));
 #endif
diff --git a/libstdc++-v3/src/c++98/ios_init.cc 
b/libstdc++-v3/src/c++98/ios_init.cc
index 4016fcab785..1b5132f1c2d 100644
--- a/libstdc++-v3/src/c++98/ios_init.cc
+++ b/libstdc++-v3/src/c++98/ios_init.cc
@@ -75,8 +75,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   extern wostream wclog;
 #endif
 
-#include "ios_base_init.h"
-
   ios_base::Init::Init()
   {
 if (__gnu_cxx::__exchange_and_add_dispatch(&_S_refcount, 1) == 0)
diff --git a/libstdc++-v3/testsuite/17_intro/static.cc 
b/libstdc++-v3/testsuite/17_intro/static.cc
index ffa7ecb7077..a0d6ed081f8 100644
--- a/libstdc++-v3/testsuite/17_intro/static.cc
+++ b/libstdc++-v3/testsuite/17_intro/static.cc
@@ -1,4 +1,4 @@
-// { dg-do link { target c++11 } }
+// { dg-do run { target c++11 } }
 // { dg-require-static-libstdcxx }
 // { dg-options "-static-libstdc++" }
 
-- 
2.38.1.436.geea7033409

Re: [PATCHv2] Use toplevel configure for GMP and MPFR for gdb

[Jeff Law via Gcc-patches]

On 11/10/22 12:05, apinski--- via Gcc-patches wrote:

From: Andrew Pinski 

This patch uses the toplevel configure parts for GMP/MPFR for
gdb. The only thing is that gdb now requires MPFR for building.
Before it was a recommended but not required library.
Also this allows building of GMP and MPFR with the toplevel
directory just like how it is done for GCC.
We now error out in the toplevel configure of the version
of GMP and MPFR that is wrong.

OK after GDB 13 branches? Build gdb 3 ways:
with GMP and MPFR in the toplevel (static library used at that point for both)
With only MPFR in the toplevel (GMP distro library used and MPFR built from 
source)
With neither GMP and MPFR in the toplevel (distro libraries used)

Changes from v1:
* Updated gdb/README and gdb/doc/gdb.texinfo.
* Regenerated using unmodified autoconf-2.69

Thanks,
Andrew Pinski

ChangeLog:
* Makefile.def: Add configure-gdb dependencies
on all-gmp and all-mpfr.
* configure.ac: Split out MPC checking from MPFR.
Require GMP and MPFR if the gdb directory exist.
* Makefile.in: Regenerate.
* configure: Regenerate.

gdb/ChangeLog:

PR bug/28500
* configure.ac: Remove AC_LIB_HAVE_LINKFLAGS
for gmp and mpfr.
Use GMPLIBS and GMPINC which is provided by the
toplevel configure.
* Makefile.in (LIBGMP, LIBMPFR): Remove.
(GMPLIBS, GMPINC): Add definition.
(INTERNAL_CFLAGS_BASE): Add GMPINC.
(CLIBS): Exchange LIBMPFR and LIBGMP
for GMPLIBS.
* target-float.c: Make the code conditional on
HAVE_LIBMPFR unconditional.
* top.c: Remove code checking HAVE_LIBMPFR.
* configure: Regenerate.
* config.in: Regenerate.
* README: Update GMP/MPFR section of the config
options.
* doc/gdb.texinfo: Likewise.


If the GDB folks confirm they want this behavior, then the toplevel bits 
are fine.


Jeff

Re: [PATCH v4] RISC-V: Add support for inlining subword atomic operations

[Jeff Law via Gcc-patches]

On 10/28/22 10:55, David Abdurachmanov via Gcc-patches wrote:

On Fri, Sep 2, 2022 at 1:09 PM Kito Cheng via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:


LGTM with minor comments, it's time to move forward, thanks Patrick and
Palmer.


Ping.

Any plans to finally land this one for GCC 13?

The hope is that this patch would make life significantly easier for
distributions. There are way too many packages failing to build due to
sub-word atomics, which is highly annoying considering that it's not
consistent between package versions. Build times on riscv64 are extremely
long which makes it even more annoying. Would love to see this finally
fixed.


It could well be the case that this gets punted.  Atomics are a bit of a 
mess at the moment and we're still trying to figure out the best way 
forward.  It's not forgotten though.


jeff

Re: [PATCH] gcc: honour -ffile-prefix-map in ASM_MAP [PR93371]

[Jeff Law via Gcc-patches]

On 11/3/22 07:29, Rasmus Villemoes wrote:

On 02/11/2022 16.45, Jeff Law wrote:

On 11/2/22 06:35, Rasmus Villemoes wrote:

However, when I try to push the new master branch I get

$ git push origin master
fatal: remote error: service not enabled: /git/gcc.git

I do gcc patches sufficiently rare that I may have forgotten the right
procedure, but this is what I think I've done previously (along with
running a "git gcc-verify HEAD" to ensure there's a proper changelog
fragment to extract, with gcc-verify being a suitable alias).

Have I simply lost by commit bit?

No idea what that error means.  If I had to guess, it'd be that you've
got an anonymous checkout tree which is obviously unsuitable for pushing
or something of that nature.

It's probably just faster/easier for me to push it for you.  I'll take
care of it momentarily.

Thanks.

I think I found out what was wrong (though I know it has worked for me
previously): My remote url was git://gcc.gnu.org/git/gcc.git , and I
used to rely on my .ssh/config specifying "villemoes" as username when
accessing gcc.gnu.org. For some reason that no longer worked, but
updating the remote url to git+ssh://villem...@gcc.gnu.org/git/gcc.git
seemed to do the trick.


Good to know you got it sorted out.




What do you think about applying this to older branches? IMO it's a
defect from when the umbrella -ffile-prefix-map was introduced, and the
potential for regressions should be very low, but I can also see how it
might not really qualify as a bug fix.


I'd probably lean against backporting.  Generally we try to limit 
backporting to regression fixes, incorrect code generation issues and 
the like.  This seems much less serious.



Jeff

Re: [PATCH] RISC-V: Use binvi to cover more immediates than with xori alone

[Jeff Law via Gcc-patches]

On 11/10/22 14:35, Philipp Tomsich wrote:

Sequences of the form "a ^ C" with C being the positive half of a
signed immediate's range with one extra bit set in addtion are mapped
to xori and one binvi to avoid using a temporary (and a multi-insn
sequence to load C into that temporary).

gcc/ChangeLog:

* config/riscv/bitmanip.md (*binvi_extrabit): New pattern.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/zbs-binvi.c: New test.


Could this have been potentially done by extending the ior pattern with 
a code iterator that covered IOR/XOR?



Not a big deal, but if it'd work, consider to avoid the pattern duplication.


OK.

jeff

Re: [PATCH] RISC-V: Use bseti to cover more immediates than with ori alone

[Jeff Law via Gcc-patches]

On 11/10/22 14:34, Philipp Tomsich wrote:

Sequences of the form "a | C" with C being the positive half of a
signed immediate's range with one extra bit set in addtion are mapped
to ori and one binvi to avoid using a temporary (and a multi-insn
sequence to load C into that temporary).

gcc/ChangeLog:

* config/riscv/bitmanip.md (*bseti_extrabit): New pattern

gcc/testsuite/ChangeLog:

* gcc.target/riscv/zbs-bseti.c: New test.

Signed-off-by: Philipp Tomsich 
---
- Depends on a predicate posted in "RISC-V: Optimize branches testing
   a bit-range or a shifted immediate".  Depending on the order of
   applying these, I'll take care to pull that part out of the other
   patch if needed.

  gcc/config/riscv/bitmanip.md   | 19 +++
  gcc/testsuite/gcc.target/riscv/zbs-bseti.c | 27 ++
  2 files changed, 46 insertions(+)
  create mode 100644 gcc/testsuite/gcc.target/riscv/zbs-bseti.c

diff --git a/gcc/config/riscv/bitmanip.md b/gcc/config/riscv/bitmanip.md
index 06126ac4819..436ff4ba958 100644
--- a/gcc/config/riscv/bitmanip.md
+++ b/gcc/config/riscv/bitmani
@@ -512,6 +512,25 @@
"bseti\t%0,%1,%S2"
[(set_attr "type" "bitmanip")])
  
+; Catch those cases where we can use a bseti + ori or bseti + bseti

+; instead of a lui + addi + or sequence.
+(define_insn_and_split "*bseti_extrabit"
+  [(set (match_operand:X 0 "register_operand" "=r")
+   (ior:X (match_operand:X 1 "register_operand" "r")
+  (match_operand:X 2 "uimm_extra_bit_operand" "i")))]
+  "TARGET_ZBS"
+  "#"
+  "&& reload_completed"
+  [(set (match_dup 0) (ior:X (match_dup 1) (match_dup 3)))
+   (set (match_dup 0) (ior:X (match_dup 0) (match_dup 4)))]
+{
+   unsigned HOST_WIDE_INT bits = UINTVAL (operands[2]);
+   unsigned HOST_WIDE_INT topbit = HOST_WIDE_INT_1U << floor_log2 (bits);
+
+   operands[3] = GEN_INT (bits &~ topbit);
+   operands[4] = GEN_INT (topbit);
+})


I briefly thought you might need an earlyclobber for the output, but you 
consume the input register in the first generated insn, so you should be OK.



OK.

jeff

Re: [PATCH] Add a target hook for sibcall epilogues

[Jeff Law via Gcc-patches]

On 11/11/22 09:22, Richard Sandiford via Gcc-patches wrote:

Epilogues for sibling calls are generated using the
sibcall_epilogue pattern.  One disadvantage of this approach
is that the target doesn't know which call the epilogue is for,
even though the code that generates the pattern has the call
to hand.

Although call instructions are currently rtxes, and so could be
passed as an operand to the pattern, the main point of introducing
rtx_insn was to move towards separating the rtx and insn types
(a good thing IMO).  There also isn't an existing practice of
passing genuine instructions (as opposed to labels) to
instruction patterns.

This patch therefore adds a hook that can be defined as an
alternative to sibcall_epilogue.  The advantage is that it
can be passed the call; the disadvantage is that it can't
use .md conveniences like generating instructions from
textual patterns (although most epilogues are too complex
to benefit much from that anyway).

Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?

Richard


gcc/
* doc/gccint/target-macros/miscellaneous-parameters.rst:
Add TARGET_EMIT_EPILOGUE_FOR_SIBCALL.
* doc/gccint/target-macros/tm.rst.in: Regenerate.
* target.def (emit_epilogue_for_sibcall): New hook.
* calls.cc (can_implement_as_sibling_call_p): Use it.
* function.cc (thread_prologue_and_epilogue_insns): Likewise.
(reposition_prologue_and_epilogue_notes): Likewise.
* config/aarch64/aarch64-protos.h (aarch64_expand_epilogue): Take
an rtx_call_insn * rather than a bool.
* config/aarch64/aarch64.cc (aarch64_expand_epilogue): Likewise.
(TARGET_EMIT_EPILOGUE_FOR_SIBCALL): Define.
* config/aarch64/aarch64.md (epilogue): Update call.
(sibcall_epilogue): Delete.


Presumably you're going to do something useful with the new hook :-)


OK.

jeff

Re: [PATCH] gcc: m68k: fix PR target/107645

[Jeff Law via Gcc-patches]

On 11/12/22 20:47, Max Filippov wrote:

On Sat, Nov 12, 2022 at 11:42 AM Jeff Law  wrote:

ISTM that we'd need to strip the unspec and process its argument
instead.

I tried that first, the result was more ICEs because that pattern
wasn't recognized at later stages. Then I read the change to the
comment over the symbolic_operand predicate:
https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/config/m68k/predicates.md;h=6ca261fb92a2b7ecd53a0356d06410e2c0d70965;hp=417989f6d6c408fa82af9f9649a204b9a754d1dc;hb=75df395f15f2;hpb=676fd528c9990a4f1046b51d40059893c3a71490
and that made me think that the intention was to not recognize
the unspecs in that predicate.


Thanks for clarifying.  ISTM that operand predicate is quite poorly named.


OK for the trunk.


jeff

Re: [PATCH] doc: invoke: pru/riscv: Fix option list formatting

[Jeff Law via Gcc-patches]

On 11/15/22 16:08, Christoph Muellner wrote:

From: Christoph Müllner 

This patch fixes a wrong placed closing bracket in the RISC-V option
list and an unneeded @gol in the PRU option list in invoke.texi.

gcc/ChangeLog:

* doc/invoke.texi: Fix PRU/RISC-V option list formatting.


OK.


Jeff

Re: [PATCH v3] LoongArch: Add prefetch instructions.

[Lulu Cheng]

在 2022/11/16 上午11:06, WANG Xuerui 写道:


On 2022/11/16 10:10, Lulu Cheng wrote:

v2 -> v3:
1. Remove preldx support.

---
Enable sw prefetching at -O3 and higher.

Co-Authored-By: xujiahao 

gcc/ChangeLog:

* config/loongarch/constraints.md (ZD): New constraint.
* config/loongarch/loongarch-def.c: Initial number of parallel 
prefetch.

* config/loongarch/loongarch-tune.h (struct loongarch_cache):
Define number of parallel prefetch.
* config/loongarch/loongarch.cc 
(loongarch_option_override_internal):

Set up parameters to be used in prefetching algorithm.
* config/loongarch/loongarch.md (prefetch): New template.
---
  gcc/config/loongarch/constraints.md   | 10 ++
  gcc/config/loongarch/loongarch-def.c  |  2 ++
  gcc/config/loongarch/loongarch-tune.h |  1 +
  gcc/config/loongarch/loongarch.cc | 28 +++
  gcc/config/loongarch/loongarch.md | 14 ++
  5 files changed, 55 insertions(+)

diff --git a/gcc/config/loongarch/constraints.md 
b/gcc/config/loongarch/constraints.md

index 43cb7b5f0f5..46f7f63ae31 100644
--- a/gcc/config/loongarch/constraints.md
+++ b/gcc/config/loongarch/constraints.md
@@ -86,6 +86,10 @@
  ;;    "ZB"
  ;;  "An address that is held in a general-purpose register.
  ;;  The offset is zero"
+;;    "ZD"
+;;    "An address operand whose address is formed by a base register
+;; and offset that is suitable for use in instructions with the 
same

+;; addressing mode as @code{preld}."
  ;; "<" "Matches a pre-dec or post-dec operand." (Global 
non-architectural)
  ;; ">" "Matches a pre-inc or post-inc operand." (Global 
non-architectural)

  @@ -190,3 +194,9 @@ (define_memory_constraint "ZB"
    The offset is zero"
    (and (match_code "mem")
 (match_test "REG_P (XEXP (op, 0))")))
+
+(define_address_constraint "ZD"
+  "An address operand whose address is formed by a base register
+   and offset that is suitable for use in instructions with the same
+   addressing mode as @code{preld}."
+   (match_test "loongarch_12bit_offset_address_p (op, mode)"))


How is this different with the "m" constraint? AFAIK preld and ld 
share the same addressing mode (i.e. base register + 12-bit signed 
immediate offset).

The "m" constraint is defined as follows:
(define_memory_constraint "m"
*  (and (match_code "mem")*

   (match_test "loongarch_12bit_offset_address_p (XEXP (op, 0), 
mode)")))


This setting must be a memory operand.

''ZD" constraint is a address operand.

I think (mem:mode (address operand)) = memory operand.




diff --git a/gcc/config/loongarch/loongarch-def.c 
b/gcc/config/loongarch/loongarch-def.c

index cbf995d81b5..80ab10a52a8 100644
--- a/gcc/config/loongarch/loongarch-def.c
+++ b/gcc/config/loongarch/loongarch-def.c
@@ -62,11 +62,13 @@ loongarch_cpu_cache[N_TUNE_TYPES] = {
    .l1d_line_size = 64,
    .l1d_size = 64,
    .l2d_size = 256,
+  .simultaneous_prefetches = 4,
    },
    [CPU_LA464] = {
    .l1d_line_size = 64,
    .l1d_size = 64,
    .l2d_size = 256,
+  .simultaneous_prefetches = 4,
    },
  };
  diff --git a/gcc/config/loongarch/loongarch-tune.h 
b/gcc/config/loongarch/loongarch-tune.h

index 6f3530f5c02..8e3eb29472b 100644
--- a/gcc/config/loongarch/loongarch-tune.h
+++ b/gcc/config/loongarch/loongarch-tune.h
@@ -45,6 +45,7 @@ struct loongarch_cache {
  int l1d_line_size;  /* bytes */
  int l1d_size;   /* KiB */
  int l2d_size;   /* kiB */
+    int simultaneous_prefetches; /* number of parallel prefetch */

nit: "prefetches" or "prefetch ops" or "int prefetch_width"?

  };
    #endif /* LOONGARCH_TUNE_H */
diff --git a/gcc/config/loongarch/loongarch.cc 
b/gcc/config/loongarch/loongarch.cc

index 8d5d8d965dd..8ee32c90573 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -63,6 +63,7 @@ along with GCC; see the file COPYING3.  If not see
  #include "context.h"
  #include "builtins.h"
  #include "rtl-iter.h"
+#include "opts.h"
    /* This file should be included last.  */
  #include "target-def.h"
@@ -6100,6 +6101,33 @@ loongarch_option_override_internal (struct 
gcc_options *opts)

    if (loongarch_branch_cost == 0)
  loongarch_branch_cost = loongarch_cost->branch_cost;
  +  /* Set up parameters to be used in prefetching algorithm. */
+  int simultaneous_prefetches
+    = loongarch_cpu_cache[LARCH_ACTUAL_TUNE].simultaneous_prefetches;
+
+  SET_OPTION_IF_UNSET (opts, _options_set,
+   param_simultaneous_prefetches,
+   simultaneous_prefetches);
+
+  SET_OPTION_IF_UNSET (opts, _options_set,
+   param_l1_cache_line_size,
+ loongarch_cpu_cache[LARCH_ACTUAL_TUNE].l1d_line_size);
+
+  SET_OPTION_IF_UNSET (opts, _options_set,
+   param_l1_cache_size,
+ loongarch_cpu_cache[LARCH_ACTUAL_TUNE].l1d_size);
+
+  SET_OPTION_IF_UNSET (opts, _options_set,
+   param_l2_cache_size,
+ 

Undeliverable mail: RE:询盘 22310169

[Mail Delivery Subsystem]

Failed to deliver to 'enqu...@technochemicals.com.tn'
Message detected as SPAM

Reporting-MTA: dns; mx01.ingw.orange.tn

Original-Recipient: rfc822;
Final-Recipient: system;
Action: failed
Status: 5.0.0
Diagnostic-Code: smtp;Message detected as SPAM
Received: by mx01.ingw.orange.tn (CommuniGate Pro PIPE 6.1.16)
  with PIPE id 152997231; Wed, 16 Nov 2022 04:09:57 +0100
X-TFF-CGPSA-Version: 1.7
X-TFF-CGPSA-Filter: Scanned
Return-Path: 
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mx01.ingw.orqnge.tn
X-Spam-Flag: YES
X-Spam-Level: *
X-Spam-Status: Yes, score=5.6 required=5.0 tests=FREEMAIL_FORGED_REPLYTO,
	FREEMAIL_REPLYTO_END_DIGIT,FUZZY_XPILL,HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,
	MIME_HTML_ONLY,PDS_TONAME_EQ_TOLOCAL_FREEM_FORGE,TVD_SPACE_RATIO_MINFP
	autolearn=disabled version=3.4.0
X-Spam-Report: 
	*  0.2 FREEMAIL_REPLYTO_END_DIGIT Reply-To freemail username ends in digit
	*  (llvt6092[at]21cn.com)
	*  0.1 FUZZY_XPILL BODY: Attempt to obfuscate words in spam
	*  0.0 HTML_MESSAGE BODY: HTML included in message
	*  0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
	*  0.6 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag
	*  2.5 FREEMAIL_FORGED_REPLYTO Freemail in Reply-To, but not From
	*  0.0 TVD_SPACE_RATIO_MINFP Space ratio (vertical text obfuscation?)
	*  2.0 PDS_TONAME_EQ_TOLOCAL_FREEM_FORGE Forged replyto and
	*  __PDS_TONAME_EQ_TOLOCAL
Received: from [114.234.17.10] (HELO gnu.org)
  by mx01.ingw.orange.tn (CommuniGate Pro SMTP 6.1.16)
  with ESMTP id 152997206 for enqu...@technochemicals.com.tn; Wed, 16 Nov 2022 04:09:42 +0100
Received-SPF: softfail
 receiver=mx01.ingw.orange.tn; client-ip=114.234.17.10; envelope-from=gcc-patc...@gnu.org
X-CUSTOM-MAIL-MASTER-SENT-ID: 5197DE0F-2F00-481B-9C41-BBED3067A2EA
From: "21ojJH33" 
Subject: =?GB2312?B?UkU60a/FzA==?= 22310169
To: "enquiry" 
MIME-Version: 1.0
Reply-To: llvt6...@21cn.com
Date: Wed, 16 Nov 2022 11:09:43 +0800
Message-Id: <491892c2-4e7d-461d-b704-d2b731d8a...@gnu.org>
X-Mailer: MailMasterPC/4.13.2.1001 (Windows 7)
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

Re: [PATCH v3] LoongArch: Add prefetch instructions.

[WANG Xuerui]

On 2022/11/16 10:10, Lulu Cheng wrote:

v2 -> v3:
1. Remove preldx support.

---
Enable sw prefetching at -O3 and higher.

Co-Authored-By: xujiahao 

gcc/ChangeLog:

* config/loongarch/constraints.md (ZD): New constraint.
* config/loongarch/loongarch-def.c: Initial number of parallel prefetch.
* config/loongarch/loongarch-tune.h (struct loongarch_cache):
Define number of parallel prefetch.
* config/loongarch/loongarch.cc (loongarch_option_override_internal):
Set up parameters to be used in prefetching algorithm.
* config/loongarch/loongarch.md (prefetch): New template.
---
  gcc/config/loongarch/constraints.md   | 10 ++
  gcc/config/loongarch/loongarch-def.c  |  2 ++
  gcc/config/loongarch/loongarch-tune.h |  1 +
  gcc/config/loongarch/loongarch.cc | 28 +++
  gcc/config/loongarch/loongarch.md | 14 ++
  5 files changed, 55 insertions(+)

diff --git a/gcc/config/loongarch/constraints.md 
b/gcc/config/loongarch/constraints.md
index 43cb7b5f0f5..46f7f63ae31 100644
--- a/gcc/config/loongarch/constraints.md
+++ b/gcc/config/loongarch/constraints.md
@@ -86,6 +86,10 @@
  ;;"ZB"
  ;;  "An address that is held in a general-purpose register.
  ;;  The offset is zero"
+;;"ZD"
+;; "An address operand whose address is formed by a base register
+;;  and offset that is suitable for use in instructions with the same
+;;  addressing mode as @code{preld}."
  ;; "<" "Matches a pre-dec or post-dec operand." (Global non-architectural)
  ;; ">" "Matches a pre-inc or post-inc operand." (Global non-architectural)
  
@@ -190,3 +194,9 @@ (define_memory_constraint "ZB"

The offset is zero"
(and (match_code "mem")
 (match_test "REG_P (XEXP (op, 0))")))
+
+(define_address_constraint "ZD"
+  "An address operand whose address is formed by a base register
+   and offset that is suitable for use in instructions with the same
+   addressing mode as @code{preld}."
+   (match_test "loongarch_12bit_offset_address_p (op, mode)"))


How is this different with the "m" constraint? AFAIK preld and ld share 
the same addressing mode (i.e. base register + 12-bit signed immediate 
offset).



diff --git a/gcc/config/loongarch/loongarch-def.c 
b/gcc/config/loongarch/loongarch-def.c
index cbf995d81b5..80ab10a52a8 100644
--- a/gcc/config/loongarch/loongarch-def.c
+++ b/gcc/config/loongarch/loongarch-def.c
@@ -62,11 +62,13 @@ loongarch_cpu_cache[N_TUNE_TYPES] = {
.l1d_line_size = 64,
.l1d_size = 64,
.l2d_size = 256,
+  .simultaneous_prefetches = 4,
},
[CPU_LA464] = {
.l1d_line_size = 64,
.l1d_size = 64,
.l2d_size = 256,
+  .simultaneous_prefetches = 4,
},
  };
  
diff --git a/gcc/config/loongarch/loongarch-tune.h b/gcc/config/loongarch/loongarch-tune.h

index 6f3530f5c02..8e3eb29472b 100644
--- a/gcc/config/loongarch/loongarch-tune.h
+++ b/gcc/config/loongarch/loongarch-tune.h
@@ -45,6 +45,7 @@ struct loongarch_cache {
  int l1d_line_size;  /* bytes */
  int l1d_size;   /* KiB */
  int l2d_size;   /* kiB */
+int simultaneous_prefetches; /* number of parallel prefetch */

nit: "prefetches" or "prefetch ops" or "int prefetch_width"?

  };
  
  #endif /* LOONGARCH_TUNE_H */

diff --git a/gcc/config/loongarch/loongarch.cc 
b/gcc/config/loongarch/loongarch.cc
index 8d5d8d965dd..8ee32c90573 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -63,6 +63,7 @@ along with GCC; see the file COPYING3.  If not see
  #include "context.h"
  #include "builtins.h"
  #include "rtl-iter.h"
+#include "opts.h"
  
  /* This file should be included last.  */

  #include "target-def.h"
@@ -6100,6 +6101,33 @@ loongarch_option_override_internal (struct gcc_options 
*opts)
if (loongarch_branch_cost == 0)
  loongarch_branch_cost = loongarch_cost->branch_cost;
  
+  /* Set up parameters to be used in prefetching algorithm.  */

+  int simultaneous_prefetches
+= loongarch_cpu_cache[LARCH_ACTUAL_TUNE].simultaneous_prefetches;
+
+  SET_OPTION_IF_UNSET (opts, _options_set,
+  param_simultaneous_prefetches,
+  simultaneous_prefetches);
+
+  SET_OPTION_IF_UNSET (opts, _options_set,
+  param_l1_cache_line_size,
+  loongarch_cpu_cache[LARCH_ACTUAL_TUNE].l1d_line_size);
+
+  SET_OPTION_IF_UNSET (opts, _options_set,
+  param_l1_cache_size,
+  loongarch_cpu_cache[LARCH_ACTUAL_TUNE].l1d_size);
+
+  SET_OPTION_IF_UNSET (opts, _options_set,
+  param_l2_cache_size,
+  loongarch_cpu_cache[LARCH_ACTUAL_TUNE].l2d_size);
+
+
+  /* Enable sw prefetching at -O3 and higher.  */
+  if (opts->x_flag_prefetch_loop_arrays < 0
+  && (opts->x_optimize >= 3 || opts->x_flag_profile_use)
+  && !opts->x_optimize_size)
+

Re: [rs6000, patch] Enable have_cbranchcc4 on rs6000

[David Edelsohn via Gcc-patches]

On Tue, Nov 15, 2022 at 9:32 PM HAO CHEN GUI  wrote:

> Hi,
>   The patch enables have_cbrnachcc4 which is a flag in ifcvt.cc to
> indicate if branch by CC bits is invalid or not. As rs6000 already has
> "*cbranch" insn which does branching according to CC bits, the flag
> should be enabled and relevant branches can be optimized out. The test
> case illustrates the optimization.
>
>   "*cbranch" is an anonymous insn which can't be generated directly.
> So changing "const_int 0" to the third operand predicated by
> "zero_constant" won't cause ICEs as orginal patterns still can be matched.
>
>   Bootstrapped and tested on powerpc64-linux BE and LE with no regressions.
> Is this okay for trunk? Any recommendations? Thanks a lot.
>
>
> ChangeLog
> 2022-11-16  Haochen Gui 
>
> gcc/
> * config/rs6000/rs6000.md (*cbranch): Rename to...
> (cbranchcc4): ...this, and set const_int 0 to the third operand.
>
> gcc/testsuite/
> * gcc.target/powerpc/cbranchcc4.c: New.
>
>
> patch.diff
> diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
> index e9e5cd1e54d..ee171f21f6a 100644
> --- a/gcc/config/rs6000/rs6000.md
> +++ b/gcc/config/rs6000/rs6000.md
> @@ -13067,11 +13067,11 @@ (define_insn_and_split "*_cc"
>  ;; Conditional branches.
>  ;; These either are a single bc insn, or a bc around a b.
>
> -(define_insn "*cbranch"
> +(define_insn "cbranchcc4"
>[(set (pc)
> (if_then_else (match_operator 1 "branch_comparison_operator"
>   [(match_operand 2 "cc_reg_operand"
> "y")
> -  (const_int 0)])
> +  (match_operand 3 "zero_constant")])
>   (label_ref (match_operand 0))
>   (pc)))]
>""
>

Shouldn't cbranchcc4 be a separate pattern?  This pattern has an existing
purpose and an expected ordering of operands.

cbranchcc4 is passed the comparison operator as operand 0.  Other ports
ignore the second comparison operator and use (const_int 0).  Operand 3 is
the label, which seems to be the reason that you needed to change it to
match_operand 3.

It's great to add cbranchcc4 to the Power port where it definitely was an
omission, but adapting *cbranch for that purpose is the wrong approach.
The changes to the pattern are incorrect because they are covering up a
difference in ordering of the operands.  One can argue that the named
pattern only enables the functionality in ifcvt and the pattern otherwise
is used in its previous role.  But this is a Frankenstein monster
approach.  You're trying to twist the existing pattern so that it triggers
as cbranchcc4, but creating a pattern that messes up its arguments and only
works because the new, named pattern never is called.  This is too ugly.
Please fix.

Thanks, David

diff --git a/gcc/testsuite/gcc.target/powerpc/cbranchcc4.c
> b/gcc/testsuite/gcc.target/powerpc/cbranchcc4.c
> new file mode 100644
> index 000..1751d274bbf
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/cbranchcc4.c
> @@ -0,0 +1,8 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fdump-rtl-ce1" } */
> +/* { dg-final {scan-rtl-dump "noce_try_store_flag_constants" "ce1" } } */
> +
> +int test (unsigned int a, unsigned int b)
> +{
> +return (a < b ? 0 : (a > b ? 2 : 1));
> +}
>

[PATCH] libstdc++: Fix stream initialization with static library [PR107701]

[Patrick Palka via Gcc-patches]

When linking with a static library, the linker seems to exclude a
constituent .o object (including its global initializers) if nothing
from it is referenced by the program (unless e.g. --whole-archive is
used).  This behavior breaks iostream when linking with static libstdc++.a
(on systems that support init priorities) because we're defining the
global initializer for the standard stream objects in a separate TU
(ios_init.cc) from the stream objects definitions (globals_io.cc).

Thus in order to ensure that the global initializer for the standard
stream objects doesn't get wrongly dropped when statically linking,
we need to perform the initialization from the same TU that actually
defines the stream objects.

Tested on x86_64-pc-linux-gnu, does this look OK for trunk?

PR libstdc++/107701

libstdc++-v3/ChangeLog:

* src/c++98/globals_io.cc: Include "io_base_init.h" here
instead of ...
* src/c++98/ios_init.cc: ... here.
* testsuite/17_intro/static.cc: Run the test as well.
---
 libstdc++-v3/src/c++98/globals_io.cc  | 2 ++
 libstdc++-v3/src/c++98/ios_init.cc| 2 --
 libstdc++-v3/testsuite/17_intro/static.cc | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/libstdc++-v3/src/c++98/globals_io.cc 
b/libstdc++-v3/src/c++98/globals_io.cc
index 04fecb22aeb..bfd808b5bbd 100644
--- a/libstdc++-v3/src/c++98/globals_io.cc
+++ b/libstdc++-v3/src/c++98/globals_io.cc
@@ -69,6 +69,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   fake_wostream wclog;
 #endif
 
+#include "ios_base_init.h"
+
 _GLIBCXX_END_NAMESPACE_VERSION
 } // namespace
 
diff --git a/libstdc++-v3/src/c++98/ios_init.cc 
b/libstdc++-v3/src/c++98/ios_init.cc
index 4016fcab785..1b5132f1c2d 100644
--- a/libstdc++-v3/src/c++98/ios_init.cc
+++ b/libstdc++-v3/src/c++98/ios_init.cc
@@ -75,8 +75,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   extern wostream wclog;
 #endif
 
-#include "ios_base_init.h"
-
   ios_base::Init::Init()
   {
 if (__gnu_cxx::__exchange_and_add_dispatch(&_S_refcount, 1) == 0)
diff --git a/libstdc++-v3/testsuite/17_intro/static.cc 
b/libstdc++-v3/testsuite/17_intro/static.cc
index ffa7ecb7077..a0d6ed081f8 100644
--- a/libstdc++-v3/testsuite/17_intro/static.cc
+++ b/libstdc++-v3/testsuite/17_intro/static.cc
@@ -1,4 +1,4 @@
-// { dg-do link { target c++11 } }
+// { dg-do run { target c++11 } }
 // { dg-require-static-libstdcxx }
 // { dg-options "-static-libstdc++" }
 
-- 
2.38.1.436.geea7033409

Re: [PATCH] rtl: Try to remove EH edges after {pro,epi}logue generation [PR90259]

[Kewen.Lin via Gcc-patches]

on 2022/11/10 11:30, Kewen.Lin wrote:
> on 2022/11/9 15:56, Eric Botcazou wrote:
>>> The previous testings on powerpc64{,le}-linux-gnu covered language Go, but
>>> not Ada.  I re-tested it with languages c,c++,fortran,objc,obj-c++,go,ada
>>> on powerpc64le-linux-gnu, the result looked good.  Both x86 and aarch64
>>> cfarm machines which I used for testing don't have gnat installed, do you
>>> think testing Ada on ppc64le is enough?
>>
>> Sure, thanks for having done it!
>>
> 
> Thanks for confirming.
> 
> I'm going to push this next Monday if there is no objection or further
> comments in this week.
> 

Committed in r13-4079.  Do we want this to be backported a week later?

BR,
Kewen

[rs6000, patch] Enable have_cbranchcc4 on rs6000

[HAO CHEN GUI via Gcc-patches]

Hi,
  The patch enables have_cbrnachcc4 which is a flag in ifcvt.cc to
indicate if branch by CC bits is invalid or not. As rs6000 already has
"*cbranch" insn which does branching according to CC bits, the flag
should be enabled and relevant branches can be optimized out. The test
case illustrates the optimization.

  "*cbranch" is an anonymous insn which can't be generated directly.
So changing "const_int 0" to the third operand predicated by
"zero_constant" won't cause ICEs as orginal patterns still can be matched.

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


ChangeLog
2022-11-16  Haochen Gui 

gcc/
* config/rs6000/rs6000.md (*cbranch): Rename to...
(cbranchcc4): ...this, and set const_int 0 to the third operand.

gcc/testsuite/
* gcc.target/powerpc/cbranchcc4.c: New.


patch.diff
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index e9e5cd1e54d..ee171f21f6a 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -13067,11 +13067,11 @@ (define_insn_and_split "*_cc"
 ;; Conditional branches.
 ;; These either are a single bc insn, or a bc around a b.

-(define_insn "*cbranch"
+(define_insn "cbranchcc4"
   [(set (pc)
(if_then_else (match_operator 1 "branch_comparison_operator"
  [(match_operand 2 "cc_reg_operand" "y")
-  (const_int 0)])
+  (match_operand 3 "zero_constant")])
  (label_ref (match_operand 0))
  (pc)))]
   ""
diff --git a/gcc/testsuite/gcc.target/powerpc/cbranchcc4.c 
b/gcc/testsuite/gcc.target/powerpc/cbranchcc4.c
new file mode 100644
index 000..1751d274bbf
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/cbranchcc4.c
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-rtl-ce1" } */
+/* { dg-final {scan-rtl-dump "noce_try_store_flag_constants" "ce1" } } */
+
+int test (unsigned int a, unsigned int b)
+{
+return (a < b ? 0 : (a > b ? 2 : 1));
+}

[PATCH v3] LoongArch: Add prefetch instructions.

[Lulu Cheng]

v2 -> v3:
1. Remove preldx support.

---
Enable sw prefetching at -O3 and higher.

Co-Authored-By: xujiahao 

gcc/ChangeLog:

* config/loongarch/constraints.md (ZD): New constraint.
* config/loongarch/loongarch-def.c: Initial number of parallel prefetch.
* config/loongarch/loongarch-tune.h (struct loongarch_cache):
Define number of parallel prefetch.
* config/loongarch/loongarch.cc (loongarch_option_override_internal):
Set up parameters to be used in prefetching algorithm.
* config/loongarch/loongarch.md (prefetch): New template.
---
 gcc/config/loongarch/constraints.md   | 10 ++
 gcc/config/loongarch/loongarch-def.c  |  2 ++
 gcc/config/loongarch/loongarch-tune.h |  1 +
 gcc/config/loongarch/loongarch.cc | 28 +++
 gcc/config/loongarch/loongarch.md | 14 ++
 5 files changed, 55 insertions(+)

diff --git a/gcc/config/loongarch/constraints.md 
b/gcc/config/loongarch/constraints.md
index 43cb7b5f0f5..46f7f63ae31 100644
--- a/gcc/config/loongarch/constraints.md
+++ b/gcc/config/loongarch/constraints.md
@@ -86,6 +86,10 @@
 ;;"ZB"
 ;;  "An address that is held in a general-purpose register.
 ;;  The offset is zero"
+;;"ZD"
+;; "An address operand whose address is formed by a base register
+;;  and offset that is suitable for use in instructions with the same
+;;  addressing mode as @code{preld}."
 ;; "<" "Matches a pre-dec or post-dec operand." (Global non-architectural)
 ;; ">" "Matches a pre-inc or post-inc operand." (Global non-architectural)
 
@@ -190,3 +194,9 @@ (define_memory_constraint "ZB"
   The offset is zero"
   (and (match_code "mem")
(match_test "REG_P (XEXP (op, 0))")))
+
+(define_address_constraint "ZD"
+  "An address operand whose address is formed by a base register
+   and offset that is suitable for use in instructions with the same
+   addressing mode as @code{preld}."
+   (match_test "loongarch_12bit_offset_address_p (op, mode)"))
diff --git a/gcc/config/loongarch/loongarch-def.c 
b/gcc/config/loongarch/loongarch-def.c
index cbf995d81b5..80ab10a52a8 100644
--- a/gcc/config/loongarch/loongarch-def.c
+++ b/gcc/config/loongarch/loongarch-def.c
@@ -62,11 +62,13 @@ loongarch_cpu_cache[N_TUNE_TYPES] = {
   .l1d_line_size = 64,
   .l1d_size = 64,
   .l2d_size = 256,
+  .simultaneous_prefetches = 4,
   },
   [CPU_LA464] = {
   .l1d_line_size = 64,
   .l1d_size = 64,
   .l2d_size = 256,
+  .simultaneous_prefetches = 4,
   },
 };
 
diff --git a/gcc/config/loongarch/loongarch-tune.h 
b/gcc/config/loongarch/loongarch-tune.h
index 6f3530f5c02..8e3eb29472b 100644
--- a/gcc/config/loongarch/loongarch-tune.h
+++ b/gcc/config/loongarch/loongarch-tune.h
@@ -45,6 +45,7 @@ struct loongarch_cache {
 int l1d_line_size;  /* bytes */
 int l1d_size;   /* KiB */
 int l2d_size;   /* kiB */
+int simultaneous_prefetches; /* number of parallel prefetch */
 };
 
 #endif /* LOONGARCH_TUNE_H */
diff --git a/gcc/config/loongarch/loongarch.cc 
b/gcc/config/loongarch/loongarch.cc
index 8d5d8d965dd..8ee32c90573 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -63,6 +63,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "context.h"
 #include "builtins.h"
 #include "rtl-iter.h"
+#include "opts.h"
 
 /* This file should be included last.  */
 #include "target-def.h"
@@ -6100,6 +6101,33 @@ loongarch_option_override_internal (struct gcc_options 
*opts)
   if (loongarch_branch_cost == 0)
 loongarch_branch_cost = loongarch_cost->branch_cost;
 
+  /* Set up parameters to be used in prefetching algorithm.  */
+  int simultaneous_prefetches
+= loongarch_cpu_cache[LARCH_ACTUAL_TUNE].simultaneous_prefetches;
+
+  SET_OPTION_IF_UNSET (opts, _options_set,
+  param_simultaneous_prefetches,
+  simultaneous_prefetches);
+
+  SET_OPTION_IF_UNSET (opts, _options_set,
+  param_l1_cache_line_size,
+  loongarch_cpu_cache[LARCH_ACTUAL_TUNE].l1d_line_size);
+
+  SET_OPTION_IF_UNSET (opts, _options_set,
+  param_l1_cache_size,
+  loongarch_cpu_cache[LARCH_ACTUAL_TUNE].l1d_size);
+
+  SET_OPTION_IF_UNSET (opts, _options_set,
+  param_l2_cache_size,
+  loongarch_cpu_cache[LARCH_ACTUAL_TUNE].l2d_size);
+
+
+  /* Enable sw prefetching at -O3 and higher.  */
+  if (opts->x_flag_prefetch_loop_arrays < 0
+  && (opts->x_optimize >= 3 || opts->x_flag_profile_use)
+  && !opts->x_optimize_size)
+opts->x_flag_prefetch_loop_arrays = 1;
+
   if (TARGET_DIRECT_EXTERN_ACCESS && flag_shlib)
 error ("%qs cannot be used for compiling a shared library",
   "-mdirect-extern-access");
diff --git a/gcc/config/loongarch/loongarch.md 
b/gcc/config/loongarch/loongarch.md
index 682ab961741..2fda5381904 

Re: [PATCH] LoongArch: Fix atomic_exchange make comparison and may jump out

[Jinyang He]

On 2022/11/15 下午10:21, Xi Ruoyao wrote:


On Tue, 2022-11-15 at 21:03 +0800, Jinyang He wrote:

gcc/ChangeLog:

* config/loongarch/sync.md:
Add atomic_cas_value_exchange_and_7 and fix atomic_exchange.

nit:

* config/loongarch/sync.md (atomic_cas_value_exchange_and_7):
New define_insn.
(atomic_exchange): Use atomic_cas_value_exchange_and_7 instead
of atomic_cas_value_cmp_and.


gcc/testsuite/ChangeLog:

* gcc.target/loongarch/sync-1.c: New test.

Likewise, ChangeLog content should be indented with a tab. (Not 8
spaces: if my mail client changes my tab to 8 spaces I'm sorry).

/* snip */


OK. Thanks for the clear commit message and the explanation of format.



+  return "%G6\\n\\t"
+    "1:\\n\\t"
+    "ll.\\t%0,%1\\n\\t"
+    "and\\t%7,%0,%z3\\n\\t"
+    "or%i5\\t%7,%7,%5\\n\\t"
+    "sc.\\t%7,%1\\n\\t"
+    "beqz\\t%7,1b\\n\\t";

Do we need a "dbar 0x700" after beqz?

/* snip */


That's worth discussing. Actually I don't see any dbar hint definition
like 0x700 in the manual right now.
Besides, I think what should be provided here is a relaxed version. And
whether the barrier exsit or not is depend on the specific memory_order.

https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#_dbar





diff --git a/gcc/testsuite/gcc.target/loongarch/sync-1.c 
b/gcc/testsuite/gcc.target/loongarch/sync-1.c
new file mode 100644
index 0..cebed6a9b
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/sync-1.c
@@ -0,0 +1,104 @@
+/* Test __sync_test_and_set in atomic_exchange */
+/* { dg-do run } */
+/* { dg-options "-lpthread -std=c11" } */

This test seems not deterministic.  And the use of sched_yield is very
tricky, as the man page says:

sched_yield() is intended for use with  real-time  scheduling  policies
(i.e., SCHED_FIFO or SCHED_RR).  Use of sched_yield() with nondetermin‐
istic scheduling policies such as SCHED_OTHER is unspecified  and  very
likely means your application design is broken.


Yes, there might be something wrong. The test is just a variants from
llvm::tsan. It was presented to prove that the old implementation did
have problems.




I'd suggest to create a bug report at https://gcc.gnu.org/bugzilla


Thanks, I need to do that. It is must be I missing something at
https://gcc.gnu.org/contribute.html.



and
post this test in the PR.  Then add the PR number into the changelog,
and just add a { dg-do compile } and { dg-final { scan-assembler ... } }
test into the testsuite to ensure the correct ll/sc loop is generated.

A bug report also emphasises that this is a bug fix, which is suitable
for GCC 13 (in stage 3 now) and GCC 12 (the fix will be backported).


I will create a bug report where we all can discuss it.
Thanks for your review and help. :-)

[PATCH] testsuite: Fix mistransformed gcov

[Hans-Peter Nilsson via Gcc-patches]

How was r13-2619-g34b9a03353d3fd "gcov: Respect triplet when looking
for gcov" tested?  I'm having a hard time believing it was tested with
a *cross-compiler* *in-build-tree*.  I think it was only tested for
the special-case of an installed cross-compiler; not even with a
native build exercising the false branch (see patch), considering that
a breaking typo ("}" vs "]") snuck by in the first revision, before
commit.

I guess reviewers forgot to ask that, but it's really on the
submitter; it's a general requirement for patches to say how it was
tested.  Usually no more is needed than "tested with a cross-compiler
for ..., no regressions" (implying running twice and comparing results
before and after the patch).

In this case, when adjusting test-framework bits, a little more care
and mentioned details about how it was tested, would have been in
order.  It's likely it'd have shown that an uninstalled in-tree cross
(an IMHO more expected case) wasn't tested, which that patch broke for
the one gcov invocation that the testsuite does for cross-builds
(IIUC).

It can be said like this: I tested *this* patch as follows (all
directory names below manually redacted), showing no regressions and
fixing the regression for the in-tree cross build;

For a native build (x86_64, Debian 11):
- In the gcc build directory:
 make check RUNTESTFLAGS=gcov.exp

- In an empty new directory after native installation in /pre.
/gccsrc/top/contrib/test_installed --prefix=/pre gcov.exp

- Also, for good measure (mentioned somewhere in the installation
documentation) native:
for tool in gcc g++ ; do env PATH=/pre/bin:$PATH runtest \
 --tool $tool --srcdir=/gccsrc/top/gcc/testsuite gcov.exp; done

For a cris-elf cross:
- In the gcc build directory:
make check 'RUNTESTFLAGS=--target_board=cris-sim gcov.exp'

- In an empty new directory after installation in /pre.
/gccsrc/top/contrib/test_installed --with-gcc=/pre/bin/cris-elf-gcc \
 --with-g++=/pre/bin/cris-elf-g++ --with-gfortran=/pre/bin/cris-elf-gfortran \
 --target=cris-elf --target_board=cris-sim gcov.exp

Ok to commit?

brgds, H-P
PS. Beware that the proc name may be up for bikeshedding.

 8<  8<  8<  8< 

In commit r13-2619-g34b9a03353d3fd, [transform] was applied to all
invocations of gcov, for both out-of-tree and in-tree testing.
For in-tree cross builds, this means gcov was called as
"/path/to/gccobj/gcc/target-tuple-gcov" gcov-pr94029.c which is
incorrect, as it's there "/path/to/gccobj/gcc/gcov" until it's
installed.  This caused a testsuite failure, like:

Running /x/gcc/gcc/testsuite/gcc.misc-tests/gcov.exp ...
FAIL: gcc.misc-tests/gcov-pr94029.c gcov failed: spawn failed

To avoid cumbersome conditionals, use a dedicated new helper function.

gcc/testsuite:
* lib/gcc-dg.exp (gcc-transform-out-of-tree): New proc.
* g++.dg/gcov/gcov.exp, gcc.misc-tests/gcov.exp: Call
gcc-transform-out-of-tree instead of transform.
---
 gcc/testsuite/g++.dg/gcov/gcov.exp|  4 ++--
 gcc/testsuite/gcc.misc-tests/gcov.exp |  4 ++--
 gcc/testsuite/lib/gcc-dg.exp  | 13 +
 3 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/gcc/testsuite/g++.dg/gcov/gcov.exp 
b/gcc/testsuite/g++.dg/gcov/gcov.exp
index 04e7a0164865..c9f20958836b 100644
--- a/gcc/testsuite/g++.dg/gcov/gcov.exp
+++ b/gcc/testsuite/g++.dg/gcov/gcov.exp
@@ -24,9 +24,9 @@ global GXX_UNDER_TEST
 
 # Find gcov in the same directory as $GXX_UNDER_TEST.
 if { ![is_remote host] && [string match "*/*" [lindex $GXX_UNDER_TEST 0]] } {
-set GCOV [file dirname [lindex $GXX_UNDER_TEST 0]]/[transform gcov]
+set GCOV [file dirname [lindex $GXX_UNDER_TEST 
0]]/[gcc-transform-out-of-tree gcov]
 } else {
-set GCOV [transform gcov]
+set GCOV [gcc-transform-out-of-tree gcov]
 }
 
 # Initialize harness.
diff --git a/gcc/testsuite/gcc.misc-tests/gcov.exp 
b/gcc/testsuite/gcc.misc-tests/gcov.exp
index b8e9661aa537..90ceec46e0f0 100644
--- a/gcc/testsuite/gcc.misc-tests/gcov.exp
+++ b/gcc/testsuite/gcc.misc-tests/gcov.exp
@@ -24,9 +24,9 @@ global GCC_UNDER_TEST
 
 # For now find gcov in the same directory as $GCC_UNDER_TEST.
 if { ![is_remote host] && [string match "*/*" [lindex $GCC_UNDER_TEST 0]] } {
-set GCOV [file dirname [lindex $GCC_UNDER_TEST 0]]/[transform gcov]
+set GCOV [file dirname [lindex $GCC_UNDER_TEST 
0]]/[gcc-transform-out-of-tree gcov]
 } else {
-set GCOV [transform gcov]
+set GCOV [gcc-transform-out-of-tree gcov]
 }
 
 # Initialize harness.
diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
index 23ec038f41eb..2910c9ce0998 100644
--- a/gcc/testsuite/lib/gcc-dg.exp
+++ b/gcc/testsuite/lib/gcc-dg.exp
@@ -1429,5 +1429,18 @@ proc scan-symbol-not { args } {
 }
 }
 
+# Transform a tool-name to its canonical-target-name by "transform"
+# (which may return the original name for native targets) but only if
+# testing out-of-tree.  When in-tree, the tool is expected to be found
+# by its original 

RE: [wwwdocs] gcc-13: Mention Intel new ISA and march support.

[Jiang, Haochen via Gcc-patches]

Hi Gerald,

I will remove "to GCC" here if there is no more comment from others on Thursday.
For me it is reasonable.

Thx,
Haochen

> -Original Message-
> From: Gerald Pfeifer 
> Sent: Monday, November 14, 2022 9:56 PM
> To: Jiang, Haochen 
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [wwwdocs] gcc-13: Mention Intel new ISA and march support.
> 
> On Thu, 10 Nov 2022, Haochen Jiang via Gcc-patches wrote:
> > +  New ISA extension support for Intel AVX-IFMA was added to GCC.
> 
> Here and in the other cases I'd skip "to GCC". This is clear from the context
> (this being the GCC release notes :-) and makes it shorter.
> 
> Gerald

Re: [PATCH] RISC-V: Use .p2align for code-alignment

[Philipp Tomsich]

On Tue, 15 Nov 2022 at 22:14, Philipp Tomsich  wrote:
>
> Jeff,
>
> On Tue, 15 Nov 2022 at 17:37, Jeff Law  wrote:
> >
> >
> > On 11/13/22 13:41, Philipp Tomsich wrote:
> >
> > RISC-V's .p2align (currently) ignores the max-skip argument.  As we
> > have experimental patches underway to address this in a
> > backwards-compatible manner, let's prepare GCC for the day when
> > binutils gets updated.
> >
> > gcc/ChangeLog:
> >
> > * config/riscv/riscv.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Implement.
> >
> >
> > What are the implications if we start using p2align immediately when the 
> > current (broken?) state of the assembler?  I'm pretty sure configure is 
> > already turning on HAVE_GAS_SKIP_P2ALIGN.  From a native risc-v build:
> >
> >
> > auto-host.h:#define HAVE_GAS_MAX_SKIP_P2ALIGN 1
>
> This is your tree, which has the (partial fix — i.e., the best we can
> do without breaking backward compatibility) for .p2align.
> When building against upstream binutils, this should not be defined.

After rereading the generated configure-script, I've changed my mind
The check the does nothing to ensure that the max-skip is actually
honored and only tests whether it is accepted.

Having the max-skip silently ignored may still be the lesser evil.

Philipp.

Re: [PATCH] c++: Reject UDLs in certain contexts [PR105300]

[Marek Polacek via Gcc-patches]

On Tue, Nov 15, 2022 at 06:58:39PM -0500, Jason Merrill wrote:
> On 11/12/22 06:53, Marek Polacek wrote:
> > In this PR, we are crashing because we've encountered a UDL where a
> > string-literal is expected.  This patch makes the parser reject string
> > and character UDLs in all places where the grammar requires a
> > string-literal and not a user-defined-string-literal.
> > 
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> 
> Since the grammar has
> 
> user-defined-string-literal :
>   string-literal ud-suffix
> 
> maybe we want to move the UDL handling out to a cp_parser_udl_string_literal
> that calls cp_parser_string_literal?

Umm, maybe, but the UDL handling code seems to be too entrenched in
cp_parser_string_literal and I don't think it's going to be easy to extract
it :/.

Marek

[PATCH v2] c++: P2448 - Relaxing some constexpr restrictions [PR106649]

[Marek Polacek via Gcc-patches]

On Mon, Nov 14, 2022 at 06:00:58PM -0500, Jason Merrill wrote:
> On 11/9/22 10:53, Marek Polacek wrote:
> > This patch implements C++23 P2448, which lifts more restrictions on the
> > constexpr keyword.  It's effectively going the way of being just a hint
> > (hello, inline!).
> > 
> > This gist is relatively simple: in C++23, a constexpr function's return
> > type/parameter type doesn't have to be a literal type; and you can have
> > a constexpr function for which no invocation satisfies the requirements
> > of a core constant expression.  For example,
> > 
> >void f(int& i); // not constexpr
> > 
> >constexpr void g(int& i) {
> >  f(i); // unconditionally calls a non-constexpr function
> >}
> > 
> > is now OK, even though there isn't an invocation of 'g' that would be
> > a constant expression.  Maybe 'f' will be made constexpr soon, or maybe
> > this depends on the version of C++ used, and similar.  The patch is
> > unfortunately not that trivial.  The important bit is to use the new
> > require_potential_rvalue_constant_expression_fncheck in
> > maybe_save_constexpr_fundef (and where appropriate).  It has a new flag
> > that says that we're checking the body of a constexpr function, and in
> > that case it's OK to find constructs that aren't a constant expression.
> > 
> > Since it's useful to be able to check for problematic constructs even
> > in C++23, this patch implements a new warning, -Winvalid-constexpr,
> > which is a pedwarn turned on by default in C++20 and earlier, and which
> > can be turned on in C++23 as well, in which case it's an ordinary warning.
> > This I implemented by using the new function constexpr_error, used in
> > p_c_e_1 and friends.  (In some cases I believe fundef_p will be always
> > false (= hard error), but it made sense to me to be consistent and use
> > constexpr_error throughout p_c_e_1.)
> > 
> > While working on this I think I found a bug, see constexpr-nonlit15.C
> > and .  This patch doesn't address that.
> > 
> > I also don't love that in C++23, if you don't use -Winvalid-constexpr,
> > and call a constexpr function that in fact isn't constexpr-ready yet,
> > sometimes all you get is an error saying "called in a constant expression"
> > like in constexpr-nonlit12.C.  This could be remedied by some tweaks to
> > explain_invalid_constexpr_fn, I reckon (it gives up on !DECL_DEFAULTED_FN).
> 
> And also in maybe_save_constexpr_fn: if -Wno-invalid-constexpr, "complain"
> should be false so we save the definition for explain_invalid_constexpr_fn
> to refer to.

I did something similar: don't return if warn_invalid_constexpr == 0.
I thought I'd just adjust the initializer for 'complain' but due to
constexpr-ice4.C we should call is_valid_constexpr_fn even when
warn_invalid_constexpr is 0.  The only non-testsuite changes are to
maybe_save_constexpr_fundef and explain_invalid_constexpr_fn.

Updated patch below, now we emit a better diagnostic for 
constexpr-nonlit12.C even with -std=c++23.  And also in C++20 with
-Wno-invalid-constexpr.

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

-- >8 --
This patch implements C++23 P2448, which lifts more restrictions on the
constexpr keyword.  It's effectively going the way of being just a hint
(hello, inline!).

This gist is relatively simple: in C++23, a constexpr function's return
type/parameter type doesn't have to be a literal type; and you can have
a constexpr function for which no invocation satisfies the requirements
of a core constant expression.  For example,

  void f(int& i); // not constexpr

  constexpr void g(int& i) {
f(i); // unconditionally calls a non-constexpr function
  }

is now OK, even though there isn't an invocation of 'g' that would be
a constant expression.  Maybe 'f' will be made constexpr soon, or maybe
this depends on the version of C++ used, and similar.  The patch is
unfortunately not that trivial.  The important bit is to use the new
require_potential_rvalue_constant_expression_fncheck in
maybe_save_constexpr_fundef (and where appropriate).  It has a new flag
that says that we're checking the body of a constexpr function, and in
that case it's OK to find constructs that aren't a constant expression.

Since it's useful to be able to check for problematic constructs even
in C++23, this patch implements a new warning, -Winvalid-constexpr,
which is a pedwarn turned on by default in C++20 and earlier, and which
can be turned on in C++23 as well, in which case it's an ordinary warning.
This I implemented by using the new function constexpr_error, used in
p_c_e_1 and friends.  (In some cases I believe fundef_p will be always
false (= hard error), but it made sense to me to be consistent and use
constexpr_error throughout p_c_e_1.)

While working on this I think I found a bug, see constexpr-nonlit15.C
and .  This patch doesn't address that.

This patch includes changes to diagnose the problem if the user doesn't

Re: [PATCH] c++, v2: Implement C++23 P2647R1 - Permitting static constexpr variables in constexpr functions

[Jonathan Wakely via Gcc-patches]

On Tue, 15 Nov 2022 at 23:50, Jakub Jelinek  wrote:
>
> On Tue, Nov 15, 2022 at 06:36:38PM -0500, Jason Merrill wrote:
> > > Here is an updated patch that passed bootstrap/regtest, the only
> > > change is another testcase tweak.
> > >
> > > 2022-11-13  Jakub Jelinek  
> > >
> > > gcc/c-family/
> > > * c-cppbuiltin.cc (c_cpp_builtins): Bump __cpp_constexpr
> > > value from 202207L to 202211L.
> > > gcc/cp/
> > > * constexpr.cc (cxx_eval_constant_expression): Implement C++23
> > > P2647R1 - Permitting static constexpr variables in constexpr 
> > > functions.
> > > Allow decl_maybe_constant_var_p static or thread_local vars for
> > > C++23.
> >
> > This was accepted as a DR, so it shouldn't be limited to C++23 mode.
> > Certainly it should be allowed in C++20 mode; I don't have a strong opinion
> > about C++14/17.  Jonathan, do you?
>
> How will a feature with feature test macro with multiple values work as DR?
> Or will everything but the macro be treated as a DR (so __cpp_constexpr >=
> 202211L only for C++23)?

Yes, I think so. We just won't be able to advertise this feature as
supported in C++20.

> Because __cpp_constexpr >= 202211L is >= 202207L too and that implies
> P2448R2 which wasn't a DR and >= 202110L which implies P2242R3 which wasn't a
> DR.  And C++20 added other 2 non-DR papers that bumped the value.
> C++17 another one.
>
> > > (potential_constant_expression_1): Likewise.
> > > gcc/testsuite/
> > > * g++.dg/cpp23/constexpr-nonlit17.C: New test.
> > > * g++.dg/cpp23/feat-cxx2b.C: Adjust expected __cpp_constexpr
> > > value.
> > > * g++.dg/ext/stmtexpr19.C: Don't expect an error for C++23 or later.
>
> Jakub
>

Re: [PATCH] c++, v2: Implement C++23 P2647R1 - Permitting static constexpr variables in constexpr functions

[Jonathan Wakely via Gcc-patches]

On Tue, 15 Nov 2022 at 23:36, Jason Merrill  wrote:
>
> On 11/13/22 01:45, Jakub Jelinek wrote:
> > On Fri, Nov 11, 2022 at 06:07:04PM +0100, Jakub Jelinek wrote:
> >> The following patch on top of Marek's P2448 PR106649 patch
> >> (mainly because that patch implements the previous __cpp_constexpr
> >> feature test macro bump so this can't go in earlier; OT,
> >> P2280R4 doesn't have any feature test macro?) implements this
> >> simple paper.
> >>
> >> Ok for trunk if it passes bootstrap/regtest and is voted into C++23?
> >
> > Here is an updated patch that passed bootstrap/regtest, the only
> > change is another testcase tweak.
> >
> > 2022-11-13  Jakub Jelinek  
> >
> > gcc/c-family/
> >   * c-cppbuiltin.cc (c_cpp_builtins): Bump __cpp_constexpr
> >   value from 202207L to 202211L.
> > gcc/cp/
> >   * constexpr.cc (cxx_eval_constant_expression): Implement C++23
> >   P2647R1 - Permitting static constexpr variables in constexpr 
> > functions.
> >   Allow decl_maybe_constant_var_p static or thread_local vars for
> >   C++23.
>
> This was accepted as a DR, so it shouldn't be limited to C++23 mode.
> Certainly it should be allowed in C++20 mode; I don't have a strong
> opinion about C++14/17.  Jonathan, do you?

I don't. The lack of this feature caused some awkwardness implementing
a C++23 library feature in , but that means my desire for it
was only in C++23 mode. And that has been mitigated by changes Patrick
made to work around it anyway.

I think it does make sense for C++20, where constexpr is pretty close
to "normal" code, what with dynamic allocations, std::string etc. but
I don't see a great need for it before C++20.

>
> >   (potential_constant_expression_1): Likewise.
> > gcc/testsuite/
> >   * g++.dg/cpp23/constexpr-nonlit17.C: New test.
> >   * g++.dg/cpp23/feat-cxx2b.C: Adjust expected __cpp_constexpr
> >   value.
> >   * g++.dg/ext/stmtexpr19.C: Don't expect an error for C++23 or later.
> >
> > --- gcc/c-family/c-cppbuiltin.cc.jj   2022-11-11 17:14:52.021613271 +0100
> > +++ gcc/c-family/c-cppbuiltin.cc  2022-11-11 17:17:45.065265246 +0100
> > @@ -1074,7 +1074,7 @@ c_cpp_builtins (cpp_reader *pfile)
> > /* Set feature test macros for C++23.  */
> > cpp_define (pfile, "__cpp_size_t_suffix=202011L");
> > cpp_define (pfile, "__cpp_if_consteval=202106L");
> > -   cpp_define (pfile, "__cpp_constexpr=202207L");
> > +   cpp_define (pfile, "__cpp_constexpr=202211L");
> > cpp_define (pfile, "__cpp_multidimensional_subscript=202110L");
> > cpp_define (pfile, "__cpp_named_character_escapes=202207L");
> > cpp_define (pfile, "__cpp_static_call_operator=202207L");
> > --- gcc/cp/constexpr.cc.jj2022-11-11 17:14:52.024613231 +0100
> > +++ gcc/cp/constexpr.cc   2022-11-11 17:16:54.384952917 +0100
> > @@ -7085,7 +7085,8 @@ cxx_eval_constant_expression (const cons
> >   && (TREE_STATIC (r)
> >   || (CP_DECL_THREAD_LOCAL_P (r) && !DECL_REALLY_EXTERN (r)))
> >   /* Allow __FUNCTION__ etc.  */
> > - && !DECL_ARTIFICIAL (r))
> > + && !DECL_ARTIFICIAL (r)
> > + && (cxx_dialect < cxx23 || !decl_maybe_constant_var_p (r)))
> > {
> >   if (!ctx->quiet)
> > {
> > @@ -9577,7 +9578,10 @@ potential_constant_expression_1 (tree t,
> > tmp = DECL_EXPR_DECL (t);
> > if (VAR_P (tmp) && !DECL_ARTIFICIAL (tmp))
> >   {
> > -   if (CP_DECL_THREAD_LOCAL_P (tmp) && !DECL_REALLY_EXTERN (tmp))
> > +   if (CP_DECL_THREAD_LOCAL_P (tmp)
> > +   && !DECL_REALLY_EXTERN (tmp)
> > +   && (cxx_dialect < cxx23
> > +   || !decl_maybe_constant_var_p (tmp)))
> >   {
> > if (flags & tf_error)
> >   constexpr_error (DECL_SOURCE_LOCATION (tmp), fundef_p,
> > @@ -9585,7 +9589,9 @@ potential_constant_expression_1 (tree t,
> >"% context", tmp);
> > return false;
> >   }
> > -   else if (TREE_STATIC (tmp))
> > +   else if (TREE_STATIC (tmp)
> > +&& (cxx_dialect < cxx23
> > +|| !decl_maybe_constant_var_p (tmp)))
> >   {
> > if (flags & tf_error)
> >   constexpr_error (DECL_SOURCE_LOCATION (tmp), fundef_p,
> > --- gcc/testsuite/g++.dg/cpp23/constexpr-nonlit17.C.jj2022-11-11 
> > 17:59:59.972852793 +0100
> > +++ gcc/testsuite/g++.dg/cpp23/constexpr-nonlit17.C   2022-11-11 
> > 17:59:38.725141231 +0100
> > @@ -0,0 +1,12 @@
> > +// P2647R1 - Permitting static constexpr variables in constexpr functions
> > +// { dg-do compile { target c++23 } }
> > +
> > +constexpr char
> > +test ()
> > +{
> > +  static const int x = 5;
> > +  static constexpr char c[] = "Hello World";
> > +  return *(c + x);
> > +}
> > +
> > +static_assert (test () == ' ');
> > --- gcc/testsuite/g++.dg/cpp23/feat-cxx2b.C.jj2022-11-11 
> > 17:14:52.194610922 +0100
> > +++ 

Re: [PATCH 7/7] riscv: Add support for str(n)cmp inline expansion

[Philipp Tomsich]

On Tue, 15 Nov 2022 at 01:46, Kito Cheng  wrote:
>
> Hi Christoph:
>
> > This patch implements expansions for the cmpstrsi and the cmpstrnsi
> > builtins using Zbb instructions (if available).
> > This allows to inline calls to strcmp() and strncmp().
> >
> > The expansion basically emits a peeled comparison sequence (i.e. a peeled
> > comparison loop) which compares XLEN bits per step if possible.
> >
> > The emitted sequence can be controlled, by setting the maximum number
> > of compared bytes (-mstring-compare-inline-limit).
>
> I would like to have a unified option interface,
> maybe -m[no-]inline-str[n]cmp and -minline-str[n]cmp-limit.

For the basic option (-m[no-]inline-str[n]cmp), I would punt to
-fno-builtin-str[n]cmp.
The limit-one sounds more like a --param?

> And add some option like this:
> -minline-str[n]cmp=[bitmanip|vector|auto] in future,

If we want to follow the lead of others, then x86 has a -mstringop-strategy=alg


> since I assume we'll have different versions of those things.
>
> >
> > gcc/ChangeLog:
> >
> > * config/riscv/riscv-protos.h (riscv_expand_strn_compare): New
> >   prototype.
> > * config/riscv/riscv-string.cc (GEN_EMIT_HELPER3): New helper
> >   macros.
> > (GEN_EMIT_HELPER2): New helper macros.
> > (expand_strncmp_zbb_sequence): New function.
> > (riscv_emit_str_compare_zbb): New function.
> > (riscv_expand_strn_compare): New function.
> > * config/riscv/riscv.md (cmpstrnsi): Invoke expansion functions
> >   for strn_compare.
> > (cmpstrsi): Invoke expansion functions for strn_compare.
> > * config/riscv/riscv.opt: Add new parameter
> >   '-mstring-compare-inline-limit'.
>
> We need to document this option.

Re: [PATCH v3 1/3] libcpp: reject codepoints above 0x10FFFF

[Jason Merrill via Gcc-patches]

On 11/8/22 16:10, Ben Boeckel wrote:

Unicode does not support such values because they are unrepresentable in
UTF-16.

libcpp/

* charset.cc: Reject encodings of codepoints above 0x10.
UTF-16 does not support such codepoints and therefore all
Unicode rejects such values.


OK.


Signed-off-by: Ben Boeckel 
---
  libcpp/charset.cc | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/libcpp/charset.cc b/libcpp/charset.cc
index 12a398e7527..324b5b19136 100644
--- a/libcpp/charset.cc
+++ b/libcpp/charset.cc
@@ -158,6 +158,10 @@ struct _cpp_strbuf
 encoded as any of DF 80, E0 9F 80, F0 80 9F 80, F8 80 80 9F 80, or
 FC 80 80 80 9F 80.  Only the first is valid.
  
+   Additionally, Unicode declares that all codepoints above 0010 are

+   invalid because they cannot be represented in UTF-16. As such, all 5- and
+   6-byte encodings are invalid.
+
 An implementation note: the transformation from UTF-16 to UTF-8, or
 vice versa, is easiest done by using UTF-32 as an intermediary.  */
  
@@ -216,7 +220,7 @@ one_utf8_to_cppchar (const uchar **inbufp, size_t *inbytesleftp,

if (c <= 0x3FF && nbytes > 5) return EILSEQ;
  
/* Make sure the character is valid.  */

-  if (c > 0x7FFF || (c >= 0xD800 && c <= 0xDFFF)) return EILSEQ;
+  if (c > 0x10 || (c >= 0xD800 && c <= 0xDFFF)) return EILSEQ;
  
*cp = c;

*inbufp = inbuf;
@@ -320,7 +324,7 @@ one_utf32_to_utf8 (iconv_t bigend, const uchar **inbufp, 
size_t *inbytesleftp,
s += inbuf[bigend ? 2 : 1] << 8;
s += inbuf[bigend ? 3 : 0];
  
-  if (s >= 0x7FFF || (s >= 0xD800 && s <= 0xDFFF))

+  if (s > 0x10 || (s >= 0xD800 && s <= 0xDFFF))
  return EILSEQ;
  
rval = one_cppchar_to_utf8 (s, outbufp, outbytesleftp);

Re: [PATCH v3 2/3] libcpp: add a function to determine UTF-8 validity of a C string

[Jason Merrill via Gcc-patches]

On 11/8/22 16:10, Ben Boeckel wrote:

This simplifies the interface for other UTF-8 validity detections when a
simple "yes" or "no" answer is sufficient.

libcpp/

* charset.cc: Add `_cpp_valid_utf8_str` which determines whether
a C string is valid UTF-8 or not.
* internal.h: Add prototype for `_cpp_valid_utf8_str`.

Signed-off-by: Ben Boeckel 
---
  libcpp/charset.cc | 20 
  libcpp/internal.h |  2 ++
  2 files changed, 22 insertions(+)

diff --git a/libcpp/charset.cc b/libcpp/charset.cc
index 324b5b19136..e130bc01f48 100644
--- a/libcpp/charset.cc
+++ b/libcpp/charset.cc
@@ -1868,6 +1868,26 @@ _cpp_valid_utf8 (cpp_reader *pfile,
return true;
  }
  
+/*  Detect whether a C-string is a valid UTF-8-encoded set of bytes. Returns

+`false` if any contained byte sequence encodes an invalid Unicode codepoint
+or is not a valid UTF-8 sequence. Returns `true` otherwise. */
+
+extern bool
+_cpp_valid_utf8_str (const char *name)
+{
+  const uchar* in = (const uchar*)name;
+  size_t len = strlen(name);


You'se missing a space before (.


+  cppchar_t cp;
+
+  while (*in)
+{
+  if (one_utf8_to_cppchar(, , ))


Here too.

OK with those fixed.


+   return false;
+}
+
+  return true;
+}
+
  /* Subroutine of convert_hex and convert_oct.  N is the representation
 in the execution character set of a numeric escape; write it into the
 string buffer TBUF and update the end-of-string pointer therein.  WIDE
diff --git a/libcpp/internal.h b/libcpp/internal.h
index badfd1b40da..4f2dd4a2f5c 100644
--- a/libcpp/internal.h
+++ b/libcpp/internal.h
@@ -834,6 +834,8 @@ extern bool _cpp_valid_utf8 (cpp_reader *pfile,
 struct normalize_state *nst,
 cppchar_t *cp);
  
+extern bool _cpp_valid_utf8_str (const char *str);

+
  extern void _cpp_destroy_iconv (cpp_reader *);
  extern unsigned char *_cpp_convert_input (cpp_reader *, const char *,
  unsigned char *, size_t, size_t,

Re: [PATCH] c++: Reject UDLs in certain contexts [PR105300]

[Jason Merrill via Gcc-patches]

On 11/12/22 06:53, Marek Polacek wrote:

In this PR, we are crashing because we've encountered a UDL where a
string-literal is expected.  This patch makes the parser reject string
and character UDLs in all places where the grammar requires a
string-literal and not a user-defined-string-literal.

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


Since the grammar has

user-defined-string-literal :
string-literal ud-suffix

maybe we want to move the UDL handling out to a 
cp_parser_udl_string_literal that calls cp_parser_string_literal?



PR c++/105300

gcc/c-family/ChangeLog:

* c-pragma.cc (handle_pragma_message): Warn for CPP_STRING_USERDEF.

gcc/cp/ChangeLog:

* parser.cc (cp_parser_string_literal): Add a bool parameter.
Give an error when UDLs are not permitted.
(cp_parser_primary_expression): Adjust the call to
cp_parser_string_literal.
(cp_parser_linkage_specification): Likewise.
(cp_parser_static_assert): Likewise.
(cp_parser_operator): Likewise.
(cp_parser_asm_definition): Likewise.
(cp_parser_asm_specification_opt): Likewise.
(cp_parser_asm_operand_list): Likewise.
(cp_parser_asm_clobber_list): Likewise.
(cp_parser_omp_context_selector): Likewise.
(pragma_lex): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/udlit-error1.C: New test.
---
  gcc/c-family/c-pragma.cc  |  3 +
  gcc/cp/parser.cc  | 69 ++-
  gcc/testsuite/g++.dg/cpp0x/udlit-error1.C | 21 +++
  3 files changed, 65 insertions(+), 28 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/udlit-error1.C

diff --git a/gcc/c-family/c-pragma.cc b/gcc/c-family/c-pragma.cc
index 142a46441ac..49f405b605b 100644
--- a/gcc/c-family/c-pragma.cc
+++ b/gcc/c-family/c-pragma.cc
@@ -1390,6 +1390,9 @@ handle_pragma_message (cpp_reader *)
  }
else if (token == CPP_STRING)
  message = x;
+  else if (token == CPP_STRING_USERDEF)
+GCC_BAD ("string literal with user-defined suffix is invalid in this "
+"context");
else
  GCC_BAD ("expected a string after %<#pragma message%>");
  
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc

index e4021835ed5..ae2798e2a33 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -2226,7 +2226,7 @@ pop_unparsed_function_queues (cp_parser *parser)
  static cp_expr cp_parser_identifier
(cp_parser *);
  static cp_expr cp_parser_string_literal
-  (cp_parser *, bool, bool, bool);
+  (cp_parser *, bool, bool, bool, bool);
  static cp_expr cp_parser_userdef_char_literal
(cp_parser *);
  static tree cp_parser_userdef_string_literal
@@ -4402,7 +4402,8 @@ cp_parser_identifier (cp_parser* parser)
 TREE_STRING representing the combined, nul-terminated string
 constant.  If TRANSLATE is true, translate the string to the
 execution character set.  If WIDE_OK is true, a wide string is
-   invalid here.
+   valid here.  If UDL_OK is true, a string literal with user-defined
+   suffix can be used in this context.
  
 C++98 [lex.string] says that if a narrow string literal token is

 adjacent to a wide string literal token, the behavior is undefined.
@@ -4414,7 +4415,7 @@ cp_parser_identifier (cp_parser* parser)
 FUTURE: ObjC++ will need to handle @-strings here.  */
  static cp_expr
  cp_parser_string_literal (cp_parser *parser, bool translate, bool wide_ok,
- bool lookup_udlit = true)
+ bool udl_ok, bool lookup_udlit = true)
  {
tree value;
size_t count;
@@ -4439,6 +4440,12 @@ cp_parser_string_literal (cp_parser *parser, bool 
translate, bool wide_ok,
  
if (cpp_userdef_string_p (tok->type))

  {
+  if (!udl_ok)
+   {
+ error_at (loc, "string literal with user-defined suffix "
+   "is invalid in this context");
+ return error_mark_node;
+   }
string_tree = USERDEF_LITERAL_VALUE (tok->u.value);
curr_type = cpp_userdef_string_remove_type (tok->type);
curr_tok_is_userdef_p = true;
@@ -5655,7 +5662,7 @@ cp_parser_primary_expression (cp_parser *parser,
 argument to cp_parser_string_literal.  */
return (cp_parser_string_literal (parser,
parser->translate_strings_p,
-   true)
+   /*wide_ok=*/true, /*udl_ok=*/true)
  .maybe_add_location_wrapper ());
  
  case CPP_OPEN_PAREN:

@@ -16161,15 +16168,14 @@ cp_parser_function_specifier_opt (cp_parser* parser,
  static void
  cp_parser_linkage_specification (cp_parser* parser, tree prefix_attr)
  {
-  tree linkage;
-
/* Look for the `extern' keyword.  */
cp_token *extern_token
  = cp_parser_require_keyword (parser, RID_EXTERN, RT_EXTERN);
  
/* Look for the string-literal.  */

cp_token *string_token = cp_lexer_peek_token 

Re: [PATCH 2/5] c++: Set the locus of the function result decl

[Jason Merrill via Gcc-patches]

On 11/12/22 13:45, Bernhard Reutner-Fischer wrote:

gcc/cp/ChangeLog:

* decl.cc (start_function): Set the result decl source location to
the location of the typespec.

---
Bootstrapped and regtested on x86_86-unknown-linux with no regressions.
Ok for trunk?

Cc: Nathan Sidwell 
Cc: Jason Merrill 
---
  gcc/cp/decl.cc | 15 ++-
  1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index 6e98ea35a39..ed40815e645 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -17449,6 +17449,8 @@ start_function (cp_decl_specifier_seq *declspecs,
tree attrs)
  {
tree decl1;
+  tree result;
+  bool ret;


We now prefer to declare new variables as late as possible, usually when 
they are initialized.



decl1 = grokdeclarator (declarator, declspecs, FUNCDEF, 1, );
invoke_plugin_callbacks (PLUGIN_START_PARSE_FUNCTION, decl1);
@@ -17461,7 +17463,18 @@ start_function (cp_decl_specifier_seq *declspecs,
  gcc_assert (same_type_p (TREE_TYPE (TREE_TYPE (decl1)),
 integer_type_node));
  
-  return start_preparsed_function (decl1, attrs, /*flags=*/SF_DEFAULT);

+  ret = start_preparsed_function (decl1, attrs, /*flags=*/SF_DEFAULT);
+
+  /* decl1 might be ggc_freed here.  */
+  decl1 = current_function_decl;
+
+  /* Set the result decl source location to the location of the typespec.  */
+  if (TREE_CODE (decl1) == FUNCTION_DECL
+  && declspecs->locations[ds_type_spec] != UNKNOWN_LOCATION
+  && (result = DECL_RESULT (decl1)) != NULL_TREE
+  && DECL_SOURCE_LOCATION (result) == input_location)
+DECL_SOURCE_LOCATION (result) = declspecs->locations[ds_type_spec];


One way to handle the template case would be for the code in 
start_preparsed_function that sets DECL_RESULT to check whether decl1 is 
a template instantiation, and in that case copy the location from the 
template's DECL_RESULT, i.e.


DECL_RESULT (DECL_TEMPLATE_RESULT (DECL_TI_TEMPLATE (decl1)))


+  return ret;
  }
  
  /* Returns true iff an EH_SPEC_BLOCK should be created in the body of

Re: [PATCH] c++, v2: Implement C++23 P2647R1 - Permitting static constexpr variables in constexpr functions

[Jakub Jelinek via Gcc-patches]

On Tue, Nov 15, 2022 at 06:36:38PM -0500, Jason Merrill wrote:
> > Here is an updated patch that passed bootstrap/regtest, the only
> > change is another testcase tweak.
> > 
> > 2022-11-13  Jakub Jelinek  
> > 
> > gcc/c-family/
> > * c-cppbuiltin.cc (c_cpp_builtins): Bump __cpp_constexpr
> > value from 202207L to 202211L.
> > gcc/cp/
> > * constexpr.cc (cxx_eval_constant_expression): Implement C++23
> > P2647R1 - Permitting static constexpr variables in constexpr functions.
> > Allow decl_maybe_constant_var_p static or thread_local vars for
> > C++23.
> 
> This was accepted as a DR, so it shouldn't be limited to C++23 mode.
> Certainly it should be allowed in C++20 mode; I don't have a strong opinion
> about C++14/17.  Jonathan, do you?

How will a feature with feature test macro with multiple values work as DR?
Or will everything but the macro be treated as a DR (so __cpp_constexpr >=
202211L only for C++23)?
Because __cpp_constexpr >= 202211L is >= 202207L too and that implies
P2448R2 which wasn't a DR and >= 202110L which implies P2242R3 which wasn't a
DR.  And C++20 added other 2 non-DR papers that bumped the value.
C++17 another one.

> > (potential_constant_expression_1): Likewise.
> > gcc/testsuite/
> > * g++.dg/cpp23/constexpr-nonlit17.C: New test.
> > * g++.dg/cpp23/feat-cxx2b.C: Adjust expected __cpp_constexpr
> > value.
> > * g++.dg/ext/stmtexpr19.C: Don't expect an error for C++23 or later.

Jakub

Re: [PATCH] c++, v2: Implement C++23 P2647R1 - Permitting static constexpr variables in constexpr functions

[Jason Merrill via Gcc-patches]

On 11/13/22 01:45, Jakub Jelinek wrote:

On Fri, Nov 11, 2022 at 06:07:04PM +0100, Jakub Jelinek wrote:

The following patch on top of Marek's P2448 PR106649 patch
(mainly because that patch implements the previous __cpp_constexpr
feature test macro bump so this can't go in earlier; OT,
P2280R4 doesn't have any feature test macro?) implements this
simple paper.

Ok for trunk if it passes bootstrap/regtest and is voted into C++23?


Here is an updated patch that passed bootstrap/regtest, the only
change is another testcase tweak.

2022-11-13  Jakub Jelinek  

gcc/c-family/
* c-cppbuiltin.cc (c_cpp_builtins): Bump __cpp_constexpr
value from 202207L to 202211L.
gcc/cp/
* constexpr.cc (cxx_eval_constant_expression): Implement C++23
P2647R1 - Permitting static constexpr variables in constexpr functions.
Allow decl_maybe_constant_var_p static or thread_local vars for
C++23.


This was accepted as a DR, so it shouldn't be limited to C++23 mode. 
Certainly it should be allowed in C++20 mode; I don't have a strong 
opinion about C++14/17.  Jonathan, do you?



(potential_constant_expression_1): Likewise.
gcc/testsuite/
* g++.dg/cpp23/constexpr-nonlit17.C: New test.
* g++.dg/cpp23/feat-cxx2b.C: Adjust expected __cpp_constexpr
value.
* g++.dg/ext/stmtexpr19.C: Don't expect an error for C++23 or later.

--- gcc/c-family/c-cppbuiltin.cc.jj 2022-11-11 17:14:52.021613271 +0100
+++ gcc/c-family/c-cppbuiltin.cc2022-11-11 17:17:45.065265246 +0100
@@ -1074,7 +1074,7 @@ c_cpp_builtins (cpp_reader *pfile)
  /* Set feature test macros for C++23.  */
  cpp_define (pfile, "__cpp_size_t_suffix=202011L");
  cpp_define (pfile, "__cpp_if_consteval=202106L");
- cpp_define (pfile, "__cpp_constexpr=202207L");
+ cpp_define (pfile, "__cpp_constexpr=202211L");
  cpp_define (pfile, "__cpp_multidimensional_subscript=202110L");
  cpp_define (pfile, "__cpp_named_character_escapes=202207L");
  cpp_define (pfile, "__cpp_static_call_operator=202207L");
--- gcc/cp/constexpr.cc.jj  2022-11-11 17:14:52.024613231 +0100
+++ gcc/cp/constexpr.cc 2022-11-11 17:16:54.384952917 +0100
@@ -7085,7 +7085,8 @@ cxx_eval_constant_expression (const cons
&& (TREE_STATIC (r)
|| (CP_DECL_THREAD_LOCAL_P (r) && !DECL_REALLY_EXTERN (r)))
/* Allow __FUNCTION__ etc.  */
-   && !DECL_ARTIFICIAL (r))
+   && !DECL_ARTIFICIAL (r)
+   && (cxx_dialect < cxx23 || !decl_maybe_constant_var_p (r)))
  {
if (!ctx->quiet)
  {
@@ -9577,7 +9578,10 @@ potential_constant_expression_1 (tree t,
tmp = DECL_EXPR_DECL (t);
if (VAR_P (tmp) && !DECL_ARTIFICIAL (tmp))
{
- if (CP_DECL_THREAD_LOCAL_P (tmp) && !DECL_REALLY_EXTERN (tmp))
+ if (CP_DECL_THREAD_LOCAL_P (tmp)
+ && !DECL_REALLY_EXTERN (tmp)
+ && (cxx_dialect < cxx23
+ || !decl_maybe_constant_var_p (tmp)))
{
  if (flags & tf_error)
constexpr_error (DECL_SOURCE_LOCATION (tmp), fundef_p,
@@ -9585,7 +9589,9 @@ potential_constant_expression_1 (tree t,
 "% context", tmp);
  return false;
}
- else if (TREE_STATIC (tmp))
+ else if (TREE_STATIC (tmp)
+  && (cxx_dialect < cxx23
+  || !decl_maybe_constant_var_p (tmp)))
{
  if (flags & tf_error)
constexpr_error (DECL_SOURCE_LOCATION (tmp), fundef_p,
--- gcc/testsuite/g++.dg/cpp23/constexpr-nonlit17.C.jj  2022-11-11 
17:59:59.972852793 +0100
+++ gcc/testsuite/g++.dg/cpp23/constexpr-nonlit17.C 2022-11-11 
17:59:38.725141231 +0100
@@ -0,0 +1,12 @@
+// P2647R1 - Permitting static constexpr variables in constexpr functions
+// { dg-do compile { target c++23 } }
+
+constexpr char
+test ()
+{
+  static const int x = 5;
+  static constexpr char c[] = "Hello World";
+  return *(c + x);
+}
+
+static_assert (test () == ' ');
--- gcc/testsuite/g++.dg/cpp23/feat-cxx2b.C.jj  2022-11-11 17:14:52.194610922 
+0100
+++ gcc/testsuite/g++.dg/cpp23/feat-cxx2b.C 2022-11-11 17:48:56.038865825 
+0100
@@ -134,8 +134,8 @@
  
  #ifndef __cpp_constexpr

  #  error "__cpp_constexpr"
-#elif __cpp_constexpr != 202207
-#  error "__cpp_constexpr != 202207"
+#elif __cpp_constexpr != 202211
+#  error "__cpp_constexpr != 202211"
  #endif
  
  #ifndef __cpp_decltype_auto

--- gcc/testsuite/g++.dg/ext/stmtexpr19.C.jj2020-01-14 20:02:46.839608995 
+0100
+++ gcc/testsuite/g++.dg/ext/stmtexpr19.C   2022-11-12 09:17:40.706245495 
+0100
@@ -8,7 +8,7 @@ const test* setup()
  {
static constexpr test atest =
  {
-  ({ static const int inner = 123;  }) // { dg-error "static" }
+  ({ static const int inner = 123;  }) // { dg-error "static" "" { 
target c++20_down } }
  };
  
return 

Re: [PATCH] c++, v2: Implement CWG 2654 - Un-deprecation of compound volatile assignments

[Jason Merrill via Gcc-patches]

On 11/13/22 01:43, Jakub Jelinek wrote:

On Fri, Nov 11, 2022 at 08:43:04AM +0100, Jakub Jelinek wrote:

Again, because stage1 close is near, posting the following patch
to implement CWG 2654.

Ok for trunk if it passes bootstrap/regtest and is voted into C++23
and C++20 as a DR?


Here is an updated patch that passed bootstrap/regtest, difference
is just a few further testsuite tweaks.


OK.


2022-11-13  Jakub Jelinek  

* typeck.cc (cp_build_modify_expr): Implement CWG 2654
- Un-deprecation of compound volatile assignments.  Remove
-Wvolatile warning about compound volatile assignments.

* g++.dg/cpp2a/volatile1.C (fn2, fn3, racoon): Adjust expected
diagnostics.
* g++.dg/cpp2a/volatile3.C (fn2, fn3, racoon): Likewise.
* g++.dg/cpp2a/volatile5.C (f): Likewise.
* g++.dg/ext/vector25.C (foo): Don't expect a warning.
* g++.dg/cpp1y/new1.C (test_unused): Likewise.

--- gcc/cp/typeck.cc.jj 2022-11-09 11:22:42.617628059 +0100
+++ gcc/cp/typeck.cc2022-11-10 23:19:00.394228067 +0100
@@ -9513,19 +9513,6 @@ cp_build_modify_expr (location_t loc, tr
 && MAYBE_CLASS_TYPE_P (TREE_TYPE (lhstype)))
|| MAYBE_CLASS_TYPE_P (lhstype)));
  
-	  /* An expression of the form E1 op= E2.  [expr.ass] says:

-"Such expressions are deprecated if E1 has volatile-qualified
-type and op is not one of the bitwise operators |, &, ^."
-We warn here rather than in cp_genericize_r because
-for compound assignments we are supposed to warn even if the
-assignment is a discarded-value expression.  */
- if (modifycode != BIT_AND_EXPR
- && modifycode != BIT_IOR_EXPR
- && modifycode != BIT_XOR_EXPR
- && (TREE_THIS_VOLATILE (lhs) || CP_TYPE_VOLATILE_P (lhstype)))
-   warning_at (loc, OPT_Wvolatile,
-   "compound assignment with %-qualified left "
-   "operand is deprecated");
  /* Preevaluate the RHS to make sure its evaluation is complete
 before the lvalue-to-rvalue conversion of the LHS:
  
--- gcc/testsuite/g++.dg/cpp2a/volatile1.C.jj	2022-08-16 13:15:22.739043862 +0200

+++ gcc/testsuite/g++.dg/cpp2a/volatile1.C  2022-11-10 23:23:18.949717772 
+0100
@@ -74,17 +74,17 @@ fn2 ()
decltype(i = vi = 42) x3 = i;
  
// Compound assignments.

-  vi += i; // { dg-warning "assignment with .volatile.-qualified left operand is 
deprecated" "" { target c++20 } }
-  vi -= i; // { dg-warning "assignment with .volatile.-qualified left operand is 
deprecated" "" { target c++20 } }
-  vi %= i; // { dg-warning "assignment with .volatile.-qualified left operand is 
deprecated" "" { target c++20 } }
+  vi += i; // { dg-bogus "assignment with .volatile.-qualified left operand is 
deprecated" }
+  vi -= i; // { dg-bogus "assignment with .volatile.-qualified left operand is 
deprecated" }
+  vi %= i; // { dg-bogus "assignment with .volatile.-qualified left operand is 
deprecated" }
vi ^= i; // { dg-bogus "assignment with .volatile.-qualified left operand is 
deprecated" }
vi |= i; // { dg-bogus "assignment with .volatile.-qualified left operand is 
deprecated" }
vi &= i; // { dg-bogus "assignment with .volatile.-qualified left operand is 
deprecated" }
-  vi /= i; // { dg-warning "assignment with .volatile.-qualified left operand is 
deprecated" "" { target c++20 } }
+  vi /= i; // { dg-bogus "assignment with .volatile.-qualified left operand is 
deprecated" }
vi = vi += 42; // { dg-warning "assignment with .volatile.-qualified left operand is 
deprecated" "" { target c++20 } }
vi += vi = 42; // { dg-warning "assignment with .volatile.-qualified left operand is 
deprecated" "" { target c++20 } }
i *= vi;
-  decltype(vi -= 42) x2 = vi; // { dg-warning "assignment with .volatile.-qualified left 
operand is deprecated" "" { target c++20 } }
+  decltype(vi -= 42) x2 = vi; // { dg-bogus "assignment with .volatile.-qualified 
left operand is deprecated" }
  
// Structured bindings.

int a[] = { 10, 5 };
@@ -107,12 +107,12 @@ fn3 ()
volatile U u;
u.c = 42;
i = u.c = 42; // { dg-warning "assignment with .volatile.-qualified left operand is 
deprecated" "" { target c++20 } }
-  u.c += 42; // { dg-warning "assignment with .volatile.-qualified left operand is 
deprecated" "" { target c++20 } }
+  u.c += 42; // { dg-bogus "assignment with .volatile.-qualified left operand is 
deprecated" }
  
volatile T t;

t.a = 3;
j = t.a = 3; // { dg-warning "assignment with .volatile.-qualified left operand is 
deprecated" "" { target c++20 } }
-  t.a += 3; // { dg-warning "assignment with .volatile.-qualified left operand is 
deprecated" "" { target c++20 } }
+  t.a += 3; // { dg-bogus "assignment with .volatile.-qualified left operand is 
deprecated" }
  
volatile int *src = 

*src; // No assignment, don't warn.
@@ -135,7 

Re: [PATCH] c++, v2: Implement CWG2635 - Constrained structured bindings

[Jason Merrill via Gcc-patches]

On 11/13/22 01:50, Jakub Jelinek wrote:

On Sat, Nov 12, 2022 at 12:23:56PM +0100, Jakub Jelinek wrote:

The following patch implements CWG2635.

So far tested on
GXX_TESTSUITE_STDS=98,11,14,17,20,2b make check-g++ 
RUNTESTFLAGS="dg.exp=decomp*"
ok for trunk if it passes full bootstrap/regtest and it is voted in?


Here is another version of the patch that passed bootstrap/regtest, the only
change are tweaks to 2 further testcases.

2022-11-13  Jakub Jelinek  

* decl.cc (grokdeclarator): Implement
CWG2635 - Constrained structured bindings.  Diagnose constrained
auto type.


Let's make the constrained auto case a pedwarn instead of an error.


* g++.dg/cpp2a/decomp5.C: New test.
* g++.dg/cpp2a/concepts-placeholder7.C: Adjust expected diagnostics.
* g++.dg/cpp2a/concepts-placeholder8.C: Likewise.

--- gcc/cp/decl.cc.jj   2022-11-11 17:14:33.103869977 +0100
+++ gcc/cp/decl.cc  2022-11-12 12:13:52.217239729 +0100
@@ -12660,7 +12660,8 @@ grokdeclarator (const cp_declarator *dec
  gcc_unreachable ();
}
if (TREE_CODE (type) != TEMPLATE_TYPE_PARM
- || TYPE_IDENTIFIER (type) != auto_identifier)
+ || TYPE_IDENTIFIER (type) != auto_identifier
+ || PLACEHOLDER_TYPE_CONSTRAINTS_INFO (type))
{
  if (type != error_mark_node)
{
--- gcc/testsuite/g++.dg/cpp2a/decomp5.C.jj 2022-11-12 12:17:21.024392082 
+0100
+++ gcc/testsuite/g++.dg/cpp2a/decomp5.C2022-11-12 12:20:00.700214521 
+0100
@@ -0,0 +1,20 @@
+// CWG2635 - Constrained structured bindings
+// { dg-do compile { target c++20 } }
+
+namespace std {
+  template struct tuple_size;
+  template struct tuple_element;
+}
+
+struct A {
+  int i;
+  A(int x) : i(x) {}
+  template  int& get() { return i; }
+};
+
+template<> struct std::tuple_size { static const int value = 2; };
+template struct std::tuple_element { using type = int; };
+
+template concept C = true;
+C auto [x, y] = A{1}; // { dg-error "structured binding declaration cannot have type 'auto 
\\\[requires ::C<, >\\\]'" }
+ // { dg-message "type must be cv-qualified 'auto' or reference to 
cv-qualified 'auto'" "" { target *-*-* } .-1 }
--- gcc/testsuite/g++.dg/cpp2a/concepts-placeholder7.C.jj   2021-04-06 
23:49:08.22716 +0200
+++ gcc/testsuite/g++.dg/cpp2a/concepts-placeholder7.C  2022-11-13 
12:17:38.570047510 +0100
@@ -7,16 +7,16 @@ template 
  void f() {
int x[] = {1,2};
int y[] = {3};
-  C1 auto [a,b] = x;
-  C1 auto [c] = y; // { dg-error "constraints" }
+  C1 auto [a,b] = x;   // { dg-error "structured binding declaration cannot have type 'auto 
\\\[requires ::C1<, >\\\]'" }
+  C1 auto [c] = y; // { dg-error "structured binding declaration cannot have type 'auto 
\\\[requires ::C1<, >\\\]'" }
  }
  
  template 

  void g() {
T x[] = {1,2};
T y[] = {3};
-  C1 auto [a,b] = x;
-  C1 auto [c] = y; // { dg-error "constraints" }
+  C1 auto [a,b] = x;   // { dg-error "structured binding declaration cannot have type 'auto 
\\\[requires ::C1<, >\\\]'" }
+  C1 auto [c] = y; // { dg-error "structured binding declaration cannot have type 'auto 
\\\[requires ::C1<, >\\\]'" }
  }
  template void g();
  
@@ -27,6 +27,6 @@ struct S { int a, b; } s;
  
  template 

  void h() {
-  const C2 auto& [a, b] = s;
+  const C2 auto& [a, b] = s;  // { dg-error "structured binding declaration cannot have 
type 'const auto \\\[requires ::C2<, >\\\]'" }
  }
  template void h();
--- gcc/testsuite/g++.dg/cpp2a/concepts-placeholder8.C.jj   2021-04-06 
23:49:08.22716 +0200
+++ gcc/testsuite/g++.dg/cpp2a/concepts-placeholder8.C  2022-11-13 
12:19:17.034684881 +0100
@@ -5,6 +5,6 @@ template  concept is_const = __
  void f() {
int x[] = {1,2};
const int y[] = {3};
-  const is_const auto [a,b] = x; // { dg-error "constraints" }
-  const is_const auto [c] = y;
+  const is_const auto [a,b] = x;   // { dg-error "structured binding declaration cannot 
have type 'const auto \\\[requires ::is_const<, >\\\]'" }
+  const is_const auto [c] = y; // { dg-error "structured binding declaration cannot 
have type 'const auto \\\[requires ::is_const<, >\\\]'" }
  }


Jakub

[PATCH] doc: invoke: pru/riscv: Fix option list formatting

[Christoph Muellner]

From: Christoph Müllner 

This patch fixes a wrong placed closing bracket in the RISC-V option
list and an unneeded @gol in the PRU option list in invoke.texi.

gcc/ChangeLog:

* doc/invoke.texi: Fix PRU/RISC-V option list formatting.

Signed-off-by: Christoph Müllner 
---
 gcc/doc/invoke.texi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 057439a004c..cbfe1102bd2 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -1197,7 +1197,7 @@ See RS/6000 and PowerPC Options.
 
 @emph{PRU Options}
 @gccoptlist{-mmcu=@var{mcu}  -minrt  -mno-relax  -mloop @gol
--mabi=@var{variant} @gol}
+-mabi=@var{variant}}
 
 @emph{RISC-V Options}
 @gccoptlist{-mbranch-cost=@var{N-instruction} @gol
@@ -1220,8 +1220,8 @@ See RS/6000 and PowerPC Options.
 -malign-data=@var{type} @gol
 -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
+-mstack-protector-guard-offset=@var{offset} @gol
+-mcsr-check -mno-csr-check}
 
 @emph{RL78 Options}
 @gccoptlist{-msim  -mmul=none  -mmul=g13  -mmul=g14  -mallregs @gol
-- 
2.38.1

Re: [PATCH] doc: invoke: riscv: Fix closing block bracket

[Christoph Müllner]

On Tue, Nov 15, 2022 at 11:54 PM Andreas Schwab 
wrote:

> On Nov 15 2022, Christoph Muellner wrote:
>
> > diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> > index 057439a004c..dfac7c85844 100644
> > --- a/gcc/doc/invoke.texi
> > +++ b/gcc/doc/invoke.texi
> > @@ -1220,8 +1220,8 @@ See RS/6000 and PowerPC Options.
> >  -malign-data=@var{type} @gol
> >  -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
> > +-mstack-protector-guard-offset=@var{offset} @gol
> > +-mcsr-check -mno-csr-check @gol}
>
> There should be no @gol at the end of the list.
>

I saw the @gol at the end of the PRU Options list (just above RISC-V).
I will make a v2 where I will remove the @gol from there as well.

Thanks,
Christoph



>
> --
> Andreas Schwab, sch...@linux-m68k.org
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
> "And now for something completely different."
>

Re: [PATCH] c++: Alignment changes to layout compatibility/common initial sequence - DR2583

[Jason Merrill via Gcc-patches]

On 11/14/22 01:28, Jakub Jelinek wrote:

Hi!

Working virtually out of Baker Island.

When trying to figure out what to do about alignment,
layout_compatible_type_p returns false if TYPE_ALIGN on
ENUMERAL_TYPE/CLASS_TYPE_P (but not scalar types?) differ, or if members
don't have the same positions.

What is in DR2583 doesn't say anything like that though, on the other side
it says that if the corresponding entities don't have the same alignment
requirements, they aren't part of the common initial sequence.

So, my understanding of this is we shouldn't check TYPE_ALIGN in
layout_compatible_type_p, but instead DECL_ALIGN in
next_common_initial_seqence.


Agreed.


Lightly tested (on is-layout*/is-corresponding*/dr2583.C only) so far,
ok if it passes full bootstrap/regtest?
Or do we need different rules?

2022-11-14  Jakub Jelinek  

* typeck.cc (next_common_initial_seqence): Return false members have
different DECL_ALIGN.
(layout_compatible_type_p): Don't test TYPE_ALIGN of ENUMERAL_TYPE
or CLASS_TYPE_P.

* g++.dg/cpp2a/is-layout-compatible3.C: Expect enums with different
alignas to be layout compatible, while classes with different
alignas on members layout incompatible.
* g++.dg/DRs/dr2583.C: New test.

--- gcc/cp/typeck.cc.jj 2022-11-13 04:53:46.010682269 -1200
+++ gcc/cp/typeck.cc2022-11-13 23:14:41.355180354 -1200
@@ -1833,6 +1833,8 @@ next_common_initial_seqence (tree 
if ((!lookup_attribute ("no_unique_address", DECL_ATTRIBUTES (memb1)))
!= !lookup_attribute ("no_unique_address", DECL_ATTRIBUTES (memb2)))
  return false;
+  if (DECL_ALIGN (memb1) != DECL_ALIGN (memb2))
+return false;
if (!tree_int_cst_equal (bit_position (memb1), bit_position (memb2)))
  return false;
return true;
@@ -1854,15 +1856,13 @@ layout_compatible_type_p (tree type1, tr
type2 = cp_build_qualified_type (type2, TYPE_UNQUALIFIED);
  
if (TREE_CODE (type1) == ENUMERAL_TYPE)

-return (TYPE_ALIGN (type1) == TYPE_ALIGN (type2)
-   && tree_int_cst_equal (TYPE_SIZE (type1), TYPE_SIZE (type2))
+return (tree_int_cst_equal (TYPE_SIZE (type1), TYPE_SIZE (type2))
&& same_type_p (finish_underlying_type (type1),
finish_underlying_type (type2)));
  
if (CLASS_TYPE_P (type1)

&& std_layout_type_p (type1)
&& std_layout_type_p (type2)
-  && TYPE_ALIGN (type1) == TYPE_ALIGN (type2)
&& tree_int_cst_equal (TYPE_SIZE (type1), TYPE_SIZE (type2)))
  {
tree field1 = TYPE_FIELDS (type1);
--- gcc/testsuite/g++.dg/cpp2a/is-layout-compatible3.C.jj   2021-08-18 
21:42:27.414421719 -1200
+++ gcc/testsuite/g++.dg/cpp2a/is-layout-compatible3.C  2022-11-13 
23:20:05.008776825 -1200
@@ -55,10 +55,10 @@ static_assert (!std::is_layout_compatibl
  static_assert (!std::is_layout_compatible_v);
  static_assert (!std::is_layout_compatible_v);
  static_assert (!std::is_layout_compatible_v);
-static_assert (!std::is_layout_compatible_v);
+static_assert (std::is_layout_compatible_v);
  static_assert (!std::is_layout_compatible_v);
  static_assert (!std::is_layout_compatible_v);
  static_assert (!std::is_layout_compatible_v);
-static_assert (std::is_layout_compatible_v);
+static_assert (!std::is_layout_compatible_v);
  static_assert (std::is_layout_compatible_v);
  static_assert (std::is_layout_compatible_v);
--- gcc/testsuite/g++.dg/DRs/dr2583.C.jj2022-11-13 22:58:11.977640606 
-1200
+++ gcc/testsuite/g++.dg/DRs/dr2583.C   2022-11-13 23:18:04.630414835 -1200
@@ -0,0 +1,31 @@
+// DR 2583 - Common initial sequence should consider over-alignment.
+// { dg-do compile { target c++11 } }
+
+#include 
+
+struct A {
+  int i;
+  char c;
+};
+
+struct B {
+  int i;
+  alignas(8) char c;
+};
+
+struct S0 {
+  alignas(16) char x[128];
+  int i;
+};
+
+struct alignas(16) S1 {
+  char x[128];
+  int i;
+};
+
+#if __cpp_lib_is_layout_compatible >= 201907L
+static_assert (std::is_corresponding_member (::i, ::i), "");
+static_assert (alignof (char) == 8 || !std::is_corresponding_member (::c, ::c), 
"");


Maybe

std_is_corresponding_member (::c, ::c) == (alignof (char) == 8)

?

Could also use an alignas(alignof(type)) case to verify that it matches 
a member with no alignas.



+static_assert (alignof (char) == 16 || !std::is_corresponding_member (::x, ::x), 
"");
+static_assert (alignof (char) == 16 || !std::is_corresponding_member (::i, ::i), 
"");
+#endif

Jakub

Re: [PATCH] doc: invoke: riscv: Fix closing block bracket

[Andreas Schwab]

On Nov 15 2022, Christoph Muellner wrote:

> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 057439a004c..dfac7c85844 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -1220,8 +1220,8 @@ See RS/6000 and PowerPC Options.
>  -malign-data=@var{type} @gol
>  -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
> +-mstack-protector-guard-offset=@var{offset} @gol
> +-mcsr-check -mno-csr-check @gol}

There should be no @gol at the end of the list.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

[PATCH] doc: invoke: riscv: Fix closing block bracket

[Christoph Muellner]

From: Christoph Müllner 

This patch fixes a wrong placed closing bracket in the RISC-V section of
invoke.texi.

gcc/ChangeLog:

* doc/invoke.texi: Fix closing block bracket

Signed-off-by: Christoph Müllner 
---
 gcc/doc/invoke.texi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 057439a004c..dfac7c85844 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -1220,8 +1220,8 @@ See RS/6000 and PowerPC Options.
 -malign-data=@var{type} @gol
 -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
+-mstack-protector-guard-offset=@var{offset} @gol
+-mcsr-check -mno-csr-check @gol}
 
 @emph{RL78 Options}
 @gccoptlist{-msim  -mmul=none  -mmul=g13  -mmul=g14  -mallregs @gol
-- 
2.38.1

Re: [PATCH 7/7] riscv: Add support for str(n)cmp inline expansion

[Christoph Müllner]

On Tue, Nov 15, 2022 at 1:46 AM Kito Cheng  wrote:

> Hi Christoph:
>
> > This patch implements expansions for the cmpstrsi and the cmpstrnsi
> > builtins using Zbb instructions (if available).
> > This allows to inline calls to strcmp() and strncmp().
> >
> > The expansion basically emits a peeled comparison sequence (i.e. a peeled
> > comparison loop) which compares XLEN bits per step if possible.
> >
> > The emitted sequence can be controlled, by setting the maximum number
> > of compared bytes (-mstring-compare-inline-limit).
>
> I would like to have a unified option interface,
> maybe -m[no-]inline-str[n]cmp and -minline-str[n]cmp-limit.
>

Ok, I don't mind (in fact, I thought about this as well).
The reason why it is how it is: I took inspiration from the rs6000 backend.


> And add some option like this:
> -minline-str[n]cmp=[bitmanip|vector|auto] in future,
> since I assume we'll have different versions of those things.
>
> >
> > gcc/ChangeLog:
> >
> > * config/riscv/riscv-protos.h (riscv_expand_strn_compare): New
> >   prototype.
> > * config/riscv/riscv-string.cc (GEN_EMIT_HELPER3): New helper
> >   macros.
> > (GEN_EMIT_HELPER2): New helper macros.
> > (expand_strncmp_zbb_sequence): New function.
> > (riscv_emit_str_compare_zbb): New function.
> > (riscv_expand_strn_compare): New function.
> > * config/riscv/riscv.md (cmpstrnsi): Invoke expansion functions
> >   for strn_compare.
> > (cmpstrsi): Invoke expansion functions for strn_compare.
> > * config/riscv/riscv.opt: Add new parameter
> >   '-mstring-compare-inline-limit'.
>
> We need to document this option.
>

Re: [PATCH] RISC-V: Zihintpause: add __builtin_riscv_pause

[Philipp Tomsich]

On Tue, 15 Nov 2022 at 17:40, Jeff Law  wrote:
>
>
> On 11/13/22 13:41, Philipp Tomsich wrote:
> > The Zihintpause extension uses an opcode from the 'fence' opcode range
> > to add a true hint instruction (i.e. if it is not supported on any
> > given platform, the 'fence' that is encoded will not enforce any
> > specific ordering on memory accesses) for entering a low-power state
> > (e.g. in an idle thread).  We expose this new instruction through a
> > machine-dependent builtin to allow generating it without a requirement
> > for any inline assembly.
> >
> > Given that the encoding of 'pause' is valid (as a 'fence' encoding)
> > even for processors that do not (yet) support Zihintpause, we make
> > this builtin available without any further TARGET_* constraints.
> >
> > gcc/ChangeLog:
> >
> >   * config/riscv/riscv-builtins.cc (struct riscv_builtin_description):
> >   add the pause machine-dependent builtin with no result and no
> >  arguments; mark it as always present (pause is a true hint
> >  that encodes into a fence-insn, if not supported with the new
> >  pause semantics).
> >   * config/riscv/riscv-ftypes.def: Add type for void -> void.
> >   * config/riscv/riscv.md (riscv_pause): Add risc_pause and 
> > UNSPECV_PAUSE
> >   * 
> > doc/gcc/extensions-to-the-c-language-family/target-builtins/risc-v-built-in-functions.rst:
> >   Document.
> >   * optabs.cc (maybe_gen_insn): Allow nops == 0 (void -> void).
> >
> > gcc/testsuite/ChangeLog:
> >
> >   * gcc.target/riscv/builtin_pause.c: New test.
>
> OK.  Though I think you'll need to adjust the doc patch now with the
> sphinx work reverted.

Applied to master with the earlier changes to texinfo restored. Thanks!
--Philipp.

Re: [PATCH v2] c++: Disable -Wignored-qualifiers for template args [PR107492]

[Jason Merrill via Gcc-patches]

On 11/14/22 14:33, Marek Polacek wrote:

On Thu, Nov 03, 2022 at 03:22:12PM -0400, Jason Merrill wrote:

On 11/1/22 13:01, Marek Polacek wrote:

It seems wrong to issue a -Wignored-qualifiers warning for code like:

static_assert(!is_same_v);

because there the qualifier matters.  Likewise in template
specialization:

template struct S { };
template<> struct S { };
template<> struct S { }; // OK, not a redefinition

I'm of the mind that we should disable the warning for template
arguments, as in the patch below.


Hmm, I'm not sure why we would want to treat template arguments differently
from other type-ids.  Maybe only warn if funcdecl_p?


I think that makes sense.  There are other contexts in which cv-quals
matter, for instance trailing-return-type.


Well, technically they matter in all contexts, including function 
declaration:


const void f();
template  struct same;
template  struct same{};
same s;

but much more likely to be a confused user in that case, whereas in a 
template context it's likely to be some deep magic.  :)



Updated patch below, plus I've extended the testcase.  Thanks,

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


OK.


-- >8 --
It seems wrong to issue a -Wignored-qualifiers warning for code like:

   static_assert(!is_same_v);

because there the qualifier matters.  Likewise in template
specialization:

   template struct S { };
   template<> struct S { };
   template<> struct S { }; // OK, not a redefinition

And likewise in other type-id contexts such as trailing-return-type:

   auto g() -> const void (*)();

This patch limits the warning to the function declaration context only.

PR c++/107492

gcc/cp/ChangeLog:

* decl.cc (grokdeclarator): Only emit a -Wignored-qualifiers warning
when funcdecl_p.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wignored-qualifiers3.C: New test.
---
  gcc/cp/decl.cc|  6 -
  .../g++.dg/warn/Wignored-qualifiers3.C| 24 +++
  2 files changed, 29 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/warn/Wignored-qualifiers3.C

diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index 890cfcabd35..67b9f24d7d6 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -13038,7 +13038,11 @@ grokdeclarator (const cp_declarator *declarator,
  
  	if (type_quals != TYPE_UNQUALIFIED)

  {
-   if (SCALAR_TYPE_P (type) || VOID_TYPE_P (type))
+   /* It's wrong, for instance, to issue a -Wignored-qualifiers
+  warning for
+   static_assert(!is_same_v);
+   because there the qualifier matters.  */
+   if (funcdecl_p && (SCALAR_TYPE_P (type) || VOID_TYPE_P (type)))
  warning_at (typespec_loc, OPT_Wignored_qualifiers, "type "
  "qualifiers ignored on function return type");
/* [dcl.fct] "A volatile-qualified return type is
diff --git a/gcc/testsuite/g++.dg/warn/Wignored-qualifiers3.C 
b/gcc/testsuite/g++.dg/warn/Wignored-qualifiers3.C
new file mode 100644
index 000..dedb38fc995
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wignored-qualifiers3.C
@@ -0,0 +1,24 @@
+// PR c++/107492
+// { dg-do compile { target c++14 } }
+// { dg-additional-options "-Wignored-qualifiers" }
+
+// Here the 'const' matters, so don't warn.
+template struct S { };
+template<> struct S { };
+template<> struct S { }; // { dg-bogus "ignored" }
+
+template constexpr bool is_same_v = false;
+template constexpr bool is_same_v = true;
+
+static_assert( ! is_same_v< void(*)(), const void(*)() >, ""); // { dg-bogus 
"ignored" }
+
+// Here the 'const' matters as well -> don't warn.
+auto g() -> const void (*)(); // { dg-bogus "ignored" }
+auto g() -> const void (*)() { return nullptr; } // { dg-bogus "ignored" }
+
+// Here as well.
+const void (*h)() = static_cast(h); // { dg-bogus "ignored" }
+
+// But let's keep the warning here.
+const void f(); // { dg-warning "ignored" }
+const void f() { } // { dg-warning "ignored" }

base-commit: c41bbfcaf9d6ef5b57a7e89bba70b861c08a686b

Re: [PATCH] c++, v2: Allow attributes on concepts - DR 2428

[Jason Merrill via Gcc-patches]

On 11/14/22 22:54, Jakub Jelinek wrote:

On Tue, Nov 15, 2022 at 09:54:00AM +0100, Jakub Jelinek via Gcc-patches wrote:

On Mon, Nov 14, 2022 at 07:00:54PM -0500, Jason Merrill wrote:

The following patch adds parsing of attributes to concept definition,
allows deprecated attribute to be specified (some ugliness needed
because CONCEPT_DECL is a cp/*.def attribute and so can't be mentioned
in c-family/ directly; used what is used for objc method decls,
an alternative would be a langhook)


Several of the codes in c-common.def are C++-only, you might just move it
over?


and checks TREE_DEPRECATED in
build_standard_check (not sure if that is the right spot, or whether
it shouldn't be checked also for variable and function concepts and
how to write testcase coverage for that).


I wouldn't bother with var/fn concepts, they're obsolete.


Ok, so like this?
The previous version passed bootstrap/regtest on x86_64-linux and i686-linux,
I'll of course test this one as well.


Better with a patch.  Sorry.


OK.


2022-11-15  Jakub Jelinek  

gcc/c-family/
* c-common.def (CONCEPT_DECL): New tree, moved here from
cp-tree.def.
* c-common.cc (c_common_init_ts): Handle CONCEPT_DECL.
* c-attribs.cc (handle_deprecated_attribute): Allow deprecated
attribute on CONCEPT_DECL.
gcc/cp/
* cp-tree.def (CONCEPT_DECL): Move to c-common.def.
* cp-objcp-common.cc (cp_common_init_ts): Don't handle CONCEPT_DECL
here.
* cp-tree.h (finish_concept_definition): Add ATTRS parameter.
* parser.cc (cp_parser_concept_definition): Parse attributes in
between identifier and =.  Adjust finish_concept_definition
caller.
* pt.cc (finish_concept_definition): Add ATTRS parameter.  Call
cplus_decl_attributes.
* constraint.cc (build_standard_check): If CONCEPT_DECL is
TREE_DEPRECATED, emit -Wdeprecated-declaration warnings.
gcc/testsuite/
* g++.dg/cpp2a/concepts-dr2428.C: New test.

--- gcc/c-family/c-common.def.jj2022-10-14 09:28:27.975164491 +0200
+++ gcc/c-family/c-common.def   2022-11-15 09:34:01.384591076 +0100
@@ -81,6 +81,14 @@ DEFTREECODE (CONTINUE_STMT, "continue_st
 SWITCH_STMT_SCOPE, respectively.  */
  DEFTREECODE (SWITCH_STMT, "switch_stmt", tcc_statement, 4)
  
+/* Extensions for C++ Concepts. */

+
+/* Concept definition. This is not entirely different than a VAR_DECL
+   except that a) it must be a template, and b) doesn't have the wide
+   range of value and linkage options available to variables.  Used
+   by C++ FE and in c-family attribute handling.  */
+DEFTREECODE (CONCEPT_DECL, "concept_decl", tcc_declaration, 0)
+
  /*
  Local variables:
  mode:c
--- gcc/c-family/c-common.cc.jj 2022-11-13 12:29:08.165504692 +0100
+++ gcc/c-family/c-common.cc2022-11-15 09:34:48.828950083 +0100
@@ -8497,6 +8497,8 @@ c_common_init_ts (void)
MARK_TS_EXP (FOR_STMT);
MARK_TS_EXP (SWITCH_STMT);
MARK_TS_EXP (WHILE_STMT);
+
+  MARK_TS_DECL_COMMON (CONCEPT_DECL);
  }
  
  /* Build a user-defined numeric literal out of an integer constant type VALUE

--- gcc/c-family/c-attribs.cc.jj2022-11-14 13:35:34.184160348 +0100
+++ gcc/c-family/c-attribs.cc   2022-11-15 09:30:57.370081060 +0100
@@ -4211,7 +4211,8 @@ handle_deprecated_attribute (tree *node,
  || VAR_OR_FUNCTION_DECL_P (decl)
  || TREE_CODE (decl) == FIELD_DECL
  || TREE_CODE (decl) == CONST_DECL
- || objc_method_decl (TREE_CODE (decl)))
+ || objc_method_decl (TREE_CODE (decl))
+ || TREE_CODE (decl) == CONCEPT_DECL)
TREE_DEPRECATED (decl) = 1;
else if (TREE_CODE (decl) == LABEL_DECL)
{
--- gcc/cp/cp-tree.def.jj   2022-09-29 18:11:34.83800 +0200
+++ gcc/cp/cp-tree.def  2022-11-15 09:32:17.456996090 +0100
@@ -495,11 +495,6 @@ DEFTREECODE (OMP_DEPOBJ, "omp_depobj", t
  
  /* Extensions for Concepts. */
  
-/* Concept definition. This is not entirely different than a VAR_DECL

-   except that a) it must be a template, and b) doesn't have the wide
-   range of value and linkage options available to variables.  */
-DEFTREECODE (CONCEPT_DECL, "concept_decl", tcc_declaration, 0)
-
  /* Used to represent information associated with constrained declarations. */
  DEFTREECODE (CONSTRAINT_INFO, "constraint_info", tcc_exceptional, 0)
  
--- gcc/cp/cp-objcp-common.cc.jj	2022-09-30 18:38:55.349607203 +0200

+++ gcc/cp/cp-objcp-common.cc   2022-11-15 09:34:21.963313049 +0100
@@ -473,7 +473,6 @@ cp_common_init_ts (void)
/* New decls.  */
MARK_TS_DECL_COMMON (TEMPLATE_DECL);
MARK_TS_DECL_COMMON (WILDCARD_DECL);
-  MARK_TS_DECL_COMMON (CONCEPT_DECL);
  
MARK_TS_DECL_NON_COMMON (USING_DECL);
  
--- gcc/cp/cp-tree.h.jj	2022-11-15 08:17:07.561388452 +0100

+++ gcc/cp/cp-tree.h2022-11-15 09:30:57.371081046 +0100
@@ -8324,7 +8324,7 @@ struct diagnosing_failed_constraint
  extern cp_expr finish_constraint_or_expr  (location_t, cp_expr, cp_expr);
  extern 

Re: [PATCH] c++: Fix up calls to static operator() or operator[] [PR107624]

[Jason Merrill via Gcc-patches]

On 11/15/22 02:28, Jakub Jelinek wrote:

Hi!

On Mon, Nov 14, 2022 at 06:29:44PM -0500, Jason Merrill wrote:

Indeed.  The code in build_new_method_call for this case has the comment

   /* In an expression of the form `a->f()' where `f' turns
  out to be a static member function, `a' is
  none-the-less evaluated.  */


Had to tweak 3 spots for this.  Furthermore, found that if in non-pedantic
C++20 compilation static operator[] is accepted, we required that it has 2
arguments, I think it is better to require exactly one because that case
is the only one that will actually work in C++20 and older.

Lightly tested so far, ok for trunk if it passes bootstrap/regtest?

Or do you want to outline the
  if (result != error_mark_node
  && TREE_CODE (TREE_TYPE (cand->fn)) != METHOD_TYPE
  && TREE_SIDE_EFFECTS (obj))
{
  /* But avoid the implicit lvalue-rvalue conversion when 'a'
 is volatile.  */
  tree a = obj;
  if (TREE_THIS_VOLATILE (a))
a = build_this (a);
  if (TREE_SIDE_EFFECTS (a))
result = build2 (COMPOUND_EXPR, TREE_TYPE (result), a, result);
}
part that is now repeated 4 times to some helper function?  If yes,
any suggestion on a good name?


Please.  Maybe keep_unused_object_arg?


2022-11-15  Jakub Jelinek  

PR c++/107624
* call.cc (build_op_call): If obj has side-effects
and operator() is static member function, return COMPOUND_EXPR
with the obj side-effects other than reading from volatile
object.
(build_op_subscript): Likewise.
(build_new_op): Similarly for ARRAY_REF, just for arg1 rather than
obj.
* decl.cc (grok_op_properties): For C++20 and earlier, if operator[]
is static member function, require exactly one parameter rather than
exactly two parameters.

* g++.dg/cpp23/static-operator-call4.C: New test.
* g++.dg/cpp23/subscript10.C: New test.
* g++.dg/cpp23/subscript11.C: New test.

--- gcc/cp/call.cc.jj   2022-11-15 07:59:57.337231337 +0100
+++ gcc/cp/call.cc  2022-11-15 13:02:33.369531156 +0100
@@ -5137,7 +5137,24 @@ build_op_call (tree obj, vecfn) == FUNCTION_DECL
   && DECL_OVERLOADED_OPERATOR_P (cand->fn)
   && DECL_OVERLOADED_OPERATOR_IS (cand->fn, CALL_EXPR))
-   result = build_over_call (cand, LOOKUP_NORMAL, complain);
+   {
+ result = build_over_call (cand, LOOKUP_NORMAL, complain);
+ /* In an expression of the form `a()' where cand->fn
+which is operator() turns out to be a static member function,
+`a' is none-the-less evaluated.  */
+ if (result != error_mark_node
+ && TREE_CODE (TREE_TYPE (cand->fn)) != METHOD_TYPE
+ && TREE_SIDE_EFFECTS (obj))
+   {
+ /* But avoid the implicit lvalue-rvalue conversion when 'a'
+is volatile.  */
+ tree a = obj;
+ if (TREE_THIS_VOLATILE (a))
+   a = build_this (a);
+ if (TREE_SIDE_EFFECTS (a))
+   result = build2 (COMPOUND_EXPR, TREE_TYPE (result), a, result);
+   }
+   }
else
{
  if (TREE_CODE (cand->fn) == FUNCTION_DECL)
@@ -7046,6 +7063,24 @@ build_new_op (const op_location_t ,
  gcc_unreachable ();
}
}
+
+ /* In an expression of the form `a[]' where cand->fn
+which is operator[] turns out to be a static member function,
+`a' is none-the-less evaluated.  */
+ if (code == ARRAY_REF
+ && result
+ && result != error_mark_node
+ && TREE_CODE (TREE_TYPE (cand->fn)) != METHOD_TYPE
+ && TREE_SIDE_EFFECTS (arg1))
+   {
+ /* But avoid the implicit lvalue-rvalue conversion when 'a'
+is volatile.  */
+ tree a = arg1;
+ if (TREE_THIS_VOLATILE (a))
+   a = build_this (a);
+ if (TREE_SIDE_EFFECTS (a))
+   result = build2 (COMPOUND_EXPR, TREE_TYPE (result), a, result);
+   }
}
else
{
@@ -7302,6 +7337,24 @@ build_op_subscript (const op_location_t
  /* Specify evaluation order as per P0145R2.  */
  CALL_EXPR_ORDERED_ARGS (call) = op_is_ordered (ARRAY_REF) == 1;
}
+
+ /* In an expression of the form `a[]' where cand->fn
+which is operator[] turns out to be a static member function,
+`a' is none-the-less evaluated.  */
+ if (result
+ && result != error_mark_node
+ && TREE_CODE (TREE_TYPE (cand->fn)) != METHOD_TYPE
+ && TREE_SIDE_EFFECTS (obj))
+   {
+ /* But avoid the implicit lvalue-rvalue conversion when 'a'
+is volatile.  

Re: [PATCH] RISC-V: Use .p2align for code-alignment

[Philipp Tomsich]

Jeff,

On Tue, 15 Nov 2022 at 17:37, Jeff Law  wrote:
>
>
> On 11/13/22 13:41, Philipp Tomsich wrote:
>
> RISC-V's .p2align (currently) ignores the max-skip argument.  As we
> have experimental patches underway to address this in a
> backwards-compatible manner, let's prepare GCC for the day when
> binutils gets updated.
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Implement.
>
>
> What are the implications if we start using p2align immediately when the 
> current (broken?) state of the assembler?  I'm pretty sure configure is 
> already turning on HAVE_GAS_SKIP_P2ALIGN.  From a native risc-v build:
>
>
> auto-host.h:#define HAVE_GAS_MAX_SKIP_P2ALIGN 1

This is your tree, which has the (partial fix — i.e., the best we can
do without breaking backward compatibility) for .p2align.
When building against upstream binutils, this should not be defined.

Philipp.

[PATCH] Fortran: ICE in simplification of array expression involving power [PR107680]

[Harald Anlauf via Gcc-patches]

Dear all,

when constant expressions involve parentheses, array constructors,
typespecs, and the power operator (**), we could fail with an ICE
during simplification in arith_power.

Debugging of the testcase showed we call the proper type conversions
needed for the arithmetic operation, but under certain circumstances
we seem to lose the typespec on the way to the invocation of the
simplification.  We then run into unhandled combinations of operand
types.

The attached patch is likely a sort of a band-aid to the problem:
we check the operand types in arith_power, and if we see that a
conversion is (still) needed, we punt and defer the simplification.

AFAICT this is safe.  It does not address a possibly deeply
covered issue in gfortran, which was suspected when analyzing
pr107000.  But as this is elusive, that may be hard to locate
and fix.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

Thanks,
Harald

From efe9dafabc2e2cc2dab079dfa3be3d09b3471c0f Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Tue, 15 Nov 2022 21:20:20 +0100
Subject: [PATCH] Fortran: ICE in simplification of array expression involving
 power [PR107680]

gcc/fortran/ChangeLog:

	PR fortran/107680
	* arith.cc (arith_power): Check that operands are properly converted
	before attempting to simplify.

gcc/testsuite/ChangeLog:

	PR fortran/107680
	* gfortran.dg/pr107680.f90: New test.
---
 gcc/fortran/arith.cc   |  7 ++
 gcc/testsuite/gfortran.dg/pr107680.f90 | 34 ++
 2 files changed, 41 insertions(+)
 create mode 100644 gcc/testsuite/gfortran.dg/pr107680.f90

diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc
index fc9224ebc5c..c4ab75b401c 100644
--- a/gcc/fortran/arith.cc
+++ b/gcc/fortran/arith.cc
@@ -845,6 +845,13 @@ arith_power (gfc_expr *op1, gfc_expr *op2, gfc_expr **resultp)
   if (!gfc_numeric_ts (>ts) || !gfc_numeric_ts (>ts))
 return ARITH_INVALID_TYPE;

+  /* The result type is derived from op1 and must be compatible with the
+ result of the simplification.  Otherwise postpone simplification until
+ after operand conversions usually done by gfc_type_convert_binary.  */
+  if ((op1->ts.type == BT_INTEGER && op2->ts.type != BT_INTEGER)
+  || (op1->ts.type == BT_REAL && op2->ts.type == BT_COMPLEX))
+return ARITH_NOT_REDUCED;
+
   rc = ARITH_OK;
   result = gfc_get_constant_expr (op1->ts.type, op1->ts.kind, >where);

diff --git a/gcc/testsuite/gfortran.dg/pr107680.f90 b/gcc/testsuite/gfortran.dg/pr107680.f90
new file mode 100644
index 000..4ed431eb06f
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr107680.f90
@@ -0,0 +1,34 @@
+! { dg-do compile }
+! { dg-options "-fdump-tree-original" }
+! PR fortran/107680 - ICE in arith_power
+! Contributed by G.Steinmetz
+
+program p
+  real,parameter :: x(*) = [real:: ([1])]   **  2.0
+  complex, parameter :: y(*) = [real:: ([1])]   ** (2.0,1.0)
+  complex, parameter :: z(*) = [complex :: ([1])]   ** (2.0,1.0)
+  complex, parameter :: u(*) = [complex :: ([1.0])] ** (2.0,1.0)
+  complex, parameter :: v(*) = [real:: ([(1.0,2.0)])] ** (3.0,1.0)
+  complex, parameter :: w(*) = [integer :: ([(1.0,2.0)])] ** (3.0,1.0)
+  print *, [real:: ([3])]   **  2
+  print *, [real:: ([3])]   **  2.0
+  print *, [real:: ([1])]   ** (1.0,2.0)
+  print *, [real:: ([1.0])] ** (1.0,2.0)
+  print *, [complex :: ([3])]   **  2
+  print *, [complex :: ([3])]   **  2.0
+  print *, [complex :: ([1])]   ** (1.0,2.0)
+  print *, [complex :: ([1.0])] ** (1.0,2.0)
+  print *, [integer :: ([3.0])] **  2
+  print *, [integer :: ([3.0])] **  2.0
+  print *, [integer :: ([1.0])] ** (1.0,2.0)
+  print *, [integer :: ([(1.0,2.0)])] ** (3.0,1.0)
+  print *, v(1)
+  if (u(1) /= 1) stop 1
+  if (v(1) /= 1) stop 2
+  if (w(1) /= 1) stop 3
+  if (x(1) /= 1) stop 4
+  if (y(1) /= 1) stop 5
+  if (z(1) /= 1) stop 6
+end
+
+! { dg-final { scan-tree-dump-not "_gfortran_stop_numeric" "original" } }
--
2.35.3

Re: [PATCH Rust front-end v3 01/46] Use DW_ATE_UTF for the Rust 'char' type

[Marc Poulhiès via Gcc-patches]

Mark Wielaard  writes:

> https://code.wildebeest.org/git/user/mjw/gccrs/commit/?h=no-Rust-old
> if someone wants to push that, to merge for a v4.

Sorry, missed that part, taking care of merging it right now :)

https://github.com/Rust-GCC/gccrs/pull/1649

Thanks,
Marc

Re: [PATCH] RISC-V uninit-pred-9_b.c failure

[Jeff Law via Gcc-patches]

On 11/15/22 12:08, Kevin Lee wrote:

The gimple generated by riscv is identical to that of powerpc64
currently. It seems like the change at 
r12-4790-4b3a325f07acebf47e82de227ce1d5ba62f5bcae also affected riscv64 like 
powerpc64 and cris.

gcc/testsuite/ChangeLog:

* gcc.dg/uninit-pred-9_b.c: Xfail for riscv64


Note that if we start adjusting BRANCH_COST then this may need further 
refinement, but I think it's fine for now.



OK

jeff

[PATCH] RISC-V uninit-pred-9_b.c failure

[Kevin Lee]

The gimple generated by riscv is identical to that of powerpc64
currently. It seems like the change at 
r12-4790-4b3a325f07acebf47e82de227ce1d5ba62f5bcae also affected riscv64 like 
powerpc64 and cris.

gcc/testsuite/ChangeLog:

* gcc.dg/uninit-pred-9_b.c: Xfail for riscv64
---
 gcc/testsuite/gcc.dg/uninit-pred-9_b.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/uninit-pred-9_b.c 
b/gcc/testsuite/gcc.dg/uninit-pred-9_b.c
index 53c4a5399ea..843f5323713 100644
--- a/gcc/testsuite/gcc.dg/uninit-pred-9_b.c
+++ b/gcc/testsuite/gcc.dg/uninit-pred-9_b.c
@@ -17,7 +17,7 @@ int foo (int n, int l, int m, int r)
 
   if (l > 100)
 if ( (n <= 9) &&  (m < 100)  && (r < 19) )
-  blah(v); /* { dg-bogus "uninitialized" "bogus warning" { xfail 
powerpc64*-*-* cris-*-* } } */
+  blah(v); /* { dg-bogus "uninitialized" "bogus warning" { xfail 
powerpc64*-*-* cris-*-* riscv64*-*-* } */
 
   if ( (n <= 8) &&  (m < 99)  && (r < 19) )
   blah(v); /* { dg-bogus "uninitialized" "pr101674" { xfail mmix-*-* } } */
-- 
2.25.1

[committed] bpf: avoid possible use of uninitialized variable

[David Faust via Gcc-patches]

Fix a maybe-uninitialized warning introduced in commit:
068baae1864 bpf: add preserve_field_info builtin

Thanks to Jan-Benedict Glaw for pointing this out.

Tested on bpf-unknown-none, committed as obvious.

gcc/

* config/bpf/bpf.cc (bpf_expand_builtin): Avoid use of uninitialized
variable in error case.
---
 gcc/config/bpf/bpf.cc | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/gcc/config/bpf/bpf.cc b/gcc/config/bpf/bpf.cc
index 16af2412bf6..51e46955015 100644
--- a/gcc/config/bpf/bpf.cc
+++ b/gcc/config/bpf/bpf.cc
@@ -1254,11 +1254,14 @@ bpf_expand_builtin (tree exp, rtx target 
ATTRIBUTE_UNUSED,
   /* A resolved overloaded __builtin_preserve_field_info.  */
   tree src = CALL_EXPR_ARG (exp, 0);
   tree kind_tree = CALL_EXPR_ARG (exp, 1);
-  unsigned HOST_WIDE_INT kind_val;
+  unsigned HOST_WIDE_INT kind_val = 0;
   if (tree_fits_uhwi_p (kind_tree))
kind_val = tree_to_uhwi (kind_tree);
   else
-   error ("invalid argument to built-in function");
+   {
+ error ("invalid argument to built-in function");
+ return expand_normal (error_mark_node);
+   }
 
   enum btf_core_reloc_kind kind = (enum btf_core_reloc_kind) kind_val;
 
-- 
2.37.2

Re: [PATCH v2] analyzer: add warnings relating to sockets [PR106140]

[David Malcolm via Gcc-patches]

On Fri, 2022-11-11 at 22:27 -0500, David Malcolm wrote:
> Changed in v2: ported doc changes from texinfo to sphinx
> 
> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
> 
> I can self-approve this patch, but it depends on the named constants
> patch here:
>   * [PATCH v2] c, analyzer: support named constants in analyzer
> [PR106302]
>     *
> https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605835.html
> which requires review of the C frontend changes.

Marek approved v3 of the named constants patch (thanks!), so I've now
committed both that, and this (ported back to texinfo from sphinx) to
trunk, as:
  r13-4073-gd8aba860b34203
and
  r13-4074-g86a90006864840
respectively.

Dave

Re: why does gcc jit require pthread?

[Jonathan Wakely via Gcc-patches]

On Tue, 15 Nov 2022 at 18:50, David Malcolm  wrote:
>
> [Fixing typo in the Subject ("git" -> "jit" ); CCing jit mailing list]
>
> On Fri, 2022-11-11 at 17:16 +, Jonathan Wakely wrote:
> > On Mon, 7 Nov 2022 at 13:51, Jonathan Wakely wrote:
> > >
> > > On Mon, 7 Nov 2022 at 13:33, LIU Hao wrote:
> > > >
> > > > 在 2022-11-07 20:57, Jonathan Wakely 写道:
> > > > > It would be a lot nicer if playback::context met the C++
> > > > > Lockable
> > > > > requirements, and playback::context::compile () could just take
> > > > > a
> > > > > scoped lock on *this:
> > > > >
> > > > >
> > > >
> > > > Yeah yeah that makes a lot of sense. Would you please just commit
> > > > that? I don't have write access to
> > > > GCC repo, and it takes a couple of hours for me to bootstrap GCC
> > > > just for this tiny change.
> > >
> > > Somebody else needs to approve it first. I'll combine our patches
> > > and
> > > test and submit it properly for approval.
> >
> > Here's a complete patch that actually builds now, although I'm seeing
> > a stage 2 vs stage 3 comparison error which I don't have time to look
> > into right now.
>
> I confess that I'm not familiar with C++11's mutex and locking types,
> but having read through the relevant entries on cppreference.com, the
> patch looks correct to me.
>
> Are these classes well-supported on the minimum compiler version we
> support?  (Jonathan, I defer to your judgement here)

std::mutex has been supported since 4.4.0 and is very simple. The
implementation on trunk is identical to the one in gcc 4.8.5 except
for adding 'noexcept' to mutex::native_handle (), which is not
relevant to this change.

> Jonathan: you said in your followup email that it "bootstraps and
> passes testing on x86_64-pc-linux-gnu (CentOS 8 Stream)".  This is
> possibly a silly question, but did this testing include the jit
> testsuite?  A gotcha here is that --enable-languages=all does *not*
> enable jit.

Yes, I built with --enable-languages=c,c++,jit --enable-host-shared

> The patch is OK for trunk if you have favorable answers for the above
> two questions.
>
> Thanks!
> Dave
>

Re: why does gcc jit require pthread?

[David Malcolm via Gcc-patches]

[Fixing typo in the Subject ("git" -> "jit" ); CCing jit mailing list]

On Fri, 2022-11-11 at 17:16 +, Jonathan Wakely wrote:
> On Mon, 7 Nov 2022 at 13:51, Jonathan Wakely wrote:
> > 
> > On Mon, 7 Nov 2022 at 13:33, LIU Hao wrote:
> > > 
> > > 在 2022-11-07 20:57, Jonathan Wakely 写道:
> > > > It would be a lot nicer if playback::context met the C++
> > > > Lockable
> > > > requirements, and playback::context::compile () could just take
> > > > a
> > > > scoped lock on *this:
> > > > 
> > > > 
> > > 
> > > Yeah yeah that makes a lot of sense. Would you please just commit
> > > that? I don't have write access to
> > > GCC repo, and it takes a couple of hours for me to bootstrap GCC
> > > just for this tiny change.
> > 
> > Somebody else needs to approve it first. I'll combine our patches
> > and
> > test and submit it properly for approval.
> 
> Here's a complete patch that actually builds now, although I'm seeing
> a stage 2 vs stage 3 comparison error which I don't have time to look
> into right now.

I confess that I'm not familiar with C++11's mutex and locking types,
but having read through the relevant entries on cppreference.com, the
patch looks correct to me.

Are these classes well-supported on the minimum compiler version we
support?  (Jonathan, I defer to your judgement here)

Jonathan: you said in your followup email that it "bootstraps and
passes testing on x86_64-pc-linux-gnu (CentOS 8 Stream)".  This is
possibly a silly question, but did this testing include the jit
testsuite?  A gotcha here is that --enable-languages=all does *not*
enable jit.

The patch is OK for trunk if you have favorable answers for the above
two questions.

Thanks!
Dave

[Patch] nvptx/mkoffload.cc: Fix "$nohost" check

[Tobias Burnus]

Found when working on real reverse offload - as
the reverse-offload stub function was added to the reverse-offload table.
Reason - as mentioned in the commit log: lhd_set_decl_assembler_name.

I intent to commit it tomorrow as obvious, unless there are further
comments.

Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
nvptx/mkoffload.cc: Fix "$nohost" check

If lhd_set_decl_assembler_name is invoked - in particular if
!TREE_PUBLIC (decl) && !DECL_FILE_SCOPE_P (decl) - the '.nohost' suffix
might change to '.nohost.2'. This happens for the existing reverse offload
testcases via cgraph_node::analyze and is a side effect of
r13-3455-g178ac530fe67e4f2fc439cc4ce89bc19d571ca31 for some reason.

The solution is to not only check for a tailing '$nohost' but also for
'$nohost$' in nvptx/mkoffload.cc.

gcc/ChangeLog:

	* config/nvptx/mkoffload.cc (process): Recognize '$nohost$...'
	besides tailing '$nohost' as being for reverse offload.

 gcc/config/nvptx/mkoffload.cc | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/gcc/config/nvptx/mkoffload.cc b/gcc/config/nvptx/mkoffload.cc
index 854cd72f3c7..5d89ba8a788 100644
--- a/gcc/config/nvptx/mkoffload.cc
+++ b/gcc/config/nvptx/mkoffload.cc
@@ -364,7 +364,8 @@ process (FILE *in, FILE *out, uint32_t omp_requires)
 	 Alternatively, besides searching for 'BEGIN FUNCTION DECL',
 	 checking for '.visible .entry ' + id->ptx_name would be
 	 required.  */
-	  if (!endswith (id->ptx_name, "$nohost"))
+	  if (!endswith (id->ptx_name, "$nohost")
+	  && !strstr (id->ptx_name, "$nohost$"))
 	continue;
 	  fprintf (out, "\t\".extern ");
 	  const char *p = input + file_idx[fidx];
@@ -402,7 +403,8 @@ process (FILE *in, FILE *out, uint32_t omp_requires)
 		"$offload_func_table[] = {");
   for (comma = "", id = func_ids; id; comma = ",", id = id->next)
 	fprintf (out, "%s\"\n\t\t\"%s", comma,
-		 endswith (id->ptx_name, "$nohost") ? id->ptx_name : "0");
+		 (endswith (id->ptx_name, "$nohost")
+		  || strstr (id->ptx_name, "$nohost$")) ? id->ptx_name : "0");
   fprintf (out, "};\\n\";\n\n");
 }
 

Re: [PATCH v3] c, analyzer: support named constants in analyzer [PR106302]

[Marek Polacek via Gcc-patches]

On Tue, Nov 15, 2022 at 01:35:05PM -0500, David Malcolm wrote:
> On Mon, 2022-11-14 at 15:42 -0500, Marek Polacek wrote:
> > On Fri, Nov 11, 2022 at 10:23:10PM -0500, David Malcolm wrote:
> > > Changes since v1: ported the doc changes from texinfo to sphinx
> > > 
> > > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
> > > 
> > > Are the C frontend parts OK for trunk?  (I can self-approve the
> > > analyzer parts)
> > 
> > Sorry for the delay.
> >  
> > > The patch adds an interface for frontends to call into the analyzer
> > > as
> > > the translation unit finishes.  The analyzer can then call back
> > > into the
> > > frontend to ask about the values of the named constants it cares
> > > about
> > > whilst the frontend's data structures are still around.
> > > 
> > > The patch implements this for the C frontend, which looks up the
> > > names
> > > by looking for named CONST_DECLs (which handles enum values). 
> > > Failing
> > > that, it attempts to look up the values of macros but only the
> > > simplest
> > > cases are supported (a non-traditional macro with a single
> > > CPP_NUMBER
> > > token).  It does this by building a buffer containing the macro
> > > definition and rerunning a lexer on it.
> > > 
> > > The analyzer gracefully handles the cases where named values aren't
> > > found (such as anything more complicated than described above).
> > > 
> > > The patch ports the analyzer to use this mechanism for "O_RDONLY",
> > > "O_WRONLY", and "O_ACCMODE".  I have successfully tested my socket
> > > patch
> > > to also use this for "SOCK_STREAM" and "SOCK_DGRAM", so the
> > > technique
> > > seems to work.
> > 
> > So this works well for code like
> > 
> > enum __socket_type {
> > SOCK_STREAM = 1,
> > 
> > #define SOCK_STREAM SOCK_STREAM
> > };
> > 
> > ?
> 
> Yes: c_translation_unit::lookup_constant_by_id does the "lookup_name"
> first, and this finds the CONST_DECL, so it doesn't need to look at
> macros for this case.

Ah, nice.
 
> I've added a testcase for this in the v3 patch (gcc.dg/analyzer/named-
> constants-via-enum-and-macro.c)

Thanks.

> Thanks for the review.  Here's a v3 version of the patch.
> 
> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
> 
> Are the C FE parts OK for trunk?

Ok, thanks.
 

Marek

[PATCH v3] c, analyzer: support named constants in analyzer [PR106302]

[David Malcolm via Gcc-patches]

On Mon, 2022-11-14 at 15:42 -0500, Marek Polacek wrote:
> On Fri, Nov 11, 2022 at 10:23:10PM -0500, David Malcolm wrote:
> > Changes since v1: ported the doc changes from texinfo to sphinx
> > 
> > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
> > 
> > Are the C frontend parts OK for trunk?  (I can self-approve the
> > analyzer parts)
> 
> Sorry for the delay.
>  
> > The patch adds an interface for frontends to call into the analyzer
> > as
> > the translation unit finishes.  The analyzer can then call back
> > into the
> > frontend to ask about the values of the named constants it cares
> > about
> > whilst the frontend's data structures are still around.
> > 
> > The patch implements this for the C frontend, which looks up the
> > names
> > by looking for named CONST_DECLs (which handles enum values). 
> > Failing
> > that, it attempts to look up the values of macros but only the
> > simplest
> > cases are supported (a non-traditional macro with a single
> > CPP_NUMBER
> > token).  It does this by building a buffer containing the macro
> > definition and rerunning a lexer on it.
> > 
> > The analyzer gracefully handles the cases where named values aren't
> > found (such as anything more complicated than described above).
> > 
> > The patch ports the analyzer to use this mechanism for "O_RDONLY",
> > "O_WRONLY", and "O_ACCMODE".  I have successfully tested my socket
> > patch
> > to also use this for "SOCK_STREAM" and "SOCK_DGRAM", so the
> > technique
> > seems to work.
> 
> So this works well for code like
> 
> enum __socket_type {
> SOCK_STREAM = 1,
> 
> #define SOCK_STREAM SOCK_STREAM
> };
> 
> ?

Yes: c_translation_unit::lookup_constant_by_id does the "lookup_name"
first, and this finds the CONST_DECL, so it doesn't need to look at
macros for this case.

I've added a testcase for this in the v3 patch (gcc.dg/analyzer/named-
constants-via-enum-and-macro.c)

> 
> > diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc
> > index d70697b1d63..efe19fbe70b 100644
> > --- a/gcc/c/c-parser.cc
> > +++ b/gcc/c/c-parser.cc
> > @@ -72,6 +72,8 @@ along with GCC; see the file COPYING3.  If not
> > see
> >  #include "memmodel.h"
> >  #include "c-family/known-headers.h"
> >  #include "bitmap.h"
> > +#include "analyzer/analyzer-language.h"
> > +#include "toplev.h"
> >  
> >  /* We need to walk over decls with incomplete struct/union/enum
> > types
> > after parsing the whole translation unit.
> > @@ -1662,6 +1664,87 @@ static bool
> > c_parser_objc_diagnose_bad_element_prefix
> >(c_parser *, struct c_declspecs *);
> >  static location_t c_parser_parse_rtl_body (c_parser *, char *);
> >  
> > +#if ENABLE_ANALYZER
> > +
> > +namespace ana {
> > +
> > +/* Concrete implementation of ana::translation_unit for the C
> > frontend.  */
> > +
> > +class c_translation_unit : public translation_unit
> > +{
> > +public:
> > +  /* Implementation of translation_unit::lookup_constant_by_id for
> > use by the
> > + analyzer to look up named constants in the user's source
> > code.  */
> > +  tree lookup_constant_by_id (tree id) const final override
> > +  {
> > +/* Consider decls.  */
> > +if (tree decl = lookup_name (id))
> > +  if (TREE_CODE (decl) == CONST_DECL)
> > +   if (tree value = DECL_INITIAL (decl))
> > + if (TREE_CODE (value) == INTEGER_CST)
> > +   return value;
> > +
> > +/* Consider macros.  */
> > +cpp_hashnode *hashnode = C_CPP_HASHNODE (id);
> > +if (cpp_macro_p (hashnode))
> > +  if (tree value = consider_macro (hashnode->value.macro))
> > +   return value;
> > +
> > +return NULL_TREE;
> > +  }
> > +
> > +private:
> > +  /* Attempt to get an INTEGER_CST from MACRO.
> > + Only handle the simplest cases: where MACRO's definition is a
> > single
> > + token containing a number, by lexing the number again.
> > + This will handle e.g.
> > +   #define NAME 42
> > + and other bases but not negative numbers, parentheses or e.g.
> > +   #define NAME 1 << 7
> > + as doing so would require a parser.  */
> > +  tree consider_macro (cpp_macro *macro) const
> > +  {
> > +if (macro->paramc > 0)
> > +  return NULL_TREE;
> > +if (macro->kind == cmk_traditional)
> 
> Do you really want to handle cmk_assert?  I'd say you want
> 
>   if (macro->kind != cmk_macro)

Thanks; fixed in the v3 patch.

> 
> > +  return NULL_TREE;
> > +if (macro->count != 1)
> > +  return NULL_TREE;
> > +const cpp_token  = macro->exp.tokens[0];
> > +if (tok.type != CPP_NUMBER)
> > +  return NULL_TREE;
> > +
> > +cpp_reader *old_parse_in = parse_in;
> > +parse_in = cpp_create_reader (c_dialect_cxx () ? CLK_GNUCXX:
> > CLK_GNUC89,
> > + ident_hash, line_table);
> 
> Why not always CLK_GNUC89 since we're in the C FE?

Fixed (I was copying and pasting from a selftest in input.c, IIRC).

> 
> > +
> > +pretty_printer pp;
> > +pp_string (, (const char 

Re: [PATCH] libstdc++: Enable building libstdc++.{a,so} when !HOSTED

[Arsen Arsenović via Gcc-patches]

Jonathan Wakely  writes:

> On Thu, 20 Oct 2022 at 16:53, Arsen Arsenović via Libstdc++
>  wrote:
>>
>> This enables us to provide symbols for placeholders and numeric limits,
>
>
> I'm not convinced this is worth doing.
>
> The placeholders and the numeric_limits members are all inline
> variables for C++17 and later, and C++17 is the compiler's default
> mode. The placeholders aren't even required to exist for freestanding
> prior to C++23. For the numeric_limits definitions, I suppose it is a
> problem that users can't take their address in freestanding today
> unless they compile as C++17.
>
>> and allows users to mess about with linker flags less.
>
> i.e. they don't have to use -nostdlib and/or link with gcc -lsupc++,
> but can just use g++?
>
> That seems more compelling than providing definitions of the
> placeholders and limits members.

Indeed, with just a few more changes that I didn't get the chance to
polish up before S3 (setting the MATH_LIBRARY target macro to "" and
disabling linking crt0 when building --without-headers
--without-newlib), and the other patches I did submit, I could get a
freestanding test program building with just -nolibc:

  i686-elf-g++ -ffreestanding -ggdb3 -O2 -fno-omit-frame-pointer \
-std=gnu++20 -T ../linkscript.ld -nolibc \
-Wl,-z,max-page-size=0x1000 -o frello frello-main.o frello-abort.o \
-frello-support.o frello-memory.o frello-logging.o frello-assert.o \
frello-entry.o

Most of these flags serve unrelated purposes, and the linker script is
the default one for this configuration, with some sections shifted
about.

Have a great evening!
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: [AArch64] Enable generation of FRINTNZ instructions

[Richard Sandiford via Gcc-patches]

"Andre Vieira (lists)"  writes:
> On 07/11/2022 11:05, Richard Biener wrote:
>> On Fri, 4 Nov 2022, Andre Vieira (lists) wrote:
>>
>>> Sorry for the delay, just been reminded I still had this patch outstanding
>>> from last stage 1. Hopefully since it has been mostly reviewed it could go 
>>> in
>>> for this stage 1?
>>>
>>> I addressed the comments and gave the slp-part of vectorizable_call some TLC
>>> to make it work.
>>>
>>> I also changed vect_get_slp_defs as I noticed that the call from
>>> vectorizable_call was creating an auto_vec with 'nargs' that might be less
>>> than the number of children in the slp_node
>> how so?  Please fix that in the caller.  It looks like it probably
>> shoud use vect_nargs instead?
> Well that was my first intuition, but when I looked at it further the 
> variant it's calling:
> void vect_get_slp_defs (vec_info *, slp_tree slp_node, vec > 
> *vec_oprnds, unsigned n)
>
> Is actually creating a vector of vectors of slp defs. So for each child 
> of slp_node it calls:
> void vect_get_slp_defs (slp_tree slp_node, vec *vec_defs)
>
> Which returns a vector of vectorized defs. So vect_nargs would be the 
> right size for the inner vec of vec_defs, but the outer should 
> have the same number of elements as the original slp_node has children.
>
> However, at the call site (vectorizable_call), the operand we pass to 
> vect_get_slp_defs 'vec_defs', is initialized before the code-path is 
> specialized for slp_node. I'll go see if I can change the call site to 
> not have to do that, given the continue at the end of the if (slp_node) 
> BB I don't think it needs to use vec_defs after it, but it may require 
> some massaging to be able to define it separately for each code-path.
>
>>
>>> , so that quick_push might not be
>>> safe as is, so I added the reserve (n) to ensure it's safe to push. I didn't
>>> actually come across any failure because of it though. Happy to split this
>>> into a separate patch if needed.
>>>
>>> Bootstrapped and regression tested on aarch64-none-linux-gnu and
>>> x86_64-pc-linux-gnu.
>>>
>>> OK for trunk?
>> I'll leave final approval to Richard but
>>
>> - This only needs 1 bit, but occupies the full 16 to ensure a nice
>> + This only needs 1 bit, but occupies the full 15 to ensure a nice
>>layout.  */
>> unsigned int vectorizable : 16;
>>
>> you don't actually change the width of the bitfield.  I would find
>> it more natural to have
>>
>>signed int type0 : 7;
>>signed int type0_vtrans : 1;
>>signed int type1 : 7;
>>signed int type1_vtrans : 1;
>>
>> with typeN_vtrans specifying how the types transform when vectorized.
>> I would imagine another variant we could need is narrow/widen
>> according to either result or other argument type?  That said,
>> just your flag would then be
>>
>>signed int type0 : 7;
>>signed int pad   : 1;
>>signed int type1 : 7;
>>signed int type1_vect_as_scalar : 1;
>>
>> ?
> That's a cool idea! I'll leave it as a single bit for now like that, if 
> we want to re-use it for multiple transformations we will obviously need 
> to rename & give it more bits.

I think we should steal bits from vectorizable rather than shrink
type0 and type1 though.  Then add a 14-bit padding field to show
how many bits are left.

> @@ -3340,9 +3364,20 @@ vectorizable_call (vec_info *vinfo,
>rhs_type = unsigned_type_node;
>  }
> 
> +  /* The argument that is not of the same type as the others.  */
>int mask_opno = -1;
> +  int scalar_opno = -1;
>if (internal_fn_p (cfn))
> -mask_opno = internal_fn_mask_index (as_internal_fn (cfn));
> +{
> +  internal_fn ifn = as_internal_fn (cfn);
> +  if (direct_internal_fn_p (ifn)
> +   && direct_internal_fn (ifn).type1_is_scalar_p)
> + scalar_opno = direct_internal_fn (ifn).type1;
> +  else
> + /* For masked operations this represents the argument that carries the
> +mask.  */
> + mask_opno = internal_fn_mask_index (as_internal_fn (cfn));

This doesn't seem logically like an else.  We should do both.

LGTM otherwise for the bits outside match.pd.  If Richard's happy with
the match.pd bits then I think the patch is OK with those changes and
without the vect_get_slp_defs thing (as you mentioned downthread).

Thanks,
Richard


>>
>>> gcc/ChangeLog:
>>>
>>>      * config/aarch64/aarch64.md (ftrunc2): New
>>> pattern.
>>>      * config/aarch64/iterators.md (FRINTNZ): New iterator.
>>>      (frintnz_mode): New int attribute.
>>>      (VSFDF): Make iterator conditional.
>>>      * internal-fn.def (FTRUNC_INT): New IFN.
>>>      * internal-fn.cc (ftrunc_int_direct): New define.
>>>      (expand_ftrunc_int_optab_fn): New custom expander.
>>>      (direct_ftrunc_int_optab_supported_p): New supported_p.
>>>      * internal-fn.h (direct_internal_fn_info): Add new member
>>>      type1_is_scalar_p.
>>>      * match.pd: Add to the existing TRUNC pattern match.
>>>     

Re: [PATCH 2/2] aarch64: Add support for widening LDAPR instructions

[Richard Sandiford via Gcc-patches]

"Andre Vieira (lists)"  writes:
> Updated version of the patch to account for the testsuite changes in the 
> first patch.
>
> On 10/11/2022 11:20, Andre Vieira (lists) via Gcc-patches wrote:
>> Hi,
>>
>> This patch adds support for the widening LDAPR instructions.
>>
>> Bootstrapped and regression tested on aarch64-none-linux-gnu.
>>
>> OK for trunk?
>>
>> 2022-11-09  Andre Vieira  
>>     Kyrylo Tkachov  
>>
>> gcc/ChangeLog:
>>
>>     * config/aarch64/atomics.md 
>> (*aarch64_atomic_load_rcpc_zext): New pattern.
>>     (*aarch64_atomic_load_rcpc_zext): Likewise.
>>
>> gcc/testsuite/ChangeLog:
>>
>>     * gcc.target/aarch64/ldapr-ext.c: New test.
>
> diff --git a/gcc/config/aarch64/atomics.md b/gcc/config/aarch64/atomics.md
> index 
> dc5f52ee8a4b349c0d8466a16196f83604893cbb..9670bef7d8cb2b32c5146536d806a7e8bdffb2e3
>  100644
> --- a/gcc/config/aarch64/atomics.md
> +++ b/gcc/config/aarch64/atomics.md
> @@ -704,6 +704,28 @@
>}
>  )
>  
> +(define_insn "*aarch64_atomic_load_rcpc_zext"
> +  [(set (match_operand:GPI 0 "register_operand" "=r")
> +(zero_extend:GPI
> +  (unspec_volatile:ALLX
> +[(match_operand:ALLX 1 "aarch64_sync_memory_operand" "Q")
> + (match_operand:SI 2 "const_int_operand")]   ;; model
> +   UNSPECV_LDAP)))]
> +  "TARGET_RCPC"
> +  "ldapr\t%0, %1"

It would be good to add:

   > 

to the condition, so that we don't provide bogus SI->SI and DI->DI
extensions.  (They shouldn't be generated, but it's better not to provide
them anyway.)

Thanks,
Richard

> +)
> +
> +(define_insn "*aarch64_atomic_load_rcpc_sext"
> +  [(set (match_operand:GPI  0 "register_operand" "=r")
> +(sign_extend:GPI
> +  (unspec_volatile:ALLX
> +[(match_operand:ALLX 1 "aarch64_sync_memory_operand" "Q")
> + (match_operand:SI 2 "const_int_operand")]   ;; model
> +   UNSPECV_LDAP)))]
> +  "TARGET_RCPC"
> +  "ldaprs\t%0, %1"
> +)
> +
>  (define_insn "atomic_store"
>[(set (match_operand:ALLI 0 "aarch64_rcpc_memory_operand" "=Q,Ust")
>  (unspec_volatile:ALLI
> diff --git a/gcc/testsuite/gcc.target/aarch64/ldapr-ext.c 
> b/gcc/testsuite/gcc.target/aarch64/ldapr-ext.c
> new file mode 100644
> index 
> ..aed27e06235b1d266decf11745dacf94cc59e76d
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/ldapr-ext.c
> @@ -0,0 +1,94 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -std=c99" } */
> +/* { dg-final { check-function-bodies "**" "" "" } } */
> +#include 
> +
> +#pragma GCC target "+rcpc"
> +
> +atomic_ullong u64;
> +atomic_llong s64;
> +atomic_uint u32;
> +atomic_int s32;
> +atomic_ushort u16;
> +atomic_short s16;
> +atomic_uchar u8;
> +atomic_schar s8;
> +
> +#define TEST(name, ldsize, rettype)  \
> +rettype  \
> +test_##name (void)   \
> +{\
> +  return atomic_load_explicit (, memory_order_acquire);   \
> +}
> +
> +/*
> +**test_u8_u64:
> +**...
> +**   ldaprb  x0, \[x[0-9]+\]
> +**   ret
> +*/
> +
> +TEST(u8_u64, u8, unsigned long long)
> +
> +/*
> +**test_s8_s64:
> +**...
> +**   ldaprsb x0, \[x[0-9]+\]
> +**   ret
> +*/
> +
> +TEST(s8_s64, s8, long long)
> +
> +/*
> +**test_u16_u64:
> +**...
> +**   ldaprh  x0, \[x[0-9]+\]
> +**   ret
> +*/
> +
> +TEST(u16_u64, u16, unsigned long long)
> +
> +/*
> +**test_s16_s64:
> +**...
> +**   ldaprsh x0, \[x[0-9]+\]
> +**   ret
> +*/
> +
> +TEST(s16_s64, s16, long long)
> +
> +/*
> +**test_u8_u32:
> +**...
> +**   ldaprb  w0, \[x[0-9]+\]
> +**   ret
> +*/
> +
> +TEST(u8_u32, u8, unsigned)
> +
> +/*
> +**test_s8_s32:
> +**...
> +**   ldaprsb w0, \[x[0-9]+\]
> +**   ret
> +*/
> +
> +TEST(s8_s32, s8, int)
> +
> +/*
> +**test_u16_u32:
> +**...
> +**   ldaprh  w0, \[x[0-9]+\]
> +**   ret
> +*/
> +
> +TEST(u16_u32, u16, unsigned)
> +
> +/*
> +**test_s16_s32:
> +**...
> +**   ldaprsh w0, \[x[0-9]+\]
> +**   ret
> +*/
> +
> +TEST(s16_s32, s16, int)

Re: [PATCH] Allow prologues and epilogues to be inserted later

[Jeff Law via Gcc-patches]

On 11/11/22 09:21, Richard Sandiford via Gcc-patches wrote:

Arm's SME adds a new processor mode called streaming mode.
This mode enables some new (matrix-oriented) instructions and
disables several existing groups of instructions, such as most
Advanced SIMD vector instructions and a much smaller set of SVE
instructions.  It can also change the current vector length.

There are instructions to switch in and out of streaming mode.
However, their effect on the ISA and vector length can't be represented
directly in RTL, so they need to be emitted late in the pass pipeline,
close to md_reorg.

It's sometimes the responsibility of the prologue and epilogue to
switch modes, which means we need to emit the prologue and epilogue
sequences late as well.  (This loses shrink-wrapping and scheduling
opportunities, but that's a price worth paying.)

This patch therefore adds a target hook for forcing prologue
and epilogue insertion to happen later in the pipeline.

Tested on aarch64-linux-gnu (including with a follow-on patch)
and x86_64-linux-gnu.  OK to install?
  I'll ob
Richard


gcc/
* target.def (use_late_prologue_epilogue): New hook.
* doc/gccint/target-macros/miscellaneous-parameters.rst: Add
TARGET_USE_LATE_PROLOGUE_EPILOGUE.
* doc/gccint/target-macros/tm.rst.in: Regenerate.
* passes.def (pass_late_thread_prologue_and_epilogue): New pass.
* tree-pass.h (make_pass_late_thread_prologue_and_epilogue): Declare.
* function.cc (pass_thread_prologue_and_epilogue::gate): New function.
(pass_data_late_thread_prologue_and_epilogue): New pass variable.
(pass_late_thread_prologue_and_epilogue): New pass class.
(make_pass_late_thread_prologue_and_epilogue): New function.


I'm not sure how we'll enforce the no target independent code motion 
limitation that this seems to need and the exception made for reorg is 
hackish in that it appears we just rely on the fact that reorg isn't run 
for the one target where this matters.  That does make me wonder if we 
should future proof this ever so slightly -- is there a reasonably easy 
way to fail if a target were to define delay slots and the need for late 
prologue/epilogue?  If so, that seems advisable.



No objection to the meat of the patch, just wondering a bit about the 
additional sanity checking we can do...



Jeff

Re: [PATCH 3/8]middle-end: Support extractions of subvectors from arbitrary element position inside a vector

[Richard Sandiford via Gcc-patches]

Tamar Christina  writes:
>> -Original Message-
>> From: Hongtao Liu 
>> Sent: Tuesday, November 15, 2022 9:37 AM
>> To: Tamar Christina 
>> Cc: Richard Sandiford ; Tamar Christina via
>> Gcc-patches ; nd ;
>> rguent...@suse.de
>> Subject: Re: [PATCH 3/8]middle-end: Support extractions of subvectors from
>> arbitrary element position inside a vector
>>
>> On Tue, Nov 15, 2022 at 4:51 PM Tamar Christina
>>  wrote:
>> >
>> > > -Original Message-
>> > > From: Hongtao Liu 
>> > > Sent: Tuesday, November 15, 2022 8:36 AM
>> > > To: Tamar Christina 
>> > > Cc: Richard Sandiford ; Tamar Christina
>> > > via Gcc-patches ; nd ;
>> > > rguent...@suse.de
>> > > Subject: Re: [PATCH 3/8]middle-end: Support extractions of
>> > > subvectors from arbitrary element position inside a vector
>> > >
>> > > Hi:
>> > >   I'm from https://gcc.gnu.org/pipermail/gcc-patches/2022-
>> > > November/606040.html.
>> > > >  }
>> > > >
>> > > >/* See if we can get a better vector mode before extracting.
>> > > > */ diff --git a/gcc/optabs.cc b/gcc/optabs.cc index
>> > > >
>> > >
>> cff37ccb0dfc3dd79b97d0abfd872f340855dc96..f338df410265dfe55b68961600
>> > > 9
>> > > 0
>> > > > a453cc6a28d9 100644
>> > > > --- a/gcc/optabs.cc
>> > > > +++ b/gcc/optabs.cc
>> > > > @@ -6267,6 +6267,7 @@ expand_vec_perm_const (machine_mode
>> mode,
>> > > rtx v0, rtx v1,
>> > > >v0_qi = gen_lowpart (qimode, v0);
>> > > >v1_qi = gen_lowpart (qimode, v1);
>> > > >if (targetm.vectorize.vec_perm_const != NULL
>> > > > + && targetm.can_change_mode_class (mode, qimode,
>> > > > + ALL_REGS)
>> > > It looks like you want to guard gen_lowpart, shouldn't it be better
>> > > to use validate_subreg  or (tmp = gen_lowpart_if_possible (mode,
>> target_qi)).
>> > > IMHO, targetm.can_change_mode_class is mostly used for RA, but not
>> > > to guard gen_lowpart.
>> >
>> > Hmm I don't think this is quite true, there are existing usages in
>> > expr.cc and rtanal.cc That do this and aren't part of RA.  As I
>> > mentioned before for instance the canoncalization of vec_select to subreg
>> in rtlanal for instances uses this.
>> In theory, we need to iterate through all reg classes that can be assigned 
>> for
>> both qimode and mode, if any regclass returns true for
>> targetm.can_change_mode_class, the bitcast(validate_subreg) should be ok.
>> Here we just passed ALL_REGS.
>
> Yes, and most targets where this transformation is valid return true here.
>
> I've checked:
>  * alpha
>  * arm
>  * aarch64
>  * rs6000
>  * s390
>  * sparc
>  * pa
>  * mips
>
> And even the default example that other targets use from the documentation
> would return true as the size of the modes are the same.
>
> X86 and RISCV are the only two targets that I found (but didn't check all) 
> that
> blankly return a result based on just the register classes.
>
> That is to say, there are more targets that adhere to the interpretation that
> rclass here means "should be possible in some class in rclass" rather than
> "should be possible in ALL classes of rclass".

Yeah, I agree.  A query "can something stored in ALL_REGS change from
mode M1 to mode M2?" is meaningful if at least one register R in ALL_REGS
can hold both M1 and M2.  It's then the target's job to answer
conservatively so that the result covers all such R.

In principle it's OK for a target to err on the side of caution and forbid
things that are actually OK.  But that's going to risk losing performance
in some cases, and sometimes that loss of performance will be unacceptable.
IMO that's what's happening here.  The target is applying x87 rules to
things that (AIUI) are never stored in x87 registers, and so losing
performance as a result.

Note that the RA also uses ALL_REGS for some things, so this usage
isn't specific to non-RA code.

IMO it's not the job of target-independent code to iterate through
individual classes and aggregate the result.  One of the reasons for
having union classes is to avoid the need to do that.  And ALL_REGS
is the ultimate union class. :-)

The patch looks correct to me.

Thanks,
Richard

>> >
>> > So there are already existing precedence for this.  And the
>> > documentation for the hook says:
>> >
>> > "This hook returns true if it is possible to bitcast values held in 
>> > registers of
>> class rclass from mode from to mode to and if doing so preserves the low-
>> order bits that are common to both modes. The result is only meaningful if
>> rclass has registers that can hold both from and to. The default
>> implementation returns true"
>> >
>> > So it looks like it's use outside of RA is perfectly valid.. and the
>> > documentation also mentions in the example the use from the mid-end as
>> an example.
>> >
>> > But if the mid-end maintainers are happy I'll use something else.
>> >
>> > Tamar
>> >
>> > > I did similar things in
>> > > https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579296.html
>> > > (and ALL_REGS doesn't cover all cases for 

Re: [PATCH] RISC-V: Split "(a & (1UL << bitno)) ? 0 : 1" to bext + xori

[Jeff Law via Gcc-patches]

On 11/13/22 13:48, Philipp Tomsich wrote:

We avoid reassociating "(~(a >> BIT_NO)) & 1" into "((~a) >> BIT_NO) & 1"
by splitting it into a zero-extraction (bext) and an xori.  This both
avoids burning a register on a temporary and generates a sequence that
clearly captures 'extract bit, then invert bit'.

This change improves the previously generated
 srl   a0,a0,a1
 not  a0,a0
 andi  a0,a0,1
into
 bext  a0,a0,a1
 xori  a0,a0,1

Signed-off-by: Philipp Tomsich 

gcc/ChangeLog:

* config/riscv/bitmanip.md: Add split covering
"(a & (1 << BIT_NO)) ? 0 : 1".

gcc/testsuite/ChangeLog:

* gcc.target/riscv/zbs-bext.c: Add testcases.
* gcc.target/riscv/zbs-bexti.c: Add testcases.


OK.   Not terribly happy with the SUBREG, but I can guess that's an 
artifact of other patterns which require that operand to be QImode.



Jeff

Re: [PATCH v2 0/2] Basic support for the Ventana VT1 w/ instruction fusion

[Palmer Dabbelt]

On Mon, 14 Nov 2022 23:25:54 PST (-0800), richard.guent...@gmail.com wrote:

On Tue, Nov 15, 2022 at 12:01 AM Philipp Tomsich
 wrote:


On Mon, 14 Nov 2022 at 23:47, Palmer Dabbelt  wrote:
>
> [Trying to join the threads here.]
>
> On Mon, 14 Nov 2022 13:28:23 PST (-0800), philipp.toms...@vrull.eu wrote:
> > Jeff,
> >
> > On Mon, 14 Nov 2022 at 22:23, Jeff Law  wrote:
> >>
> >>
> >> On 11/14/22 13:00, Palmer Dabbelt wrote:
> >> > On Sun, 13 Nov 2022 12:48:22 PST (-0800), philipp.toms...@vrull.eu wrote:
> >> >>
> >> >> This series provides support for the Ventana VT1 (a 4-way superscalar
> >> >> rv64gc_zba_zbb_zbc_zbs_zifenci_xventanacondops core) including support
> >> >> for the supported instruction fusion patterns.
> >> >>
> >> >> This includes the addition of the fusion-aware scheduling
> >> >> infrastructure for RISC-V and implements idiom recognition for the
> >> >> fusion patterns supported by VT1.
> >> >>
> >> >> Note that we don't signal support for XVentanaCondOps at this point,
> >> >> as the XVentanaCondOps support is in-flight separately. Changing the
> >> >> defaults for VT1 can happen late in the cycle, so no need to link the
> >> >> two different changesets.
> >> >>
> >> >> Changes in v2:
> >> >> - Rebased and changed over to .rst-based documentation
> >> >> - Updated to catch more fusion cases
> >> >> - Signals support for Zifencei
> >> >>
> >> >> Philipp Tomsich (2):
> >> >>   RISC-V: Add basic support for the Ventana-VT1 core
> >> >>   RISC-V: Add instruction fusion (for ventana-vt1)
> >> >>
> >> >>  gcc/config/riscv/riscv-cores.def  |   3 +
> >> >>  gcc/config/riscv/riscv-opts.h |   2 +-
> >> >>  gcc/config/riscv/riscv.cc | 233 ++
> >> >>  .../risc-v-options.rst|   5 +-
> >> >>  4 files changed, 240 insertions(+), 3 deletions(-)
> >> >
> >> > I guess we never really properly talked about this on the GCC mailing
> >> > lists, but IMO it's fine to start taking code for designs that have
> >> > been announced under the assumption that if the hardware doesn't
> >> > actually show up according to those timelines that it will be assumed
> >> > to have never existed and thus be removed more quickly than usual.
> >> Absolutely.   I have zero interest in carrying around code for
> >> nonexistent or dead variants.
> >> >
> >> > That said, I can't find anything describing that the VT-1 exists aside
> >> > from these patches.  Is there anything that describes this design and
> >> > when it's expected to be available?
> >>
> >> What do you need?  I can give some broad overview information on the
> >> design, but it would likely just mirror what's already been mentioned in
> >> these patches.
> >>
> >>
> >> As far as schedules.  I'm not sure what I can say.  I'll check on that.
>
> I'm less worried about the "does this pipeline model match the HW" bits,
> at least until the HW is publicly available then all we can do is rely
> on the vendor (and even after the HW is public the vendor might be the
> only one who cares enough to figure things out, nothing we can really do
> upstream there).  We've had some issues with nobody caring enough about
> the C906 pipeline model to sort out whether some patches are a net win,
> but if nobody (including the vendor) cares about the HW enough to
> benchmark things then there's not much we can do.
>
> My bigger worry is getting roped in to supporting a bunch of hardware
> that doesn't actually exist yet and may never make it outside some
> vendor's lab.  That can generally be a ton of work and filters
> throughout GCC, even outside of the RISC-V backend.  We've already got
> enough chaos just trying to follow the ISA, chasing down issues related
> to hardware that may not ever manifest is just going to lead to
> craziness.
>
> So on my end the point of the schedule is to have something we can look
> at and determine that the hardware is somehow defunct.  The fairest way
> we could come up with was to tie it to some sort of company announcement
> of the hardware: obviously everyone knows their internal timelines, but
> that's not fair to companies that don't employ someone with commit
> access.  Requirement some sort of public announcement means everyone has
> the same rules to play by, IMO that's really important in RISC-V land as
> there's so many vendors.
>
> >> It was never my intention to bypass any process/procedures here. So if I
> >> did, my apologies.
> >
> > The controversial part is XVentanaCondOps (as it is a vendor-defined
> > extension), so I'll certainly hold off on that until both you and
> > Palmer are in agreement on how to proceed there.
>
> The pipeline models are essentially in the same spot.  We've got a bit
> of a precedent there for taking them just based on an announcement, but
> there isn't one here.
>
> [and the other side of the thread]
>
> On Mon, 14 Nov 2022 13:14:35 PST (-0800), philipp.toms...@vrull.eu wrote:
> > On Mon, 14 Nov 2022 at 21:58, 

Re: [PATCH] RISC-V: Split "(a & (1UL << bitno)) ? 0 : -1" to bext + addi

[Jeff Law via Gcc-patches]

On 11/13/22 13:48, Philipp Tomsich wrote:

For a straightforward application of bext for the following function
   long bext64(long a, char bitno)
   {
 return (a & (1UL << bitno)) ? 0 : -1;
   }
we generate
srl a0,a0,a1# 7 [c=4 l=4]  lshrdi3
andia0,a0,1 # 8 [c=4 l=4]  anddi3/1
addia0,a0,-1# 14[c=4 l=4]  adddi3/1
due to the following failed match at combine time:
   (set (reg:DI 82)
(zero_extract:DI (reg:DI 83)
 (const_int 1 [0x1])
 (reg:DI 84)))

The existing pattern for bext requires the 3rd argument to
zero_extract to be a QImode register wrapped in a zero_extension.
This adds an additional pattern that allows an Xmode argument.

With this change, the testcase compiles to
bexta0,a0,a1# 8 [c=4 l=4]  *bextdi
addia0,a0,-1# 14[c=4 l=4]  adddi3/1

gcc/ChangeLog:

* config/riscv/bitmanip.md (*bext): Add an additional
pattern that allows the 3rd argument to zero_extract to be
an Xmode register operand.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/zbs-bext.c: Add testcases.
* gcc.target/riscv/zbs-bexti.c: Add testcases.


It's fairly common to want variants with extraction as well as a simple 
register operand.   The biggest concern is typically around 
SHIFT_COUNT_TRUNCATED, but given we already have an extract variant 
y'all should have already addressed concerns around SHIFT_COUNT_TRUNCATED.


OK.

jeff

[PATCH] testsuite: Fix missing EFFECTIVE_TARGETS variable errors

[Maciej W. Rozycki]

Permit running vector tests outside `check_vect_support_and_set_flags' 
environment, removing errors such as:

ERROR: gcc.dg/analyzer/torture/pr93350.c   -O0 : can't read 
"EFFECTIVE_TARGETS": no such variable for " dg-require-effective-target 1 
vect_int "

or:

ERROR: gcc.dg/bic-bitmask-13.c: error executing dg-final: can't read 
"EFFECTIVE_TARGETS": no such variable

with `mips-linux-gnu' target testing.

The EFFECTIVE_TARGETS variable has originated from commit 9b7937cf8a06 
("Add support to run auto-vectorization tests for multiple effective 
targets."), where arrangements have been made to run vector tests run 
within `check_vect_support_and_set_flags' environment iteratively over 
all the vector unit variants available in the architecture using extra 
compilation flags regardless of whether the target environment arranged 
for a particular testsuite run has vector support enabled by default.  
So far this has been used for the MIPS target only.

Vector tests have since been added though that run outside environment 
set up by `check_vect_support_and_set_flags' just using the current
compilation environment with no extra flags added.  This works for most 
targets, however causes problems with the MIPS target, because outside 
`check_vect_support_and_set_flags' environment the EFFECTIVE_TARGETS 
variable will not have been correctly set up even if it was added to 
the particular script invoking the test in question.

Fix this by using just the current compilation environment whenever a 
vector feature is requested by `et-is-effective-target' in the absence 
of the EFFECTIVE_TARGETS variable.  This required some modification to 
individual vector feature tests, which always added the compilation 
flags required for the determination of whether the given vector unit 
variant can be verified with the current testsuite run (except for the 
Loongson MMI variant).  Now explicit flags are only passed in setting up 
EFFECTIVE_TARGETS and otherwise the current compilation environment will 
determine whether such a vector test is applicable.

This changes how Loongson MMI is handled in that the `-mloongson-mmi' 
flag is explicitly passed for the determination of whether this vector 
unit variant can be verified, which I gather is how it was supposed to 
be arranged anyway because the flag is then added for testing the 
Loongson MMI variant.

gcc/testsuite/
* lib/target-supports.exp
(check_effective_target_mpaired_single): Add `args' argument and
pass it to `check_no_compiler_messages' replacing
`-mpaired-single'.
(add_options_for_mips_loongson_mmi): Add `args' argument and 
pass it to `check_no_compiler_messages'.
(check_effective_target_mips_msa): Add `args' argument and pass 
it to `check_no_compiler_messages' replacing `-mmsa'.
(check_effective_target_mpaired_single_runtime)
(add_options_for_mpaired_single): Pass `-mpaired-single' to
`check_effective_target_mpaired_single'.
(check_effective_target_mips_loongson_mmi_runtime)
(add_options_for_mips_loongson_mmi): Pass `-mloongson-mmi' to
`check_effective_target_mips_loongson_mmi'.
(check_effective_target_mips_msa_runtime)
(add_options_for_mips_msa): Pass `-mmsa' to
`check_effective_target_mips_msa'.
(et-is-effective-target): Verify that EFFECTIVE_TARGETS exists
and if not, just check if the current compilation environment
supports the target feature requested.
(check_vect_support_and_set_flags): Pass `-mpaired-single',
`-mloongson-mmi', and `-mmsa' to the respective target feature
checks.
---
Hi,

 This removes said errors and depending on the compilation flags used with 
a testsuite invocation may give scores such as:

UNSUPPORTED: gcc.dg/analyzer/torture/pr93350.c   -O0

or:

PASS: gcc.dg/analyzer/torture/pr93350.c   -O0  (test for excess errors)

In some cases, including in particular Loongson MMI now enabled, it causes 
extra failures to appear, but my interpretation is they are preexisting 
issues either with the compiler or the respective test cases, which just 
did not previously show up simply because the test cases were not run.  
Therefore I conclude they are not issues with the test framework update 
proposed here.

 OK to apply then?

  Maciej
---
 gcc/testsuite/lib/target-supports.exp |   41 +++---
 1 file changed, 23 insertions(+), 18 deletions(-)

gcc-test-effective-targets.diff
Index: gcc/gcc/testsuite/lib/target-supports.exp
===
--- gcc.orig/gcc/testsuite/lib/target-supports.exp
+++ gcc/gcc/testsuite/lib/target-supports.exp
@@ -1329,10 +1329,10 @@ proc check_effective_target_pie { } {
 
 # Return true if the target supports -mpaired-single (as used on MIPS).
 
-proc check_effective_target_mpaired_single { } {
+proc check_effective_target_mpaired_single { args } {
  

Re: [PATCH] RISC-V: Zihintpause: add __builtin_riscv_pause

[Jeff Law via Gcc-patches]

On 11/13/22 13:41, Philipp Tomsich wrote:

The Zihintpause extension uses an opcode from the 'fence' opcode range
to add a true hint instruction (i.e. if it is not supported on any
given platform, the 'fence' that is encoded will not enforce any
specific ordering on memory accesses) for entering a low-power state
(e.g. in an idle thread).  We expose this new instruction through a
machine-dependent builtin to allow generating it without a requirement
for any inline assembly.

Given that the encoding of 'pause' is valid (as a 'fence' encoding)
even for processors that do not (yet) support Zihintpause, we make
this builtin available without any further TARGET_* constraints.

gcc/ChangeLog:

* config/riscv/riscv-builtins.cc (struct riscv_builtin_description):
add the pause machine-dependent builtin with no result and no
 arguments; mark it as always present (pause is a true hint
 that encodes into a fence-insn, if not supported with the new
 pause semantics).
* config/riscv/riscv-ftypes.def: Add type for void -> void.
* config/riscv/riscv.md (riscv_pause): Add risc_pause and UNSPECV_PAUSE
* 
doc/gcc/extensions-to-the-c-language-family/target-builtins/risc-v-built-in-functions.rst:
Document.
* optabs.cc (maybe_gen_insn): Allow nops == 0 (void -> void).

gcc/testsuite/ChangeLog:

* gcc.target/riscv/builtin_pause.c: New test.


OK.  Though I think you'll need to adjust the doc patch now with the 
sphinx work reverted.



Jeff

Re: [PATCH] RISC-V: Use .p2align for code-alignment

[Jeff Law via Gcc-patches]

On 11/13/22 13:41, Philipp Tomsich wrote:

RISC-V's .p2align (currently) ignores the max-skip argument.  As we
have experimental patches underway to address this in a
backwards-compatible manner, let's prepare GCC for the day when
binutils gets updated.

gcc/ChangeLog:

* config/riscv/riscv.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Implement.



What are the implications if we start using p2align immediately when the 
current (broken?) state of the assembler?  I'm pretty sure configure is 
already turning on HAVE_GAS_SKIP_P2ALIGN.  From a native risc-v build:



auto-host.h:#define HAVE_GAS_MAX_SKIP_P2ALIGN 1



jeff

Re: [RFC PATCH] ipa-guarded-deref: Add new pass to dereference function pointers

[Jeff Law via Gcc-patches]

On 11/14/22 08:38, Christoph Müllner wrote:


Ok, I will add the check.

Still, I don't think that the optimization changes the behavior in the
case of different ABIs
(i.e. the situation is problematic regardless if there is an indirect call
or a guarded direct call).
What could be done additionally to dropping the candidate is to emit a
warning (similar like ipa-devirt does for ODR violations).


The one target I'm aware of where this is most likely to cause problems 
would be the older 32bit PA SOM ABI.  It has the property that the ABI 
uses different registers for parameter passing for direct vs indirect 
calls.  But with all this happening before RTL generation we should be 
fine, even for that ABI (and its generally safe in that ABI to change an 
indirect to a direct call, but not vice-versa).



Jeff

[PATCH] [range-ops] Minor readability fix.

[Aldy Hernandez via Gcc-patches]

I know it's past the end of stage1, but I'm afraid we'll drag this
around forever in the GCC12 branch, and it's an easy readbility fix.

p.s. Or if you prefer:

if (!lb_nan && !ub_nan && !maybe_nan && )
  r.clear_nan ();

OK for trunk?

gcc/ChangeLog:

* range-op-float.cc (range_operator_float::fold_range): Make check
for maybe_isnan more readable.
---
 gcc/range-op-float.cc | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/gcc/range-op-float.cc b/gcc/range-op-float.cc
index 53a0928c6aa..86107e16553 100644
--- a/gcc/range-op-float.cc
+++ b/gcc/range-op-float.cc
@@ -83,10 +83,12 @@ range_operator_float::fold_range (frange , tree type,
 
   r.set (type, lb, ub);
 
-  if (lb_nan || ub_nan || maybe_nan)
+  if (lb_nan || ub_nan || maybe_nan
+  || op1.maybe_isnan ()
+  || op2.maybe_isnan ())
 // Keep the default NAN (with a varying sign) set by the setter.
 ;
-  else if (!op1.maybe_isnan () && !op2.maybe_isnan ())
+  else
 r.clear_nan ();
 
   return true;
-- 
2.38.1

Re: [PATCH]middle-end: replace GET_MODE_WIDER_MODE with GET_MODE_NEXT_MODE

[Jeff Law via Gcc-patches]

On 11/15/22 07:54, Richard Sandiford via Gcc-patches wrote:

Tamar Christina  writes:

-Original Message-
From: Richard Sandiford 
Sent: Tuesday, November 15, 2022 11:59 AM
To: Tamar Christina via Gcc-patches 
Cc: Tamar Christina ; nd ;
rguent...@suse.de; j...@ventanamicro.com
Subject: Re: [PATCH]middle-end: replace GET_MODE_WIDER_MODE with
GET_MODE_NEXT_MODE

Tamar Christina via Gcc-patches  writes:

Hi All,

After the fix to the addsub patch yesterday for bootstrap I had only

regtested on x86.

While looking today it seemed the new tests were failing, this was
caused by a change in the behavior of the GET_MODE_WIDER_MODE

macro on trunk.

This patch fixes that issue. Sorry for the mess, have rebased all branches

now.

Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.

Ok for master?

Thanks,
Tamar

gcc/ChangeLog:

* match.pd: Replace GET_MODE_WIDER_MODE with
GET_MODE_NEXT_MODE.

--- inline copy of patch --
diff --git a/gcc/match.pd b/gcc/match.pd index


1b0ab7cf60fa4772fbe8304c622b0b8fab1bdefa..28191a992039c6f3a1dab5f7c0
e3

5dd58dc47092 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -7997,7 +7997,7 @@ and,
 machine_mode wide_mode;
   }
   (if (sel.series_p (0, 2, 0, 2)
-  && GET_MODE_WIDER_MODE (vec_mode).exists (_mode)
+  && GET_MODE_NEXT_MODE (vec_mode).exists (_mode)
  && VECTOR_MODE_P (wide_mode)
  && (GET_MODE_UNIT_BITSIZE (vec_mode) * 2
  == GET_MODE_UNIT_BITSIZE (wide_mode)))

Does anything guarantee that the next mode will be the right one?
It think it would be safer to replace the last three && conditions with:

&& GET_MODE_2XWIDER_MODE (GET_MODE_INNER (vec_mode)).exists
(_elt_mode)
&& multiple_p (GET_MODE_NUNITS (vec_mode), 2, _nunits)
&& related_vector_mode (vec_mode, wide_elt_mode,
   wide_nunits).exists (_mode)

I see, respun patch accordingly.

LGTM, but I'm nervous when it comes to match.pd stuff so I'd prefer
Richi or Jeff to have the final say.


It's just a matter of finding that 2X wider mode to make the 
transformation possible.  So I don't see any concerns here.



jeff

Re: [PATCH] Fix gdb FilteringTypePrinter (again)

[Jonathan Wakely via Gcc-patches]

On 06/10/22 19:38 +0200, François Dumont wrote:

Hi

Looks like the previous patch was not enough. When using it in the
context of a build without dual abi and versioned namespace I started
having failures again. I guess I hadn't rebuild everything properly.

This time I think the problem was in those lines:

    if self.type_obj == type_obj:
    return strip_inline_namespaces(self.name)

I've added a call to gdb.types.get_basic_type so that we do not compare
a type with its typedef.

Thanks for the pointer to the doc !

Doing so I eventually use your code Jonathan to make FilteringTypeFilter
more specific to a given instantiation.

    libstdc++: Fix gdb FilteringTypePrinter

    Once we found a matching FilteringTypePrinter instance we look for
the associated
    typedef and check that the returned Python Type is equal to the
Type to recognize.
    But gdb Python Type includes properties to distinguish a typedef
from the actual
    type. So use gdb.types.get_basic_type to check if we are indeed on
the same type.

    Additionnaly enhance FilteringTypePrinter matching mecanism by
introducing targ1 that,
    if not None, will be used as the 1st template parameter.

    libstdc++-v3/ChangeLog:

    * python/libstdcxx/v6/printers.py (FilteringTypePrinter):
Rename 'match' field
    'template'. Add self.targ1 to specify the first template
parameter of the instantiation
    to match.
    (add_one_type_printer): Add targ1 optional parameter,
default to None.
    Use gdb.types.get_basic_type to compare the type to
recognize and the type
    returned from the typedef lookup.
    (register_type_printers): Adapt calls to add_one_type_printers.

Tested under Linux x86_64 normal, version namespace with or without dual
abi.

François

diff --git a/libstdc++-v3/python/libstdcxx/v6/printers.py 
b/libstdc++-v3/python/libstdcxx/v6/printers.py
index 0fa7805183e..52339b247d8 100644
--- a/libstdc++-v3/python/libstdcxx/v6/printers.py
+++ b/libstdc++-v3/python/libstdcxx/v6/printers.py
@@ -2040,62 +2040,72 @@ def add_one_template_type_printer(obj, name, defargs):

class FilteringTypePrinter(object):
r"""
-A type printer that uses typedef names for common template specializations.
+A type printer that uses typedef names for common template instantiations.

Args:
-match (str): The class template to recognize.
+template (str): The class template to recognize.
name (str): The typedef-name that will be used instead.
+targ1 (str): The first template argument.
+If arg1 is provided (not None), only template instantiations with 
this type
+as the first template argument, e.g. if 
template='basic_string is the same type as
+e.g. for template='basic_istream', name='istream', if any instantiation of
+std::basic_istream is the same type as std::istream then print it as
+std::istream.
+
+e.g. for template='basic_istream', name='istream', targ1='char', if any
+instantiation of std::basic_istream is the same type as
std::istream then print it as std::istream.
"""


These are template specializations, not instantiations. Please undo
the changes to the comments, because the comments are 100% correct
now, and would become wrong with this patch.

template struct foo { };
using F = foo; // #1
template struct foo { }; // #2
template<> struct foo { }; // #3

#1 is a *specialization* of the class template foo. It is
*instantiated* when you construct one or depend on its size, or its
members.
#2 is a *partial specialization* and #3 is an explicit specialization.
But #1 is a speclialization, not an instantiation.

Instantiation is a process that happens during compilation. A
specialization is a type (or function, or variable) generated from a
template by substituting arguments for the template parameters. The
python type printer matches specializations.



-def __init__(self, match, name):
-self.match = match
+def __init__(self, template, name, targ1):


Is there a reason to require targ1 here, instead of making it
optional, by using =None as the default?




+self.template = template
self.name = name
+self.targ1 = targ1
self.enabled = True

class _recognizer(object):
"The recognizer class for FilteringTypePrinter."

-def __init__(self, match, name):
-self.match = match
+def __init__(self, template, name, targ1):
+self.template = template
self.name = name
+self.targ1 = targ1
self.type_obj = None

def recognize(self, type_obj):
"""
-If type_obj starts with self.match and is the same type as
+If type_obj starts with self.template and is the same type as
self.name then return self.name, otherwise None.
"""
if type_obj.tag is None:
return None

Re: [PATCH 2/2] libstdc++: Move stream initialization into compiled library [PR44952]

[Hans-Peter Nilsson via Gcc-patches]

> From: Patrick Palka via Gcc-patches 
> Date: Fri, 4 Nov 2022 16:05:25 +0100

> This patch moves the global object for constructing the standard streams
> out from  and into the compiled library on targets that support
> the init_priority attribute.  This means that  no longer
> introduces a separate global constructor in each TU that includes it.
> 
> We can do this only if the init_priority attribute is supported because
> we need to force that the stream initialization runs first before any
> user-defined global initializer in programs that that use a static
> libstdc++.a.
> 
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look right?
> Unfortunately I don't have access to a system that truly doesn't support
> init priorities, so I instead tested that situation by artificially
> disabling the init_priority attribute on x86_64.
> 
>   PR libstdc++/44952
>   PR libstdc++/98108
> 
> libstdc++-v3/ChangeLog:
> 
>   * include/bits/c++config (_GLIBCXX_HAS_ATTRIBUTE): Define.
>   (_GLIBCXX_HAVE_ATTRIBUTE_INIT_PRIORITY): Define.
>   * include/std/iostream (__ioinit): Define only if init_priority
>   attribute isn't usable.
>   * src/c++98/ios_init.cc (__ioinit): Define here instead if
>   the init_priority is usable.
>   * src/c++98/ios_base_init.h: New file.

This (r13-3707-g4e4e3ffd10f53e) broke statically linked programs
using iostreams (affected embedded targets + "native" with
-static).  For me it manifests as adding some 100+ fails to my
cris-elf autotester also repeatable using a native Debian 11
x86_64 build running the test-suite with -static like "make
check-gcc-c++ 'RUNTESTFLAGS=--target_board=unix/-static
old-deja.exp=15071.C'".

I opened PR107701 for it.

brgds, H-P

Re: PING: [PATCH v6] tree-optimization/101186 - extend FRE with "equivalence map" for condition prediction

[Jeff Law via Gcc-patches]

On 11/15/22 03:44, Di Zhao OS via Gcc-patches wrote:

Hi,

I saw that Stage 1 of GCC 13 development is just ended. So is this
considered? Or should I bring this up when general development is
reopened?


Yes, it can still be considered.  The guideline is the patch must be 
posted before stage1 closes, which this patch obviously was. Richi as 
both the release manager and the expert on this part of GCC is by far 
the best person to judge the technical aspect of the patch and the 
cost/benefit of including it as we work our way through stage3 in our 
development cycle.



jeff

Re: [PATCH] libstdc++: Enable building libstdc++.{a,so} when !HOSTED

[Jonathan Wakely via Gcc-patches]

On Thu, 20 Oct 2022 at 16:53, Arsen Arsenović via Libstdc++
 wrote:
>
> This enables us to provide symbols for placeholders and numeric limits,


I'm not convinced this is worth doing.

The placeholders and the numeric_limits members are all inline
variables for C++17 and later, and C++17 is the compiler's default
mode. The placeholders aren't even required to exist for freestanding
prior to C++23. For the numeric_limits definitions, I suppose it is a
problem that users can't take their address in freestanding today
unless they compile as C++17.

> and allows users to mess about with linker flags less.

i.e. they don't have to use -nostdlib and/or link with gcc -lsupc++,
but can just use g++?

That seems more compelling than providing definitions of the
placeholders and limits members.


>
> libstdc++-v3/ChangeLog:
>
> * Makefile.am [!_GLIBCXX_HOSTED]: Enable src/ subdirectory.
> * Makefile.in: Regenerate.
> * src/Makefile.am [!_GLIBCXX_HOSTED]: Omit compatibility files.
> There's no history to be compatible with.
> * src/c++11/Makefile.am [!_GLIBCXX_HOSTED]: Omit hosted-only
> source files from the build.
> * src/c++17/Makefile.am [!_GLIBCXX_HOSTED]: Likewise.
> * src/c++20/Makefile.am [!_GLIBCXX_HOSTED]: Likewise.
> * src/c++98/Makefile.am [!_GLIBCXX_HOSTED]: Likewise.
> * src/Makefile.in: Regenerate.
> * src/c++11/Makefile.in: Regenerate.
> * src/c++17/Makefile.in: Regenerate.
> * src/c++20/Makefile.in: Regenerate.
> * src/c++98/Makefile.in: Regenerate.
> ---
> Afternoon,
>
> With these changes, when we aren't hosted, we get a libstdc++ library that
> contains only library facilities available in freestanding (i.e. placeholders
> and limits.cc).  This is, AFAICT, the only code in libstdc++.{a,so} that can
> (and should) be available in freestanding.
>
> As an implementation note, this could be a little bit faster (at
> build/configure time), though not necessarily nicer, by having
> src/Makefile.am not try to build convenience libraries for versions of
> C++ that provide nothing.  I opted not to do this since it'd make
> src/Makefile.am even more complex, and make future changes harder to 
> implement.
> libstdc++ also isn't that slow to build, anyway.
>
> Tested on i686-elf.
>
> Have a good day!
>
>  libstdc++-v3/Makefile.am   |  4 ++--
>  libstdc++-v3/Makefile.in   |  4 ++--
>  libstdc++-v3/src/Makefile.am   |  6 +
>  libstdc++-v3/src/Makefile.in   |  8 +--
>  libstdc++-v3/src/c++11/Makefile.am | 16 ++---
>  libstdc++-v3/src/c++11/Makefile.in | 37 +++---
>  libstdc++-v3/src/c++17/Makefile.am |  4 
>  libstdc++-v3/src/c++17/Makefile.in |  6 +++--
>  libstdc++-v3/src/c++20/Makefile.am |  4 
>  libstdc++-v3/src/c++20/Makefile.in |  6 +++--
>  libstdc++-v3/src/c++98/Makefile.am |  4 
>  libstdc++-v3/src/c++98/Makefile.in |  6 +++--
>  12 files changed, 77 insertions(+), 28 deletions(-)
>
> diff --git a/libstdc++-v3/Makefile.am b/libstdc++-v3/Makefile.am
> index 0d147ad3ffe..d7f2b6e76a5 100644
> --- a/libstdc++-v3/Makefile.am
> +++ b/libstdc++-v3/Makefile.am
> @@ -24,11 +24,11 @@ include $(top_srcdir)/fragment.am
>
>  if GLIBCXX_HOSTED
>  ## Note that python must come after src.
> -  hosted_source = src doc po testsuite python
> +  hosted_source = doc po testsuite python
>  endif
>
>  ## Keep this list sync'd with acinclude.m4:GLIBCXX_CONFIGURE.
> -SUBDIRS = include libsupc++ $(hosted_source)
> +SUBDIRS = include libsupc++ src $(hosted_source)
>
>  ACLOCAL_AMFLAGS = -I . -I .. -I ../config
>
> diff --git a/libstdc++-v3/src/Makefile.am b/libstdc++-v3/src/Makefile.am
> index b83c222d51d..4eb78e76297 100644
> --- a/libstdc++-v3/src/Makefile.am
> +++ b/libstdc++-v3/src/Makefile.am
> @@ -121,7 +121,13 @@ cxx11_sources = \
> ${cxx0x_compat_sources} \
> ${ldbl_alt128_compat_sources}
>
> +if GLIBCXX_HOSTED
>  libstdc___la_SOURCES = $(cxx98_sources) $(cxx11_sources)
> +else
> +# When freestanding, there's currently no compatibility to preserve.  Should
> +# that change, any compatibility sources can be added here.
> +libstdc___la_SOURCES =
> +endif
>
>  libstdc___la_LIBADD = \
> $(GLIBCXX_LIBS) \
> diff --git a/libstdc++-v3/src/c++11/Makefile.am 
> b/libstdc++-v3/src/c++11/Makefile.am
> index ecd46aafc01..72f05100c98 100644
> --- a/libstdc++-v3/src/c++11/Makefile.am
> +++ b/libstdc++-v3/src/c++11/Makefile.am
> @@ -51,6 +51,10 @@ else
>  cxx11_abi_sources =
>  endif
>
> +sources_freestanding = \
> +   limits.cc \
> +   placeholders.cc
> +
>  sources = \
> chrono.cc \
> codecvt.cc \
> @@ -66,9 +70,7 @@ sources = \
> hashtable_c++0x.cc \
> ios.cc \
> ios_errcat.cc \
> -   limits.cc \
> mutex.cc \
> -   placeholders.cc \
> random.cc \
> regex.cc  \
> shared_ptr.cc \
> @@ -118,7 +120,15 @@ endif
>
>  vpath % 

Re: [PATCH 2/2] arm: Add support for MVE Tail-Predicated Low Overhead Loops

[Andre Vieira (lists) via Gcc-patches]

On 11/11/2022 17:40, Stam Markianos-Wright via Gcc-patches wrote:

Hi all,

This is the 2/2 patch that contains the functional changes needed
for MVE Tail Predicated Low Overhead Loops.  See my previous email
for a general introduction of MVE LOLs.

This support is added through the already existing loop-doloop
mechanisms that are used for non-MVE dls/le looping.

Changes are:

1) Relax the loop-doloop mechanism in the mid-end to allow for
   decrement numbers other that -1 and for `count` to be an
   rtx containing the number of elements to be processed, rather
   than an expression for calculating the number of iterations.
2) Add a `allow_elementwise_doloop` target hook. This allows the
   target backend to manipulate the iteration count as it needs:
   in our case to change it from a pre-calculation of the number
   of iterations to the number of elements to be processed.
3) The doloop_end target-insn now had an additional parameter:
   the `count` (note: this is before it gets modified to just be
   the number of elements), so that the decrement value is
   extracted from that parameter.

And many things in the backend to implement the above optimisation:

4)  Appropriate changes to the define_expand of doloop_end and new
    patterns for dlstp and letp.
5) `arm_attempt_dlstp_transform`: (called from the define_expand of
    doloop_end) this function checks for the loop's suitability for
    dlstp/letp transformation and then implements it, if possible.
6) `arm_mve_get_loop_unique_vctp`: A function that loops through
    the loop contents and returns the vctp VPR-genereting operation
    within the loop, if it is unique and there is exclusively one
    vctp within the loop.
7) A couple of utility functions: `arm_mve_get_vctp_lanes` to map
   from vctp unspecs to number of lanes, and `arm_get_required_vpr_reg`
   to check an insn to see if it requires the VPR or not.

No regressions on arm-none-eabi with various targets and on
aarch64-none-elf. Thoughts on getting this into trunk?

Thank you,
Stam Markianos-Wright

gcc/ChangeLog:

    * config/aarch64/aarch64.md: Add extra doloop_end arg.
    * config/arm/arm-protos.h (arm_attempt_dlstp_transform): New.
    * config/arm/arm.cc (TARGET_ALLOW_ELEMENTWISE_DOLOOP): New.
    (arm_mve_get_vctp_lanes): New.
    (arm_get_required_vpr_reg): New.
    (arm_mve_get_loop_unique_vctp): New.
    (arm_attempt_dlstp_transform): New.
    (arm_allow_elementwise_doloop): New.
    * config/arm/iterators.md:
    * config/arm/mve.md (*predicated_doloop_end_internal): New.
    (dlstp_insn): New.
    * config/arm/thumb2.md (doloop_end): Update for MVE LOLs.
    * config/arm/unspecs.md: New unspecs.
    * config/ia64/ia64.md: Add extra doloop_end arg.
    * config/pru/pru.md: Add extra doloop_end arg.
    * config/rs6000/rs6000.md: Add extra doloop_end arg.
    * config/s390/s390.md: Add extra doloop_end arg.
    * config/v850/v850.md: Add extra doloop_end arg.
    * doc/tm.texi: Document new hook.
    * doc/tm.texi.in: Likewise.
    * loop-doloop.cc (doloop_condition_get): Relax conditions.
    (doloop_optimize): Add support for elementwise LoLs.
    * target-insns.def (doloop_end): Add extra arg.
    * target.def (allow_elementwise_doloop): New hook.
    * targhooks.cc (default_allow_elementwise_doloop): New.
    * targhooks.h (default_allow_elementwise_doloop): New.

gcc/testsuite/ChangeLog:

    * gcc.target/arm/lob.h: Update framework.
    * gcc.target/arm/lob1.c: Likewise.
    * gcc.target/arm/lob6.c: Likewise.
    * gcc.target/arm/dlstp-int16x8.c: New test.
    * gcc.target/arm/dlstp-int32x4.c: New test.
    * gcc.target/arm/dlstp-int64x2.c: New test.
    * gcc.target/arm/dlstp-int8x16.c: New test.


### Inline copy of patch ###

diff --git a/gcc/config/aarch64/aarch64.md 
b/gcc/config/aarch64/aarch64.md
index 
f2e3d905dbbeb2949f2947f5cfd68208c94c9272..7a6d24a80060b4a704a481ccd1a32d96e7b0f369 
100644

--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -7366,7 +7366,8 @@
 ;; knows what to generate.
 (define_expand "doloop_end"
   [(use (match_operand 0 "" ""))  ; loop pseudo
-   (use (match_operand 1 "" ""))] ; label
+   (use (match_operand 1 "" ""))  ; label
+   (use (match_operand 2 "" ""))] ; decrement constant
   "optimize > 0 && flag_modulo_sched"
 {
   rtx s0;
diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
index 
550272facd12e60a49bf8a3b20f811cc13765b3a..7684620f0f4d161dd9e9ad2d70308021ec3d3d34 
100644

--- a/gcc/config/arm/arm-protos.h
+++ b/gcc/config/arm/arm-protos.h
@@ -63,7 +63,7 @@ extern void arm_decompose_di_binop (rtx, rtx, rtx *, 
rtx *, rtx *, rtx *);

 extern bool arm_q_bit_access (void);
 extern bool arm_ge_bits_access (void);
 extern bool arm_target_insn_ok_for_lob (rtx);
-
+extern rtx arm_attempt_dlstp_transform (rtx, rtx);
 #ifdef RTX_CODE
 enum reg_class

libsanitizer: sync from master

[Martin Liška]

Hi.

I've just pushed libsanitizer update that was tested on x86_64-linux and 
ppc64le-linux systems.
Moreover, I run bootstrap on x86_64-linux and checked ABI difference with 
abidiff.

Pushed as r13-4068-g3037f11fb86eda.

Cheers,
Martin

Re: [committed] libstdc++: Fix detection of std::format support for __float128 [PR107693]

[Jonathan Wakely via Gcc-patches]

On Tue, 15 Nov 2022 at 14:42, Jakub Jelinek wrote:
>
> On Tue, Nov 15, 2022 at 02:31:19PM +, Jonathan Wakely via Gcc-patches 
> wrote:
> > Tested x86_64-linux and x86_64-w64-mingw32. Pushed to trunk.
> >
> > -- >8 --
> >
> > std::format gives linker errors on targets that define __float128 but
> > do not support using it with std::to_chars. This improves the handling
> > of 128-bit flaoting-point types so they are disabled if unsupportable.
> >
> > libstdc++-v3/ChangeLog:
> >
> >   PR libstdc++/107693
> >   * include/std/format (_GLIBCXX_FORMAT_F128): Define to 2 when
> >   basic_format_arg needs to use its _M_f128 member.
> >   (__extended_floating_point, __floating_point): Replace with ...
> >   (__formattable_floating_point): New concept.
> >   * testsuite/std/format/functions/format.cc: Check whether
> >   __float128 is supported. Also test _Float128.
>
> > --- a/libstdc++-v3/include/std/format
> > +++ b/libstdc++-v3/include/std/format
>
> > +#elif __FLT128_DIG__ && defined(__GLIBC_PREREQ) // see floating_to_chars.cc
>
> I'd just use here
> #elif __FLT128_DIG__ && defined(_GLIBCXX_HAVE_FLOAT128_MATH)
> instead.
>
> The reason for defined(__GLIBC_PREREQ) in floating_{to,from}_chars.cc
> is that I didn't want to make the ABI of linux libstdc++.so.6 dependent
> on whether gcc was built against glibc 2.26+ or older glibc.
> So, the symbols exist in libstdc++.so.6 even for older glibcs, but it will
> actually only work properly (without losing precision; otherwise it will
> just go through long double) if at runtime one uses glibc 2.26+.

Yes, and my intention was that std::format would also support
__float128, with the same imprecise behaviour. But could just limit
std::format support to when std::to_chars works properly.

> But in the headers, defined(_GLIBCXX_HAVE_FLOAT128_MATH) is used everywhere
> else (which is true only when compiling against glibc 2.26+).

Re: [PATCH 2/2] Add a new warning option -Wstrict-flex-arrays.

[Qing Zhao via Gcc-patches]

Ping on this patch.

thanks.

Qing

> On Nov 8, 2022, at 9:51 AM, Qing Zhao  wrote:
> 
> '-Wstrict-flex-arrays'
> Warn about inproper usages of flexible array members according to
> the LEVEL of the 'strict_flex_array (LEVEL)' attribute attached to
> the trailing array field of a structure if it's available,
> otherwise according to the LEVEL of the option
> '-fstrict-flex-arrays=LEVEL'.
> 
> This option is effective only when LEVEL is bigger than 0.
> Otherwise, it will be ignored with a warning.
> 
> when LEVEL=1, warnings will be issued for a trailing array
> reference of a structure that have 2 or more elements if the
> trailing array is referenced as a flexible array member.
> 
> when LEVEL=2, in addition to LEVEL=1, additional warnings will be
> issued for a trailing one-element array reference of a structure if
> the array is referenced as a flexible array member.
> 
> when LEVEL=3, in addition to LEVEL=2, additional warnings will be
> issued for a trailing zero-length array reference of a structure if
> the array is referenced as a flexible array member.
> 
> At the same time, keep -Warray-bounds=[1|2] warnings unchanged from
> -fstrict-flex-arrays.
> 
> gcc/ChangeLog:
> 
>   * attribs.cc (strict_flex_array_level_of): New function.
>   * attribs.h (strict_flex_array_level_of): Prototype for new function.
>   * doc/invoke.texi: Document -Wstrict-flex-arrays option. Update
>   -fstrict-flex-arrays[=n] options.
>   * gimple-array-bounds.cc (array_bounds_checker::check_array_ref):
>   Issue warnings for -Wstrict-flex-arrays.
>   (get_up_bounds_for_array_ref): New function.
>   (check_out_of_bounds_and_warn): New function.
>   * opts.cc (finish_options): Issue warnings for unsupported combination
>   of -Warray-bounds and -fstrict-flex-arrays, -Wstrict_flex_arrays and
>   -fstrict-flex-array.
>   * tree-vrp.cc (execute_vrp): Enable the pass when
>   warn_strict_flex_array is true.
>   (execute_ranger_vrp): Likewise.
>   * tree.cc (array_ref_flexible_size_p): Add one new argument.
>   (component_ref_sam_type): New function.
>   (component_ref_size): Add one new argument,
>   * tree.h (array_ref_flexible_size_p): Update prototype.
>   (enum struct special_array_member): Add two new enum values.
>   (component_ref_sam_type): New prototype.
>   (component_ref_size): Update prototype.
> 
> gcc/c-family/ChangeLog:
> 
>   * c.opt (Wstrict-flex-arrays): New option.
> 
> gcc/c/ChangeLog:
> 
>   * c-decl.cc (is_flexible_array_member_p): Call new function
>   strict_flex_array_level_of.
> 
> gcc/testsuite/ChangeLog:
> 
>   * c-c++-common/Wstrict-flex-arrays.c: New test.
>   * c-c++-common/Wstrict-flex-arrays_2.c: New test.
>   * gcc.dg/Wstrict-flex-arrays-2.c: New test.
>   * gcc.dg/Wstrict-flex-arrays-3.c: New test.
>   * gcc.dg/Wstrict-flex-arrays-4.c: New test.
>   * gcc.dg/Wstrict-flex-arrays-5.c: New test.
>   * gcc.dg/Wstrict-flex-arrays-6.c: New test.
>   * gcc.dg/Wstrict-flex-arrays-7.c: New test.
>   * gcc.dg/Wstrict-flex-arrays-8.c: New test.
>   * gcc.dg/Wstrict-flex-arrays-9.c: New test.
>   * gcc.dg/Wstrict-flex-arrays.c: New test.
> ---
> gcc/attribs.cc|  30 ++
> gcc/attribs.h |   2 +
> gcc/c-family/c.opt|   5 +
> gcc/c/c-decl.cc   |  22 +-
> gcc/doc/invoke.texi   |  33 ++-
> gcc/gimple-array-bounds.cc| 264 +-
> gcc/opts.cc   |  15 +
> .../c-c++-common/Wstrict-flex-arrays.c|   9 +
> .../c-c++-common/Wstrict-flex-arrays_2.c  |   9 +
> gcc/testsuite/gcc.dg/Wstrict-flex-arrays-2.c  |  46 +++
> gcc/testsuite/gcc.dg/Wstrict-flex-arrays-3.c  |  46 +++
> gcc/testsuite/gcc.dg/Wstrict-flex-arrays-4.c  |  49 
> gcc/testsuite/gcc.dg/Wstrict-flex-arrays-5.c  |  48 
> gcc/testsuite/gcc.dg/Wstrict-flex-arrays-6.c  |  48 
> gcc/testsuite/gcc.dg/Wstrict-flex-arrays-7.c  |  50 
> gcc/testsuite/gcc.dg/Wstrict-flex-arrays-8.c  |  49 
> gcc/testsuite/gcc.dg/Wstrict-flex-arrays-9.c  |  49 
> gcc/testsuite/gcc.dg/Wstrict-flex-arrays.c|  46 +++
> gcc/tree-vrp.cc   |   6 +-
> gcc/tree.cc   | 165 ---
> gcc/tree.h|  15 +-
> 21 files changed, 870 insertions(+), 136 deletions(-)
> create mode 100644 gcc/testsuite/c-c++-common/Wstrict-flex-arrays.c
> create mode 100644 gcc/testsuite/c-c++-common/Wstrict-flex-arrays_2.c
> create mode 100644 gcc/testsuite/gcc.dg/Wstrict-flex-arrays-2.c
> create mode 100644 gcc/testsuite/gcc.dg/Wstrict-flex-arrays-3.c
> create mode 100644 gcc/testsuite/gcc.dg/Wstrict-flex-arrays-4.c
> create mode 100644 gcc/testsuite/gcc.dg/Wstrict-flex-arrays-5.c

[PING] Re: [PATCH v7 00/34] libgcc: Thumb-1 Floating-Point Assembly for Cortex M0

[Daniel Engel]

Hello, 

Is there still any interest in merging this patch? 

Thanks,
Daniel


On Mon, Oct 31, 2022, at 8:44 AM, Daniel Engel wrote:
> Hi Richard,
>
> I am re-submitting my libgcc patch from 2021:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563585.html
> https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587383.html
>
> I believe I have finally made the stage1 window. 
>
> Regards,
> Daniel
>
> ---
>
> Changes since v6:
>
> * Rebased and tested with gcc-13
>
> There are no regressions for -march={armv4t,armv6s-m,armv7-m,armv7-a}.
> Clean master:
>
> # of expected passes529397
> # of unexpected failures41160
> # of unexpected successes   12
> # of expected failures  3442
> # of unresolved testcases   978
> # of unsupported tests  28993
>
> Patched master:
>
> # of expected passes529397
> # of unexpected failures41160
> # of unexpected successes   12
> # of expected failures  3442
> # of unresolved testcases   978
> # of unsupported tests  28993
>
> ---
>
> This patch series adds an assembly-language implementation of IEEE-754 
> compliant
> single-precision functions designed for the Cortex M0 (v6m) architecture.  
> There
> are improvements to most of the EABI integer functions as well.  This is the
> ibgcc component of a larger library project originally proposed in 2018:
>
> https://gcc.gnu.org/legacy-ml/gcc/2018-11/msg00043.html
>
> As one point of comparison, a test program [1] links 916 bytes from libgcc 
> with
> the patched toolchain vs 10276 bytes with gcc-arm-none-eabi-9-2020-q2 
> toolchain.
> That's a 90% size reduction.
>
> I have extensive test vectors [2], and this patch pass all tests on an 
> STM32F051.
> These vectors were derived from UCB [3], Testfloat [4], and IEEECC754 
> [5], plus
> many of my own generation.
>
> There may be some follow-on projects worth discussing:
>
> * The library is currently integrated into the ARM v6s-m multilib only.  
> It
> is likely that some other architectures would benefit from these routines.
> However, I have NOT profiled the existing implementations (ieee754-sf.S) 
> to
> estimate where improvements may be found.
>
> * GCC currently lacks test for some functions, such as 
> __aeabi_[u]ldivmod().
> There may be useful bits in [1] that can be integrated.
>
> On Cortex M0, the library has (approximately) the following properties:
>
> Function(s) Size (bytes)Cycles  
> Stack   Accuracy
> __clzsi250  20  
> 0   exact
> __clzsi2 (OPTIMIZE_SIZE)22  51  
> 0   exact
> __clzdi28+__clzsi2  4+__clzsi2  
> 0   exact
>
> __clrsbsi2  8+__clzsi2  6+__clzsi2  
> 0   exact
> __clrsbdi2  18+__clzsi2 (8..10)+__clzsi2
> 0   exact
>
> __ctzsi252  21  
> 0   exact
> __ctzsi2 (OPTIMIZE_SIZE)24  52  
> 0   exact
> __ctzdi28+__ctzsi2  5+__ctzsi2  
> 0   exact
>
> __ffssi28   6..(5+__ctzsi2) 
> 0   exact
> __ffsdi214+__ctzsi2 9..(8+__ctzsi2) 
> 0   exact
>
> __popcountsi2   52  25  
> 0   exact
> __popcountsi2 (OPTIMIZE_SIZE)   14  9..201  
> 0   exact
> __popcountdi2   34+__popcountsi246  
> 0   exact
> __popcountdi2 (OPTIMIZE_SIZE)   12+__popcountsi217..401 
> 0   exact
>
> __paritysi2 24  14  
> 0   exact
> __paritysi2 (OPTIMIZE_SIZE) 16  38  
> 0   exact
> __paritydi2 2+__paritysi2   1+__paritysi2   
> 0   exact
>
> __umulsidi3 44  24  
> 0   exact
> __mulsidi3  30+__umulsidi3  24+__umulsidi3  
> 8   exact
> __muldi3 (__aeabi_lmul) 10+__umulsidi3  6+__umulsidi3   
> 0   exact
> __ashldi3 (__aeabi_llsl)22  13  
> 0   exact
> __lshrdi3 (__aeabi_llsr)22  13  
> 0   exact
> __ashrdi3 (__aeabi_lasr)22  13  
> 0   exact
>
> __aeabi_lcmp20  13  
> 0   exact
> __aeabi_ulcmp   16  10  
> 0   exact
>
> __udivsi3 (__aeabi_uidiv)   56  72..385 
> 0   < 1 lsb

Re: [PATCH]middle-end: replace GET_MODE_WIDER_MODE with GET_MODE_NEXT_MODE

[Richard Sandiford via Gcc-patches]

Tamar Christina  writes:
>> -Original Message-
>> From: Richard Sandiford 
>> Sent: Tuesday, November 15, 2022 11:59 AM
>> To: Tamar Christina via Gcc-patches 
>> Cc: Tamar Christina ; nd ;
>> rguent...@suse.de; j...@ventanamicro.com
>> Subject: Re: [PATCH]middle-end: replace GET_MODE_WIDER_MODE with
>> GET_MODE_NEXT_MODE
>> 
>> Tamar Christina via Gcc-patches  writes:
>> > Hi All,
>> >
>> > After the fix to the addsub patch yesterday for bootstrap I had only
>> regtested on x86.
>> > While looking today it seemed the new tests were failing, this was
>> > caused by a change in the behavior of the GET_MODE_WIDER_MODE
>> macro on trunk.
>> >
>> > This patch fixes that issue. Sorry for the mess, have rebased all branches
>> now.
>> >
>> > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
>> >
>> > Ok for master?
>> >
>> > Thanks,
>> > Tamar
>> >
>> > gcc/ChangeLog:
>> >
>> >* match.pd: Replace GET_MODE_WIDER_MODE with
>> >GET_MODE_NEXT_MODE.
>> >
>> > --- inline copy of patch --
>> > diff --git a/gcc/match.pd b/gcc/match.pd index
>> >
>> 1b0ab7cf60fa4772fbe8304c622b0b8fab1bdefa..28191a992039c6f3a1dab5f7c0
>> e3
>> > 5dd58dc47092 100644
>> > --- a/gcc/match.pd
>> > +++ b/gcc/match.pd
>> > @@ -7997,7 +7997,7 @@ and,
>> > machine_mode wide_mode;
>> >   }
>> >   (if (sel.series_p (0, 2, 0, 2)
>> > -  && GET_MODE_WIDER_MODE (vec_mode).exists (_mode)
>> > +  && GET_MODE_NEXT_MODE (vec_mode).exists (_mode)
>> >  && VECTOR_MODE_P (wide_mode)
>> >  && (GET_MODE_UNIT_BITSIZE (vec_mode) * 2
>> >  == GET_MODE_UNIT_BITSIZE (wide_mode)))
>> 
>> Does anything guarantee that the next mode will be the right one?
>> It think it would be safer to replace the last three && conditions with:
>> 
>>&& GET_MODE_2XWIDER_MODE (GET_MODE_INNER (vec_mode)).exists
>> (_elt_mode)
>>&& multiple_p (GET_MODE_NUNITS (vec_mode), 2, _nunits)
>>&& related_vector_mode (vec_mode, wide_elt_mode,
>> wide_nunits).exists (_mode)
>
> I see, respun patch accordingly.

LGTM, but I'm nervous when it comes to match.pd stuff so I'd prefer
Richi or Jeff to have the final say.

Thanks,
Richard

>
> Ok for master?
>
> --- inline copy of patch ---
>
> diff --git a/gcc/match.pd b/gcc/match.pd
> index 
> 1b0ab7cf60fa4772fbe8304c622b0b8fab1bdefa..82f05bbc912e4f80f3984d930c4a8dcb010136e1
>  100644
> --- a/gcc/match.pd
> +++ b/gcc/match.pd
> @@ -7995,12 +7995,15 @@ and,
> vec_perm_indices sel (builder, 2, nelts);
> machine_mode vec_mode = TYPE_MODE (type);
> machine_mode wide_mode;
> +   scalar_mode wide_elt_mode;
> +   poly_uint64 wide_nunits;
> +   scalar_mode inner_mode = GET_MODE_INNER (vec_mode);
>   }
>   (if (sel.series_p (0, 2, 0, 2)
> -  && GET_MODE_WIDER_MODE (vec_mode).exists (_mode)
> -   && VECTOR_MODE_P (wide_mode)
> -   && (GET_MODE_UNIT_BITSIZE (vec_mode) * 2
> -   == GET_MODE_UNIT_BITSIZE (wide_mode)))
> +   && GET_MODE_2XWIDER_MODE (inner_mode).exists (_elt_mode)
> +   && multiple_p (GET_MODE_NUNITS (vec_mode), 2, _nunits)
> +   && related_vector_mode (vec_mode, wide_elt_mode,
> +   wide_nunits).exists (_mode))
>   (with
>{
>  tree stype

Re: [committed] libstdc++: Fix detection of std::format support for __float128 [PR107693]

[Jakub Jelinek via Gcc-patches]

On Tue, Nov 15, 2022 at 02:31:19PM +, Jonathan Wakely via Gcc-patches wrote:
> Tested x86_64-linux and x86_64-w64-mingw32. Pushed to trunk.
> 
> -- >8 --
> 
> std::format gives linker errors on targets that define __float128 but
> do not support using it with std::to_chars. This improves the handling
> of 128-bit flaoting-point types so they are disabled if unsupportable.
> 
> libstdc++-v3/ChangeLog:
> 
>   PR libstdc++/107693
>   * include/std/format (_GLIBCXX_FORMAT_F128): Define to 2 when
>   basic_format_arg needs to use its _M_f128 member.
>   (__extended_floating_point, __floating_point): Replace with ...
>   (__formattable_floating_point): New concept.
>   * testsuite/std/format/functions/format.cc: Check whether
>   __float128 is supported. Also test _Float128.

> --- a/libstdc++-v3/include/std/format
> +++ b/libstdc++-v3/include/std/format

> +#elif __FLT128_DIG__ && defined(__GLIBC_PREREQ) // see floating_to_chars.cc

I'd just use here
#elif __FLT128_DIG__ && defined(_GLIBCXX_HAVE_FLOAT128_MATH)
instead.

The reason for defined(__GLIBC_PREREQ) in floating_{to,from}_chars.cc
is that I didn't want to make the ABI of linux libstdc++.so.6 dependent
on whether gcc was built against glibc 2.26+ or older glibc.
So, the symbols exist in libstdc++.so.6 even for older glibcs, but it will
actually only work properly (without losing precision; otherwise it will
just go through long double) if at runtime one uses glibc 2.26+.

But in the headers, defined(_GLIBCXX_HAVE_FLOAT128_MATH) is used everywhere
else (which is true only when compiling against glibc 2.26+).

Jakub

[committed] libstdc++: Fix std::format test for strict -std=c++20 mode

[Jonathan Wakely via Gcc-patches]

Tested x86_64-linux and x86_64-w64-mingw32. Pushed to trunk.

-- >8 --

Adjust a test to avoid using std::make_unsigned_t<__int128>. That's
ill-formed in strict modes because std::is_integral_v<__int128> is
false.

libstdc++-v3/ChangeLog:

* testsuite/std/format/functions/format.cc: Do not use
std::make_unsigned_t<__int128>.
---
 libstdc++-v3/testsuite/std/format/functions/format.cc | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/libstdc++-v3/testsuite/std/format/functions/format.cc 
b/libstdc++-v3/testsuite/std/format/functions/format.cc
index c01405eac90..8019fbdf712 100644
--- a/libstdc++-v3/testsuite/std/format/functions/format.cc
+++ b/libstdc++-v3/testsuite/std/format/functions/format.cc
@@ -233,7 +233,7 @@ test_wchar()
 void
 test_minmax()
 {
-  auto check = [](T) {
+  auto check = []>(T, U = 0) {
 const int digits = std::numeric_limits::digits;
 const std::string zeros(digits, '0');
 const std::string ones(digits, '1');
@@ -241,7 +241,6 @@ test_minmax()
 VERIFY( s == "-1" + zeros );
 s = std::format("{:b}" , std::numeric_limits::max());
 VERIFY( s == ones );
-using U = std::make_unsigned_t;
 s = std::format("{:0{}b}" , std::numeric_limits::min(), digits + 1);
 VERIFY( s == '0' + zeros );
 s = std::format("{:b}" , std::numeric_limits::max());
@@ -252,7 +251,9 @@ test_minmax()
   check(std::int32_t(0));
   check(std::int64_t(0));
 #ifdef __SIZEOF_INT128__
-  check(__int128(0));
+  // std::make_unsigned_t<__int128> is invalid for strict -std=c++20 mode,
+  // so pass a second argument of the unsigned type.
+  check(__int128(0), (unsigned __int128)(0));
 #endif
 }
 
-- 
2.38.1

[committed] libstc++: std::formattable concept should not be defined for C++20

[Jonathan Wakely via Gcc-patches]

Tested x86_64-linux and x86_64-w64-mingw32. Pushed to trunk.

-- >8 --

This concept was added by a C++23 proposal, so don't define it for
C++20.

Split the format/formatter/formatter.cc test into two parts, one that
tests the C++20 requirements and one that tests the C++23 concept.

libstdc++-v3/ChangeLog:

* include/std/format (formattable): Only define for C++23/
* testsuite/std/format/formatter.cc: Moved to...
* testsuite/std/format/formatter/requirements.cc: ...here.
* testsuite/std/format/formatter/concept.cc: New test.
* testsuite/std/format/functions/format.cc: Replace use of
std::formattable in C++20.
---
 libstdc++-v3/include/std/format   | 11 +++-
 .../testsuite/std/format/formatter/concept.cc | 46 
 .../requirements.cc}  | 54 +--
 .../testsuite/std/format/functions/format.cc  | 12 -
 4 files changed, 77 insertions(+), 46 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/std/format/formatter/concept.cc
 rename libstdc++-v3/testsuite/std/format/{formatter.cc => 
formatter/requirements.cc} (50%)

diff --git a/libstdc++-v3/include/std/format b/libstdc++-v3/include/std/format
index c79c8f2ce31..204a1710aca 100644
--- a/libstdc++-v3/include/std/format
+++ b/libstdc++-v3/include/std/format
@@ -2181,11 +2181,14 @@ namespace __format
 } // namespace __format
 /// @endcond
 
+#if __cplusplus > 202002L
   // [format.formattable], concept formattable
   template
 concept formattable
   = __format::__formattable_impl, _CharT>;
+#endif
 
+#if __cpp_lib_format_ranges
   /// @cond undocumented
 namespace __format
 {
@@ -2199,6 +2202,7 @@ namespace __format
   = conditional_t<__const_formattable_range<_Rg, _CharT>, const _Rg, _Rg>;
 } // namespace __format
   /// @endcond
+#endif // format_ranges
 
   /// An iterator after the last character written, and the number of
   /// characters that would have been written.
@@ -3485,16 +3489,19 @@ namespace __format
 
std::visit_format_arg([this](auto& __arg) {
  using _Type = remove_reference_t;
+ using _Formatter = typename _Context::template formatter_type<_Type>;
  if constexpr (is_same_v<_Type, monostate>)
__format::__invalid_arg_id_in_format_string();
  else if constexpr (is_same_v<_Type, handle>)
__arg.format(this->_M_pc, this->_M_fc);
- else
+ else if constexpr (is_default_constructible_v<_Formatter>)
{
- typename _Context::template formatter_type<_Type> __f;
+ _Formatter __f;
  this->_M_pc.advance_to(__f.parse(this->_M_pc));
  this->_M_fc.advance_to(__f.format(__arg, this->_M_fc));
}
+ else
+   static_assert(__format::__formattable_with<_Type, _Context>);
}, _M_fc.arg(__id));
   }
 };
diff --git a/libstdc++-v3/testsuite/std/format/formatter/concept.cc 
b/libstdc++-v3/testsuite/std/format/formatter/concept.cc
new file mode 100644
index 000..fe56dc44a68
--- /dev/null
+++ b/libstdc++-v3/testsuite/std/format/formatter/concept.cc
@@ -0,0 +1,46 @@
+// { dg-options "-std=gnu++23" }
+// { dg-do compile { target c++23 } }
+
+#include 
+
+struct S { };
+
+template<> struct std::formatter : std::formatter {
+  template
+  auto format(S, std::basic_format_context& ctx) const {
+return formatter::format("ess", ctx);
+  }
+};
+
+struct T { };
+
+template<> struct std::formatter : std::formatter {
+  // This function only accepts std::format_context, not other contexts.
+  auto format(T, std::format_context& ctx) const {
+return formatter::format("tee", ctx);
+  }
+};
+
+struct U { };
+
+void
+test_concept() // [format.formattable]
+{
+  static_assert( std::formattable );
+  static_assert( std::formattable );
+  static_assert( std::formattable );
+  static_assert( std::formattable );
+  static_assert( std::formattable );
+  static_assert( std::formattable );
+  static_assert( std::formattable );
+  static_assert( std::formattable );
+  static_assert( std::formattable );
+  static_assert( ! std::formattable );
+  static_assert( ! std::formattable );
+  static_assert( ! std::formattable );
+  static_assert( std::formattable );
+  static_assert( std::formattable );
+  static_assert( ! std::formattable ); // only formats as char
+  static_assert( ! std::formattable ); // formatter not generic
+  static_assert( ! std::formattable ); // no formatter
+}
diff --git a/libstdc++-v3/testsuite/std/format/formatter.cc 
b/libstdc++-v3/testsuite/std/format/formatter/requirements.cc
similarity index 50%
rename from libstdc++-v3/testsuite/std/format/formatter.cc
rename to libstdc++-v3/testsuite/std/format/formatter/requirements.cc
index 64ff2dbfbfd..3bff8bdbd5d 100644
--- a/libstdc++-v3/testsuite/std/format/formatter.cc
+++ b/libstdc++-v3/testsuite/std/format/formatter/requirements.cc
@@ -4,48 +4,6 @@
 #include 
 #include 
 
-struct S { };
-
-template<> struct 

[committed] libstdc++: Fix detection of std::format support for __float128 [PR107693]

[Jonathan Wakely via Gcc-patches]

Tested x86_64-linux and x86_64-w64-mingw32. Pushed to trunk.

-- >8 --

std::format gives linker errors on targets that define __float128 but
do not support using it with std::to_chars. This improves the handling
of 128-bit flaoting-point types so they are disabled if unsupportable.

libstdc++-v3/ChangeLog:

PR libstdc++/107693
* include/std/format (_GLIBCXX_FORMAT_F128): Define to 2 when
basic_format_arg needs to use its _M_f128 member.
(__extended_floating_point, __floating_point): Replace with ...
(__formattable_floating_point): New concept.
* testsuite/std/format/functions/format.cc: Check whether
__float128 is supported. Also test _Float128.
---
 libstdc++-v3/include/std/format   | 77 ++-
 .../testsuite/std/format/functions/format.cc  | 20 -
 2 files changed, 59 insertions(+), 38 deletions(-)

diff --git a/libstdc++-v3/include/std/format b/libstdc++-v3/include/std/format
index 1796362ceef..c79c8f2ce31 100644
--- a/libstdc++-v3/include/std/format
+++ b/libstdc++-v3/include/std/format
@@ -1213,40 +1213,35 @@ namespace __format
   _Spec<_CharT> _M_spec{};
 };
 
+  // Decide how 128-bit floating-point types should be formatted (or not).
+  // When supported, the typedef __format::__float128_t is the type that
+  // format arguments should be converted to for storage in basic_format_arg.
+  // Define the macro _GLIBCXX_FORMAT_F128 to say they're supported.
+  // _GLIBCXX_FORMAT_F128=1 means __float128, _Float128 etc. will be formatted
+  // by converting them to long double (or __ieee128 for powerpc64le).
+  // _GLIBCXX_FORMAT_F128=2 means basic_format_arg needs to enable explicit
+  // support for _Float128, rather than formatting it as another type.
+#undef _GLIBCXX_FORMAT_F128
+
 #ifdef _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT
-# define _GLIBCXX_FORMAT_F128 1
+
+  // Format 128-bit floating-point types using __ieee128.
   using __float128_t = __ieee128;
-#elif defined _GLIBCXX_LDOUBLE_IS_IEEE_BINARY128
 # define _GLIBCXX_FORMAT_F128 1
+
+#elif defined _GLIBCXX_LDOUBLE_IS_IEEE_BINARY128
+
+  // Format 128-bit floating-point types using long double.
   using __float128_t = long double;
-#elif __FLT128_DIG__
-# define _GLIBCXX_FORMAT_F128 2
+# define _GLIBCXX_FORMAT_F128 1
+
+#elif __FLT128_DIG__ && defined(__GLIBC_PREREQ) // see floating_to_chars.cc
+
+  // Format 128-bit floating-point types using _Float128.
   using __float128_t = _Float128;
-#else
-# undef _GLIBCXX_FORMAT_F128
-#endif
+# define _GLIBCXX_FORMAT_F128 2
 
-#ifdef _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT
-  template
-concept __extended_floating_point = __is_same(_Tp, _Float128)
- || __is_same(_Tp, __ibm128)
- || __is_same(_Tp, __ieee128);
-#elif _GLIBCXX_FORMAT_F128
-  template
-concept __extended_floating_point = __is_same(_Tp, __float128_t);
-#else
-  template
-concept __extended_floating_point = false;
-#endif
-
-  template
-concept __floating_point = std::floating_point<_Tp>
-|| __extended_floating_point<_Tp>;
-
-  using std::to_chars;
-
-#if _GLIBCXX_FORMAT_F128 == 2 \
-  && (__cplusplus == 202002L || !defined(_GLIBCXX_HAVE_FLOAT128_MATH))
+# if __cplusplus == 202002L || !defined(_GLIBCXX_HAVE_FLOAT128_MATH)
   // These overloads exist in the library, but are not declared for C++20.
   // Make them available as std::__format::to_chars.
   to_chars_result
@@ -1260,8 +1255,16 @@ namespace __format
   to_chars_result
   to_chars(char*, char*, _Float128, chars_format, int) noexcept
 __asm("_ZSt8to_charsPcS_DF128_St12chars_formati");
+# endif
 #endif
 
+  using std::to_chars;
+
+  // We can format a floating-point type iff it is usable with to_chars.
+  template
+concept __formattable_float = requires (_Tp __t, char* __p)
+{ __format::to_chars(__p, __p, __t, chars_format::scientific, 6); };
+
   template<__char _CharT>
 struct __formatter_fp
 {
@@ -1984,7 +1987,7 @@ namespace __format
 #endif
 
   /// Format a floating-point value.
-  template<__format::__floating_point _Tp, __format::__char _CharT>
+  template<__format::__formattable_float _Tp, __format::__char _CharT>
 struct formatter<_Tp, _CharT>
 {
   formatter() = default;
@@ -2607,7 +2610,7 @@ namespace __format
 #ifdef _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT
__ieee128 _M_f128;
__ibm128  _M_ibm128;
-#elif _GLIBCXX_FORMAT_F128
+#elif _GLIBCXX_FORMAT_F128 == 2
__float128_t _M_f128;
 #endif
   };
@@ -2663,7 +2666,7 @@ namespace __format
  else if constexpr (is_same_v<_Tp, unsigned __int128>)
return __u._M_u128;
 #endif
-#if _GLIBCXX_FORMAT_F128
+#if _GLIBCXX_FORMAT_F128 == 2
  else if constexpr (is_same_v<_Tp, __float128_t>)
return __u._M_f128;
 #endif
@@ -2843,13 +2846,15 @@ namespace __format
return type_identity<_Float64>();
 # endif
 #endif
-#ifdef __FLT128_DIG__
+#if 

Re: [PATCH] LoongArch: Fix atomic_exchange make comparison and may jump out

[Xi Ruoyao via Gcc-patches]

On Tue, 2022-11-15 at 21:03 +0800, Jinyang He wrote:
> gcc/ChangeLog:
> 
> * config/loongarch/sync.md:
> Add atomic_cas_value_exchange_and_7 and fix atomic_exchange.

nit:

* config/loongarch/sync.md (atomic_cas_value_exchange_and_7): 
New define_insn.
(atomic_exchange): Use atomic_cas_value_exchange_and_7 instead 
of atomic_cas_value_cmp_and.

> gcc/testsuite/ChangeLog:
>
> * gcc.target/loongarch/sync-1.c: New test.

Likewise, ChangeLog content should be indented with a tab. (Not 8
spaces: if my mail client changes my tab to 8 spaces I'm sorry).

/* snip */

> +  return "%G6\\n\\t"
> +    "1:\\n\\t"
> +    "ll.\\t%0,%1\\n\\t"
> +    "and\\t%7,%0,%z3\\n\\t"
> +    "or%i5\\t%7,%7,%5\\n\\t"
> +    "sc.\\t%7,%1\\n\\t"
> +    "beqz\\t%7,1b\\n\\t";

Do we need a "dbar 0x700" after beqz?

/* snip */

> diff --git a/gcc/testsuite/gcc.target/loongarch/sync-1.c 
> b/gcc/testsuite/gcc.target/loongarch/sync-1.c
> new file mode 100644
> index 0..cebed6a9b
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/loongarch/sync-1.c
> @@ -0,0 +1,104 @@
> +/* Test __sync_test_and_set in atomic_exchange */
> +/* { dg-do run } */
> +/* { dg-options "-lpthread -std=c11" } */

This test seems not deterministic.  And the use of sched_yield is very
tricky, as the man page says:

   sched_yield() is intended for use with  real-time  scheduling  policies
   (i.e., SCHED_FIFO or SCHED_RR).  Use of sched_yield() with nondetermin‐
   istic scheduling policies such as SCHED_OTHER is unspecified  and  very
   likely means your application design is broken.

I'd suggest to create a bug report at https://gcc.gnu.org/bugzilla and
post this test in the PR.  Then add the PR number into the changelog,
and just add a { dg-do compile } and { dg-final { scan-assembler ... } }
test into the testsuite to ensure the correct ll/sc loop is generated.

A bug report also emphasises that this is a bug fix, which is suitable
for GCC 13 (in stage 3 now) and GCC 12 (the fix will be backported).

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

Re: [PATCH] doc: Reword the description of -mrelax-cmpxchg-loop [PR 107676]

[Alexander Monakov via Gcc-patches]

On Tue, 15 Nov 2022, Jonathan Wakely wrote:

> > How about the following:
> >
> > When emitting a compare-and-swap loop for @ref{__sync Builtins}
> > and @ref{__atomic Builtins} lacking a native instruction, optimize
> > for the highly contended case by issuing an atomic load before the
> > @code{CMPXCHG} instruction, and invoke the @code{PAUSE} instruction
> > when restarting the loop.
> 
> That's much better, thanks. My only remaining quibble would be that
> "invoking" an instruction seems only marginally better than running
> one. Emitting? Issuing? Using? Adding?

Right, it should be 'using'; let me also add 'to save CPU power':

When emitting a compare-and-swap loop for @ref{__sync Builtins}
and @ref{__atomic Builtins} lacking a native instruction, optimize
for the highly contended case by issuing an atomic load before the
@code{CMPXCHG} instruction, and using the @code{PAUSE} instruction
to save CPU power when restarting the loop.

Alexander

Re: [PATCH] [PR68097] Try to avoid recursing for floats in tree_*_nonnegative_warnv_p.

[Aldy Hernandez via Gcc-patches]

On Mon, Nov 14, 2022 at 10:12 AM Richard Biener
 wrote:
>
> On Sat, Nov 12, 2022 at 7:30 PM Aldy Hernandez  wrote:
> >
> > It irks me that a PR named "we should track ranges for floating-point
> > hasn't been closed in this release.  This is an attempt to do just
> > that.
> >
> > As mentioned in the PR, even though we track ranges for floats, it has
> > been suggested that avoiding recursing through SSA defs in
> > gimple_assign_nonnegative_warnv_p is also a goal.  We can do this with
> > various ranger components without the need for a heavy handed approach
> > (i.e. a full ranger).
> >
> > I have implemented two versions of known_float_sign_p() that answer
> > the question whether we definitely know the sign for an operation or a
> > tree expression.
> >
> > Both versions use get_global_range_query, which is a wrapper to query
> > global ranges.  This means, that no caching or propagation is done.
> > In the case of an SSA, we just return the global range for it (think
> > SSA_NAME_RANGE_INFO).  In the case of a tree code with operands, we
> > also use get_global_range_query to resolve the operands, and then call
> > into range-ops, which is our lowest level component.  There is no
> > ranger or gori involved.  All we're doing is resolving the operation
> > with the ranges passed.
> >
> > This is enough to avoid recursing in the case where we definitely know
> > the sign of a range.  Otherwise, we still recurse.
> >
> > Note that instead of get_global_range_query(), we could use
> > get_range_query() which uses a ranger (if active in a pass), or
> > get_global_range_query if not.  This would allow passes that have an
> > active ranger (with enable_ranger) to use a full ranger.  These passes
> > are currently, VRP, loop unswitching, DOM, loop versioning, etc.  If
> > no ranger is active, get_range_query defaults to global ranges, so
> > there's no additional penalty.
> >
> > Would this be acceptable, at least enough to close (or rename the PR ;-))?
>
> I think the checks would belong to the gimple_stmt_nonnegative_warnv_p 
> function
> only (that's the SSA name entry from the fold-const.cc ones)?
>
> I also notice the use of 'bool' for the "sign".  That's not really
> descriptive.  We
> have SIGNED and UNSIGNED (aka enum signop), not sure if that's the
> perfect match vs. NEGATIVE and NONNEGATIVE.  Maybe the functions
> name is just bad and they should be known_float_negative_p?

Yeah, SIGNED and UNSIGNED doesn't seem to be much clearer than "bool signbit".

For instance, we have the following in frange:

  void set_nan (tree type, bool sign);
  void update_nan (bool sign);
  bool maybe_isnan (bool sign) const;
  bool signbit_p (bool ) const;

I'm OK changing them to enum signop if you prefer.  I'm just not
totally convinced it's more readable.

??

Aldy

Re: [PATCH Rust front-end v3 38/46] gccrs: Add HIR to GCC GENERIC lowering entry point

[Arthur Cohen]

On 11/9/22 14:53, Richard Biener wrote:

On Wed, Oct 26, 2022 at 10:37 AM  wrote:


From: Philip Herron 

This patch contains the entry point and utilities used for the lowering
of HIR nodes to `tree`s. It also contains a constant evaluator, ported
over from the C++ frontend.

Co-authored-by: David Faust 
Co-authored-by: Faisal Abbas <90.abbasfai...@gmail.com>
---
  gcc/rust/backend/rust-compile-context.cc | 146 
  gcc/rust/backend/rust-compile-context.h  | 343 ++
  gcc/rust/backend/rust-compile.cc | 414 +
  gcc/rust/backend/rust-compile.h  |  47 +++
  gcc/rust/backend/rust-constexpr.cc   | 441 +++
  gcc/rust/backend/rust-constexpr.h|  31 ++
  6 files changed, 1422 insertions(+)
  create mode 100644 gcc/rust/backend/rust-compile-context.cc
  create mode 100644 gcc/rust/backend/rust-compile-context.h
  create mode 100644 gcc/rust/backend/rust-compile.cc
  create mode 100644 gcc/rust/backend/rust-compile.h
  create mode 100644 gcc/rust/backend/rust-constexpr.cc
  create mode 100644 gcc/rust/backend/rust-constexpr.h

diff --git a/gcc/rust/backend/rust-compile-context.cc 
b/gcc/rust/backend/rust-compile-context.cc
new file mode 100644
index 000..cb2addf6c21
--- /dev/null
+++ b/gcc/rust/backend/rust-compile-context.cc
@@ -0,0 +1,146 @@
+// Copyright (C) 2020-2022 Free Software Foundation, Inc.
+
+// This file is part of GCC.
+
+// GCC is free software; you can redistribute it and/or modify it under
+// the terms of the GNU General Public License as published by the Free
+// Software Foundation; either version 3, or (at your option) any later
+// version.
+
+// GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+// WARRANTY; without even the implied warranty of MERCHANTABILITY or
+// FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+// for more details.
+
+// You should have received a copy of the GNU General Public License
+// along with GCC; see the file COPYING3.  If not see
+// .
+
+#include "rust-compile-context.h"
+#include "rust-compile-type.h"
+
+namespace Rust {
+namespace Compile {
+
+Context::Context (::Backend *backend)
+  : backend (backend), resolver (Resolver::Resolver::get ()),
+tyctx (Resolver::TypeCheckContext::get ()),
+mappings (Analysis::Mappings::get ()), mangler (Mangler ())
+{
+  setup_builtins ();
+}
+
+void
+Context::setup_builtins ()
+{
+  auto builtins = resolver->get_builtin_types ();
+  for (auto it = builtins.begin (); it != builtins.end (); it++)
+{
+  HirId ref;
+  bool ok = tyctx->lookup_type_by_node_id ((*it)->get_node_id (), );
+  rust_assert (ok);
+
+  TyTy::BaseType *lookup;
+  ok = tyctx->lookup_type (ref, );
+  rust_assert (ok);
+
+  TyTyResolveCompile::compile (this, lookup);
+}
+}
+
+hashval_t
+Context::type_hasher (tree type)
+{
+  inchash::hash hstate;
+
+  hstate.add_int (TREE_CODE (type));
+
+  if (TYPE_NAME (type))
+{
+  hashval_t record_name_hash
+   = IDENTIFIER_HASH_VALUE (DECL_NAME (TYPE_NAME (type)));
+  hstate.add_object (record_name_hash);
+}


The following does look a bit like type_hash_canon_hash.  I'll probably see what
we use tree type hashing for, just wondering here.


+  for (tree t = TYPE_ATTRIBUTES (type); t; t = TREE_CHAIN (t))
+/* Just the identifier is adequate to distinguish.  */
+hstate.add_object (IDENTIFIER_HASH_VALUE (TREE_PURPOSE (t)));
+
+  switch (TREE_CODE (type))
+{
+case METHOD_TYPE:
+  hstate.add_object (TYPE_HASH (TYPE_METHOD_BASETYPE (type)));
+  /* FALLTHROUGH. */
+case FUNCTION_TYPE:
+  for (tree t = TYPE_ARG_TYPES (type); t; t = TREE_CHAIN (t))
+   if (TREE_VALUE (t) != error_mark_node)
+ hstate.add_object (TYPE_HASH (TREE_VALUE (t)));
+  break;
+
+case OFFSET_TYPE:
+  hstate.add_object (TYPE_HASH (TYPE_OFFSET_BASETYPE (type)));
+  break;
+
+  case ARRAY_TYPE: {


GCC coding conventions would say the { goes to the next line and indented.
The rust FE might intentionally diverge from that standard, if so a
pointer in some
README in rust/ would be helpful.


This is not our intention. We would like to stick to the GCC coding 
convention, and use a `.clang-format` file to do so and apply it before 
merging any code. However it clearly has some limitations. I'll be on 
the lookout for these patterns and fix them by hand, or try and figure 
out how to edit the clang-format file.



+   if (TYPE_DOMAIN (type))
+ hstate.add_object (TYPE_HASH (TYPE_DOMAIN (type)));
+   if (!AGGREGATE_TYPE_P (TREE_TYPE (type)))
+ {
+   unsigned typeless = TYPE_TYPELESS_STORAGE (type);
+   hstate.add_object (typeless);
+ }
+  }
+  break;
+
+  case INTEGER_TYPE: {
+   tree t = TYPE_MAX_VALUE (type);
+   if (!t)
+ t = TYPE_MIN_VALUE (type);
+   for (int i = 0; i < TREE_INT_CST_NUNITS 

Re: [PATCH] doc: Reword the description of -mrelax-cmpxchg-loop [PR 107676]

[Jonathan Wakely via Gcc-patches]

On Tue, 15 Nov 2022 at 13:34, Alexander Monakov  wrote:
>
> On Tue, 15 Nov 2022, Jonathan Wakely via Gcc-patches wrote:
>
> > > @item -mrelax-cmpxchg-loop
> > > @opindex mrelax-cmpxchg-loop
> > >-Relax cmpxchg loop by emitting an early load and compare before cmpxchg,
> > >-execute pause if load value is not expected. This reduces excessive
> > >-cachline bouncing when and works for all atomic logic fetch builtins
> > >-that generates compare and swap loop.
> > >+For compare and swap loops that emitted by some __atomic_* builtins
> >
> > s/that emitted/that are emitted/
> >
> > >+(e.g. __atomic_fetch_(or|and|xor|nand) and their __atomic_*_fetch
> > >+counterparts), emit an atomic load before cmpxchg instruction. If the
> >
> > s/before cmpxchg/before the cmpxchg/
> >
> > >+loaded value is not equal to expected, execute a pause instead of
> >
> > s/not equal to expected/not equal to the expected/
> >
> > >+directly run the cmpxchg instruction. This might reduce excessive
> >
> > s/directly run/directly running/
>
> This results in "... execute a pause instead of directly running the
> cmpxchg instruction", which needs further TLC because:
>
> * 'a pause' should be 'the PAUSE instruction';
> * 'directly running [an instruction]' does not seem correct in context.
>
> The option also applies to __sync builtins, not just __atomic.
>
>
> How about the following:
>
> When emitting a compare-and-swap loop for @ref{__sync Builtins}
> and @ref{__atomic Builtins} lacking a native instruction, optimize
> for the highly contended case by issuing an atomic load before the
> @code{CMPXCHG} instruction, and invoke the @code{PAUSE} instruction
> when restarting the loop.

That's much better, thanks. My only remaining quibble would be that
"invoking" an instruction seems only marginally better than running
one. Emitting? Issuing? Using? Adding?